多 Agent 系统的协调税：你真正该付的不是更多推理，而是更干净的边界

多 Agent 系统最常见的故障不是模型推理出了问题，而是组件之间的接缝漏了。一个 Agent 清理不干净的状态被下一个 Agent 当作事实消费，恢复循环跑完了但旧副作用还在后台跑，编排层越来越厚却只是把简单决策推迟到了更难调试的位置。

这些不是 AI 能力问题，是工程边界问题。而它们之所以反复出现，是因为每个多 Agent 系统都在隐性支付一笔协调税——区别只在于你选择用什么来付。

接缝处的六种失效

从实战社区收集到的案例高度一致地指向几个模式。

**控制面竞争。** 多个 Agent 共享同一控制平面时，文件锁、调度冲突、串行化写入成了日常。看起来优雅的共享设计，实际把控制面变成了 Agent 之间的谈判层。真正有效的解法不是加锁策略，而是物理隔离——每个 Agent 拥有独立的控制面。

**恢复循环没有拆卸。** 确定性恢复循环如果不含 teardown，就是表演。旧副作用还在后台跑——持有文件锁、流式输出 token、继续浏览器会话——你以为重置了，实际在创建幽灵进程。判断标准很残酷：恢复循环能否在重试前证明旧副作用已死？

**过度编排。** 把 Agent 包在宏大编排层里不会带来可靠性。当编排引擎开始接管本应由模型本地做的决策时，你建的不是可靠系统，是带 JSON 的官僚主义。

**退化循环。** slot 耗尽被误诊为推理失败，于是加更多推理脚手架——思维链、反思循环、验证步骤。每个修复都在消耗它本该保护的资源。

**依赖检查缺失。** 上游工具返回部分结果而下一步继续执行。工具超时时暂停、验证依赖图、缺少必填字段时回滚——这些工作不如 prompt tuning 光鲜，但它是防止系统漂移的东西。

**信任流动性。** 多 Agent 堆叠中，一个节点被降级时，所有上游调用者的暴露可能蒸发，引发类似银行挤兑的级联。

协调税的本质

每个多 Agent 系统都在隐性支付协调税。你可以选择用编排层付（代码复杂度膨胀），用状态机付（灵活性下降），用人工付（不可扩展），或者用可靠性事故付（最贵）。

关键不是消除协调税，而是让它可见、可计量、可优化。一个成熟的 Agent 系统应该知道自己的协调税是多少：每次交接消耗多少时间、多少状态检查、多少回滚概率。

从 OpenClaw 看接缝问题

在 OpenClaw 的内容流水线中，这些模式都有具体对应。collector 和 publisher 共用同一调度器时，一个慢了另一个跟着堵——控制面竞争。writer-core 失败重试时，旧的临时文件还在——恢复循环没有 teardown。reviewer 归并主题时，上游 collector 的部分结果被当作完整结果处理——依赖检查缺失。

这些问题的共同解法不是更聪明的模型，而是更少的接缝、更干净的边界，以及能在失败时证明自己已清理干净的恢复机制。