Spring AI 的 Agent 野心：从 Recursive Advisors 到 ACP / A2A

一个判断需要修正

在之前的文章里，我写过一句结论：

“Spring AI 官方定位是’连接企业数据和 API 与 AI 模型’——让 LLM 像 JDBC、JMS 那样成为企业系统里一个可插拔的中间件。Spring AI 刻意不做 Agent Framework。”

前半句仍然成立。但后半句——“刻意不做 Agent Framework”——需要修正。

证据来自 Spring I/O 2026。Broadcom 团队（Mark Pollack、Christian Tzolov、Dariusz Jędrzejczyk）在演讲中公开了 Spring AI 的 Agent 路线图，三个关键词：

Recursive Advisors — 受控迭代框架，Agent 的核心是上下文编排器
ACP（Agent Client Protocol） — 标准化 client → agent 通信
A2A（Agent-to-Agent） — 直接 Agent 协作

目标是构建生产级 Agent 系统，包括编码 Agent（类似 Claude Code）。

这不是”可能做”，是”正在做”。判断需要更新。

Recursive Advisors：不是新框架，是 Advisor 的递归

先搞清楚 Recursive Advisors 到底是什么。它不是一个新的 Agent 框架，而是 Spring AI 2.0 已有的 Advisor 机制的延伸。

Advisor 机制回顾

Spring AI 2.0 的 Advisor 是”AI 交互管道中的切面增强”，类似 AOP 但针对 AI：

1	用户请求 → [ChatMemory] → [RAG] → [SafeGuard] → [ToolCalling] → LLM → 响应

每个 Advisor 可以在请求前、响应后做增强。这是”线性管道”模式——请求经过一串 Advisor，最后到达 LLM。

Recursive Advisors 改了什么

Recursive Advisors 让 Advisor 可以递归调用——一个 Advisor 的输出可以作为另一个 Advisor 的输入，形成迭代循环：

用户请求 → [Recursive Advisor]
               ├─ 调用 LLM
               ├─ 检查输出质量
               ├─ 不满意？→ 修正 prompt → 再调用 LLM
               └─ 满意？→ 返回结果

这就实现了 Agent 的核心行为：感知 → 决策 → 行动 → 观察 → 再决策的循环。

官方说法是：”可用于构建类似 MemGPT 或 Claude Code 的 Agent 系统。”

和 Spring AI Alibaba Graph 的区别

维度	Recursive Advisors	Spring AI Alibaba Graph
归属	Spring AI 核心	Alibaba 扩展
抽象层级	Advisor（管道切面）	StateGraph（状态机）
编排方式	递归迭代	显式节点 + 边
适合场景	单 Agent 的迭代优化	多 Agent 的协作编排
学习曲线	低（就是 Advisor）	中（需要理解 Graph DSL）

关键区别：Recursive Advisors 解决”一个 Agent 怎么迭代地把事情做对”，Graph 解决”多个 Agent 怎么协作把复杂任务做完”。

这不是替代关系，是不同层级。Recursive Advisors 是”Agent 的内核”，Graph 是”Agent 间的协调器”。

ACP：Agent 通信的标准化

ACP（Agent Client Protocol）要解决的问题是：客户端怎么跟 Agent 通信？

当前的状况是：每个 Agent 框架都有自己的 API。你用 Spring AI Alibaba 写的 Agent，跟用 LangChain 写的 Agent，通信协议完全不同。前端或者第三方调用方需要为每个框架写适配。

ACP 的目标是标准化这层：

1
2
3

客户端（Web / CLI / IDE）
    ↓ ACP 协议
Agent Server（Spring AI / LangChain / 其他框架）

Gemini CLI 已经支持 ACP。这意味着你可以用同一个客户端协议跟不同框架实现的 Agent 通信。

为什么这对后端工程师重要

