我是小兵，一个动手派AI架构师。“AI工程化实战”系列第 14 篇。
三个好 Agent，串起来废了
第 13 篇《LLMOps 不完全指南》结尾我写过一句：楼盖好了、也管起来了，接下来是楼里住几个人、怎么分工。写那句话的时候我以为分工是道送分题——多一双手多一份力。
下一个业务就把这句话按回去让我重写了。
一条 Multi-Agent 协作链，三个 Agent 分工（检索 / 规划 / 执行）。我按第 13 篇的纪律把每个 Agent 的版本三元组都锁好、都过了评测门，三个单看都漂亮。
上线第一天就翻车：检索 Agent 返回一条字段不全的结果，规划 Agent 把它当事实用、还基于它编了个计划，执行 Agent 照着错计划动手。
三个好 Agent，串起来废了。
回滚的时候我又卡在第 13 篇那个老问题上，只是这次更难：模型名我知道，可那一刻链路上另外两个 Agent 是哪个版本、它们之间传的是什么，我答不上来——因为我从来没把整条 Agent 编排当过一回事。
多 Agent 不是加法，是 N-1 条没人管过的边
这条路上我踩过三个误区，一个比一个贵。
第一，把多 Agent 当“N 个单 Agent 的加法”。注意力全在“每个 Agent 的 Prompt 怎么写”上，单测全绿就觉得万事大吉。可节点只是 O(N)，边数最少是 N-1，一旦允许多对多（扇入 / 辩论 / 分层），上限直接冲到 O(N²)。
这不是我的体感。公开的失败模式分类（MAST，1600+ 条 trace、7 个框架）把多 Agent 的失败归纳成 14 种模式、3 大类，其中约 79% 是“规格 + 协作 / 协调”问题，不是基础设施、模型或工具故障。
第二，被“N 元组”的焦虑吓住。真做下来答案是：不会。每个 Agent 各自还是一个独立三元组，身份不升维、也不该升维。多 Agent 真正新增的是边，边该用一张单独的表管。
第三，把“拆多 Agent”当第一架构。拆解不是免费的：每多一个 Agent 就多一份 Prompt 维护、多一条要定契约的边、多一处要背锅的点。
量级上，多 Agent 普遍比单 Agent 贵，公开研究里普遍2–15 倍，最坏到上百倍。
先把结论撂这儿：三层结构，管的是边
Multi-Agent 协作 = 节点层 + 边层 + 顶层。
节点层是 N 个 Agent，每个各自还是一个三元组，原样复用第 13 篇。改某个 Agent 的 Prompt，只有它自己的指纹变，别的 Agent 一动不动。
边层是 N-1 条协作契约——这才是新增的、也是坑最多的东西。
顶层是那六样纪律：编排拓扑、单元门与端到端协作门两道评测、编排原子发布、跨 Agent 父子 trace 树、错误沿边归因、死循环与成本熔断。
一句话：管好每个 Agent，不等于管好一次协作。
边是什么？一张“谁调谁”的契约表
“边 / 协作契约”这词你可能想去搜，先一句话说圆：它就是一张“谁调谁、传什么 schema、超时怎么办、失败兜底给谁、最多转几圈”的表。
你把它当成微服务里的接口契约就行。在开放协议里，它落到 A2A 就是 Agent Card 到 Task 的那次交接；在失败研究里，它就是 handoff contract——下游默认不信任上游输入、要带置信分和溯源标签。
它跑不掉这几样字段：传什么 schema、超时多久、失败兜底给谁、最多走几步（max_hops）、最多烧多少钱，外加一个给这条边定身份的指纹。
关键的一句：边也是代码。只把每个 Agent 的 Prompt 进了版本控制不够——Agent 之间那条边也要进仓库、改动走 PR、能对账到版本号。
Agent 之间传的从来不是数据，是责任——A 的坏输出到了 B 手里，就是 B 的事实。
两道门：单元门全过，不等于协作门过
这是本篇最容易漏、也最反直觉的一条。
单元门测的是一个 Agent 的三元组，回答“这个 Agent 自己退步没有”；端到端协作门测的是一整个编排版本（N 个节点 + N-1 条边），跑一个完整任务，回答“这条链还能不能干活”。
只有协作门过了、编排指纹进了已验证编排表，才许上 serving。少了单元门，端到端挂了不知道是哪个节点的问题；少了协作门，N 个好 Agent 凑一起照样废。
公开口径也是同一条：单测式评测只看功能正确性、测不了整条链的协作；更硬的一条是结构化覆盖研究——一个 workflow 可以“端到端 benchmark 通过、却留着一堆结构义务没测”。
顺序链还有个量级要记着：错误沿边传播是复利式的。一个 95% 准确率的 Agent 把输出传给下一个，合成后掉到 90% 出头，再下一个 85% 左右，十个顺序 Agent 串下来只剩六成上下，还不如一个单 Agent。
demo 里这条是确定性的：三个单元门 pass_rate 全是 1.0、全绿，端到端协作门照样 0.4 < 0.8 判红，整条链被拦下。配套那两百来行可跑代码就把建节点、建边表、过两道门、编排原子发布、跨 Agent trace、沿边归因、熔断死循环全跑了一遍，纯标准库、离线可跑。
坑一：三个都过了评测门，串起来第一天就翻车
症状：单 Agent 单测全绿，上线后检索 Agent 返回一条字段不全的结果，规划 Agent 当事实用、编了个错计划，执行 Agent 照错计划动手。追责的时候三个节点谁都“没做错”——它们的单测都过了。
排查：根因不是哪个 Agent 不行，是每条边都没有契约——A 的输出对 A 自己合规、对 B 不完整，中间没有闸。跨 Agent 上下文污染最危险的地方在于：A 编造的“事实”格式合法、被 B 当事实接受、固化成底层假设，形式上没毛病、语义是假的。
修复：给每条边建协作契约（schema + 超时 + 兜底 + 步数上限），边上的 schema 闸当传输闸用。demo 里同一个坏结果，有闸时被拦在边上、没进下游；无闸时一路传到最下游炸掉，归因能把根因钉在那条具体的边上。
教训：单元门全过 ≠ 协作门过。多 Agent 的评测必须多一道端到端的门，抓的正是节点门看不见的边上的错。
坑二：两个 Agent 互相调用跑成环，一夜烧穿账单
症状：辩论型拓扑里 A 和 B 互相看对方意见再反馈，某一版 Prompt 让它们进入了“越辩越不服”的循环，谁也没退出条件，跑了一整夜。
排查：根因是边成了环、却没人给边设退出条件——单向边最多传错，环状边能无限跑。这不是运气差：环状拓扑的死循环是默认行为，微软 Azure 的架构指南里明确要求管理型 agent 要“防止无限修复循环”；公开的失败分类里也有一条 unaware-of-termination（不知道该停）。
修复：每条边带最大调用步数 + 整条链带总预算上限，超了直接熔断；辩论拓扑必须显式设“几轮之后强制仲裁”。demo 里辩论环 max_hops=3，转到第 8 步就被熔断，不是等它自己停。
教训：环状拓扑的死循环不是意外，是默认——没有退出条件的边，早晚会烧光；熔断要在设计时就焊进协作契约，不是出事后再加。
选型就一句：默认不拆
三条路线里，单 Agent 硬扛是默认、拆了不管边是坑、拆了且管边是重武器。
先默认走单 Agent；只有当“拆”能换到并行、省钱、独立迭代之一时，才升级到“拆了且管边”，而且升级的第一个动作是“先建边表”，不是“先拆 Agent”——先有约束，再谈拆分。
demo 里还做了个可复现的实验：把规划 Agent 从链里摘掉（检索直连执行），任务照样跑通，花费从 0.0036 降到 0.0024。那个规划 Agent 一点活没多干，只多收了一份钱。
三个反直觉判断
坑在边上，不在节点上；三元组不升维，升维的是边；多 Agent 是最后一颗子弹，不是第一架构。
一句话收口：多 Agent 的活，管的不是节点，是边；N 个好 Agent 凑在一起，照样是一条废链。
下一篇《开源工具箱 30+ 选型地图》：多 Agent 怎么协作，这一篇讲完；几十个工具怎么选，下一张地图上见。
这篇是脱水版。完整版含可离线跑的 mini_orchestra.py + 8 个断言的测试、节点层/边层/顶层三层结构、六样协作纪律、两个付费踩坑，已同步发布在 CSDN。点文末“阅读原文”看完整代码和可跑 Demo。
评论区聊聊：你拆多 Agent 时，是先建协作契约边表，还是先把 Agent 拆开再说？
我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。