2025 年底，我们接手了一个跨系统的合同审核场景：需要读取合同、比对内部条款库、核对相对方资质，最后输出风险清单。团队的第一反应是做三个智能体——阅读、检索、审核——由一个调度器统一指挥。听起来像教科书里的架构，实际运行两周后，我们把它改回了单体加固定流程。
原因不复杂：三个智能体互相等待彼此的「理解结果」，任何一方表述含糊，下游就会放大误差；而每次调用都携带完整上下文，Token 成本涨了近两倍，端到端时延从 9 秒涨到 27 秒。
为什么拆分容易失控
多智能体系统的失败通常不是模型不够强，而是三件事没有约束好。
- 上下文漂移：每个节点都会对上游输出做一次「再理解」，三次转述之后，原始合同条款的关键限定语经常丢失。
- 责任模糊：当最终结论错误时，很难判断是检索漏了条款，还是审核误判；日志里只有一串自然语言，没有明确的责任边界。
- 循环放大：调度器让审核智能体「再检查一遍」，审核智能体要求补充检索，检索智能体又回头要更明确的查询——这种循环在缺少预算控制时会持续消耗配额。
我们现在的三个拆分判据
经过这次复盘，我们把「是否拆成多个智能体」变成了三个可讨论的问题，而不是架构品味之争。
- 知识域是否真的不同？如果两个角色查的是同一份文档、用同一套口径，拆开只会增加转述损耗。
- 权限边界是否需要隔离？当不同环节需要访问不同密级的数据时，拆分是安全要求，而不是性能选择。
- 能否独立验证？如果每个子任务都能定义清晰的验收标准（例如字段抽取准确率、条款匹配召回率），拆分才有意义。
三个问题里有两个以上回答「是」，我们才建议拆分；否则优先做单体加固定流程。
编排的四条工程约束
当确实需要多个角色协同时，下面四条约束是我们每个项目的默认配置。
1. 用状态机而不是自由对话
节点之间的流转由代码控制，模型只负责节点内部的判断。调度器不允许模型自行决定「下一步找谁」，否则调试成本会指数级上升。
2. 每个节点都要幂等
检索、抽取、校验类节点必须支持重复执行且结果一致。这样在超时重试时不会产生副作用，也方便做离线回放。
3. 时间与成本预算前置
一个会话允许调用几次模型、总共多少 Token、端到端多少秒，在编排开始前就写死。超出预算时自动降级到「确定性流程 + 人工接管」，而不是继续尝试。
4. 高风险节点强制人工
涉及金额、合规结论、对外承诺的输出，一律经过人工确认。AgentOS 把这个节点做成阻塞式，未确认不进入下一步。
评测要分两层做
只测端到端结果，无法定位问题；只测单节点，又无法反映组合效应。我们的做法是两层同时跑：
| 层级 | 指标 | 用途 |
|---|---|---|
| 节点级 | 抽取准确率、召回率、格式合规率 | 定位是哪一步劣化，决定换模型还是改提示词 |
| 端到端 | 任务完成率、人工接管率、平均时延、单次成本 | 判断是否达到上线门槛，以及是否值得继续投入 |
回归集至少覆盖 200 条真实问题，其中 30% 是「应该拒答」的负样本。每次改动都要跑全量，结果存档以便对比。
什么时候应该回到单体
我们的经验是：当端到端时延超过业务容忍上限、或者人工接管率高于 15% 时，先不要优化提示词，而是回到单体方案做一次对照实验。多数情况下，简化架构带来的收益，远大于换一个更强的模型。
智能体编排的价值在于把复杂流程变成可治理的工程对象，而不是让系统看起来更「智能」。如果拆分没有带来可验证的收益，它只是把复杂度从代码转移到了运维。
本文基于天辰平台三个交付项目的复盘整理，数据已做脱敏处理。转载请注明来源。