这两天看到一些文章和社区讨论，挺吓人——大意是：AI 开发的范式已经转向 Harness 了，Spring AI Alibaba 这个项目，已经放弃维护了。文章说 SAA 正式版半年没发，社区开始讨论要不要换框架，结尾顺势推荐了几个替代品。
我把它的 GitHub 翻了一上午。结论先放在这：传闻一半是真的——版本确实停了；但另一半的真相比停更有意思：阿里不是弃坑，是在给 SAA 换心脏。
本文基于 Spring AI Alibaba 1.1.2.2 / 2.0.0-M1.1 与 AgentScope Java 2.0.3（均为截至 2026-09-14 的最新版本）编写，事实核查自 GitHub Releases、commit 记录与 java2ai.com 官方博客。开源项目动向变化快，请以官方渠道为准。
半年没发正式版，这部分传闻是真的
第一层证据看 Release。打开 spring-ai-alibaba 的 Releases 页面，最新正式版是 v1.1.2.2，2026 年 3 月 10 日——到今天整整半年，没有新的正式版。再往下翻，唯一的动静是 6 月 25 日发了个预发布版 v2.0.0-M1.1（跟进 Spring AI 2.0.0-M1 + Boot 4.0），然后又是两个多月的安静。
半年不发正式版，对一个 10.8k stars 的项目来说确实反常，传闻的这部分站得住。
但这里有个细节值得玩味。这个"半年来唯一的大版本" v1.1.2.2，翻它的发布说明，最大新特性是什么？首次引入 AgentScope Java 集成——新增 spring-ai-alibaba-starter-agentscope，用一个 AgentScopeAgent 把 AgentScope 的 ReActAgent 封装成 BaseAgent，塞进 SAA 的 Graph 工作流里编排。
翻译一下：SAA 停更静默前的最后一个大动作，是"接 AgentScope"。一个被传"放弃维护"的项目，最后一次大更新是在拥抱自家兄弟框架——这不像弃坑，倒像交接前的铺路。
8 月的 GitHub 比传闻热闹，9 月突然安静了
第二层证据看 commit，传闻的另一半在这里露出破绽。
main 分支最新一条提交停在 2026 年 8 月 25 日，但往前翻，7 月 24 日到 8 月 25 日这一个月合了 35 个 PR，8 月 24 日单日合了 8 个。v1.1.2.2 发布之后到现在，main 上总共合了 137 个提交。这不是一个被放弃的仓库该有的样子。
那 8 月底到现在这三周的空窗呢？看内容就知道怎么回事：这两个月的提交以修复和测试为主——Graph 序列化的修复、Admin 控制台的中文化、JUnit 5 迁移、文档链接修正，没有一条大的功能主线。项目在"养护"，不在"建设"。
这里有个彩蛋：7 月底的三条提交，co-author 署名是 claude。AI 在给 AI 框架修 bug，2026 年的开源项目已经长这样了。
真正扎眼的不是 SAA 慢，是对比。同一个阿里，AgentScope Java 的节奏是 2.0.2（9 月 3 日）→ 2.0.3（9 月 7 日），四天一个版本；SAA 正式版半年一发。一边周更，一边半年更——资源往哪倾斜，肉眼可见。
官方博客里那句话，比停更传闻狠多了
第三层证据最关键，也最少人去看：官方自己一年前就把答案写好了。
java2ai.com 上有一篇官方公告，《一文讲透 Spring AI Alibaba 与 AgentScope 的定位与区别》，发布在 AgentScope-Java 2025 年 9 月开源后不久。公告里说得很直白：开放框架呈现两种趋势，SAA 以 Graph 为核心（工作流编排），AgentScope 以 Agentic 为核心（最大化利用基础模型能力），"两种设计理念都将是企业主流选择"，两者独立发展、不存在替代关系。然后是关键句：
未来 Spring AI Alibaba 生态将在底层全面支持 AgentScope，提供 AgentScope Starter、AgentScope Runtime Starter。
同期的 Admin 平台开源博文说得更进一步："Spring AI Alibaba 后续会把内核升级为 AgentScope。"
把这两句和 GitHub 上的事实拼起来，整个图景就清楚了：v1.1.2.2 接入 AgentScope starter 是第一步（铺路），AgentScope 那边狂奔式的周更是第二步（造心脏），SAA 这边正式版停滞但 Graph 修复不断是第三步（养护外壳）。停更的表象下面，是一份官方早就写好的合并路线图在执行。
我拆 AgentScope Java 2.0 的时候写过这个官方口径，当时留了个钩子说"这个话题值得单独写一篇"——就是今天这篇。
不是弃坑，是分工：发动机和外壳
为什么阿里要这么干？那篇公众号文章里有个判断我认同一半：AI 开发的关注点确实在从"怎么编排步骤"转向 Harness 这一层——上下文管理、工具执行约束、任务中断后怎么恢复。
我认同一半的原因是：它把这当成了 SAA 的绝症，但官方把这当成了分工。
Harness 这层恰好是 AgentScope 的主场。它在 2026 年 5 月的 v1.1 里引入 HarnessAgent，2.0 GA 把记忆体系、权限三态决策、人工审批（HITL）、沙箱、会话持久化全部做成了默认能力。我在手搓企业智能体系列里连踩四个集的坑，全在这一层：E03 第 50 轮对话翻车，翻在记忆压缩丢了时序；E04 的 RAG 被官方标记废弃，被迫走扩展包。这些问题在"工作流编排"框架里根本不是一等公民——Graph 关心节点和边，Agent 关心上下文和记忆，两个范式要的能力不一样。
阿里的解法是不让一个框架装两颗心脏：Workflow 编排留给 SAA 的 Graph（它确实在企业场景规模化落地了），Agentic 全押 AgentScope，SAA 未来通过 starter 把 AgentScope 装进 Spring 生态。发动机和外壳，各造各的。
所以"SAA 停更"的正确读法是：SAA 从"全家桶框架"收缩为"Spring 生态的工作流外壳 + Admin 平台"，Agent 引擎的活交给了 AgentScope。 阿里不是在放弃项目，是在避免重复造轮子。
选型判断：你的团队在哪一档
证据看完了，给结论。
第一档：生产在跑 SAA 1.x 的——不用慌。 Graph 工作流是官方明确继续投入的方向（v1.1.2.2 后那 137 个提交大部分在修 Graph 的序列化和 checkpoint），Boot 3.5 线稳定。心态上做个调整：把 SAA 当"工作流引擎"用，别再把它当"Agent 框架"用，新立项的 Agent 能力规划别押在它身上。
第二档：新立项、Agent 自主性优先的——直接上 AgentScope Java。 别等 SAA 2.0——它 2.0 的看点本来就是"内核换成 AgentScope"，你等于在等一件 AgentScope 的 Spring Boot 外套。真离不开 Spring 生态，SAA + AgentScope 的组合路线官方 starter 已经能跑。我上周刚串过这条链路（Nacos AI Registry 实操，SAA 1.0.0.4 做注册端、AgentScope 2.0.1 做消费端）：SAA 那半边的体感是顺的——一个 @Configuration 类把 ReactAgent 装起来，spring.ai.alibaba.a2a 配置块写好元数据，启动就自动注册进 Nacos。写惯了 Eureka 的微服务老兵对这一步零学习成本，"Spring 外壳"这个角色它接得住。
但我得说实话，组合路线第一天就撞了个坑：两个框架各自锁了不同版本的底层 a2a-java-sdk——SAA 锁 0.2.5.Beta2，AgentScope 锁 0.3.3.Final，同一个时间戳字段一边 LocalDateTime 一边 OffsetDateTime，链路一跑直接抛 InvalidFormatException，最后写了 30 行兼容代码才通。协议相同不等于互操作成功，组合路线可行，但成本藏在两边各自锁定的依赖细节里——官方"底层全面支持"真正落地之前，这条经验都有效。
第三档：观望党——盯两个节点。 一是 SAA 2.0 正式版（M1.1 已跟进 Boot 4，正式版应该不远），定"外壳"的成熟度；二是 AgentScope Starter / Runtime Starter 的正式形态，定两边融合的实际姿势。这俩落地之前，观望是合理的。
最后说回那篇传闻文章。它把 SAA 的状态定性成"放弃维护"，我查下来 commit 活着、官方路线图活着、Graph 的修复还在合。但它逼问的那个问题是真的，每个选框架的人都该借机想一遍：你选的到底是框架的功能，还是框架的路线？功能会停更，路线不会骗人。
参考来源：
