多智能体协作的工程边界：MCP 管“能做什么”，A2A 管“任务怎么流转”

单个 Agent 调工具的系统里，故障模式很直接：工具参数错了、超时了、返回了模型不理解的结果。当系统拆成规划、检索、执行、审核多个 Agent 之后，故障模式的性质变了：工具参数没有统一格式，Agent 之间传递了无法解析的自然语言；执行 Agent 重复提交订单或重复发送通知；一个 Agent 失败后，上游无法判断任务是否已经执行；更换模型供应商后，调用代码、重试策略和审计字段散落在各处。

MCP 和 A2A 各自解决一个方向的问题，但它们不是同一层的东西。MCP 是“Agent 到能力”的适配层：服务端暴露工具、资源或提示模板，客户端根据定义调用，每个工具至少要有名称、用途说明和参数模式，参数模式最好是 JSON Schema 或等价的结构化描述，以便在调用前校验。MCP 的关键价值不是“让模型自动执行一切”，而是把外部能力从提示词里分离出来，让查询工单、读知识库、创建待办成为独立工具，各自拥有不同的权限、超时和审计策略，模型只能选择已经被授予的能力。

A2A 风格接口是“Agent 到 Agent”的协作层：代理之间的协作应该像调用一个远程服务，而不是把一段自然语言塞进另一个 Agent 的上下文。一个可执行的任务消息需要包含任务标识、发起方、目标代理、输入数据、幂等键、截止时间和当前状态；状态至少要区分 submitted、running、succeeded、failed 和 cancelled，状态变化由服务端记录，而不是由模型自行声称“已经完成”。长任务由调用方先获得任务编号，再通过查询接口或事件订阅获取结果。

两者结合后的边界可以概括为：编排器通过 A2A 分派任务，Agent 内部通过 MCP 调用具体能力。A2A 负责任务生命周期——谁发起的、目标是谁、幂等键是什么、当前状态、截止时间；MCP 负责能力执行——工具名、参数 Schema、权限、超时。业务系统负责最终一致性和权限约束，而不是让协议层去承担这些职责。

一个容易被忽略的工程细节是任务契约要先于提示词定义。工单分类任务的输入应该是一个结构化的 JSON，包含 task_id、task_type、source_agent、target_agent、idempotency_key、deadline 和输入数据；输出也应该是结构化的，明确置信度和需要人工介入的条件，而不是一段自由文本。契约先行的好处是：A2A 的任务状态机和 MCP 的工具校验都有了一个确定的锚点，Agent 之间的交互不再依赖“模型能不能从自然语言里猜出意图”。多智能体系统不是聊天群，它是需要任务契约、幂等键、状态机和审计的分布式系统；MCP 和 A2A 提供了协议层的积木，但工程边界需要由业务系统来划定。