**Agent 将成为新的”服务端点”**。就像 REST 标准化了 Web API，ACP 会标准化 Agent API。后端工程师需要知道怎么把 Agent 暴露为 ACP 端点。
Agent 的可替换性。如果 Agent 通信走 ACP，那么换底层框架（从 Spring AI Alibaba 换到别的）不影响客户端。这和”JDBC 让数据库可替换”是同一个思路。
MCP 的延伸。Spring AI 2.0 已经内建了 MCP（Model Context Protocol）支持，让 Agent 可以标准化地调用外部工具。ACP 是反方向——标准化外部调用 Agent。MCP + ACP 合在一起，就是”Agent 的入站和出站协议”。

A2A：Agent 之间的直接对话

A2A（Agent-to-Agent）是最前期的路线图项，目标是让 Agent 之间可以直接通信协作。

当前的多 Agent 协作（比如 Spring AI Alibaba Graph 的 Supervisor 模式）是在同一个进程内编排的——Supervisor Agent 调度子 Agent，都在一个 JVM 里。

A2A 要做的是跨进程、跨框架的 Agent 协作：

1
2
3

Agent A（Spring AI 实现）
    ↓ A2A 协议
Agent B（Python LangChain 实现）

这比 ACP 更远。ACP 是”人 → Agent”，A2A 是”Agent → Agent”。如果 A2A 成熟，多 Agent 系统就不再局限于单一框架。

对架构选型的影响

如果你今天在设计多 Agent 系统：

时间维度	建议
现在（2026 下半年）	Spring AI Alibaba Graph 是唯一可用的 Java 多 Agent 方案
6-12 个月后	关注 ACP 标准化进展，设计时把 Agent 通信层抽象出来
12-24 个月后	A2A 可能让跨框架多 Agent 成为现实

不要等 A2A 成熟才动手。现在用 Graph 做多 Agent 编排，把通信层抽象好，将来 A2A 标准成熟时可以平滑迁移。

对学习路线的影响

这次路线图更新对我的学习路线有几个直接影响：

1. Advisor 机制需要深入学

之前可能觉得 Advisor 就是”管道中间件”，了解 RAG Advisor 和 Memory Advisor 就够了。但 Recursive Advisors 说明 Advisor 是 Spring AI Agent 能力的核心——理解 Advisor 的递归机制，就是理解 Spring AI 怎么做 Agent。

建议：写一个 Recursive Advisor 的最小实现——让 LLM 自我检查输出质量并迭代修正。这比学 Graph 的 4 种模式更基础。

2. MCP 和 ACP 要一起看

MCP 已经在 Spring AI 2.0 里了，ACP 是路线图项。理解 MCP 的 @McpTool 注解和 Streamable HTTP 传输，是为了将来理解 ACP 做准备。

建议：先用 Spring AI 2.0 的 MCP Server 暴露一个业务能力（比如”查询订单状态”），再用 MCP Client 调用它。这个闭环走通了，ACP 的概念就不陌生。

3. Spring AI Alibaba Graph 仍然值得学

Graph 不会因为 Recursive Advisors 而过时。两者解决不同问题：

Recursive Advisors = 单 Agent 的迭代内核
Graph = 多 Agent 的编排框架
ACP = Agent 的标准化通信协议
A2A = Agent 间的跨框架协作

四者是叠加关系，不是替代关系。 学习顺序建议：Advisor → Recursive Advisors → MCP → Graph → ACP（待发布）→ A2A（待发布）。

修正后的判断

之前的判断：”Spring AI 刻意不做 Agent Framework，Agent 编排交给 Spring AI Alibaba。”

修正后的判断：**”Spring AI 正在从’模型接入层’向上延伸到’Agent 基础设施层’。Recursive Advisors 是 Agent 的内核（迭代执行），ACP 是 Agent 的通信标准（客户端协议），A2A 是 Agent 间的协作协议。Spring AI Alibaba Graph 仍然有价值——它解决的是多 Agent 编排问题，这是 Spring AI 核心暂时不覆盖的。但长期来看，Spring AI 核心和 Spring AI Alibaba 的边界会持续演化。”**

核心变化：Spring AI 不再只是”Java 的 LangChain”。它正在变成”Java 的 LangChain + 部分 LangGraph + Agent 协议标准”。