Agent 崩溃风险自检清单 V1.0

3 分钟，按三大故障模式自测：你的 Agent 会不会在某个深夜静默崩溃？每一题"是"都代表一个真实踩过的坑。基于 OpenClaw 真实生产崩溃案例提炼。

① 幂等边界（Idempotency）

案例来源：OpenClaw #113434 会话句柄失效 · 某电商 agent 重复扣款 17 次

同一个任务，你的 agent 会因网络抖动/重试而重复执行（重复发消息、重复下单、重复调用支付）吗？

— #113434：上游句柄退休，重试却拿旧句柄当有效

任务有唯一 ID + 去重存储（KV/DB）吗？还是靠"应该不会重发"的侥幸？

外部 API（支付/邮件/Webhook）调用，是否对"已处理"状态做了幂等校验？

发生过"用户说没收到，日志显示发了 3 次"之类的怪事吗？

重试逻辑有上限/退避吗？还是"失败就无限重试"直到上游封你 IP？

案例来源：OpenClaw #114234 PID锁泄漏 · #114255 状态卡死 · #115326 LaunchAgent死循环

你用"进程还活着(PID)"来判断某把锁/某个任务是否还在进行吗？

— #114234：容器重建 PID 复用，锁被骗成"永远活着"

重启后，旧的 session/状态字符串会被当成"当前活跃"吗？

— #114255：网关重启后状态卡在 running，下游永久阻塞

有没有"启动更新任务"被设成了 keepalive（一次性变永久重启循环）？

— #115326：launchd keepalive 无限重启触发 breaker

"服务是否正常"的判断，依赖重启后会失效的标识符吗？

有没有遇到过"明明挂了，监控系统却报一切正常"？

案例来源：社区高频复现模式 · ARK 诊断库累计 23 例同类

一次失败是否触发"子任务雪崩式重试"（1 个失败 → 50 个并发重发）？

轮询（polling）有没有"空轮询"——没数据也每秒打一次，直到 Token 烧光？

有没有发生过"半夜 Token 消耗是白天 17 倍"的账单惊吓？

超时设置合理吗？还是"等永远"导致连接池被打满？

失败时有熔断（circuit breaker）吗？还是"挂了就一直撞"？

个红色警报 —— 这些是你的 Agent 半夜崩溃的真实诱因

勾选"是"的题越多，说明你当前架构越接近"重启即崩溃"的临界点。

崩溃时 Token 消耗是修复后的 17 倍；根因=缺少幂等守卫 + 重试无上限。修复成本：2 小时。你的清单若亮了红灯，你正经历同样的事。— 看完整案例 →

launchd 把一次性更新任务设成 keepalive → 无限重启 → 每次重启都杀掉 gateway。他熬了 3 晚。ARK 把它拆成 3 个独立 bug，永久归档。— 看完整案例 →

ARK · Agent Reliability Kit —— 由观一构建并维护

技术复盘阵地：proof-of-state-trap