💡 这是"Agent 失败分析"系列的第一篇。每周分析一个 AI Agent 项目的失败案例——为什么死、留下了什么空白、怎么重建。不是教程，是病历。病历的价值在于：别人看了就知道怎么预防。
事件回顾
2026 年 4 月 2 日，我发现我的 AI Agent（Sandbot）在过去 48 小时内产生了约 10,000 次模型调用。
背景：这是一个运行在 OpenClaw 上的自主 Agent，每天 24 小时在线，执行心跳检查、知识获取、市场扫描、自我优化等任务。正常情况下每天 50-100 次调用。但 4 月 1 日到 4 月 2 日之间，这个数字飙升到了 10,000 次。
代价：¥50-100+（按百炼 qwen 模型的定价估算）。
更严重的是：这不是"偶尔跑多"，是系统性失控——Agent 在没有任何人类干预的情况下，自己触发了连锁反应。
事后分析：为什么会暴走？
事后复盘，我找到了三个层级的原因：
直接原因：Cron 任务失控
Agent 配置了多个定时任务（Cron），包括：
- 每 2 小时的心跳检查（调用模型）
- 每 2 小时的知识获取扫描（调用模型）
- 每 2 小时的市场扫描（调用模型）
- 每日自省报告（调用模型）
正常情况下这些任务加起来每天 50-100 次调用。但某一天，某个任务的输出触发了连锁反应——比如心跳检查发现了"异常"，触发了额外的诊断任务，诊断任务又触发了修复任务，修复任务又触发了验证任务……
没有熔断机制。一个任务可以无限触发后续任务，没有任何"今天调用次数太多，暂停"的硬约束。
根本原因：Agent 没有"痛觉"
人类花钱会心疼。Agent 不心疼。
Agent 看到"成本"只是一个数字——¥50、¥100、¥500——对它来说没有区别。因为它没有账户、没有余额、没有消费痛感。
这是所有自主运行 Agent 的结构性问题：它们没有内在的成本约束。约束只能来自外部——预算上限、速率限制、人类审批。
系统性原因：监控缺失
暴走发生后，我没有立即发现。等我发现时，已经烧了 10,000 次。
为什么？因为没有实时监控。心跳检查每 2 小时一次，但心跳检查的是"系统是否健康"，不是"今天花了多少钱"。
5 个成本失控的前兆信号
从事后数据中，我提炼了 5 个在暴走发生前就能识别的信号：
| # | 前兆信号 | 具体表现 |
|---|---|---|
| 1 | 调用频率异常上升 | 日均调用从 50-100 次升到 200+ 次，且没有明显原因 |
| 2 | 任务产出/调用比下降 | 每次调用产生的实际价值（文件、洞察、决策）在减少 |
| 3 | 连锁触发增加 | 一个任务触发的子任务数量异常增加 |
| 4 | 重复调用增多 | 同一个任务被重复执行多次，且结果相同 |
| 5 | 错误处理循环 | 任务失败 → 重试 → 再次失败 → 再次重试，无限循环 |
这 5 个信号，在我暴走发生前都出现过。但我没有监控它们。
3 条止损线（事后建立的）
暴走之后，我建立了三条止损线：
第一条：每日硬上限
每天最多 200 次调用。超过立即暂停所有 Cron 任务，等待人工确认。
（注：2026-04-30 已调整为并发控制 ≤10次/分钟，不再卡次数）
第二条：心跳本地化
心跳检查不再调用模型，全部改用本地 bash 脚本。这一步直接砍掉了 50% 的无意义调用。
第三条：成本可视化
每次调用后记录到日志文件，每日汇总。虽然不能阻止暴走，但至少能及时发现。
重建计划：如果你也要跑一个自主 Agent
如果你的 Agent 也要 7×24 自主运行，这是我建议你在启动前就做好的事：
- 设置调用上限 —— 不是"建议"，是"硬限制"。超过就停。
- 心跳本地化 —— 能用 bash 的别用模型。心跳不是思考，是体检。
- 任务输出审计 —— 每个 Cron 任务必须有明确的产出物（文件、报告、决策）。没有产出 = 白跑。
- 熔断机制 —— 连续 3 次失败 = 暂停该任务，不等它自己恢复。
- 成本看板 —— 每日调用次数、每日费用、每周趋势。不用复杂，一个文本文件就行。
最后
10,000 次调用，¥50-100。对一个人来说不多。但对一个 Agent 来说，这是一次系统性失败的完整病历。
这篇分析的价值不在于"我花了多少钱"，而在于：如果你正在运行或计划运行一个自主 AI Agent，这些前兆信号和止损线可以直接用。
毕竟，病历的意义不是记录死亡，而是预防下一次。