企业官网建设流程全解析

Spring AI 2.0 GA：Java 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 已经 GA，1.x 维护线并没有被立刻关闭，仍在继续产生维护版本。

对存量项目来说，这是最实际的一条缓冲信息。它意味着"不升级"在当前时点并不等于"失去维护"，团队可以按自己的节奏安排迁移，而不是被迫在某个日期前完成全部改造。

但必须指出：1.x 维护线的官方支持期限、EOL 时间点、修复范围承诺，在本次采集到的标题级数据中没有出现[2][3]。是否续期、是否只接受安全修复、是否还会引入新模型客户端，都需要以官方博客、项目文档或发布说明为准，本文不作推断。

信号三：Releases 页面本身就是一个可复用的观测工具

spring-projects/spring-ai的 Releases 列表页[3]，是判断"当前有哪些维护线在滚动"的最直接入口。对技术负责人来说，养成定期查看发布页的习惯，比依赖二手解读更可靠：看版本号分布可以判断主版本线是否并行，看发布条目的标题与标签可以判断某次发布是特性版还是维护版，看各条目的先后关系可以粗略判断演进节奏。

本文建议把"每季度回看一次 Releases 页面"写进选型委员会的例行事项，原因会在最后一节展开。

证据边界声明

在进入正题前，先把本次数据的口径钉死：

此外，本次样本中 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 的标准写法；具体元素组合仍建议以官方文档为准）：

<dependencyManagement><dependencies><dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-bom</artifactId><version>2.0.0</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement><dependencies><!-- 具体模块不写版本号，由 BOM 对齐 --><dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-client-chat</artifactId></dependency></dependencies>

Gradle 侧对应的是平台依赖：

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 参考文档，把以下四项抄写到团队的升级工单里，并注明来源链接与核验日期：

1. Spring AI 2.x 要求的最低 JDK 版本；
2. 2.x 适配的 Spring Boot 版本区间；
3. 1.x 维护线的最低 JDK / Spring Boot 要求，作为对照；
4. 项目自身当前的 JDK 与 Spring Boot 版本。

只有四项填齐，才谈得上"可以升级"。很多团队的升级事故不是发生在 Spring AI 的 API 变更上，而是发生在连带的 JDK 或 Spring Boot 版本跃迁上。

破坏性变更与新能力：自己核验的三条路径

2.0 作为主版本号变更，存在不兼容调整是合理预期；但具体到哪些包名、接口签名、配置项、自动配置行为发生了变化，本次材料没有提供 Release Notes 或 Migration Guide 的正文内容，因此不能列清单。可以提供的是核验方法：

1. 查官方 Release Notes 与迁移指南。这是唯一权威来源，任何第三方"升级踩坑清单"都应与之对照后再使用。
2. 用编译器当探针。升级 BOM 后先跑一次干净编译，编译错误是最精确的 API 变更定位器，比通读变更日志效率更高。
3. 看依赖树与自动配置报告。行为层面的变更（例如自动配置条件、默认超时、重试策略）不会体现在编译错误里，需要通过依赖树、启动日志和运行期行为对比来发现。

三、1.x/2.x 并存期：升级路径怎么做

先做决策：四象限判断法

是否升级，取决于两个维度：项目阶段（新建还是存量）与依赖约束（能否连带提升 JDK/Spring Boot）。

其中"依赖被锁死"的典型场景包括：公司 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-Dincludes=org.springframework.ai# 2) 看看有哪些依赖存在新版本可升（用于评估连带升级量）mvn versions:display-dependency-updates# 3) Gradle 项目对应命令./gradlew dependencies--configurationruntimeClasspath|grepspring-ai# 4) 在业务代码中定位直接调用点（粗略但有效）grep-rn"org.springframework.ai"src/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,Map<String,Object>context);}

生产实现走真实模型，测试实现返回录制好的快照。这样测试断言可以写得很严格，又不受外部服务波动影响。

回滚预案至少要包含三条：依赖版本可一键回退（BOM 版本号是单点，回滚成本低）；数据与索引格式是否变化（若 2.x 涉及向量库或元数据结构调整，需确认是否可双向兼容）；灰度策略（先在一个低风险服务或模块上升级，保留一段双版本运行窗口）。

并存期的多版本隔离手段

