实践篇：MCP 用于 Tools，A2A 用于 Agents¶

很多团队会过早把两类问题混在一起：

• 如何连接工具和外部系统；
• 如何让多个智能体相互协作。

于是 MCP 和 A2A 看起来就像可以互换的东西。实际上，它们属于不同的架构层级。

1. 一条最短规则¶

如果要最短版本：

• MCP 用于连接工具、资源和适配器；
• A2A 用于智能体之间交换任务、上下文与结果。

换句话说，一个协议主要解决 智能体到工具，另一个协议主要解决 智能体到智能体。¹²

2. 什么情况下你几乎一定需要 MCP¶

如果你有一个或多个外部能力需要被系统化接入，MCP 很自然：

• 文档搜索；
• CRM；
• helpdesk；
• internal APIs；
• 文件资源；
• 知识库；
• 执行沙箱。

这时你的主要目标不是“构建一个智能体社会”，而是：

• 标准化契约；
• 把适配器从核心运行时中分离出去；
• 简化 policy checks；
• 集中处理 logging、auth 和 isolation。

这正是 MCP 最合适的位置。

3. 什么情况下你才真的需要 A2A¶

当系统里已经不只是工具，而是出现了真正独立的智能体，并且它们各自承担不同职责时，A2A 才合理：

• coordinator；
• researcher；
• analyst；
• executor；
• domain specialist。

这些智能体需要：

• 相互分发任务；
• 委派工作；
• 交换状态；
• 返回的不是工具载荷，而是另一个智能体的工作结果。

也就是说，A2A 出现的前提不是“我还想再接一个适配器”，而是系统里已经存在真实的智能体边界。

3.1. A2A 需要治理，不只是 handoff 协议¶

如果一个智能体可以把任务交给另一个智能体，平台需要治理的不只是消息本身，还包括不同 operational roles 之间的信任关系。否则 A2A 很快会变成一条不透明的委派链：没人说得清谁有权行动、应用了哪条 policy、以及结果归谁负责。

A2A 的最小治理契约应该记录：

• 调用智能体和执行智能体的 identity；
• delegated authority 的边界和生命周期；
• capability discovery：智能体可以发现和调用哪些角色；
• handoff、中间状态和最终结果的 audit trail；
• 委派之前以及外部 side effects 之前要执行的 policy checks。

一个简单的生产检查是：如果事故复盘时无法还原哪个智能体把什么任务委派给谁、依据哪条 policy、使用了哪个 scope，那么 A2A 轮廓还没有达到 production-ready。

扩展版 A2A 交接信任合约（A2A handoff trust contract） 还应该更具体：

• agent identity：每个 handoff 参与者都有稳定的 agent id、owner 和 operational role；
• delegation chain：委派记录保留原始发起者、中间智能体和最终执行者；
• allowed collaboration graph：平台明确规定哪些 agent roles 可以彼此调用；
• inter-agent authorization：接收方智能体不仅检查消息，还要检查调用方是否有权请求这个动作；
• policy inheritance：下游智能体继承原始请求的限制，而不是获得更宽的自由度；
• non-repudiation：handoff 被签名，或以其他方式绑定到 trace/evidence，使参与者之后不能否认这个步骤；
• failure attribution：telemetry 区分发起方错误、执行方错误、policy denial、tool failure 和外部环境不可用。

这个契约把 A2A 从“智能体之间的传输”变成受治理的 collaboration graph。没有它，多智能体系统看起来是分布式的，但事故调查时仍然像黑箱。

可审查的 A2A trust and delegation artifact 可以这样写：

a2a_trust_delegation:
  remote_agent_id: incident.coordinator.v2
  remote_agent_owner: sre-platform
  trust_tier: constrained_internal
  allowed_tasks:
    - collect_incident_context
    - draft_status_update
  forbidden_tasks:
    - customer_notification_without_approval
    - production_change_without_gate
  delegation_depth: 1
  context_sharing_policy: minimal_relevant_context_only
  memory_sharing_policy: no_profile_memory_write
  tool_access_via_remote_agent: incident_read_tools_only
  approval_propagation: original_approval_constraints_apply
  audit_correlation_id: trace_id:a2a_handoff_id
  failure_attribution: initiator_executor_policy_tool_external
  revocation_policy: revoke_on_policy_drift_or_owner_change

