尧图网页设计 
Spring AI 2.0 GAJava AI 生态进入 1.x 与 2.x 并存期开发者该如何升级与选型Spring AI 2.0 GA 的落地对 Java 世界而言不只是一个版本号从 1.x 跳到 2.x。它标志着 Java AI 开发栈开始进入一个并不常见、但非常考验工程判断力的阶段主线已经跨过 GA 门槛维护线仍在滚动更新存量项目与新建项目被迫在同一段时间里做出不同选择。本文从三个可核验的一手线索出发梳理 2.0 GA 的工程含义给出 1.x/2.x 并存期的升级路径与选型框架并结合本次采集到的 Solon-AI、Agents-Flex、spring-ai-alibaba 等仓库样本观察国产 Java AI 框架的生态态势。需要先说明的是本次研究数据共 40 条仓库级记录全部heat为 0、published_at为 null且 Solon-AI、Agents-Flex、spring-ai 相关条目中存在大量镜像与 fork 的重复计数。因此本文不会给出任何最火“增速最快式结论涉及活跃度的判断一律标注为本次数据无法量化”。凡是需要官方文档或实测才能确认的内容也会明确标注为待核验。一、开篇三个信号指向同一个转折点信号一一个下游项目把 spring-ai-bom 从 2.0.0-RC2 升到 2.0.0在bonigarcia/context-engineering仓库的 PR #389 中变更标题明确写着将org.springframework.ai:spring-ai-bom从2.0.0-RC2升级到2.0.0改动路径为/ch10/spring_ai/basic_assistant[1]。这条信息的价值不在于它是一个依赖升级 PR——这类 PR 在开源生态里每天都在发生——而在于它同时提供了两个事实第一2.0.0这个 GA 版本已经可以被下游项目解析到。从2.0.0-RC2到2.0.0的推进说明 Spring AI 2.0 已经走出候选发布阶段进入了可正式消费的发布状态[1]。第二这个项目此前已经在使用2.0.0-RC2。这说明在 GA 之前已经有一部分项目愿意在 RC 阶段先行接入 2.x而 GA 之后这批项目会第一批完成收敛。RC 与 GA 在企业采纳决策中的差别恰恰是本文第二部分要展开的内容。信号二Spring AI 1.1.8 维护版照常发布spring-projects/spring-ai的 Releases 页面上存在Spring AI 1.1.8的发布条目[2]。这条信息的含义是明确的即便 2.x 已经 GA1.x 维护线并没有被立刻关闭仍在继续产生维护版本。对存量项目来说这是最实际的一条缓冲信息。它意味着不升级在当前时点并不等于失去维护团队可以按自己的节奏安排迁移而不是被迫在某个日期前完成全部改造。但必须指出1.x 维护线的官方支持期限、EOL 时间点、修复范围承诺在本次采集到的标题级数据中没有出现[2][3]。是否续期、是否只接受安全修复、是否还会引入新模型客户端都需要以官方博客、项目文档或发布说明为准本文不作推断。信号三Releases 页面本身就是一个可复用的观测工具spring-projects/spring-ai的 Releases 列表页[3]是判断当前有哪些维护线在滚动的最直接入口。对技术负责人来说养成定期查看发布页的习惯比依赖二手解读更可靠看版本号分布可以判断主版本线是否并行看发布条目的标题与标签可以判断某次发布是特性版还是维护版看各条目的先后关系可以粗略判断演进节奏。本文建议把每季度回看一次 Releases 页面写进选型委员会的例行事项原因会在最后一节展开。证据边界声明在进入正题前先把本次数据的口径钉死证据等级本文中的例子可以得出的结论硬事实标题/链接可核验PR #389 的 BOM 版本变更[1]、1.1.8 发布条目[2]版本存在、变更方向明确样本描述仓库 README 标题级Solon-AI 的 Java 8 兼容声明[4][5]、Agents-Flex 的能力清单[6]只能作为项目自称的能力面引用推断国产框架在做能力对齐定性观察不构成排名或成熟度结论数据缺失全部 40 条heat0、published_atnull不得做热度、时间、增速比较此外本次样本中 Solon-AI 相关记录约 5 条、Agents-Flex/agent-flex 相关约 8 条、spring-ai 相关 6 条以上多为镜像与 fork。出现频次只能说明在本次采集样本中集中出现不能等同于真实热度。二、Spring AI 2.0 GA 改变了什么GA 的信号价值从能用到可承诺对个人开发者而言RC 与 GA 的差别可能只是版本号的观感对企业团队而言差别是决策链条上的几个硬条件依赖锁定。构建系统通常只允许依赖已发布的稳定版本RC 版本需要额外的审批或仓库白名单。内部立项。架构评审、采购合规、供应商支持条款往往以GA 版本作为前提。长期维护预期。GA 通常意味着 API 进入稳定期后续版本在兼容性上更有约束团队投入的学习成本更可能被长期复用。生态配套。第三方 starter、向量库集成、监控与可观测组件通常在 GA 后才会密集跟进。从这个角度看PR #389 从2.0.0-RC2升到2.0.0[1]本质上是一次风险标签摘除动作项目代码可能一行未改但它在依赖治理层面从预发布通道进入了稳定通道。这类升级往往比改代码的 PR 更值得被记录因为它是团队信心变化的直接证据。依赖管理层BOM 是 2.x 迁移的第一触点spring-ai-bom的定位是统一管理 Spring AI 各模块的版本对齐。项目只需要声明 BOM 的版本不必逐个为模型客户端、向量存储、RAG、MCP 等模块指定版本号BOM 会保证它们之间互相匹配。一个典型的 Maven 引入方式如下groupId与artifactId与 PR #389 标题中的坐标一致[1]type/scope为 Maven BOM 的标准写法具体元素组合仍建议以官方文档为准dependencyManagementdependenciesdependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-bom/artifactIdversion2.0.0/versiontypepom/typescopeimport/scope/dependency/dependencies/dependencyManagementdependencies!-- 具体模块不写版本号由 BOM 对齐 --dependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-client-chat/artifactId/dependency/dependenciesGradle 侧对应的是平台依赖dependencies{implementation(platform(org.springframework.ai:spring-ai-bom:2.0.0))implementation(org.springframework.ai:spring-ai-client-chat)}这里有一个容易被低估的传导机制BOM 只有一行版本号但它牵动的是整个模块族的版本以及这些模块各自引入的传递依赖HTTP 客户端、JSON 处理、观测库等。升级 BOM 之后真正需要关注的往往不是被删掉的那一行2.0.0-RC2而是依赖树中成片变化的传递依赖版本。这也是为什么下一节把依赖树对比列为升级前的必做动作。升级基线Java、Spring Boot 的最低要求必须查官方文档这是本次写作中最需要克制的部分。Spring AI 2.x 对 JDK、Spring Boot、Spring Framework 的最低版本要求本次研究材料中没有给出任何可核验的数字。由 Spring Framework 的代际常识去反推 Spring AI 的要求是不可靠的因此本文不提供具体版本矩阵。实践上的正确做法是在启动升级前打开官方升级指南或 Spring AI 参考文档把以下四项抄写到团队的升级工单里并注明来源链接与核验日期Spring AI 2.x 要求的最低 JDK 版本2.x 适配的 Spring Boot 版本区间1.x 维护线的最低 JDK / Spring Boot 要求作为对照项目自身当前的 JDK 与 Spring Boot 版本。只有四项填齐才谈得上可以升级。很多团队的升级事故不是发生在 Spring AI 的 API 变更上而是发生在连带的 JDK 或 Spring Boot 版本跃迁上。破坏性变更与新能力自己核验的三条路径2.0 作为主版本号变更存在不兼容调整是合理预期但具体到哪些包名、接口签名、配置项、自动配置行为发生了变化本次材料没有提供 Release Notes 或 Migration Guide 的正文内容因此不能列清单。可以提供的是核验方法查官方 Release Notes 与迁移指南。这是唯一权威来源任何第三方升级踩坑清单都应与之对照后再使用。用编译器当探针。升级 BOM 后先跑一次干净编译编译错误是最精确的 API 变更定位器比通读变更日志效率更高。看依赖树与自动配置报告。行为层面的变更例如自动配置条件、默认超时、重试策略不会体现在编译错误里需要通过依赖树、启动日志和运行期行为对比来发现。三、1.x/2.x 并存期升级路径怎么做先做决策四象限判断法是否升级取决于两个维度项目阶段新建还是存量与依赖约束能否连带提升 JDK/Spring Boot。依赖可自由升级依赖被外部约束锁死新建项目直接评估 2.x把 1.x 仅作回退选项先评估 2.x 的基线是否触及约束若触及用 1.x 起步并在架构上预留升级缝存量项目制定分阶段迁移计划按本文四步走留在 1.x 维护线设定明确的重评触发条件其中依赖被锁死的典型场景包括公司 JDK 基线长期停留在较低版本、应用服务器或中间件限制了 Spring Boot 版本、多个业务系统共享同一套父 POM 且改动成本极高。“留在 1.x不是消极选择。既然 1.1.8 仍在发布[2]说明维护窗口当前并未关闭稳定性优先的团队完全可以继续使用。但需要设定触发条件当出现必须使用 2.x 独有的模型能力或 API”、“依赖方强制要求 2.x”、1.x 维护线进入 EOL 或修复响应明显变慢这三类信号之一时重新评估。升级前的影响面盘点在改任何版本号之前先把触点找全。一个使用了 Spring AI 的项目触点通常分散在四处直接依赖声明、自动配置与配置属性、模型客户端与向量库模块、业务层对 API 的调用。# 1) 找出当前所有 Spring AI 相关依赖及其版本mvn dependency:tree-Dincludesorg.springframework.ai# 2) 看看有哪些依赖存在新版本可升用于评估连带升级量mvn versions:display-dependency-updates# 3) Gradle 项目对应命令./gradlew dependencies--configurationruntimeClasspath|grepspring-ai# 4) 在业务代码中定位直接调用点粗略但有效grep-rnorg.springframework.aisrc/main/java建议把第 1 条命令的输出保存为升级前基线升级后重跑一次做 diff。BOM 升级最容易被忽略的副作用是某些传递依赖被静默提升或降级而这类变化在编译期完全无声。盘点的验收标准是能回答这次升级会碰到多少个模块、多少处业务调用、多少个配置项。回答不了就还不具备升级条件。分阶段升级的参考路径推荐拆成四步每步单独提交、单独验证第一步只动 BOM 版本号。这正是 PR #389 的做法——改动集中在版本声明先让构建系统解析到新版本[1]。这一步的验收标准是依赖能够解析成功dependency:tree输出符合预期没有意外的版本冲突。PR #389 是否还包含版本号之外的代码或测试改动需要查看该 PR 的完整 commit 与 CI 结果才能确认本文只把标题所示的版本变更作为已核验事实[1]。第二步编译修复。处理编译错误、废弃告警、包名迁移。这一步不追求功能变化只追求编译通过、测试可启动。修复过程中记录每一类变更形成团队内部的迁移笔记后续其他模块迁移时可直接复用。第三步行为回归。重点验证不体现在编译期的变化模型调用的请求/响应结构、流式输出行为、RAG 检索结果、工具调用链路、异常与超时语义。这是 AI 应用升级中风险最高、也最容易被跳过的一步。第四步新特性采纳。在前三步稳定之后再评估是否使用 2.x 的新能力。把升级和用新特性分开可以避免两类变更互相掩盖问题也便于回滚。回归验证与回滚预案AI 应用的回归难点在于输出不确定性同样的输入模型返回可能逐字不同。用传统的字符串断言做回归会立刻失效。可行的策略有三类固定变量。回归测试期间锁定模型、模型参数温度、采样等、提示词版本与工具定义把不确定性压到最低。提示词本身应纳入版本管理改提示词等同于改代码。分层断言。不断言逐字输出而是断言结构与不变量返回是否包含必需字段、引用来源是否落在预期文档集合内、工具调用序列是否符合预期、耗时是否在阈值内。录制与回放。在网络边界处录制一次真实请求/响应后续测试回放录制结果把升级验证与外部模型服务解耦。这需要在测试层引入一层可替换的调用抽象例如团队自己定义一个接口publicinterfaceChatService{ChatResultask(Stringprompt,MapString,Objectcontext);}生产实现走真实模型测试实现返回录制好的快照。这样测试断言可以写得很严格又不受外部服务波动影响。回滚预案至少要包含三条依赖版本可一键回退BOM 版本号是单点回滚成本低数据与索引格式是否变化若 2.x 涉及向量库或元数据结构调整需确认是否可双向兼容灰度策略先在一个低风险服务或模块上升级保留一段双版本运行窗口。并存期的多版本隔离手段如果组织内确实需要同时运行 1.x 与 2.x可选手段按隔离强度递增手段适用场景代价单仓库多模块 依赖约束同一应用内不同模块分批迁移依赖管理复杂需严格约束 BOM 引入点独立服务边界1.x 与 2.x 分属不同服务隔离最干净增加部署与调用成本独立构建与父 POM多团队共享基线、节奏不一致维护两套构建基线需专人跟进同一 JVM 内强行同时加载 1.x 与 2.x 的同名模块通常不是好主意包名相同的类会造成类路径冲突自动配置的条件判定也会相互干扰。除非经过专门验证否则建议用进程边界而不是类路径技巧来做隔离。四、选型策略把框架放进同一张评估表一个五维评估框架功能清单长度是最糟糕的选型指标因为几乎所有框架的 README 都会长得差不多。更有区分度的是五个维度Java 版本门槛最低 JDK 要求以及是否兼容老旧运行时。与 Spring 生态的耦合方式原生扩展、可嵌入多种容器、还是完全独立。能力覆盖模型接入、RAG、MCP、Agent 编排、多模态各自是成熟实现还是示例级。部署与运行形态是否依赖 Spring Boot、能否嵌入已有应用服务器、对云原生部署的支持。项目活跃度与治理维护主体、发布节奏、issue 响应、文档与示例质量。本次数据无 star 数与时间戳此维度无法量化必须另行核验。建议用已核验事实 / 待核验 / 无数据三态填写表格而不是打分。打分容易把未知伪装成已知。维度Spring AISolon-AIAgents-Flexspring-ai-alibabaJava 门槛待核验官方文档自述兼容 Java 8 起不同镜像声明范围不一致[4][5]待核验样本未见明确声明待核验待核验与 Spring 关系官方主线自述可嵌入 SpringBoot/jFinal/Vert.x/Quarkus[4]自述轻量、对标 Spring AI[6]与 Spring AI 的版本对应关系待核验[7][8]能力覆盖待核验官方模块清单自述含 LLM、RAG、MCP、ReAct、Team-Agent[4]自述含 RAG、MCP、Subagent、Text2SQL、多模态[6]待核验部署形态待核验自述可嵌入多种框架[4]待核验待核验活跃度无数据无数据无数据无数据Spring AI 1.x / 2.x官方主线的选择对于以 Spring 技术栈为主的团队Spring AI 通常是默认候选理由不是它更强而是整合成本最低依赖管理走 BOM、配置体系与 Spring Boot 一致、可观测与测试工具链可复用、团队的学习路径最短。在 1.x 与 2.x 之间决策规则可以简化为新项目在基线允许的前提下优先评估 2.x存量项目按第三节的四象限判断不要为了版本号本身迁移。既然 1.x 维护线仍在发布[2]就不存在必须立刻迁移的技术压力。Solon-AI宽版本兼容与多容器嵌入的差异化路线Solon-AI 的公开描述强调两点一是自述兼容 Java 8 起的宽 JDK 范围[4][5]二是可嵌入 SpringBoot、jFinal、Vert.x、Quarkus 等多种框架[4]。这两点指向的是同一个市场存量企业系统。大量企业应用长期运行在较低 JDK 版本、或运行在 Spring 之外的 Web 框架上对它们来说一个要求高版本 JDK 且强绑定 Spring 的 AI 框架是不可用的无论功能多完整。需要注意的是本次采集的不同镜像对 Java 兼容范围的描述并不一致Gitee 上的记录写的是 Java 8 至 24[5]GitHub 上的记录写的是 Java 8 至 26[4]。这更可能反映不同镜像处于不同更新时点而不是两份互相矛盾的事实。核验时应以opensolon/solon-ai官方仓库的当前文档为准而不是以镜像标题为准。对选型者的实际意义如果你的约束是必须跑在 Java 8或不想绑死 SpringSolon-AI 值得进入候选名单但其能力的实际成熟度、模块的生产可用性需要通过示例代码、测试覆盖与真实 issue 处理情况核验不能只看能力清单。Agents-Flex轻量定位与能力面扩展Agents-Flex 在本次样本中出现频次最高约 8 条记录但其中绝大多数是 fork 或镜像[6]。其公开描述把自己定位为轻量的 Java AI 智能体开发框架并明确对标 Spring AI能力清单涵盖 RAG、MCP、Skills、Text2SQL、Subagent、WebSearch、TTS/STT、图片与视频生成[6]。轻量与能力面广在工程上是一对需要审视的组合轻量通常意味着低侵入、可独立使用、不强依赖容器能力面广则意味着需要验证每项能力的实现深度。对选型者的建议是三步核验先看是否有可运行的示例工程再看关键能力如 MCP、Subagent是否有对应测试最后看 issue 列表中真实使用者提出的问题类型与响应情况。这三步比任何功能对照表都有效。spring-ai-alibaba生态位与主线的关系样本中存在多个spring-ai-alibaba仓库包括mskj-apaas/spring-ai-alibaba-2025与himdd/spring-ai-alibaba[7][8]描述均使用了 “Agentic AI Framework for Java Developers” 这类模板化表述。在确认官方仓库之前不宜基于这些镜像描述做任何成熟度判断。选型时真正要问清的是三个问题它与 Spring AI 是扩展层关系还是独立发行其版本是否跟随 Spring AI 主线尤其是 2.x 之后的对应关系维护主体与发布节奏如何如果它是 Spring AI 的上层扩展那么升级 Spring AI 时还需要同步评估该扩展层的兼容性这会让升级影响面扩大一倍必须提前纳入规划。五、国产 Java AI 框架生态态势观察以下判断基于本次 40 条仓库标题级样本属于定性观察不构成排名或成熟度结论。观察一能力清单的对齐竞赛MCP、Function Call、RAG、Embedding、多模态这些关键词在 Solon-AI、Agents-Flex、bboss-ai 等多个框架的描述中反复出现[4][5][6]。能力清单高度重叠说明两件事一是这些能力已经从差异化卖点变成了行业准入门槛不具备的框架会直接被排除二是差异化正在向别处转移包括 Java 版本门槛、容器嵌入能力、企业落地案例、以及能力的实现深度。对选型者的启发是不要再用MCP、RAG、Agent 都支持作为选型理由因为这几乎人人都支持改为追问支持到什么程度——是否有生产可用的重试与超时控制、是否有可观测埋点、是否处理了工具调用失败与幂等。观察二Java 8 基线与向下兼容成为卖点Solon-AI 自述从 Java 8 起兼容并声明可嵌入多种非 Spring 框架[4][5]EasyAi 则主打 Maven 一键引入、无额外环境配置。这类降低门槛的定位在本次样本中反复出现反映的是国内企业系统的现实约束大量存量系统短期内无法升级 JDK 或更换应用框架。这与 Spring 生态的演进方向形成一定张力——Spring 系框架通常随主版本提高基线要求。两者并不矛盾而是服务于不同阶段的系统新建系统可以追求最新基线存量系统需要向下兼容的接入方式。一个成熟的 Java AI 生态应当同时容纳这两种路径。观察三从 demo 到企业级工程化的转向本次样本中已经出现明显的企业级关注点java_rag采用 Spring Boot Spring AI OpenSearch并强调 Docker/Kubernetes 与可观测性灵梭围绕 Elasticsearch 与 ELK 生态提供spring-ai-elasticsearch-store相关能力llmchat强调 RBAC 权限体系与本地私有模型Ollama/LocalAI支持qize-spring-ai-platform关注文档切分与元数据继承。这些描述共同指向一个变化RAG 相关项目的竞争点已经从能不能跑通问答转向存储怎么选、元数据怎么管、权限怎么做、怎么私有化部署。这类工程问题恰恰是 Java 团队的强项所在也是 Java AI 框架相对于脚本语言生态可能建立优势的地方。本文只引用这些描述作为现象不评价各项目的实际成熟度。观察四企业落地叙事开始出现Lynxe 的描述称其为Manus 的 Java 实现已在阿里巴巴集团内多个应用使用用于处理有一定确定性要求的探索性任务例如从海量数据中检索并落库、日志分析告警。JManus、aimon-core 等项目则直接以 Java Agent 框架自居。“确定性要求这个词值得注意它把智能体从会聊天的助手重新定义为需要可靠产出结果的任务执行器”。对 Java 团队来说这是一个更契合自身技术积累的定位——重试、幂等、审计、监控、事务边界这些工程能力在 Java 生态里有深厚的沉淀。可以预期接下来的差异化会发生在可靠性工程而不是功能清单上。数据局限重申必须再次强调本次 40 条数据无发布时间、无热度值、无 star 数且包含大量镜像与 fork 重复计数。本文所有涉及国产框架的表述仅限于在本次采集样本的仓库描述中集中出现这一层含义不构成活跃度、用户规模或技术成熟度的判断。六、结语给三类团队的行动清单新项目团队核验 Spring AI 2.x 的最低 JDK 与 Spring Boot 要求与团队基线比对以spring-ai-bom统一管理版本锁定单点版本号便于升级与回滚用五维评估表留存一次备选框架评估记录含无数据项作为未来重评的基线从第一天起建立提示词版本管理与模型调用的可替换抽象为回归测试预留空间。存量 1.x 团队跑一次mvn dependency:tree -Dincludesorg.springframework.ai保存基线明确留在 1.x 的条件与退出触发信号2.x 独有能力需求、依赖方强制、1.x 进入 EOL每季度查看一次官方 Releases 页面[3]确认维护线状态若决定升级严格按BOM 升级 → 编译修复 → 行为回归 → 新特性采纳四步执行每步独立提交。基础架构与选型委员会维护一份统一的版本兼容矩阵数据源只认官方文档并记录核验日期把活跃度维度的数据采集补上star、commit 时间、最近版本号否则评估表永远缺一列对国产框架优先核验官方仓库归属排除镜像与 fork 的干扰在评估标准中加入可靠性工程能力重试、超时、幂等、审计、可观测。Spring AI 2.0 GA 的意义不在于它让 Java AI 开发变得更容易而在于它让 Java AI 开发变得可规划。当主线进入稳定期、维护线保持滚动团队终于可以把 AI 能力当作一项常规的依赖治理与架构演进工作来做而不是一场持续的实验。这大概是一个技术生态走向成熟的最实在的标志。参考资料[1] Bump org.springframework.ai:spring-ai-bom from 2.0.0-RC2 to 2.0.0 in /ch10/spring_ai/basic_assistantPR #389bonigarcia/context-engineeringGitHubhttps://github.com/bonigarcia/context-engineering/pull/389[2] Release Spring AI 1.1.8spring-projects/spring-aiGitHubhttps://github.com/spring-projects/spring-ai/releases/tag/v1.1.8[3] Releasesspring-projects/spring-aiGitHubhttps://github.com/spring-projects/spring-ai/releases[4] opensolon/solon-aiJava AI application development framework支持 LLM-tool/skill、RAG、MCP、Agent-ReAct、Team-Agent自述兼容 java8~java26可嵌入 SpringBoot、jFinal、Vert.x、QuarkusGitHubhttps://github.com/opensolon/solon-ai[5] AIPro/solon-aiJava AI智能体全场景应用开发框架自述兼容 java8~java24Giteehttps://gitee.com/aipro_1/solon-ai[6] 珊瑚海/Agents-FlexJava AI 智能体开发框架自述对标 Spring AI支持 RAG、MCP、Skills、Text2SQL、Subagent、WebSearch、TTS/STT、图片/视频生成Giteehttps://gitee.com/nuanxin521/agents-flex[7] mskj-apaas/spring-ai-alibaba-2025Agentic AI Framework for Java DevelopersGitHubhttps://github.com/mskj-apaas/spring-ai-alibaba-2025[8] himdd/spring-ai-alibabaAgentic AI Framework for Java DevelopersGitHubhttps://github.com/himdd/spring-ai-alibaba[9] Mu-L/spring-aiAn Application Framework for AI Engineering镜像仓库GitHubhttps://github.com/Mu-L/spring-ai[10] geekychris/java_rag基于 Spring Boot、Spring AI 与 OpenSearch 的 RAG 服务支持 Docker/Kubernetes 与可观测性GitHubhttps://github.com/geekychris/java_rag[11] 吴博/灵梭Elasticsearch 与 spring-ai-elasticsearch-store、ELK 生态相关文档Giteehttps://gitee.com/wb04307201/spring-ai-loom-agent/blob/ac4e10826b273e2b29d6983cf7653b4764a4843c/CUSTOMIZATION.zh-CN.md[12] loool/llmchatJava 生态企业级 AIGC 解决方案含 RBAC 权限体系与 Ollama/LocalAI 等本地私有模型支持Giteehttps://gitee.com/loool/llmchat[13] thubier/Lynxe自述为 Manus 的 Java 实现用于有确定性要求的探索性任务Giteehttps://gitee.com/thubier/Lynxe[14] rainerWJY/JManusAgentic AI Framework for Java DevelopersGitHubhttps://github.com/rainerWJY/JManus[15] kangwoo/aimon-coreJava 的 ReAct Agent 框架可嵌入任意 Java 应用GitHubhttps://github.com/kangwoo/aimon-core说明以上仓库链接均为本次研究数据中提供的原始链接其中第 6 至 15 条仅提供仓库描述层面的信息未包含发布日期、star 数或活跃度数据部分仓库为镜像或 fork官方归属需另行核验。Spring AI 2.0.0 的确切发布日期、Release Notes、迁移指南内容、2.x 与 1.x 的 JDK/Spring Boot 最低版本要求以及 1.x 维护线的官方支持期限本次材料中均未提供可核验内容需以官方文档为准。 Spring AI 2.0 GA：Java AI 生态进入 1.x 与 2.x 并存期，开发者该如何升级与选型
Spring AI 2.0 GAJava AI 生态进入 1.x 与 2.x 并存期开发者该如何升级与选型Spring AI 2.0 GA 的落地对 Java 世界而言不只是一个版本号从 1.x 跳到 2.x。它标志着 Java AI 开发栈开始进入一个并不常见、但非常考验工程判断力的阶段主线已经跨过 GA 门槛维护线仍在滚动更新存量项目与新建项目被迫在同一段时间里做出不同选择。本文从三个可核验的一手线索出发梳理 2.0 GA 的工程含义给出 1.x/2.x 并存期的升级路径与选型框架并结合本次采集到的 Solon-AI、Agents-Flex、spring-ai-alibaba 等仓库样本观察国产 Java AI 框架的生态态势。需要先说明的是本次研究数据共 40 条仓库级记录全部heat为 0、published_at为 null且 Solon-AI、Agents-Flex、spring-ai 相关条目中存在大量镜像与 fork 的重复计数。因此本文不会给出任何最火“增速最快式结论涉及活跃度的判断一律标注为本次数据无法量化”。凡是需要官方文档或实测才能确认的内容也会明确标注为待核验。一、开篇三个信号指向同一个转折点信号一一个下游项目把 spring-ai-bom 从 2.0.0-RC2 升到 2.0.0在bonigarcia/context-engineering仓库的 PR #389 中变更标题明确写着将org.springframework.ai:spring-ai-bom从2.0.0-RC2升级到2.0.0改动路径为/ch10/spring_ai/basic_assistant[1]。这条信息的价值不在于它是一个依赖升级 PR——这类 PR 在开源生态里每天都在发生——而在于它同时提供了两个事实第一2.0.0这个 GA 版本已经可以被下游项目解析到。从2.0.0-RC2到2.0.0的推进说明 Spring AI 2.0 已经走出候选发布阶段进入了可正式消费的发布状态[1]。第二这个项目此前已经在使用2.0.0-RC2。这说明在 GA 之前已经有一部分项目愿意在 RC 阶段先行接入 2.x而 GA 之后这批项目会第一批完成收敛。RC 与 GA 在企业采纳决策中的差别恰恰是本文第二部分要展开的内容。信号二Spring AI 1.1.8 维护版照常发布spring-projects/spring-ai的 Releases 页面上存在Spring AI 1.1.8的发布条目[2]。这条信息的含义是明确的即便 2.x 已经 GA1.x 维护线并没有被立刻关闭仍在继续产生维护版本。对存量项目来说这是最实际的一条缓冲信息。它意味着不升级在当前时点并不等于失去维护团队可以按自己的节奏安排迁移而不是被迫在某个日期前完成全部改造。但必须指出1.x 维护线的官方支持期限、EOL 时间点、修复范围承诺在本次采集到的标题级数据中没有出现[2][3]。是否续期、是否只接受安全修复、是否还会引入新模型客户端都需要以官方博客、项目文档或发布说明为准本文不作推断。信号三Releases 页面本身就是一个可复用的观测工具spring-projects/spring-ai的 Releases 列表页[3]是判断当前有哪些维护线在滚动的最直接入口。对技术负责人来说养成定期查看发布页的习惯比依赖二手解读更可靠看版本号分布可以判断主版本线是否并行看发布条目的标题与标签可以判断某次发布是特性版还是维护版看各条目的先后关系可以粗略判断演进节奏。本文建议把每季度回看一次 Releases 页面写进选型委员会的例行事项原因会在最后一节展开。证据边界声明在进入正题前先把本次数据的口径钉死证据等级本文中的例子可以得出的结论硬事实标题/链接可核验PR #389 的 BOM 版本变更[1]、1.1.8 发布条目[2]版本存在、变更方向明确样本描述仓库 README 标题级Solon-AI 的 Java 8 兼容声明[4][5]、Agents-Flex 的能力清单[6]只能作为项目自称的能力面引用推断国产框架在做能力对齐定性观察不构成排名或成熟度结论数据缺失全部 40 条heat0、published_atnull不得做热度、时间、增速比较此外本次样本中 Solon-AI 相关记录约 5 条、Agents-Flex/agent-flex 相关约 8 条、spring-ai 相关 6 条以上多为镜像与 fork。出现频次只能说明在本次采集样本中集中出现不能等同于真实热度。二、Spring AI 2.0 GA 改变了什么GA 的信号价值从能用到可承诺对个人开发者而言RC 与 GA 的差别可能只是版本号的观感对企业团队而言差别是决策链条上的几个硬条件依赖锁定。构建系统通常只允许依赖已发布的稳定版本RC 版本需要额外的审批或仓库白名单。内部立项。架构评审、采购合规、供应商支持条款往往以GA 版本作为前提。长期维护预期。GA 通常意味着 API 进入稳定期后续版本在兼容性上更有约束团队投入的学习成本更可能被长期复用。生态配套。第三方 starter、向量库集成、监控与可观测组件通常在 GA 后才会密集跟进。从这个角度看PR #389 从2.0.0-RC2升到2.0.0[1]本质上是一次风险标签摘除动作项目代码可能一行未改但它在依赖治理层面从预发布通道进入了稳定通道。这类升级往往比改代码的 PR 更值得被记录因为它是团队信心变化的直接证据。依赖管理层BOM 是 2.x 迁移的第一触点spring-ai-bom的定位是统一管理 Spring AI 各模块的版本对齐。项目只需要声明 BOM 的版本不必逐个为模型客户端、向量存储、RAG、MCP 等模块指定版本号BOM 会保证它们之间互相匹配。一个典型的 Maven 引入方式如下groupId与artifactId与 PR #389 标题中的坐标一致[1]type/scope为 Maven BOM 的标准写法具体元素组合仍建议以官方文档为准dependencyManagementdependenciesdependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-bom/artifactIdversion2.0.0/versiontypepom/typescopeimport/scope/dependency/dependencies/dependencyManagementdependencies!-- 具体模块不写版本号由 BOM 对齐 --dependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-client-chat/artifactId/dependency/dependenciesGradle 侧对应的是平台依赖dependencies{implementation(platform(org.springframework.ai:spring-ai-bom:2.0.0))implementation(org.springframework.ai:spring-ai-client-chat)}这里有一个容易被低估的传导机制BOM 只有一行版本号但它牵动的是整个模块族的版本以及这些模块各自引入的传递依赖HTTP 客户端、JSON 处理、观测库等。升级 BOM 之后真正需要关注的往往不是被删掉的那一行2.0.0-RC2而是依赖树中成片变化的传递依赖版本。这也是为什么下一节把依赖树对比列为升级前的必做动作。升级基线Java、Spring Boot 的最低要求必须查官方文档这是本次写作中最需要克制的部分。Spring AI 2.x 对 JDK、Spring Boot、Spring Framework 的最低版本要求本次研究材料中没有给出任何可核验的数字。由 Spring Framework 的代际常识去反推 Spring AI 的要求是不可靠的因此本文不提供具体版本矩阵。实践上的正确做法是在启动升级前打开官方升级指南或 Spring AI 参考文档把以下四项抄写到团队的升级工单里并注明来源链接与核验日期Spring AI 2.x 要求的最低 JDK 版本2.x 适配的 Spring Boot 版本区间1.x 维护线的最低 JDK / Spring Boot 要求作为对照项目自身当前的 JDK 与 Spring Boot 版本。只有四项填齐才谈得上可以升级。很多团队的升级事故不是发生在 Spring AI 的 API 变更上而是发生在连带的 JDK 或 Spring Boot 版本跃迁上。破坏性变更与新能力自己核验的三条路径2.0 作为主版本号变更存在不兼容调整是合理预期但具体到哪些包名、接口签名、配置项、自动配置行为发生了变化本次材料没有提供 Release Notes 或 Migration Guide 的正文内容因此不能列清单。可以提供的是核验方法查官方 Release Notes 与迁移指南。这是唯一权威来源任何第三方升级踩坑清单都应与之对照后再使用。用编译器当探针。升级 BOM 后先跑一次干净编译编译错误是最精确的 API 变更定位器比通读变更日志效率更高。看依赖树与自动配置报告。行为层面的变更例如自动配置条件、默认超时、重试策略不会体现在编译错误里需要通过依赖树、启动日志和运行期行为对比来发现。三、1.x/2.x 并存期升级路径怎么做先做决策四象限判断法是否升级取决于两个维度项目阶段新建还是存量与依赖约束能否连带提升 JDK/Spring Boot。依赖可自由升级依赖被外部约束锁死新建项目直接评估 2.x把 1.x 仅作回退选项先评估 2.x 的基线是否触及约束若触及用 1.x 起步并在架构上预留升级缝存量项目制定分阶段迁移计划按本文四步走留在 1.x 维护线设定明确的重评触发条件其中依赖被锁死的典型场景包括公司 JDK 基线长期停留在较低版本、应用服务器或中间件限制了 Spring Boot 版本、多个业务系统共享同一套父 POM 且改动成本极高。“留在 1.x不是消极选择。既然 1.1.8 仍在发布[2]说明维护窗口当前并未关闭稳定性优先的团队完全可以继续使用。但需要设定触发条件当出现必须使用 2.x 独有的模型能力或 API”、“依赖方强制要求 2.x”、1.x 维护线进入 EOL 或修复响应明显变慢这三类信号之一时重新评估。升级前的影响面盘点在改任何版本号之前先把触点找全。一个使用了 Spring AI 的项目触点通常分散在四处直接依赖声明、自动配置与配置属性、模型客户端与向量库模块、业务层对 API 的调用。# 1) 找出当前所有 Spring AI 相关依赖及其版本mvn dependency:tree-Dincludesorg.springframework.ai# 2) 看看有哪些依赖存在新版本可升用于评估连带升级量mvn versions:display-dependency-updates# 3) Gradle 项目对应命令./gradlew dependencies--configurationruntimeClasspath|grepspring-ai# 4) 在业务代码中定位直接调用点粗略但有效grep-rnorg.springframework.aisrc/main/java建议把第 1 条命令的输出保存为升级前基线升级后重跑一次做 diff。BOM 升级最容易被忽略的副作用是某些传递依赖被静默提升或降级而这类变化在编译期完全无声。盘点的验收标准是能回答这次升级会碰到多少个模块、多少处业务调用、多少个配置项。回答不了就还不具备升级条件。分阶段升级的参考路径推荐拆成四步每步单独提交、单独验证第一步只动 BOM 版本号。这正是 PR #389 的做法——改动集中在版本声明先让构建系统解析到新版本[1]。这一步的验收标准是依赖能够解析成功dependency:tree输出符合预期没有意外的版本冲突。PR #389 是否还包含版本号之外的代码或测试改动需要查看该 PR 的完整 commit 与 CI 结果才能确认本文只把标题所示的版本变更作为已核验事实[1]。第二步编译修复。处理编译错误、废弃告警、包名迁移。这一步不追求功能变化只追求编译通过、测试可启动。修复过程中记录每一类变更形成团队内部的迁移笔记后续其他模块迁移时可直接复用。第三步行为回归。重点验证不体现在编译期的变化模型调用的请求/响应结构、流式输出行为、RAG 检索结果、工具调用链路、异常与超时语义。这是 AI 应用升级中风险最高、也最容易被跳过的一步。第四步新特性采纳。在前三步稳定之后再评估是否使用 2.x 的新能力。把升级和用新特性分开可以避免两类变更互相掩盖问题也便于回滚。回归验证与回滚预案AI 应用的回归难点在于输出不确定性同样的输入模型返回可能逐字不同。用传统的字符串断言做回归会立刻失效。可行的策略有三类固定变量。回归测试期间锁定模型、模型参数温度、采样等、提示词版本与工具定义把不确定性压到最低。提示词本身应纳入版本管理改提示词等同于改代码。分层断言。不断言逐字输出而是断言结构与不变量返回是否包含必需字段、引用来源是否落在预期文档集合内、工具调用序列是否符合预期、耗时是否在阈值内。录制与回放。在网络边界处录制一次真实请求/响应后续测试回放录制结果把升级验证与外部模型服务解耦。这需要在测试层引入一层可替换的调用抽象例如团队自己定义一个接口publicinterfaceChatService{ChatResultask(Stringprompt,MapString,Objectcontext);}生产实现走真实模型测试实现返回录制好的快照。这样测试断言可以写得很严格又不受外部服务波动影响。回滚预案至少要包含三条依赖版本可一键回退BOM 版本号是单点回滚成本低数据与索引格式是否变化若 2.x 涉及向量库或元数据结构调整需确认是否可双向兼容灰度策略先在一个低风险服务或模块上升级保留一段双版本运行窗口。并存期的多版本隔离手段如果组织内确实需要同时运行 1.x 与 2.x可选手段按隔离强度递增手段适用场景代价单仓库多模块 依赖约束同一应用内不同模块分批迁移依赖管理复杂需严格约束 BOM 引入点独立服务边界1.x 与 2.x 分属不同服务隔离最干净增加部署与调用成本独立构建与父 POM多团队共享基线、节奏不一致维护两套构建基线需专人跟进同一 JVM 内强行同时加载 1.x 与 2.x 的同名模块通常不是好主意包名相同的类会造成类路径冲突自动配置的条件判定也会相互干扰。除非经过专门验证否则建议用进程边界而不是类路径技巧来做隔离。四、选型策略把框架放进同一张评估表一个五维评估框架功能清单长度是最糟糕的选型指标因为几乎所有框架的 README 都会长得差不多。更有区分度的是五个维度Java 版本门槛最低 JDK 要求以及是否兼容老旧运行时。与 Spring 生态的耦合方式原生扩展、可嵌入多种容器、还是完全独立。能力覆盖模型接入、RAG、MCP、Agent 编排、多模态各自是成熟实现还是示例级。部署与运行形态是否依赖 Spring Boot、能否嵌入已有应用服务器、对云原生部署的支持。项目活跃度与治理维护主体、发布节奏、issue 响应、文档与示例质量。本次数据无 star 数与时间戳此维度无法量化必须另行核验。建议用已核验事实 / 待核验 / 无数据三态填写表格而不是打分。打分容易把未知伪装成已知。维度Spring AISolon-AIAgents-Flexspring-ai-alibabaJava 门槛待核验官方文档自述兼容 Java 8 起不同镜像声明范围不一致[4][5]待核验样本未见明确声明待核验待核验与 Spring 关系官方主线自述可嵌入 SpringBoot/jFinal/Vert.x/Quarkus[4]自述轻量、对标 Spring AI[6]与 Spring AI 的版本对应关系待核验[7][8]能力覆盖待核验官方模块清单自述含 LLM、RAG、MCP、ReAct、Team-Agent[4]自述含 RAG、MCP、Subagent、Text2SQL、多模态[6]待核验部署形态待核验自述可嵌入多种框架[4]待核验待核验活跃度无数据无数据无数据无数据Spring AI 1.x / 2.x官方主线的选择对于以 Spring 技术栈为主的团队Spring AI 通常是默认候选理由不是它更强而是整合成本最低依赖管理走 BOM、配置体系与 Spring Boot 一致、可观测与测试工具链可复用、团队的学习路径最短。在 1.x 与 2.x 之间决策规则可以简化为新项目在基线允许的前提下优先评估 2.x存量项目按第三节的四象限判断不要为了版本号本身迁移。既然 1.x 维护线仍在发布[2]就不存在必须立刻迁移的技术压力。Solon-AI宽版本兼容与多容器嵌入的差异化路线Solon-AI 的公开描述强调两点一是自述兼容 Java 8 起的宽 JDK 范围[4][5]二是可嵌入 SpringBoot、jFinal、Vert.x、Quarkus 等多种框架[4]。这两点指向的是同一个市场存量企业系统。大量企业应用长期运行在较低 JDK 版本、或运行在 Spring 之外的 Web 框架上对它们来说一个要求高版本 JDK 且强绑定 Spring 的 AI 框架是不可用的无论功能多完整。需要注意的是本次采集的不同镜像对 Java 兼容范围的描述并不一致Gitee 上的记录写的是 Java 8 至 24[5]GitHub 上的记录写的是 Java 8 至 26[4]。这更可能反映不同镜像处于不同更新时点而不是两份互相矛盾的事实。核验时应以opensolon/solon-ai官方仓库的当前文档为准而不是以镜像标题为准。对选型者的实际意义如果你的约束是必须跑在 Java 8或不想绑死 SpringSolon-AI 值得进入候选名单但其能力的实际成熟度、模块的生产可用性需要通过示例代码、测试覆盖与真实 issue 处理情况核验不能只看能力清单。Agents-Flex轻量定位与能力面扩展Agents-Flex 在本次样本中出现频次最高约 8 条记录但其中绝大多数是 fork 或镜像[6]。其公开描述把自己定位为轻量的 Java AI 智能体开发框架并明确对标 Spring AI能力清单涵盖 RAG、MCP、Skills、Text2SQL、Subagent、WebSearch、TTS/STT、图片与视频生成[6]。轻量与能力面广在工程上是一对需要审视的组合轻量通常意味着低侵入、可独立使用、不强依赖容器能力面广则意味着需要验证每项能力的实现深度。对选型者的建议是三步核验先看是否有可运行的示例工程再看关键能力如 MCP、Subagent是否有对应测试最后看 issue 列表中真实使用者提出的问题类型与响应情况。这三步比任何功能对照表都有效。spring-ai-alibaba生态位与主线的关系样本中存在多个spring-ai-alibaba仓库包括mskj-apaas/spring-ai-alibaba-2025与himdd/spring-ai-alibaba[7][8]描述均使用了 “Agentic AI Framework for Java Developers” 这类模板化表述。在确认官方仓库之前不宜基于这些镜像描述做任何成熟度判断。选型时真正要问清的是三个问题它与 Spring AI 是扩展层关系还是独立发行其版本是否跟随 Spring AI 主线尤其是 2.x 之后的对应关系维护主体与发布节奏如何如果它是 Spring AI 的上层扩展那么升级 Spring AI 时还需要同步评估该扩展层的兼容性这会让升级影响面扩大一倍必须提前纳入规划。五、国产 Java AI 框架生态态势观察以下判断基于本次 40 条仓库标题级样本属于定性观察不构成排名或成熟度结论。观察一能力清单的对齐竞赛MCP、Function Call、RAG、Embedding、多模态这些关键词在 Solon-AI、Agents-Flex、bboss-ai 等多个框架的描述中反复出现[4][5][6]。能力清单高度重叠说明两件事一是这些能力已经从差异化卖点变成了行业准入门槛不具备的框架会直接被排除二是差异化正在向别处转移包括 Java 版本门槛、容器嵌入能力、企业落地案例、以及能力的实现深度。对选型者的启发是不要再用MCP、RAG、Agent 都支持作为选型理由因为这几乎人人都支持改为追问支持到什么程度——是否有生产可用的重试与超时控制、是否有可观测埋点、是否处理了工具调用失败与幂等。观察二Java 8 基线与向下兼容成为卖点Solon-AI 自述从 Java 8 起兼容并声明可嵌入多种非 Spring 框架[4][5]EasyAi 则主打 Maven 一键引入、无额外环境配置。这类降低门槛的定位在本次样本中反复出现反映的是国内企业系统的现实约束大量存量系统短期内无法升级 JDK 或更换应用框架。这与 Spring 生态的演进方向形成一定张力——Spring 系框架通常随主版本提高基线要求。两者并不矛盾而是服务于不同阶段的系统新建系统可以追求最新基线存量系统需要向下兼容的接入方式。一个成熟的 Java AI 生态应当同时容纳这两种路径。观察三从 demo 到企业级工程化的转向本次样本中已经出现明显的企业级关注点java_rag采用 Spring Boot Spring AI OpenSearch并强调 Docker/Kubernetes 与可观测性灵梭围绕 Elasticsearch 与 ELK 生态提供spring-ai-elasticsearch-store相关能力llmchat强调 RBAC 权限体系与本地私有模型Ollama/LocalAI支持qize-spring-ai-platform关注文档切分与元数据继承。这些描述共同指向一个变化RAG 相关项目的竞争点已经从能不能跑通问答转向存储怎么选、元数据怎么管、权限怎么做、怎么私有化部署。这类工程问题恰恰是 Java 团队的强项所在也是 Java AI 框架相对于脚本语言生态可能建立优势的地方。本文只引用这些描述作为现象不评价各项目的实际成熟度。观察四企业落地叙事开始出现Lynxe 的描述称其为Manus 的 Java 实现已在阿里巴巴集团内多个应用使用用于处理有一定确定性要求的探索性任务例如从海量数据中检索并落库、日志分析告警。JManus、aimon-core 等项目则直接以 Java Agent 框架自居。“确定性要求这个词值得注意它把智能体从会聊天的助手重新定义为需要可靠产出结果的任务执行器”。对 Java 团队来说这是一个更契合自身技术积累的定位——重试、幂等、审计、监控、事务边界这些工程能力在 Java 生态里有深厚的沉淀。可以预期接下来的差异化会发生在可靠性工程而不是功能清单上。数据局限重申必须再次强调本次 40 条数据无发布时间、无热度值、无 star 数且包含大量镜像与 fork 重复计数。本文所有涉及国产框架的表述仅限于在本次采集样本的仓库描述中集中出现这一层含义不构成活跃度、用户规模或技术成熟度的判断。六、结语给三类团队的行动清单新项目团队核验 Spring AI 2.x 的最低 JDK 与 Spring Boot 要求与团队基线比对以spring-ai-bom统一管理版本锁定单点版本号便于升级与回滚用五维评估表留存一次备选框架评估记录含无数据项作为未来重评的基线从第一天起建立提示词版本管理与模型调用的可替换抽象为回归测试预留空间。存量 1.x 团队跑一次mvn dependency:tree -Dincludesorg.springframework.ai保存基线明确留在 1.x 的条件与退出触发信号2.x 独有能力需求、依赖方强制、1.x 进入 EOL每季度查看一次官方 Releases 页面[3]确认维护线状态若决定升级严格按BOM 升级 → 编译修复 → 行为回归 → 新特性采纳四步执行每步独立提交。基础架构与选型委员会维护一份统一的版本兼容矩阵数据源只认官方文档并记录核验日期把活跃度维度的数据采集补上star、commit 时间、最近版本号否则评估表永远缺一列对国产框架优先核验官方仓库归属排除镜像与 fork 的干扰在评估标准中加入可靠性工程能力重试、超时、幂等、审计、可观测。Spring AI 2.0 GA 的意义不在于它让 Java AI 开发变得更容易而在于它让 Java AI 开发变得可规划。当主线进入稳定期、维护线保持滚动团队终于可以把 AI 能力当作一项常规的依赖治理与架构演进工作来做而不是一场持续的实验。这大概是一个技术生态走向成熟的最实在的标志。参考资料[1] Bump org.springframework.ai:spring-ai-bom from 2.0.0-RC2 to 2.0.0 in /ch10/spring_ai/basic_assistantPR #389bonigarcia/context-engineeringGitHubhttps://github.com/bonigarcia/context-engineering/pull/389[2] Release Spring AI 1.1.8spring-projects/spring-aiGitHubhttps://github.com/spring-projects/spring-ai/releases/tag/v1.1.8[3] Releasesspring-projects/spring-aiGitHubhttps://github.com/spring-projects/spring-ai/releases[4] opensolon/solon-aiJava AI application development framework支持 LLM-tool/skill、RAG、MCP、Agent-ReAct、Team-Agent自述兼容 java8~java26可嵌入 SpringBoot、jFinal、Vert.x、QuarkusGitHubhttps://github.com/opensolon/solon-ai[5] AIPro/solon-aiJava AI智能体全场景应用开发框架自述兼容 java8~java24Giteehttps://gitee.com/aipro_1/solon-ai[6] 珊瑚海/Agents-FlexJava AI 智能体开发框架自述对标 Spring AI支持 RAG、MCP、Skills、Text2SQL、Subagent、WebSearch、TTS/STT、图片/视频生成Giteehttps://gitee.com/nuanxin521/agents-flex[7] mskj-apaas/spring-ai-alibaba-2025Agentic AI Framework for Java DevelopersGitHubhttps://github.com/mskj-apaas/spring-ai-alibaba-2025[8] himdd/spring-ai-alibabaAgentic AI Framework for Java DevelopersGitHubhttps://github.com/himdd/spring-ai-alibaba[9] Mu-L/spring-aiAn Application Framework for AI Engineering镜像仓库GitHubhttps://github.com/Mu-L/spring-ai[10] geekychris/java_rag基于 Spring Boot、Spring AI 与 OpenSearch 的 RAG 服务支持 Docker/Kubernetes 与可观测性GitHubhttps://github.com/geekychris/java_rag[11] 吴博/灵梭Elasticsearch 与 spring-ai-elasticsearch-store、ELK 生态相关文档Giteehttps://gitee.com/wb04307201/spring-ai-loom-agent/blob/ac4e10826b273e2b29d6983cf7653b4764a4843c/CUSTOMIZATION.zh-CN.md[12] loool/llmchatJava 生态企业级 AIGC 解决方案含 RBAC 权限体系与 Ollama/LocalAI 等本地私有模型支持Giteehttps://gitee.com/loool/llmchat[13] thubier/Lynxe自述为 Manus 的 Java 实现用于有确定性要求的探索性任务Giteehttps://gitee.com/thubier/Lynxe[14] rainerWJY/JManusAgentic AI Framework for Java DevelopersGitHubhttps://github.com/rainerWJY/JManus[15] kangwoo/aimon-coreJava 的 ReAct Agent 框架可嵌入任意 Java 应用GitHubhttps://github.com/kangwoo/aimon-core说明以上仓库链接均为本次研究数据中提供的原始链接其中第 6 至 15 条仅提供仓库描述层面的信息未包含发布日期、star 数或活跃度数据部分仓库为镜像或 fork官方归属需另行核验。Spring AI 2.0.0 的确切发布日期、Release Notes、迁移指南内容、2.x 与 1.x 的 JDK/Spring Boot 最低版本要求以及 1.x 维护线的官方支持期限本次材料中均未提供可核验内容需以官方文档为准。