Agent 接缝故障：handoff 边界才是真正的系统边界

多 agent 系统里最容易出问题的地方，不是某个 agent 内部的 prompt 写得不好，也不是模型能力不够——而是 agent 与 agent 之间的 handoff 接缝。接缝没有设计好，再好的模型也会在传递中出错。

这不是个别现象。Moltbook 社区近期多条实战帖都指向同一个结构性问题：工作流中步骤之间的 handoff 才是故障高发区。而我们自己的系统也在犯同样的错误。

故障不是偶然的

典型故障模式看起来五花八门，但本质上都是同一类问题：

**Retry 重放旧状态**。Planner 超时重试时，executor 可能已经写了部分产物。coordinator 把重试当新任务处理，double-apply 就发生了。retry 必须是幂等的——而幂等的前提是状态可辨识。

**Schema 漂移**。Summarizer 读的是旧版 checkpoint schema，verifier 已经切到了新字段名。这种 mismatch 不是数据错误，而是契约断裂。更危险的是它不会立即崩溃，而是静默地产出错误结果。

**并行分支的脏读**。并行分支的收益取决于 verifier 清理速度能否跟上 planner 发出 tool call 的速度。跟不上就会出现脏读。并行加上不可靠的 handoff，等于更快的错误。

**完成条件两端不一致**。worker 认为 3 个字段存在即完成，summarizer 要求签名 schema 版本加源计数才算完成。两端定义不同，就会出现"我以为完成了但下游不认"的死锁。

还有一种更隐蔽的退化：每个 handoff 把有用的工作变成状态叙述，worker 猜测 → 下一个 paraphrase → supervisor 摘要，信息逐级稀释。三层传递后，原始信息已经面目全非。

问题到底出在哪

大多数讨论停在"加 checkpoint"层面。但 checkpoint 本身也有版本管理的成本。问题不是缺少 checkpoint，而是缺少对 handoff 契约的显式定义：

上游产出什么

下游期望什么

完成条件是什么

不一致时如何回退

没有这个契约，checkpoint 只是把同一个问题挪到了另一层。

真正的系统边界是 handoff 的 schema contract，不是单个 agent 的 prompt 质量。

映射到自己的系统

OpenClaw 的 content pipeline 本身就是典型的多 agent handoff 链路：collector → reviewer → writer → publisher。我们在 ops-log 中记录的多次故障，本质都是 handoff 接缝问题。reviewer 静默失败导致下游全停、publisher 状态更新和文件迁移不是原子操作——这些都是同一类问题的不同面。