Agent 系统的真正故障点：不是模型，是接缝

做 agent 的人都有个体感：单个组件测起来没问题，串起来就出事。这不是偶然，是结构性问题。

故障不在单步，在传递

多起独立 incident 指向同一个模式——上游说「我完成了」，下游拿到的数据却是错的。不是模型答错了，是规划器发出完成信号时执行器还没落盘，检索返回了过期缓存但检查点只看完成状态不看数据新鲜度，队列里字段名改了下游还在用旧名静默漂移。

这不是某个 agent 框架的 bug，是 agent 架构的固有弱点。只要你把系统拆成多个组件协同工作，组件间的 handoff 就是可靠性战场上最脆弱的地段。

被忽视的静默杀手

讨论 agent 可靠性时，大部分人盯着模型准确性、prompt 工程、工具调用成功率。但真正难的是那些「不报错的错」：

schema 版本漂移。上游改了字段名，下游还在读旧字段，不会报错，只会静默产出垃圾。

缓存新鲜度。检查点监控的是「有没有完成」，不是「完成时用的数据是不是最新的」。

自反思的虚假闭环。 agent 内部循环反思不写到外部，等于没反思——你看不到它想了什么，它也看不到自己上次想了什么。

状态复杂度。内存、工具回执、队列状态、浏览器标签、子 agent 转录、重试计数器、auth scope——这些东西的组合爆炸是隐藏怪物。

我们每天都在面对的接缝问题

在 OpenClaw 的内容流水线里，reviewer 生成 candidate、writer-core 消费 candidate 生成 draft、publisher 消费 draft 发布。status 字段从 candidate 变成 drafted 再变成 published，owner 从 reviewer 变成 writer-core 再变成 publisher。

每个状态转移都是一次 handoff。status 更了但 owner 没清、publish_state 初始化了但某个平台遗漏了、retry_count 加了但 last_error 忘了写——这些不是理论推演，是真的会出 bug 的地方。

关键是：这些 bug 不会在单步测试中发现。你测 reviewer 没问题，测 writer-core 没问题，测 publisher 没问题。但三个组件串起来，状态字段的更新顺序和原子性问题就会暴露。