上一期我们在「[Agent 小知识｜A2A 是什么：Agent 之间怎么通信]」中讲到发布协调 Agent 通过 A2A，把 payment-service 的依赖兼容性分析交给了另一个团队的专业 Agent。任务交出去以后，专业方还需要查询依赖版本、读取兼容文档，才能形成判断。这些外部能力又该怎样接入？
沿用这个虚拟案例：协调方负责提出分析目标，专业方接下工作，并通过 MCP 使用所需能力。A2A 与 MCP 出现在同一项任务中，分别连接不同的参与方。
一图概览 A2A 和 MCP 如何配合
图 1：专业方通过 MCP 取得分析材料，再经 A2A 将报告交回协调方
分清两段连接
发布协调 Agent 与依赖兼容性 Agent 是两个独立的应用服务。在这次交互中，协调 Agent 发起请求，承担 A2A Client 角色；专业 Agent 提供符合 A2A 的接口，承担 A2A Server 角色。这些名称描述当前交互中的职责，不表示永久上下级。
协调 Agent 从能力卡了解专业方支持的分析能力和访问入口，再提交升级目标与依赖清单或锁文件。本例约定，专业方要返回一份兼容性报告，说明潜在冲突、依据和验证范围。
本例中，专业方为这次分析建立可跟踪的 A2A 任务，后续补充输入和报告都关联这项任务。协调方交出的是分析工作。具体先查哪个依赖、需要读取哪些说明，由专业方根据输入和自身实现组织。
这就形成了两段连接：协调方通过 A2A 与专业方协作；专业方的承载应用再通过 MCP 接入分析所需的工具、资源和提示模板。查询版本和获取文档属于后一段。
接入分析能力
专业 Agent 开始整理依赖清单，需要取得每项依赖的版本信息、运行时要求和相关兼容说明。为此，它的承载应用接入了提供版本查询与文档能力的 MCP Server。
这段交互中，承载应用承担 MCP Host 职责，管理 MCP 接入和使用策略。应用内部的 MCP Client 与指定的 MCP Server 进行协议交互；一个应用需要访问多个服务时，可以管理多个 MCP Client。模型根据任务提出查询需求，实际协议请求由接入组件发出。
同一个专业 Agent 应用，对外提供 A2A 服务，对内负责 MCP 接入。这里的“内部”说明接入由谁组织，MCP Server 可以是本地进程，也可以是远程服务。A2A Server 与 MCP Server 分别位于不同的协议关系中，不能因为都叫 Server 就合并成一个角色。
MCP Client 可以先通过 server/discover 了解 MCP Server 支持的版本与能力，再按需发现和使用具体能力。当前 MCP 2026-07-28 规范采用逐请求携带版本与客户端能力的方式，预先调用服务发现是可选的。
随后，专业方针对输入中的依赖查询版本约束，并读取或检索对应的升级说明。例如，它需要知道某个目标版本要求什么运行环境、哪些接口发生了变化，以及哪些组合仍需验证。这些查询和读取能力由接入服务提供，MCP 本身不内置依赖兼容性分析。
通过 MCP 取得的版本信息和文档内容先供专业方分析。协调 Agent 此时仍通过 A2A 跟踪任务，无须取得这段 MCP 的工具目录或逐项指定调用参数。
MCP 也有补充输入机制，并可通过可选 Tasks 扩展处理长操作。理解两者分工时，应关注连接对象和接口责任，不能只看一次调用耗时多久。
图 2：两段连接中的角色位置
补齐运行环境
专业 Agent 已经查到部分依赖的运行时约束，却发现请求没有明确目标 Node.js 版本。它可以继续收集资料，但还无法完成与目标环境的对照。于是，专业方通过 A2A 把任务标记为 TASK_STATE_INPUT_REQUIRED，并提出补充要求：“请提供目标 Node.js 版本。”协调 Agent 回复“目标环境为 Node.js 24”，将消息关联到原来的非终态任务。收到补充信息后，专业方继续查询、对照和归纳。
这里跨 A2A 边界传递的是专业方提出的信息要求和协调方的回答。内部某次 MCP 调用是否需要更多参数，先由专业方处理；是否进一步向协调方提问，要根据分析所缺的信息决定，两套交互不会自动映射为同一个状态。
交付分析报告
输入补齐以后，专业 Agent 可以把依赖版本约束、兼容文档与目标环境放在一起分析。必要且具备条件时，还可以通过受控测试验证部分判断；未执行测试的结论，需要明确其依据与限制。
版本信息和文档是分析材料，协调方需要的是针对这次升级的判断。本例将报告内容约定为：
这是应用约定的报告内容，A2A 不规定兼容性报告必须采用这张表。专业方按约定整理或封装结果，将报告作为 A2A 交付物返回给协调 Agent，并把任务标记为完成。MCP 的工具结果只有被纳入这次对外交付，才成为报告的内容；它不会因为来自工具，就自动成为 A2A 的 Artifact。
一次分析可能需要多次查询和读取，也可能利用已有材料。对外任务与内部工具调用没有固定的一对一关系，任务进度也无须逐条复述内部调用。
协调 Agent 据此决定是否补充验证、处理风险或继续发布准备。它依赖专业方约定的输入输出，无须了解对方使用哪套文档检索服务、怎样组织提示词或保存内部状态。专业方更换内部工具时，仍需满足对外约定。
如果协调方需要直接使用某项查询能力，可以由自己的应用另行接入相应服务；对专业 Agent 的一次委派，不自动授予其内部 MCP 访问权。报告交付完成，也不代表已经获得部署许可。
图 3：内部材料与对外交付的关系
守住访问边界
这条链路组合了两种协议，访问控制仍要分别落实。协调 Agent 访问专业服务，与专业方的 MCP Client 访问能力服务，是不同的访问关系。前一段已获准，不代表后一段可以使用同样的权限或直接转送令牌。访问受保护的 HTTP MCP Server 时，Server 需要校验令牌确实面向自身资源。
错误同样需要分开处理。MCP 区分协议错误和工具执行错误；某次文档查询失败以后，专业方应判断能否继续取得所需依据，再决定怎样反馈到对外任务。不能看到一次工具错误，就直接把整项分析判为失败。
两段连接的超时、重试和日志也应分别处理。排查时先确认问题发生在哪段接口，再核对任务状态；一条连接断开，不能单独证明业务已经结束。
内部信息是否对外返回，仍由应用控制。A2A 不要求公开内部工具，也不会替应用自动脱敏，报告和状态消息都要遵守约定的信息边界。
结语
清楚的任务接口，让协调方能够委派分析、使用报告，也让专业方保留组织内部能力的空间。当可协作的专业 Agent 越来越多，该怎样注册、发现并选择合适的一方？下一期继续聊聊 Agent Registry。
