这是什么

掘金上一篇工程实践把 Multi-Agent 系统的 5 类失败全部指向 AI 之间的交接 — 没有一类出在 AI 自身能力上。

Multi-Agent（多 AI 协作），就是让多个 AI 像团队一样分工干活：Planner 拆任务 → Researcher 查资料 → Coder 改代码 → Reviewer 挑错 → Publisher 输出。Demo 跑得很顺，搬到生产线后，最先坏的环节是上游 AI 说"我完成了"，下游 AI 接到一坨聊天记录，根本不知道对方做了什么、依据是什么。

这篇实践提出"Handoff Contract（交接合同）"思路：交接不是塞消息，而是写一份像后端接口一样可检查、可拒收的协议，至少包含 8 类字段（任务、上下游、输入包、状态游标、权限边界、证据包、验收标准、回执）。

行业怎么看

我们注意到，这一视角呼应了业内共识：Agent 项目落地瓶颈正从模型能力转向工程与流程。但反对声音同样值得警惕。一部分工程师认为，很多团队根本不需要 Multi-Agent，单 Agent 加工具调用就能解决 80% 场景，现在谈交接协议，是给一个还没成熟的范式过早画图纸。另一层风险是："合同"听起来严谨，反而可能把协作失败的锅从 AI 能力推给工程规范，掩盖模型本身短板。

对普通人的影响

  • 对企业 IT：采购 Multi-Agent 方案，比起追问模型能力，更值得问供应商："你们的交接协议怎么设计？失败时谁负责？"
  • 对个人职场：AI 协作工具进入办公室后，员工可能要重新理解"任务交接" — 不是丢文件，而是写清输入、约束、验收标准。
  • 对消费市场：短期内 AI 产品仍以单 Agent 为主；Multi-Agent 大规模进入消费者端，还要等工程框架先成熟。