MCP 与 A2A：调用外部能力，还是委托远端任务
所属：第二部分 · 让它做对事的四块地基（第 5–8 章） 前置：第 7 章（记忆、检索与迭代搜索）、第 6 章（工具粒度、工具合同与运行边界）、第 4 章（工具请求、执行与结果回填） 本章新概念：直接 API、MCP Host／Client／Server、A2A、Agent Card、Message、Task、Artifact、核心协议无隐式会话、M×N 适配问题
一、跨过程序边界的，是一个能力还是一项目标¶
第 7 章的运行系统会把候选材料装入本轮工作集，再由模型决定下一次搜索、读取或停止。如果搜索能力位于另一个程序里，运行系统可以把一次明确动作交出去，例如「用这些关键词找候选来源」。对方返回结果后，搜索什么、读哪篇和何时结束仍由本地运行系统决定。这是调用外部能力。
运行系统也可以把整个目标交出去，例如「调查本周稳定币监管动态，核对冲突，最后交付一页报告」。远端 Agent 在自己的运行边界内完成搜索、读取、比较和停止；调用方不参与这些内部步骤，只补充信息、跟踪进度并接收成果。这是委托远端任务。
两种动作的差别在责任范围：
能力调用只把一个边界清楚的能力请求交给对方；任务委托把目标以及目标内部的执行责任一起交给远端 Agent。
动作确定后，还要约定双方怎样交换请求和结果。本章把由某个提供方自行规定、双方单独对接的接口简称为直接 API；多方也可以采用一套共同协议。直接 API 可以承载能力调用，也可以承载任务委托。「直接」只说明接口格式由提供方自定，不说明责任边界。
| 跨过边界的是什么 | 提供方自定接口 | 采用共同协议 |
|---|---|---|
| 一个被点名的能力 | 直接 API | 主要由 MCP 统一表达 |
| 一项目标及其内部执行责任 | 直接 API | 主要由 A2A 统一表达 |
因此，直接 API、MCP 和 A2A 不是同一层的三个选项。先判断跨过边界的是能力还是任务，再判断是否需要共同协议。
二、MCP：把外部能力接到运行系统¶
如果第 7 章的 search_sources 和 read_source 位于外部服务，运行系统需要知道服务提供哪些能力、调用时交什么、返回后怎样接回工作集。MCP 是 Model Context Protocol，它为这类能力交互提供共同协议。
第 7 章的运行系统位于 MCP Host 一侧。三个角色沿一次调用分工：
| 角色 | 位于哪里 | 在能力调用中做什么 |
|---|---|---|
| Host | 使用能力的应用一侧 | 承载运行系统、模型与上下文；管理连接权限、用户同意和安全边界；决定开放哪些能力及怎样使用结果 |
| Client | Host 内部 | 与一个指定 Server 通信，把 Host 的请求送出，再把结果带回 |
| Server | 提供能力的一侧 | 暴露一组聚焦的工具、资源或提示模板，并完成收到的能力请求。比如：气象局服务可以返回天气信息 |
一次搜索可以这样发生：Host 通过 Client 发现 Server 提供搜索与读取；Host 只开放当前允许使用的能力；Client 把调用送给 Server；Server 返回候选来源或正文；运行系统把需要的结果装入工作集，模型再决定下一次搜索、读取或停止。
于是，MCP 把第 7 章已有的关系延伸到了程序边界之外：
Server 完成被点名的能力，Host 把结果接回自己的运行过程；MCP Server 不因内部使用了模型或 Agent，就自动成为整个任务的受托方。
Server 暴露的三类对象也各有职责：工具用于执行动作，资源用于读取内容，提示模板用于取得一组可填参数的消息。它们都属于 Host 可以消费的外部能力。
角色边界与交互关系见 MCP 2026-07-28 架构说明。
三、协议核心没有隐式会话，不等于应用没有状态¶
在 2026-07-28 版 MCP 中，核心协议移除了初始化握手和隐式会话标识。每个请求都要带齐处理它所需的协议信息，不应靠「这条连接之前发生过什么」才能解释。
这只是在约束协议请求，不是在禁止应用保存状态。
例如，浏览能力第一次创建浏览器实例后，可以返回一个 browser_id。后续调用显式带回这个标识，Server 再据此找到对应实例。类似地，购物车可以靠 cart_id 延续，长任务可以靠 task_id 跟踪。连续性没有消失，只是从隐式会话变成了请求里看得见的标识。
Host 仍可以保存对话、工具结果、用户同意和当前任务；Server 仍可以使用数据库或缓存。于是：
核心协议没有隐式会话，表示请求应当自包含；它不表示 Host、Server 或业务过程必须无状态。
这是带版本范围的事实，不能倒推给所有历史实现。版本变化与设计原因见 MCP 2026-07-28 发布说明。
四、A2A：把整个目标交给远端 Agent¶
如果调用方不再逐次调用搜索和读取，而是把「完成本周调研」交给另一个系统，远端就会在自己的运行边界内组织工作。它可以建立自己的工作集，使用固定检索或迭代搜索，也可以调用别的工具；调用方不需要看见这些内部步骤，只需要交流目标、补充信息、任务状态和成果。
A2A 是 Agent2Agent Protocol。第 7 章的运行系统把整个目标交给远端 Agent 时，位于 A2A Client 一侧。发起交互的一侧叫 A2A Client，接受交互的 A2A Server 也叫 Remote Agent。本章先用四个主干对象理解这段协作：
| 对象 | 在协作中的位置 | 它承载什么 |
|---|---|---|
| Agent Card | 交互开始前 | 远端声明的身份、可完成的任务、访问方式与安全要求 |
| Message | 发起或继续交流时 | 目标、问题、补充信息或过程说明 |
| Task | 工作需要被持续跟踪时 | 任务标识、当前状态与生命周期 |
| Artifact | 任务产生正式结果时 | 报告、文件或结构化成果 |
典型过程是：调用方先读取 Agent Card，判断远端声明的能力是否匹配；再用 Message 给出目标。简单交流可以直接得到一条 Message。需要持续跟踪的工作会形成 Task，远端可以更新状态或请求补充信息，最终把任务输出放进 Artifact。
这些对象共同表达的是独立 Agent 的协作边界。Remote Agent 内部可以自主规划，也可以运行固定工作流；A2A 规定双方怎样协作，不要求远端公开内部计划、记忆或工具实现。
对象定义与交互规则见 A2A v1.0 规范。
五、MCP Tasks 与 A2A Task 有重叠，但协议契约仍不同¶
把 MCP 说成「短暂、无状态的工具调用」，把 A2A 说成「长时间、有状态的任务」，已经不够准确。MCP 2026-07-28 的 Tasks 扩展也能让工具调用异步持续，并跟踪它的生命周期。
两者确实出现了功能重叠，但没有因此变成同一种协议契约：
- MCP Tasks 是可选扩展，让一次工具调用可以转为异步任务，并用显式标识查询状态和取得结果。它延长的是这次工具调用的生命周期。
- A2A Task 是 A2A 数据模型里的工作单元，位于独立 Agent 之间的 Message、Task 和 Artifact 协作关系中。简单交互也可以只返回 Message，不创建 Task。
MCP 的中途输入要分两个阶段：在异步 Task 创建前，工具调用可以先返回「仍缺哪些输入」，Client 补齐后带着这些显式输入重新发起调用；Task 创建后，这项 Task 也可以进入「等待输入」状态，Client 再通过任务更新补回信息。前一种补充属于重新发起的工具调用，后一种补充属于已经存在的 Task。因此，「能否中途补充输入」也不能用来区分 MCP 与 A2A。
因此，不能只问「有没有 Task」「是不是异步」「要运行多久」或「能不能补充输入」。要问的是：
对端是以 MCP 的工具、资源或提示模板提供能力，还是以 A2A 的 Agent Card、Message、Task 和 Artifact 参与 Agent 协作？
端点内部有没有 Agent 也不能替你判断。MCP Server 可以在内部使用 Agent，A2A Remote Agent 也可以只运行固定流程。最终看的是对外协议契约，不是运行时间、状态数量或内部实现技术。MCP Tasks 的版本位置见 MCP 2026-07-28 发布说明。
六、采用共同协议时，再比较 MCP 与 A2A¶
MCP 与 A2A 都是共同协议。此时可以用同一组问题比较：对端以什么身份出现，调用方交出什么，对端承担什么责任，以及双方用什么对象续接工作。
| 判断问题 | MCP | A2A |
|---|---|---|
| 对端以什么身份出现 | 提供工具、资源或提示模板的 Server | 接受 Agent 间交互的 Remote Agent |
| 调用方交出什么 | 一个工具调用、资源请求或提示模板参数 | 表达目标、问题或补充信息的 Message |
| 对端承担什么责任 | 完成被点名的能力请求 | 在自己的运行边界内处理收到的目标或交流 |
| 怎样发现对端能做什么 | Host 发现 Server 暴露的工具、资源和提示模板 | Client 读取 Agent Card 中的身份、任务能力、访问方式与安全要求 |
| 持续工作怎样表达 | Tasks 扩展可以跟踪异步持续的工具调用 | Task 表达远端工作的状态与生命周期；简单交流也可直接返回 Message |
| 正式结果怎样交回 | 工具结果、资源内容或提示模板消息 | 简单交流返回 Message；Task 的输出放入 Artifact |
| 何时更匹配 | 多个 Host 希望用共同方式消费外部能力 | 独立 Agent 系统需要用共同对象交流、委托或协作 |
表中的生成差异是对端身份与责任范围，不是运行时间或内部是否使用模型。MCP Server 可以在内部运行一个 Agent，但对外仍只承诺完成能力请求；A2A Remote Agent 也可以运行固定流程，但对外仍以 Agent 协作对象接收和续接工作。
直接 API 属于另一条轴：它只表示接口由单个提供方自定。一个直接 API 可以表达表中任一侧的关系。一对一集成、需要大量提供方专有特性，或没有复用需求时，直接 API 可能更合适；它不是比共同协议更低一级的方案。
七、MCP 与 A2A 可以出现在同一条链上¶
一个调研系统可能是：
调用方 Agent —A2A 委托→ 远端调研 Agent —MCP 调用→ 搜索能力 —专有 API→ 搜索服务。
A2A 管的是调用方与远端 Agent 之间的任务协作；MCP 管的是远端 Agent 怎样消费外部能力；MCP Server 内部仍可以使用专有 API。
反过来也可能成立：一个 MCP 工具在内部把请求转交给 A2A Agent。外层调用方此时看到的仍是 MCP 能力；只有当调用方需要直接参与 Agent 间的 Message、Task 和 Artifact 协作时，才需要把 A2A 边界直接暴露出来。实现可以嵌套，对外协议仍由调用方实际参与的关系决定。
MCP 统一外部能力怎样被消费，A2A 统一独立 Agent 怎样协作；两者可以嵌套，因为它们规范的交互对象不同。
八、共同协议可能减少重复适配¶
共同协议的一项直接收益，是减少重复的接口适配。假设一类边界里有 M 个接入方，每个都要连接 N 个提供方。如果每一对都使用专有接口，并且所有接入方都连接所有提供方，最多需要 M×N 组定制适配。在 MCP 场景里，可以把它理解为 M 个 Host 对接 N 个 Server；在 A2A 场景里，则是 M 个调用方对接 N 个 Remote Agent。
如果双方都实现同一种协议，并且业务语义也兼容，理想情况下，M 个接入方各实现一次协议客户端，N 个提供方各实现一次协议服务端，协议适配的实现面可以接近 M+N。
这只是满连接情况下，对适配实现种类的理想化比较，不是总成本公式，也不是选择 MCP 或 A2A 的判据。现实中仍要分别处理：
- 工具或任务的名称、输入、结果和错误是否真的同义；
- 每条连接的身份、授权和数据范围；
- 版本兼容、部署、监控和运行成本；
- 返回内容是否可靠，是否满足当前任务。
如果现实只连接其中几对，原本的定制适配也不会达到 M×N。共同协议减少的是「每一对都重新约定接口形状」的重复工作，不能自动统一业务语义，更不能把总成本直接从乘法变成加法。
九、协议不是信任、授权或正确性的证明¶
协议让双方用共同格式沟通，不会自动让对方可信。要把四个问题分开：
| 问题 | 它要确认什么 | 协议能否单独解决 |
|---|---|---|
| 互操作 | 双方能否按共同规则交换信息 | 这是协议主要改善的部分 |
| 认证 | 对方是谁 | 协议可以承载方法，仍要实际验证 |
| 授权与同意 | 对方现在允许做什么，用户是否同意 | 仍由 Host 与服务端执行策略 |
| 结果正确性 | 返回内容是否真实、可靠并满足任务 | 仍要核验，协议不能担保 |
对 MCP 来说，Host 要决定允许连接哪些 Server、开放哪些能力以及哪些数据可以送出；Server 仍要检查调用方是否有权执行动作。工具说明和返回结果来自外部，也不能因为使用共同协议就默认可信。
对 A2A 来说，Agent Card 只是远端对身份、能力与安全要求的声明。它不表示当前请求已经获得授权，也不证明 Artifact 内容正确。
协议解决“怎样交谈”，认证与授权解决“能不能做”，结果核验解决“做得对不对”。
十、三条结论¶
一，先分能力调用与任务委托，再看接口是否需要共同协议。 能力调用只把一个边界清楚的能力请求交出去；任务委托把目标及其内部执行责任交给远端 Agent。直接 API 可以承载两者；采用共同协议时，前者主要由 MCP 表达，后者主要由 A2A 表达。
二，MCP Tasks 与 A2A Task 有功能重叠，但属于不同关系网。 两者都能表示持续工作，不能用「短或长」「无状态或有状态」机械区分。MCP Tasks 跟踪异步持续的工具调用；A2A Task 则与 Agent Card、Message 和 Artifact 一起表达独立 Agent 之间的协作。
三，共同协议减少的是重复适配，不是全部系统风险。 M×N 到 M+N 只是满连接条件下对适配实现面的理想化说明。协议不会自动统一业务语义，也不会替代认证、授权、用户同意和结果核验。
十一、这一章引出的问题¶
现在，我们已经能区分「调用外部能力」与「委托远端任务」。但能委托，不等于值得把系统拆成多个 Agent。每项独立职责能否在结束时被验收或接续，是拆分边界能否成立的基础；并行、上下文隔离或独立核验只是可能的收益，还要看这些收益能否盖过交接、等待和合并成本。
下一章会用这些条件判断什么时候该拆，什么时候不该拆。
十二、自检题¶
- 主程序希望通过共同协议发现并调用一个搜索工具，拿回结果后继续自己的流程。这更匹配 MCP，还是 A2A？为什么？
- 直接 API 为什么不能简单归入「能力调用」一类？
- MCP 的 Host、Client 和 Server 各负责什么？谁决定开放哪些能力，以及结果怎样进入应用侧过程？
- MCP 2026-07-28 核心没有隐式会话，为什么浏览器实例或购物车仍能跨多次调用存在？
- A2A 的 Agent Card、Message、Task 和 Artifact 各起什么作用？
- MCP 有了 Tasks 扩展，是否就与 A2A 没有区别？判断时应该检查哪些协议对象？
- 一个 A2A Remote Agent 内部能否使用 MCP，再由 MCP Server 调用专有 API？
- M×N 接近 M+N 为什么不能被解释成总成本一定按同样比例下降？
- Agent Card 声明了能力与安全要求，是否已经证明当前调用获得授权、最终结果正确？
十三、参考答案¶
先自己答完再往下看。
- 更匹配 MCP。 调用方交出去的是一个被点名的搜索能力，不是整项调研目标；结果返回后，运行系统仍决定下一步。
- 因为「直接」只说明接口由提供方自行定义。 这个接口既可以暴露一个动作，也可以接受目标并负责一项完整任务。
- Host 管应用侧协调，Client 管连接，Server 管能力。 Host 包含运行系统，承载模型、上下文、同意与安全策略，并决定开放哪些能力、怎样使用结果；Client 在 Host 内连接一个 Server；Server 暴露并执行工具、资源或提示模板。
- 用显式业务标识续接。 后续请求带回
browser_id或cart_id，Server 据此读取状态。请求自包含，不等于应用不能保存状态。 - Agent Card 说明远端声称是谁、会什么、怎样访问；Message 承载一次交流；Task 表示工作的状态与生命周期；Artifact 承载正式成果。
- 不是。 MCP Tasks 跟踪异步持续的工具调用；A2A Task 位于 Agent Card、Message、Task 和 Artifact 组成的 Agent 协作关系中。MCP 在 Task 创建前可以返回缺少的输入，让 Client 补齐后重新发起工具调用；Task 创建后也可以进入等待输入状态，再由 Client 更新任务。因此不能用「能否补充信息」区分 MCP 与 A2A。要检查对外协议对象，而不是只数有没有 Task。
- 可以。 A2A 负责外层的任务委托，远端 Agent 可以在内部通过 MCP 使用能力，MCP Server 又可以封装专有 API。
- 因为 M×N 与 M+N 只比较满连接情况下的适配实现种类。 业务语义映射、授权、部署、运行和结果核验仍各有成本。
- 没有。 Card 是声明，不是授权结果或质量证明；身份、权限和成果仍要分别验证。
上一章：第 7 章 记忆与检索：让旧信息在需要时重新进入上下文 下一章：第 9 章 多 Agent：什么时候值得，什么时候是自找麻烦