Agent 协作机制：服务发现 → 能力对齐 → 状态交接（口播版）
面试高频问题：多个 Agent 之间怎么协作？有了 MCP 是不是就够了？ 一句话答案：不够。Agent 协作要过三层逻辑：服务发现（有哪些伙伴、各自会干什么）、能力对齐（做成什么样算合格，靠契约不靠人设）、状态交接（传状态 + 引用，不传整段对话历史）。MCP 解决的是 Agent 接工具的纵向问题，协作机制解决的是 Agent 之间分工的横向问题，两者不是一回事。落地用协调者模式，重点治语义漂移。 适用面次：三面综合 / 架构深挖 本版定位：口语应答脚本 —— 是 22 号 的机制篇：22 号讲"什么时候用、怎么部署"，本篇讲"用了之后 Agent 之间到底怎么配合"。冲突并发问题另见 19 号。
【30 秒极简版】（面试官随口一问时用）
先澄清一个常见混淆：MCP 不等于协作机制。MCP 是 Agent 接工具、接数据的标准协议，是纵向的、单次调用的；协作机制是 Agent 和 Agent 之间怎么分工、怎么交接，是横向的、跨多轮带状态的。MCP 不解决调度、不解决状态交接、也不解决冲突仲裁。 协作本身要过三层：服务发现——靠能力注册表（Agent Card：能力、输入输出 schema、权限、成本档）做语义检索，不是硬编码调用方；能力对齐——对齐的是契约不是人设，靠 schema 加完成判据，而不是靠 system prompt 写"你是一个资深专家"；状态交接——交接包包含已完成什么、当前状态、待办与判据、失败记录，原则是传状态加引用，不传整段对话历史，而且要有接收方回执。 落地用协调者模式：一个协调者负责拆分、分发、汇总、仲裁，子 Agent 之间不横向通信——可控、可观测、好排查。最大的落地痛点是语义漂移，靠术语表、交接包 schema 化、实体用 ID 来治。
【2 分钟完整口播】（正式被问到时的主干回答）
我先澄清一个很容易混的概念：MCP 不等于 Agent 协作机制。 MCP 解决的是 Agent 怎么接工具、怎么取数据——是纵向的、一次调用就结束的协议，它标准化的是"手"。而 Agent 协作解决的是 Agent 和 Agent 之间谁来做、做成什么样、怎么交接——是横向的、跨多轮带状态的。MCP 不管调度，不管状态交接，也不管冲突仲裁。一句话：MCP 是手，协作机制是组织。 两者是互补关系，不能互相替代。
协作本身要过三层逻辑。
第一层，服务发现。一个 Agent 怎么知道有哪些伙伴、各自会干什么？靠能力注册表，可以理解为每个 Agent 都有一张 Agent Card：名字、能力描述、输入输出 schema、权限范围、SLA、成本档。注册进来，有心跳探活。调用方不是硬编码"去找 3 号 Agent"，而是按能力做语义检索——我需要"能从 PDF 提取表格"的能力，注册表帮我找谁有。这样新增 Agent 不用改调用方代码，这是解耦的关键。
第二层，能力对齐。找到之后要对齐"你能做成什么样"。这里有个很重要的立场：对齐的是契约，不是人设。很多人的做法是给每个 Agent 写一大段 system prompt——"你是一个资深财务分析师，请严谨认真地…"——这是人设，不是契约，它不可校验、会因为措辞不同产生理解偏差。我用的契约是三样：输入输出的 schema、能力边界声明（明确写"不做什么"）、完成判据（做成什么样算合格）。schema 和判据是可校验的，人设不是。而且 schema 要版本化，有兼容策略，不然一个 Agent 升级就全链路崩。
第三层，状态交接，这是最容易出问题的一层。任务从 A 转到 B，交接包里必须有四样：已完成什么（做到哪了）、当前状态（结构化的，不是一段话）、待办与判据（接下来做什么、做到什么算完）、失败与尝试记录（试过什么、为什么没成，避免 B 重复踩坑）。原则是：传状态加引用，不传整段对话历史——历史存在外部，给 ID 让 B 按需取，别整段复制过去，那样既烧 token 又会把 A 的上下文偏见带给 B。而且交接要有确认：接收方回执确认理解一致，避免静默误解——A 以为说清楚了，B 理解成了另一回事，跑完才发现。
落地模式用协调者模式：一个协调者负责任务拆分、分发、汇总、冲突仲裁，子 Agent 之间不做横向通信。这样做的好处是可控、可观测、好排查——所有决策都经过一个点，出问题看协调者的日志就够了。代价是协调者会成瓶颈，规模上去了要分片或者去中心化。
最大的落地痛点是语义漂移——同一个概念在 Agent 之间传几手就变味了。比如"高风险客户"，A 理解成逾期 90 天，B 理解成投诉过三次，C 又加了层自己的理解，最后汇总出来的东西跟原始目标已经不是一回事。治法三条：术语表随交接包传递（领域词典，明确定义）、交接包 schema 化（不允许自由文本交接，自由文本就是漂移的温床）、关键实体用 ID 不用描述（客户用 customer_id，不要写"那个高风险客户"）。最后在终点做一次与原始目标的一致性回检。
一句话收尾：多 Agent 协作本质是分布式系统问题，不是提示词问题——要靠注册表、契约、交接协议来解决，不是靠把 prompt 写得更长。
一、先澄清：MCP ≠ 协作机制（第一得分点）
开口说：
这两个不是一个层面的东西，混为一谈是这题最大的露馅点。
| MCP | Agent 协作机制 | |
|---|---|---|
| 解决什么 | Agent ↔ 工具 / 数据 | Agent ↔ Agent |
| 方向 | 纵向（接工具） | 横向（分工协同） |
| 范围 | 单次调用 | 跨多轮、带状态 |
| 管不管调度 | ❌ 不管 | ✅ 谁来做 |
| 管不管状态交接 | ❌ 不管 | ✅ 怎么交接 |
| 管不管冲突仲裁 | ❌ 不管 | ✅ 归 19 号 |
得分句："MCP 是手，协作机制是组织 —— 手再多，没有组织也干不成活。"
二、三层逻辑（核心，必背）
速记：找得到（发现）· 对得齐（契约）· 交得清（交接）
层一：服务发现
| 项 | 内容 |
|---|---|
| 载体 | 能力注册表 / Agent Card：名称、能力描述、输入输出 schema、权限范围、SLA、成本档 |
| 机制 | 注册 → 心跳探活 → 按能力语义检索 |
| 关键 | 调用方按能力检索，不硬编码调用对象 → 新增 Agent 不改调用方代码（解耦） |
层二：能力对齐
⚠️ 核心立场：对齐的是契约，不是人设。
| 契约三件套 | 说明 |
|---|---|
| 输入输出 schema | 可校验、可版本化（兼容策略必须有，否则一个 Agent 升级全链路崩） |
| 能力边界声明 | 明确写"不做什么"——边界不清就是扯皮的起点 |
| 完成判据 DoD | 做成什么样算合格（呼应 20 号） |
反例（说出来很加分）：靠 system prompt 写"你是一个资深财务分析师，请严谨…"——这是人设，不可校验、会因措辞产生理解偏差；契约才是可执行的。
层三：状态交接
交接包四要素：
| 要素 | 内容 |
|---|---|
| 已完成什么 | 做到哪一步，产出在哪（引用 ID） |
| 当前状态 | 结构化 state，不是一段自由文本 |
| 待办与判据 | 接下来做什么、做到什么算完 |
| 失败与尝试记录 | 试过什么、为什么没成——防止下游重复踩坑 |
两条硬原则：
- 传状态 + 引用，不传整段对话历史 —— 历史存外部给 ID，按需取。整段复制既烧 token，还会把上游的上下文偏见带给下游。
- 交接要有回执确认 —— 接收方确认理解一致，避免静默误解（A 以为说清了，B 理解成另一回事，跑完才发现）
三、落地模式：协调者模式（Supervisor）
| 项 | 内容 |
|---|---|
| 职责 | 任务拆分 → 分发 → 汇总 → 冲突仲裁 |
| 约束 | 子 Agent 不做横向通信（所有交互过协调者） |
| 优点 | 可控、可观测、好排查——出问题看协调者日志即可（呼应 22 号 层级分发） |
| 代价 | 协调者成瓶颈 → 规模上去要分片 / 去中心化（详见 19 号） |
变体（可提一句）：流水线式点对点交接、黑板/共享状态模式（多 Agent 读写共享状态，需版本控制）。
四、最大落地痛点：语义漂移
开口说：
同一个概念传几手就变味——"高风险客户"，A 理解成逾期 90 天，B 理解成投诉三次，C 再加一层自己的理解，汇总时已经不是一回事了。
| 治法 | 做法 |
|---|---|
| 术语表随包传递 | 领域词典随交接包走，关键概念明确定义 |
| 交接包 schema 化 | 禁止自由文本交接——自由文本就是漂移的温床（呼应 23 号） |
| 关键实体用 ID | 用 customer_id，不要写"那个高风险客户" |
| 终点一致性回检 | 汇总后与原始目标对齐回检（呼应 10/20 号的目标对齐） |
五、其他落地痛点（简版）
| 痛点 | 解法 |
|---|---|
| 责任归属 | 谁的产出谁负责——交接包签字（产出 + 判据 + 责任人），便于归因 |
| 循环依赖 | A 等 B、B 等 A → 依赖图检测，规划期打断（呼应 10 号依赖校验） |
| 成本 | 模型分级 + 上下文按角色裁剪 + 早停（详见 22 号） |
六、避坑提醒
- ❌ "有了 MCP 就能多 Agent 协作" → ✅ MCP 是接工具，不管调度/交接/仲裁，必须先澄清
- ❌ 靠 system prompt 人设对齐能力 → ✅ schema + 边界声明 + DoD 判据（契约可校验，人设不可）
- ❌ 交接时整段复制对话历史 → ✅ 传状态 + 引用 ID，按需取
- ❌ 交接完就不管了 → ✅ 要回执确认，防静默误解
- ❌ 用自由文本做交接包 → ✅ schema 化，自由文本是语义漂移的温床
七、面试官在考什么
| 维度 | 你的证据 |
|---|---|
| 概念清晰度 | 能区分 MCP（纵向接工具） 与 协作机制（横向分工），不混谈 |
| 分布式思维 | 把协作抽象成服务发现 / 契约 / 交接三层，对应注册中心、接口契约、状态传递 |
| 工程细腻度 | "对齐契约不对齐人设""传状态不传历史""交接要回执"三条都是踩过坑才说得出的 |
| 痛点意识 | 主动点出语义漂移这个多 Agent 头号杀手并给出三招 |
| 体系一致性 | 与 19（冲突）、22（边界）、23（schema）、20（判据）闭环 |
八、追问预案（Q&A 演练）
Q1：MCP 和 A2A 这类协议是什么关系？
都是协议，但层次不同：MCP 标准化的是 Agent 调工具/取数据（纵向）；A2A 这类 Agent 间协议标准化的是 Agent 之间怎么发现和对话（横向）。但协议只解决"能通信"，不解决"怎么协作"——调度、契约、交接、仲裁这些仍要你在应用层设计。所以我的答案是：协议是地基，三层机制是上层建筑。
Q2：协调者成了瓶颈怎么办？
分级：小规模够用（好排查）；中规模按业务域拆多个协调者；百级以上走去中心化——规划期提前分片避开冲突，执行期用 CRDT 无冲突合并（详见 19 号）。
Q3：交接包 schema 化会不会太重？
按任务复杂度分级：简单交接（一句话能说清的）用轻量 schema；跨 Agent、跨阶段、涉及业务判据的必须完整 schema 化。原则是——交接内容越重要，格式约束越强，跟结构化输出是同一个道理。
Q4：怎么知道漂移已经发生了？
三个信号：子 Agent 产出的术语与术语表不一致、同一实体在不同 Agent 处描述不同、汇总时发现判据无法对齐。工程上加一条：交接包里带术语版本号，版本不一致就告警。
Q5：Agent 能力重叠，该派给谁？
注册表里除了能力，还要有成本档、SLA、历史成功率。调度时按"能力匹配度优先，成本与成功率次之"排序；如果差异小，就交给历史成功率高的——这是数据驱动的分派，比随机或固定分配强。
全篇串联（考前 10 秒扫这个）
先澄清：MCP 是手（纵向接工具）· 协作是组织（横向分工）— 不可替代
→ 三层：服务发现（Agent Card + 语义检索）· 能力对齐（契约三件套，不对齐人设）· 状态交接（四要素 + 传状态不传历史 + 要回执）
→ 模式：协调者（拆分·分发·汇总·仲裁，子 Agent 不横向通信）
→ 痛点：语义漂移（术语表 · schema 化 · 实体用 ID · 终点回检）
→ 收尾：多 Agent 协作是分布式系统问题，不是提示词问题关联笔记：22多Agent场景边界与部署模式-串行与层级分发（前置篇：什么时候用多 Agent、两种部署模式，本篇是其协作机制展开）、19多Agent协同冲突规避-任务分片仲裁与状态版本控制（并发冲突与版本控制的细节，本篇不重复）、09多Agent架构取舍-客服场景为什么不用多Agent（最上层取舍：什么时候不该上）、23结构化输出兜底-四层架构与强类型校验（交接包 schema 化的格式保障）、20Agent长任务不跑偏也不摆烂-目标铰链与反敷衍机制（DoD 判据 + "传引用不传全文"立场同源）、10Agent长任务失控治理-任务管控三层体系与执行闭环（依赖校验与终点一致性回检）