1. 怎么把 RAG 接入到你的 Agent 执行链路里的？是在调用工具之前先检索，还是在生成结果之后再做校验？

我们的 RAG 是通过 Spring AI 的 Advisor 接入到 ChatClient 的：模型调用前在 before() 做向量检索，把命中文档拼成上下文注入 prompt；模型生成后在 after() 把命中文档回写到响应 metadata 便于追踪。当前是“先检索再生成”的 pre-RAG，并没有单独做生成后的事实校验，后续可以增加 verifier 节点来做 post-check。

2. MCP 是完全自研的吗？和市面上成熟的 Agent 框架相比，你的方案在扩展性上有什么优势？

结论

• MCP 不是完全自研协议：我用的是 MCP 标准协议，在 Java 侧主要做的是工程化落地与平台化接入——把 MCP Server（SSE/StdIO 两种传输）动态装配进 Spring 容器，并注入到 ChatClient 的 tool-calling 链路里。
• 自研的部分在于：围绕 MCP 做了**配置化编排、动态装配、可观测执行链路（SSE 轨迹）**这一整套“企业集成层”，而不是重新造一个协议。

1) 你的 MCP 到底自研了什么、复用了什么？

复用（标准/成熟组件）

• 协议层：遵循 MCP 的工具描述与调用模型（Tool schema、call/response）。
• 传输层：支持 SSE（远程工具服务）和 StdIO（本地工具进程）。
• 调用链：通过 Spring AI 的 tool-calling 支持，把 MCP client 聚合成 tool callback provider（你代码里是 SyncMcpToolCallbackProvider 一类的注入方式）。

自研（平台落地能力）

• 动态装配：从 DB/配置加载 MCP 工具配置，在运行时创建 MCP client，并注册成 Spring Bean（按工具 id 生成 beanName）。
• 按 Agent/Client 绑定工具集：不同 Client 可组合不同 MCP 工具集合，避免“全局一锅端”。
• 装配到执行引擎：最终构建 ChatClient 时将工具回调注入，使 AutoAgent/FlowAgent 的不同 step 可以复用同一套工具能力。
• 可观测：工具调用结果可以写入执行轨迹，并通过 SSE 推给前端（便于排障与解释）。

2) 和成熟 Agent 框架相比，你的扩展性优势是什么？

我会从三点讲“扩展性”，每点都能落到工程事实：

优势 A：在 Spring 体系下的“配置化扩展 + 动态装配”

• 成熟框架（LangChain/LangGraph）在 Python 生态扩展快，但在 Java 企业环境里经常要重新做：
• 我这套做法把工具、模型、RAG、Prompt 都当成配置驱动的模块，通过规则树按依赖顺序装配成 Bean。扩展一个新 MCP Server更多是“加配置 + 注册”，不需要侵入执行链路代码。

优势 B：工具接入与 Agent 执行解耦（横切能力复用）

• RAG 用 Advisor 这种横切组件接入；MCP 工具也以“可插拔能力”注入 ChatClient。
• 结果是：同一个工具集可以被多个 Agent/多个 Step 复用；新增工具不会导致执行链路膨胀。

优势 C：工程化能力更贴近生产（可观测/可控/可治理）

成熟框架很多 demo 很快，但生产要补的能力很多。我的扩展点围绕“生产化”：

• SSE 全链路事件输出（分析/执行/总结）可观测
• 规则树装配顺序保证一致性
• 支持按 Client 绑定工具白名单（易做权限治理）
• 易插入限流、重试、超时、审计等治理层

MCP 协议本身不是我自研的，我遵循 MCP 标准，在 Java 侧主要做工程化落地：支持 SSE/StdIO 两种传输，把 MCP 客户端按配置动态创建并注册到 Spring 容器，最终注入到 ChatClient 的 tool-calling 链路里。相比市面成熟 Agent 框架，我的优势不在于算法，而在于 Java/Spring 生态下的扩展性：工具、模型、RAG、Prompt 都配置化装配，新增工具低侵入；同时具备更强的生产化集成空间——权限白名单、审计、限流和 SSE 可观测链路都能统一治理。