Koog(10) —— 生态集成：MCP、后端服务与 A2A - SharpCJ
内容提要
本文介绍 Koog Agent 的三种外部集成协议：MCP 通过 stdio 连接独立 JVM 进程，将远端工具适配进 ToolRegistry 供 Agent 调用；Ktor 与 Spring Boot 集成提供 HTTP 入口，但路由、鉴权、会话存储仍需应用自行实现；A2A 用于独立 Agent 服务间的能力发现与通信，实测了 AgentCard 发现、message/send 及 tasks/get。作者强调协议只负责互操作，业务事实、权限与状态边界仍由应用负责。
延伸解读
协议只解决互操作，不替代业务边界
文章反复强调，MCP、Ktor/Spring Boot 集成和 A2A 都只负责协议层面的互通。MCP 不决定连接哪些服务器、允许哪些工具；后端集成不会自动生成路由、鉴权或会话存储；A2A 的 AgentCard 也不会自动配置认证或实现业务。读者应把协议视为接入手段，业务事实、权限和状态边界仍需应用自行设计和校验。
版本与模块状态需逐项核验
文中固定 Koog 核心 1.3.0，但 MCP、Ktor、Spring Boot 和 A2A 相关模块多为 1.3.0-beta 预览版。作者提醒不能把官网版本占位符全部替换为正式版，并指出 beta 版 tasks/get 明确排除 artifacts、Ktor 插件未自动关闭 executor 等实际行为。依赖升级后，生命周期、缺省行为和接口差异都应重新验证，不能照搬旧例。
示例刻意隔离模型调用与协议验证
文章中的 MCP、后端和 A2A 示例大多使用确定性逻辑，不调用真实模型，DeepSeek 接入代码仅编译、API Key 用占位值。这样能把协议验证与模型决策分开，避免把协议成功误认为模型调用成功。读者在复现时应注意，提示词要求使用工具并非程序级强制，若业务必须经过工具，应在策略中明确安排工具节点。
组合架构不是必选项
作者给出“前端/业务系统 → Ktor 或 Spring Boot 后端 → Koog Agent → MCP 外部工具 → A2A 远端 Agent”的可能组合，但明确这不是推荐每个项目都采用的必选架构。后端直接调用 Koog 也成立；没有独立工具或 Agent 服务时，不必为了生态完整而增加协议层。引入协议应以实际互操作需求为前提。
Q&A
Koog 的 MCP 集成是如何把外部工具接入 Agent 的？
MCP 通过 stdio 连接独立的 JVM 进程，客户端发现服务端发布的工具描述，Koog 将这些描述适配到自己的 ToolRegistry，Agent 即可像调用本地工具一样调用远端工具。链路为：Koog Agent → ToolRegistry → MCP Client → MCP Server → 工具实现。
使用 Koog 的 Ktor 或 Spring Boot 集成后，还需要自己实现哪些功能？
集成只解决组件装配与调用问题，不会自动生成 /chat 路由、鉴权、会话存储或限流。这些仍需应用自行实现，例如路由定义、身份验证、会话管理以及请求限流等。
A2A 协议在 Koog 中主要解决什么问题？
A2A 用于独立 Agent 服务之间的能力发现与通信。调用方提交消息，对方可以即时回复，也可以创建具有状态和产物的任务。它支持 AgentCard 发现、message/send 和 tasks/get 等交互。
在 Koog 的 A2A 实现中，tasks/get 能获取到任务产物吗？
在本文使用的 1.3.0-beta 版本中，A2AServer.onGetTask 明确使用 includeArtifacts=false，因此 tasks/get 返回的任务状态为 Completed 但 artifacts 为 null。不能承诺通过 tasks/get 下载全部产物。
Koog 的 MCP 集成支持哪些传输方式？
本文固定的 MCP beta 模块支持三种入口：stdio、SSE 和 Streamable HTTP。其中 SSE 和 Streamable HTTP 不是同一个入口，该版本已包含 streamableHttp 支持。
使用 Koog 的 Ktor 集成时，如何管理 PromptExecutor 的生命周期？
Ktor 插件在 1.3.0-beta 版本中没有自动关闭 executor 的停机钩子，因此需要应用显式订阅 ApplicationStopped 事件来关闭 executor。共享的 executor 不应在每个请求中关闭。
