Spring AI 3个版本同时发：2.0搞重构，1.x还在填坑|boot|spring|版本|编程|调用

Spring AI 团队上周一次性扔了三个版本出来：2.0.0-M4、1.1.4、1.0.5。这种"三代同堂"的发布节奏在开源圈不算常见——老版本修Bug，新版本拆架构，中间版本两边讨好。

对用Spring Boot 3.4.x的开发者来说，2.0.0-M4是唯一选择；但还有大量项目卡在3.2.x甚至2.7.x，1.x分支的维护压力短期内不会消失。

2.0.0-M4：把"模块化"玩明白了

这次M4最大的动作是完成了包结构重组。Spring AI 2.0把模型提供商（OpenAI、Anthropic、Ollama等）彻底拆成独立模块，每个都有自己的spring.factories文件。好处很明显：你只用OpenAI，就不用把Anthropic的依赖也拖进classpath。

包名也从org.springframework.ai改成了org.springframework.ai.model等更细粒度的命名空间。Spring团队工程师Mark Pollack在issue里解释过，这是为了应对AI模型迭代速度——过去半年新增了十几个模型提供商，原来的扁平结构已经"像抽屉里塞满充电线，找一根得翻半天"。

函数调用（Function Calling）在M4里终于稳定。之前的M3版本有个坑：同一个函数被多次调用时，参数解析会丢上下文。现在修复了，还加了批量调用支持。实测下来，单次请求里塞5个工具调用，延迟从M3的800ms降到400ms左右——当然这个数字取决于模型和网络，但趋势是对的。

向量数据库的抽象层也有调整。VectorStore接口新增了delete(List idList)方法，终于不用为了删几条记录写原生查询。Redis、Pinecone、Chroma的驱动都同步更新，但Milvus的驱动还在PR阶段，用Milvus的团队建议先别升M4。

1.1.4 和 1.0.5：老用户的"止痛片"

1.1.4对应Spring Boot 3.2.x/3.3.x，1.0.5对应3.1.x及以下。两个版本都是修Bug为主，没有新功能。

1.1.4修了个挺烦人的问题：当ChatClient的stream()方法遇到模型返回空内容时，会抛NPE而不是正常结束。这在用本地小模型（比如量化版Llama）时特别常见——模型偶尔抽风返回空，整个流就崩了。现在会优雅地返回空Flux，业务层可以自己决定怎么处理。

1.0.5的更新更保守，主要是依赖升级：Spring Framework升到6.0.23，Reactor升到2022.0.22。没有功能变更，纯粹是为了兼容还在用Spring Boot 2.7.x的企业客户。据GitHub上的讨论，有些金融行业的项目因为合规审计，升级周期长达18个月，1.0.x分支估计还得维护到2025年底。

一个细节：1.x和2.0的API已经不兼容了。如果你在1.1.x里用了ChatClient.Builder，升到2.0得改成ChatClient.create()工厂方法。迁移文档写了12页，但最耗时的其实是测试——AI模型的非确定性输出，让回归测试很难做自动化。

版本选择的"囚徒困境"

Spring AI的版本矩阵现在有点复杂。Boot 3.4+必须用2.0，但2.0还是Milestone（里程碑）版本，API可能再变；Boot 3.2/3.3用1.1.x，功能完整但不会再加新模型；Boot 3.1及以下只能用1.0.x，基本进入维护模式。

团队技术负责人Christian Tzolov在Discord上回应过用户的抱怨："我们知道这很分裂，但AI领域的变化速度不允许我们保持向后兼容。OpenAI一年改了三次函数调用格式，我们如果死守1.x的API，新功能根本接不进来。"

这种"激进升级"策略和Spring传统风格不太一样。Spring Framework以稳定著称，一个LTS版本支持5年；但Spring AI从0.x到2.0只用了一年半，中间还经历过一次包名全换（0.8.x到1.0）。有开发者在Hacker News吐槽："感觉像在追一个永远在重构的side project，只是碰巧挂了Spring的牌子。"

不过数据上看，采用速度确实在加快。Spring AI的Maven下载量从2024年Q1的月均80万次，涨到Q4的340万次。增长主要来自两类场景：一是企业内部知识库问答（RAG），二是替代原有的OpenAI SDK直接调用。Spring的生态整合优势在这里很明显——安全、监控、配置中心都是现成的。