如果组织内确实需要同时运行 1.x 与 2.x，可选手段按隔离强度递增：

同一 JVM 内强行同时加载 1.x 与 2.x 的同名模块通常不是好主意：包名相同的类会造成类路径冲突，自动配置的条件判定也会相互干扰。除非经过专门验证，否则建议用进程边界而不是类路径技巧来做隔离。

四、选型策略：把框架放进同一张评估表

一个五维评估框架

功能清单长度是最糟糕的选型指标，因为几乎所有框架的 README 都会长得差不多。更有区分度的是五个维度：

1. Java 版本门槛：最低 JDK 要求，以及是否兼容老旧运行时。
2. 与 Spring 生态的耦合方式：原生扩展、可嵌入多种容器、还是完全独立。
3. 能力覆盖：模型接入、RAG、MCP、Agent 编排、多模态，各自是成熟实现还是示例级。
4. 部署与运行形态：是否依赖 Spring Boot、能否嵌入已有应用服务器、对云原生部署的支持。
5. 项目活跃度与治理：维护主体、发布节奏、issue 响应、文档与示例质量。本次数据无 star 数与时间戳，此维度无法量化，必须另行核验。

建议用"已核验事实 / 待核验 / 无数据"三态填写表格，而不是打分。打分容易把未知伪装成已知。

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"或"不想绑死 Spring"，Solon-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 -Dincludes=org.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_assistant（PR #389），bonigarcia/context-engineering，GitHub，https://github.com/bonigarcia/context-engineering/pull/389

[2] Release Spring AI 1.1.8，spring-projects/spring-ai，GitHub，https://github.com/spring-projects/spring-ai/releases/tag/v1.1.8

[3] Releases，spring-projects/spring-ai，GitHub，https://github.com/spring-projects/spring-ai/releases

[4] opensolon/solon-ai：Java AI application development framework（支持 LLM-tool/skill、RAG、MCP、Agent-ReAct、Team-Agent，自述兼容 java8~java26，可嵌入 SpringBoot、jFinal、Vert.x、Quarkus），GitHub，https://github.com/opensolon/solon-ai

[5] AIPro/solon-ai：Java AI（智能体）全场景应用开发框架，自述兼容 java8~java24，Gitee，https://gitee.com/aipro_1/solon-ai

[6] 珊瑚海/Agents-Flex：Java AI 智能体开发框架，自述对标 Spring AI，支持 RAG、MCP、Skills、Text2SQL、Subagent、WebSearch、TTS/STT、图片/视频生成，Gitee，https://gitee.com/nuanxin521/agents-flex

[7] mskj-apaas/spring-ai-alibaba-2025：Agentic AI Framework for Java Developers，GitHub，https://github.com/mskj-apaas/spring-ai-alibaba-2025

[8] himdd/spring-ai-alibaba：Agentic AI Framework for Java Developers，GitHub，https://github.com/himdd/spring-ai-alibaba

[9] Mu-L/spring-ai：An Application Framework for AI Engineering（镜像仓库），GitHub，https://github.com/Mu-L/spring-ai

[10] geekychris/java_rag：基于 Spring Boot、Spring AI 与 OpenSearch 的 RAG 服务，支持 Docker/Kubernetes 与可观测性，GitHub，https://github.com/geekychris/java_rag

[11] 吴博/灵梭：Elasticsearch 与 spring-ai-elasticsearch-store、ELK 生态相关文档，Gitee，https://gitee.com/wb04307201/spring-ai-loom-agent/blob/ac4e10826b273e2b29d6983cf7653b4764a4843c/CUSTOMIZATION.zh-CN.md

[12] loool/llmchat：Java 生态企业级 AIGC 解决方案，含 RBAC 权限体系与 Ollama/LocalAI 等本地私有模型支持，Gitee，https://gitee.com/loool/llmchat

[13] thubier/Lynxe：自述为 Manus 的 Java 实现，用于有确定性要求的探索性任务，Gitee，https://gitee.com/thubier/Lynxe

[14] rainerWJY/JManus：Agentic AI Framework for Java Developers，GitHub，https://github.com/rainerWJY/JManus

[15] kangwoo/aimon-core：Java 的 ReAct Agent 框架，可嵌入任意 Java 应用，GitHub，https://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 维护线的官方支持期限，本次材料中均未提供可核验内容，需以官方文档为准。