这个 artifact 应该用具体的 A2A failure modes 来审查：delegation laundering、context over-sharing、remote-agent impersonation、unbounded delegation chains、conflicting actions、lost accountability 和 cross-agent prompt injection。

4. 典型错误：过早做多智能体¶

实践里最常见的混淆往往是这样：

1. 团队现在只有一个运行时。
2. 需要接入三套系统。
3. 团队没有先做能力契约，而是直接开始设计多智能体编排。

这几乎总是额外复杂度。

如果系统里还没有真正需要拆分智能体责任的理由，那么：

• 工具更适合通过 MCP 接入；
• 编排更适合留在一个运行时里；
• 多智能体协调最好先不要过早引入。

一个很好用的实用规则是：如果这个实体不会独立做决策，也没有独立的运营角色，那它大概率还不是智能体，而只是能力。

4.1. 当前多智能体可靠性研究更多是在强化谨慎态度¶

这里还值得补上一点。最新的多智能体可靠性研究，目前并没有给出足够强的理由，支持团队默认把运行时提前做得更复杂。相反，它更清楚地展示了：一旦系统在没有明确必要性的前提下被拆开，协调失效、验证缺口和歧义会迅速增长。

所以更实际的解读应该是：

• 研究并不是在说“多建一些智能体”；
• 研究更像是在说“如果你已经决定做多智能体，就必须有明确契约、验证回路和可诊断交接”；
• 当前最佳实践依然是 single-agent first。

因此，引入 A2A 的理由不应该只是“架构上看起来更漂亮”，而应该是系统里确实已经存在无法再诚实描述成工具的独立运营角色。

4.2. 多个智能体的一致意见不等于独立验证¶

即便多个智能体得出了相似结论，也不代表系统已经获得了真正独立的验证信号。

常见问题通常包括：

• 智能体看到的是同一份受污染上下文；
• 推理路径过于相似；
• 管理器智能体在无形中把下游智能体推向预期答案；
• 共识看起来很有说服力，但其实建立在同一个错误假设上。

所以多智能体一致意见更适合作为一种信号，而不是正确性证明。

5. 决策表¶

6. 在成熟架构里它们长什么样¶

在成熟平台中，这两者通常不是竞争关系，而是位于不同层次。

flowchart LR
    A["Coordinator agent"] --> B["A2A handoff"]
    B --> C["Specialist agent"]
    A --> D["MCP client"]
    C --> E["MCP client"]
    D --> F["Tool / resource server"]
    E --> G["Tool / resource server"]

健康的模式通常是：

• 智能体通过 MCP 使用工具；
• 智能体通过 A2A 与另一个智能体协作；
• policy 和 audit 要覆盖这两个方向。

7. 什么情况下不要用 A2A¶

下面这些都是危险信号：

• 你只是想把第二个智能体当成 API 包装器；
• 第二个智能体没有独立的策略表面；
• 它没有独立的运营身份；
• 用能力契约就能更简单地描述；
• 并行化与专门化并没有带来明确价值。

在这些情况下，继续使用 MCP，甚至普通的网关/适配器层，通常更合理。

8. 一个最小代码草图¶

下面这个极简示例，展示的是思维方式差异：

def call_tool_via_mcp(tool_name: str, payload: dict) -> dict:
    return {"kind": "tool_result", "tool": tool_name, "payload": payload}


def delegate_via_a2a(agent_name: str, task: dict) -> dict:
    return {"kind": "agent_result", "agent": agent_name, "task": task}

重点不在代码本身，而在交互语义：

• 工具调用返回的是能力结果；
• A2A 交接返回的是另一个智能体的工作结果。

这两者的运营语义不一样，最好不要混在一起。

9. 现在就该做什么¶

先过一遍这份短清单，把所有回答为“否”的地方单独记下来：

• 我需要的是一个新智能体，还是一个新能力？
• 这个实体是否拥有自己的角色、策略表面和生命周期？
• 这是委派问题，还是集成问题？
• 我能不能解释为什么这里 MCP 不够用？
• 我是不是在真正需要之前，就过早做多智能体拓扑？

如果这些问题都答得不太稳，通常更安全的选择是先用 MCP，而不是 A2A。

10. 下一步做什么¶

• 第四部分：工具与执行
• 第 9 章：沙箱执行与 MCP 作为集成契约
• 第 10 章：幂等性、重试、速率限制与回滚边界
• 研究前沿：记忆、可观测性与多智能体可靠性
• 参考来源