多 Agent 协调的协议层：工具调用之外，还缺什么
前三篇分别讨论了 Harness 的控制边界、Agentic Memory 的检索本质、工作流编排的状态管理。这篇往上走一层：当多个 Agent 需要真正协作时，协议层是什么样的？
已解决的问题和还没解决的问题
先做一个现状判断。
工具调用协议，基本成熟。 MCP（Model Context Protocol）在过去一年里建立了事实上的标准：Server 暴露工具，Client（即 Agent）发现并调用工具，协议规范了这个过程的格式和语义。工具生态正在围绕 MCP 收敛，这是好事。
Agent 与 Agent 之间的协调，仍然是空白。 当 Orchestrator Agent 需要把一个子任务委派给 Executor Agent 时，这个委派用什么协议完成？Executor 执行过程中遇到阻塞，怎么上报给 Orchestrator？两个 Agent 对同一个目标有不同理解时，分歧用什么机制协商解决？
这些问题，MCP 没有回答。现有的多 Agent 系统大多用私有约定或者硬编码的消息格式解决，可以跑起来，但不具备互操作性，更难以维护和演化。
A2A（Agent-to-Agent Protocol）是 2025 年初 Google 提出的一个方向，试图填补这个空白。方向是对的，但规范本身还很早期——它解决了能力发现和任务委派的形式，但绕开了最难的问题：信任模型。
多 Agent 协调实际需要什么
我把 Agent 之间的协调需求拆成四个维度，每个维度都有独立的复杂度。
1. 能力发现（Capability Discovery）
Orchestrator 在委派任务之前，需要知道有哪些 Agent 可用，每个 Agent 能做什么、擅长什么、有什么限制。
这听起来类似服务注册。但 Agent 的能力不像 REST API 那样可以用 OpenAPI 规范描述清楚——Agent 的能力是自然语言语义层面的，”善于处理代码 review”和”善于处理 Python 代码的安全性 review”之间的差异，不是一个字段值的差异，是语义层面的差异。
实践中的问题：能力描述越精确，越难维护，越容易过时。能力描述越模糊，Orchestrator 委派时的匹配精度越低，可能把不合适的任务交给了不合适的 Agent。
目前没有好的通用解法。我们内部采用的是分层描述：粗粒度的能力标签用于初步筛选，Agent 的完整系统提示作为精细能力描述在需要时传给 Orchestrator 进行深度匹配。粗糙但够用。
2. 任务委派与上下文打包（Task Delegation）
委派不是把任务描述原文转发给 Executor。
Executor 需要完成子任务，但它没有 Orchestrator 拥有的全局上下文。Orchestrator 需要从全局上下文中提取出 Executor 完成子任务所需要的最小上下文集合，打包后随任务一起发出。
这个”最小上下文”的界定，是委派协议里最难的部分：
- 给太少：Executor 缺少必要信息，要么反复向 Orchestrator 请求补充，要么基于错误假设执行
- 给太多：Executor 的 context 窗口被不相关信息占据，干扰推理，增加成本
一个具体的例子：Orchestrator 在处理一个”重构代码库的身份验证模块”的任务，把”修改 middleware 层”委派给 Executor。Executor 需要知道：当前 middleware 的代码、目标接口规范、约束条件（不能破坏向后兼容）。但不需要知道：为什么要重构（业务背景）、其他模块的重构计划、代码库的整体架构历史。
做这个判断本身需要推理能力——Orchestrator 要理解子任务的语义，才能判断哪些上下文是必要的。这意味着这个”打包”步骤不是纯机械的，是有成本的。
3. 进度上报与状态同步（Progress Reporting）
子任务执行过程中，Orchestrator 需要知道发生了什么。
最简单的模型：执行完再汇报结果。这在短任务里没问题，在长任务里是灾难——Orchestrator 对执行过程一无所知，无法判断是否需要干预，也无法做并行的任务规划。
更好的模型：结构化的中间状态上报。Executor 在执行过程中，在关键节点（完成一个子步骤、遇到阻塞、发现新信息）向 Orchestrator 发送状态更新。状态更新不是自由文本，而是结构化的：当前步骤、完成度估计、是否需要 Orchestrator 决策、预计剩余步骤。
这里有一个协议设计上的取舍：上报频率和上报粒度。频率太高，Orchestrator 被状态更新淹没，干扰自身推理；粒度太细，每条更新携带的信息量不足，Orchestrator 难以据此做决策。
我们的实践：只在”决策节点”上报——Executor 需要 Orchestrator 输入才能继续时，强制上报；其他中间步骤记录到状态存储，Orchestrator 可以查询但不推送。这把主动通知和被动查询分开，减少了 Orchestrator 的干扰，同时保留了完整的可观测性。
4. 信任与权限传递（Trust Delegation）
这是最少被讨论、但最重要的问题。
当 Orchestrator 把任务委派给 Executor，Executor 以谁的权限执行？
场景 A：Executor 有自己的固定权限，独立于 Orchestrator。Executor 只能做它被授权能做的事，Orchestrator 的委派不能扩展 Executor 的权限。
→ 优点：权限边界清晰，Executor 的行为是可预期的
→ 缺点：如果 Executor 完成任务需要的权限超出了它自身的授权，任务就会失败，即使 Orchestrator 具备这个权限
场景 B：Orchestrator 可以把自己的部分权限委派给 Executor。Executor 在特定任务范围内，能做 Orchestrator 授权它做的事。
→ 优点：灵活，任务不会因权限不足失败
→ 缺点：权限传递链变长，难以审计；如果 Orchestrator 被攻击或者行为异常，它可能把过高的权限传递出去
这个问题在传统系统里有成熟的解法——OAuth 的 scope 委派、Kubernetes 的 RBAC 角色绑定——但在 Agent 场景里有额外的复杂度：Agent 的行为是不确定性的，你很难预先定义”完成任务 X 所需要的最小权限集合”，因为任务 X 的执行路径是动态的。
目前没有行业标准。我们内部倾向于场景 A 的变体：每类 Executor Agent 有预定义的能力边界，Orchestrator 只能委派 Executor 能力范围内的任务，不能动态扩权。代价是 Orchestrator 需要在委派前做能力匹配，任务规划更保守。但这个约束让整个系统的行为变得可审计——每个 Agent 的行为边界是静态定义的，不依赖运行时的委派链。
当前协议的实际差距
A2A 规范覆盖了能力发现（AgentCard）和任务委派（Task 对象）的形式。这是好的起点。
它目前回避的问题：
身份认证：Agent A 怎么确认它在和真正的 Agent B 通信，而不是一个冒充 B 的恶意 Agent？在单机或者受控环境里这不是问题，但在分布式的、跨组织的多 Agent 系统里，这是必须解决的。A2A 规范提到了”企业级认证需求”，但没有给出具体方案。
权限模型：如上所述，A2A 没有定义权限传递的语义。委派的边界完全由各方实现自行定义，导致互操作性存疑。
状态同步：A2A 的 Task 状态机（submitted / working / completed / failed）过于简化。生产环境里 Agent 的执行状态远比这四种更细，阻塞类型、失败原因、部分完成的定义，都需要更丰富的语义。
冲突协商：两个 Agent 对同一个资源有操作意图时（典型场景：两个 Executor 都需要修改同一份配置文件），A2A 没有冲突检测和协商机制。这在单 Orchestrator 架构里可以由 Orchestrator 协调，但在更复杂的 P2P Agent 网络里是开放问题。
开源治理视角的补充观察
作为一个开源团队的负责人，我有一个额外的视角：多 Agent 协议的标准化，高度依赖开源社区的参与。
MCP 之所以能在短时间内成为事实标准，关键原因是 Anthropic 以开放协议而非产品特性的形式发布它，并且核心实现是开源的。社区可以贡献 Server、审查规范、发现问题。这个模式加速了协议的成熟。
A2A 的路径类似，但生态成熟度还差得远。目前开源社区里大多数多 Agent 实现仍然依赖私有约定。这不是工程偷懒，是协议规范不成熟时的合理选择——过早采用不稳定的标准，迁移成本反而高。
判断标准是：当你开始看到不同团队独立实现的 Agent 之间，通过协议而不是自定义代码成功互操作，那时候才是协议真正成熟的信号。这个信号目前还没有出现。
在那之前，合理的工程决策是：在内部保持接口清晰和语义一致，但不要过度依赖任何外部协议规范。接口清晰意味着未来迁移到标准协议的成本低；不过度依赖意味着规范演化时不会被动跟进。
总结这个系列的核心判断
到这里，这个系列的四篇文章构成了一个完整的视角：
- Harness：Agent 的行为边界。工具、权限、钩子，让自主性在受控范围内发挥。
- Memory：Agent 的持久化状态。不是存储问题，是检索问题，是”在对的时刻把对的信息给模型”。
- 工作流编排：多步任务的结构化。状态外化、混合编排器、尽早暴露失败。
- 协调协议：多 Agent 的互操作基础。能力发现、任务委派、权限传递，目前仍处于早期。
这四个层次共同构成了 Agent 基础设施的核心框架。不是每个应用都需要所有四层——简单的单 Agent 任务只需要 Harness 和 Memory。但随着任务复杂度提升，后两层迟早要面对。
协议层的缺失不会阻止 Agent 系统在生产环境运行。但它会让每一个多 Agent 系统都变成一座孤岛，内部自洽，对外不透明。
行业需要的不只是更强的模型，而是让这些模型可以被工程化、可以互相协作、可以在组织边界之间流动的基础设施。协议层是这个基础设施里最后一块还没被认真对待的拼图。