多Agent
多智能体拆分的三个坑与三条铁律
交接用契约，编排能写死别交模型
把「一个 Agent 干完全程」拆成多智能体，翻车往往不是模型不行，而是拆开之后新长出来的三个失败面：Agent 之间靠大段文本转述导致信息衰减、总控 LLM 误判任务类型一错全链歪、出问题定位不到是哪个 Agent 的锅。本页给出对应的三条铁律——结构化契约交接、能写死的编排别交给 LLM、可观测性第一天就做，并附一份可直接照抄的拆分清单与自测动作。
方法 · 一图看懂
1
拆环节 — 把当前一个 Agent 干的活列成清单，每项写清输入、输出、怎么算做对；先看清链路，再谈拆人。
2
定角色 — 合并成 3-5 个单一职责 Agent（如分类 → 提取 → 风控 → 报告），一个 Agent 只干一类判断，不跨类兼职。
3
写契约 — 相邻 Agent 之间用结构化字段交接（字段名 / 类型 / 必填 / 验收项），下游只允许读它需要的字段，禁止把上游全文塞进去。
4
分编排 — 逐个检查总控节点：规则明确、候选可枚举的用 if-else 写死，只有真需要语义判断的才交给 LLM 决策。
5
埋留痕 — 每个 Agent 记录输入快照、输出、耗时、是否降级或回退，按任务 ID 串成一条可回放的链路。
6
加兜底 — 前置高风险节点（如合同分类）用「小模型 + 规则兜底」，规则命中即覆盖模型输出，不靠模型自觉。
原理 · 为什么有效
单 Agent 串行五件事（识别类型 → 提取条款 → 比对法规 → 评估风险 → 出意见），每一步都带不确定性，串起来误差被逐级放大——这就是简单保密协议能审、多方主体加对赌条款的投资协议就输出自相矛盾的根因。拆成多智能体的收益在于每一步可独立验收、错误可定位；但拆分本身会新长三个失败面：交接损耗（风控标了「高风险」，报告 Agent 被前序几千字拖得注意力漂移，自己脑补成「中等」）、编排误判（总控把租赁合同分到投资协议流程，该打回时「差不多得了」放行）、故障不可见（花两天才定位到一个「风控偶发漏条款」，根因却是提取 Agent 遇特殊表格格式丢了两行）。三条铁律与三个失败面一一对应：结构化契约把交接从自然语言转述变成字段传递，切断第一类损耗；把可枚举的判断从 LLM 收回代码，消除第二类误判——原文换用小模型加规则兜底后分类稳定性从 82% 拉到 97%；留痕从第一天就做，让「哪个 Agent、是自身还是上游脏数据」变成可查的问题而不是靠猜。
适用场景
适合：链条长、各环节能力差异明显（提取吃长上下文、风险判定吃规则与经验、报告吃写作）、每一步都能写出独立验收标准、且错一次的代价高到必须定位根因的任务——合同审核、资料汇编、代码审查、多源数据清洗。
不适合：步骤少于三个，或每一步都强依赖全局上下文（拆开后反而要重复搬运大量信息）；也不适合只跑一次、没有复现机会的一次性任务——拆分会把调试成本抬上去。如果整条链路一段规则脚本或一个提示词就能稳定跑完，就不要拆：拆分的价值来自可定位的错误，而不是来自 Agent 的数量。
自测 · 6 问
你的任务能不能拆成三个以上、每个都有独立验收标准的步骤？
两个 Agent 之间传的是字段化数据，还是一大段自然语言转述？
下游 Agent 收到的上下文里，有多少字段是它根本用不上的？
你的总控节点里，有多少判断是 LLM 在做、其实用 if-else 或正则就能写死？
出问题时，你能不能在一小时内说清是哪个 Agent、哪一步、是自身错还是上游脏数据？
每次降级与回退发生了几次，你手上有数吗？
怎么上手 · 验证步骤
先只拆两个 Agent 跑通一条最小链路（分类 + 报告），确认交接字段够用，再往里加第三个。顺序不能反：定契约 → 写死编排 → 加留痕 → 再加 Agent。原文踩的坑几乎都是「先把 Agent 堆上去，再回头补契约和日志」，补的成本远高于一开始就留。每加一个 Agent，先补它的验收标准和留痕字段，再上生产。
故意喂一份格式特殊的输入（带合并单元格的附件、主体名称与正文不一致的合同），看能否在半小时内定位到是哪个 Agent、哪一步丢的信息——能定位说明留痕合格，只能定位到「整体输出不对」说明留痕不够。再抽 50 条样本跑一遍前置分类，人工核对准确率是否 ≥ 95%；低于 90% 说明前置节点还在靠模型硬猜，该上规则兜底了。