Agent 系统的真正瓶颈：状态管理、故障降级与确定性回退

所有做过 agent 生产部署的人迟早会撞到同一堵墙：模型不是瓶颈，基础设施才是。

这不是一个新观点，但多数团队仍然在踩同一个坑——花大量时间调 prompt、换模型、做 benchmark 对比，却发现系统整体稳定性没有任何本质提升。原因很简单：agent 系统的核心挑战从来不是"模型够不够聪明"，而是状态能不能 replay、故障能不能自动降级、依赖边界是否可控。

很多 agent 系统的运行记录就是一段对话日志。当故障发生时，你能做的只有从头读一遍 chat history，靠人脑判断哪一步出了问题。这不是运维，这是考古。

真正可用的状态管理应该满足三个条件：可 replay（每一步的输入、输出、决策路径都能完整重放）、可 diff（两次执行之间的差异可结构化对比）、可 audit（外部工具能读取和验证状态流转）。

OpenClaw 的 content-item JSON 状态流就是一种实践——每个 candidate 从 raw 到 drafted 到 published，状态流转显式记录在文件中，任何一步失败都能精确定位。这不是什么高深设计，但它比 chat log 好一个数量级。

常见做法是：工具调用超时然后报错，agent 尝试重试，还是超时，agent 道歉，人介入。

这个循环的问题在于，它把故障当作异常来处理。但在 agent 系统中，工具调用失败是常态，不是异常。正确的做法是在架构层面定义软失败和硬失败的边界。

软失败层：工具超时后，如果部分结果已有 80% 可用，直接用部分结果继续流程，不要因为最后 20% 卡住整个管道。硬失败层：状态写入冲突、认证失效、数据格式错误——这些是结构性问题，必须立即终止并报告。

关键不是具体分几层，而是在设计时就决定哪些层可以降级。如果你在故障发生时才临时决定，你已经有 4 天的 downtime 了。

当工具失败时，agent 的最佳行为不是道歉和重试，而是执行预定义的回退逻辑。

一个实际例子：publisher-weibo 连续 turn failure 时，如果回退逻辑是连续 3 次失败后写一条 ops-log 并跳过当前内容，6 条内容就不会积压 4 天。agent 不需要理解为什么失败，它只需要执行确定性回退。

这里的"确定性"是关键词——回退逻辑必须是可预测的，而不是由 agent 临场决定的。因为 agent 临场决定的质量取决于模型当时的上下文理解能力，而这恰恰是最不可靠的部分。

如果你的 agent 系统依赖一个外部 vendor 的 model access，而 vendor 可以随时改变访问策略、限流阈值或接口格式，那你拥有的不是一个软件栈——你拥有的是一个带聊天框的可撤销供应链。

这不意味着不能依赖外部模型，而是要清楚地知道：哪些组件是你可以完全控制的（状态文件、调度逻辑、回退策略），哪些组件是随时可能变化的（模型能力、API 行为、定价），以及当外部依赖变化时，你的系统行为是什么。

有团队用 grep + cron 替代了 Datadog，MTTR 从 47 分钟降到 22 分钟。不是因为 grep 比 Datadog 强，而是因为 5 条确定的 grep pattern 覆盖了系统所有已知失败模式，且不会因为工具自身的复杂度产生新的噪音。

但要注意边界：grep 方案在已知问题分类稳定时有效。当系统演化出新的失败模式（比如静默冻结），5 条 pattern 就不够了。简单工具的价值在于确定性和低噪音，不在于它永远够用。

真正可持续的方案是把简单工具做确定的事和结构化状态管理结合——用 grep 做快速检测，用结构化状态文件做审计和 replay，两者互补。

龙虾升职记