Java 后端把 AI Agent 接到生产链路要拆几层

很多人第一次做 Java 后端 AI Agent，会把工具调用、RAG 和 MCP 当成三个独立模块，分别研究后再塞进 Spring Boot。结果通常是 Controller 直接调用模型，工具注册与知识召回各走各的，权限、审计和链路追踪全部断开。实际至少应拆出八个职责边界：Controller/API、Application Service、AI Gateway、Context Builder、Policy Guard、Model Client、Tool/RAG Adapter、Parser/Validator。它们可以部署在同一个进程里，但职责不能混在一起。

角色关系也很直接：工具调用提供业务动作，RAG 提供外部知识，MCP 是标准化接入工具的协议层，Agent 负责组织任务，而不是三者互相替代。对于”查知识并执行业务动作”的场景，知识与动作两类能力缺一不可；MCP 是否使用，则取决于是否需要跨进程、跨语言共享工具。把六个模块放进同一张生产落地图，比分别研究六个名词更接近 Java 后端的真实问题。

工具调用、RAG、MCP 在同一条 Agent 循环里各管什么

Agent 可以抽象为”感知—认知—行动”循环：感知负责取得用户输入和外部信息，认知阶段调用模型做判断，行动阶段再执行工具或写入业务系统。 放进企业系统后，这条循环通常表现为：构建上下文、调用模型、解析结构化结果、执行工具、校验结果、提交业务动作。

RAG 是知识读取路径。它先检索文档，再把相关片段交给 Context Builder，而不是让模型凭参数记忆猜答案。切片、Embedding、关键词召回、向量召回和重排是一条需要评测的流水线，并不等于”接上向量库就完成 RAG”。资料中列出的 bge-m3、bge-reranker-v2-m3 可以作为支持私有部署的候选，但最终仍要结合语料、语言和延迟要求选择。

工具调用是行动原语。Function Calling 或 Spring AI 的 ToolCallback 负责让模型提出结构化调用请求，真正的参数校验、权限判断和业务执行仍由 Java 后端完成。模型可以提议动作，但后端必须决定动作能不能执行。如果只是调用几个内部 Java 方法，直接使用 ToolCallback 或 @Tool 即可，不必为了架构完整强行引入 MCP。

MCP 位于工具调用之上，负责以统一协议暴露和发现工具。Spring AI 的 MCP Client 可以连接 Java 或 Python 实现的 MCP Server，使内部 API 能被多个 Agent 复用。 但 MCP 不是权限系统：Gateway 可以集中做配额、路由和粗粒度授权，MCP Server 仍需校验调用身份、租户、参数与资源权限。企业知识问答也不必强制 MCP，只有需要接入现有工具、跨语言复用或统一工具发现时，它才体现出价值。

Spring AI 抽象的是执行链，不是完整的安全治理

在 Java 侧，Spring AI 可以理解为同一条执行链上的几类入口：Model Client 负责模型交互，ToolCallback 与 @Tool 提供内部工具，RAG Advisor 负责检索增强，MCP Client 负责协议化工具接入。 Context Builder 和 Policy Guard 通常仍需要业务代码实现，因为只有业务系统知道用户身份、租户、数据范围和操作风险。

一次请求可以按 Controller → Application Service → AI Gateway → Context Builder/Policy Guard/Model Client/Tool/RAG Adapter → Parser/Validator 推进。Spring AI 解决的是模型、检索和工具之间的胶水代码，不会自动补齐 RBAC、审批、审计、幂等和结果校验。

Java 的优势主要在工程基建，而不是模型能力本身。已有 Spring 体系中的事务、网关、RBAC、限流、熔断、审计和链路追踪，可以直接复用到 AI Gateway；向量存储也可以接入团队已经维护的数据库或搜索系统。 因此不必为了一个 RAG 请求就在核心链路中强行增加 Python 服务。

但 Java 基建也不能替代 AI 专项能力。团队仍要补上文档清洗、切片策略、Embedding、召回评测、提示注入防护和模型成本管理。若缺少这些经验，Spring AI 只能减少接口适配，无法自动提高答案质量。

上线前先把边界卡住，再扩大 Agent 自主性

三项工作不必排出先后顺序：先定义工具清单和权限边界，再建立最小 Trace，随后用固定测试集做评测；任何有副作用的工具，在护栏完成前都不应开放生产流量。评测决定是否发布，Trace 负责定位问题，护栏则决定哪些动作根本不应执行。

Agent 的自主步骤越多，链路可靠性越容易下降。资料以每一步正确率 95% 作示例时，三步整体成功率约为 86%，十步约为 60%。 这组数字不是某个模型的实测结果，而是说明多步误差会累积。因此，能用固定 Workflow 解决的问题，就不要让模型自行决定流程；必须使用 Agent 时，也要限制最大步数、超时、Token 和工具范围。

护栏也不能只写一句 System Prompt。模型网关负责限流、配额和输入输出过滤，工具网关负责身份、租户与资源权限，敏感操作还需要审批、幂等键和结果校验。召回文档与工具返回值都应视为不可信数据，不能因为其中出现指令文本，就提升为系统指令。

评测不能只看回答是否流畅。资料中的 Ragas 0.2 示例使用 Faithfulness 判断回答是否能被召回上下文支持，使用 Context Recall 观察关键信息是否被召回。但这些指标不能覆盖工具选择、参数正确性、权限违规和任务完成率，生产评测集还应覆盖工具调用与端到端任务结果。

可观测性至少要串起一次请求中的模型调用、召回文档及分数、工具名称、脱敏参数、校验结果、Token 消耗和延迟。Java 项目可以沿用 Micrometer Tracing，并输出为 OpenTelemetry 兼容的 Trace。只有能看到完整决策链，评测失败和工具异常才能被复现，而不是只留下一个最终回答。

长上下文 RAG 的成本与重排取舍、Agent 间委托时的权限传递，以及敏感数据应在入库前还是检索后脱敏，目前仍会随语料规模和合规要求变化。MCP 解决了工具共享的一部分问题，却没有自动解决委托链上的身份与授权传递；脱敏也不应被理解为简单的二选一，通常需要结合索引内容、访问控制和日志保留策略共同设计。因此，这套八层结构是当前可落地的职责划分，而不是 AI Agent 的终态架构。