一夜之间，AI Agent 烧掉了我 1000 美元：真正可怕的不是模型贵，而是“代理失控”
昨晚，我以为只是让 Claude 帮我做一次代码审查。
任务很普通：
检查代码是否完成任务，是否支持 OpenSpec 的规则流转。
结果第二天一看，账单直接炸了。
我看到的不是一两个请求失败，而是一排刺眼的报错：
Agent stalled: no progress for 600s
stream watchdog did not recover
Too many pending requests
Concurrency limit exceeded
DAILY_LIMIT_EXCEEDED
第一反应当然是：模型是不是有 bug？cc-switch 是不是统计错了？Claude 是不是发疯了？
查完日志后，结论更吓人：
不是模型突然发疯，而是 Agent 工作流进入了递归派生。
事故现场
本地 cc-switch 数据库显示，主要消耗集中在同一个 Claude session：
session_id: 6d2296bc-65e7-42d9-a92a-6358bbb56a42
项目: /Users/lininn/work/openflow
时间: 2026-06-15 晚上到 2026-06-16 早上
模型: gpt-5.5
成功计费请求: 10244 次
输入 tokens: 约 593M
输出 tokens: 约 5.17M
cache read: 约 532M
cc-switch 估算费用: 约 $3386.97
我本来以为自己只是花了 1000 刀。
结果本地记录告诉我：如果按 cc-switch 的价格表估算，实际风险敞口可能超过 3000 刀。
更关键的是，这个 session 下面生成了：
subagent .jsonl: 10146 个
subagent .meta.json: 10146 个
也就是说，这不是“开了几个 Agent 做 review”。
这是上万个子代理在同一个任务里被反复创建。
真正的爆点：Agent 开 Agent
这次事故的根因不是某个接口 429，也不是 watchdog 超时。
429 和 watchdog 都只是症状。
真正的链路是这样的：
- 我让 Claude 检查代码。
- Claude 触发了
code-review技能。 code-review技能要求启动 7 类独立 review agent：diff scan、removed behavior、cross-file trace、reuse、simplification、efficiency、altitude。- 子代理启动后，也加载了技能列表。
- 某些子代理没有直接完成自己的小任务，而是再次触发
code-review。 - 新的
code-review又继续启动 7 类 Agent。 - 于是变成：
主 Agent
-> 7 个 review agent
-> 每个又触发 code-review
-> 再开更多 agent
-> 再继续派生
这就是一次典型的 subagent recursion。
看起来是“智能协作”，本质上是“没有熔断的指数级任务扩散”。
为什么报错出现在最后？
截图里的错误是：
Agent stalled: no progress for 600s
很多人看到这个会以为：哦，是 Agent 卡死，所以没花多少钱。
恰恰相反。
它卡死的时候，钱已经花出去了。
在 watchdog 判定 600 秒无输出之前，大量请求已经成功返回并计费。后面看到的 429、daily limit、context window exceeded，只是系统被打爆之后的残响。
失败请求通常不收费。
真正烧钱的是前面那 10244 次成功请求。
这件事给我的最大教训
过去我们担心的是：
- 模型太贵
- prompt 太长
- 输出太多
- 上下文太大
但 Agent 时代真正危险的是：
一个看似合理的工作流，可能在你睡觉时自动复制自己。
尤其是这些场景非常危险：
- code review 自动派多个 Agent
- 子代理可以继续调用 Skill
- 子代理可以继续调用 Agent
- 没有预算上限
- 没有并发上限
- 出错后继续输入“继续”
- 高价模型作为默认路由
这几个条件叠在一起，就是账单事故。
怎么修？
我后面会按三层修。
第一层，禁止子代理再开子代理。
在 code-review 技能最前面加硬规则：
If this skill is running inside a Claude Agent/subagent,
do not invoke Skill, Agent, Task, code-review, simplify, review,
or any workflow that spawns agents.
In subagent context, complete the assigned review directly
with local read/search tools only, return the requested JSON, and stop.
同时所有子代理 prompt 里都要加：
Do not invoke Skill tool.
Do not invoke Agent tool.
Do not run code-review, simplify, review, or any workflow.
Complete this exact task directly.
第二层，给 cc-switch 加保险丝。
建议：
max_retries: 从 6 降到 1 或 2
高价模型 daily limit: 20-50 美元
Claude 并发限制: 2-4
gpt-5.5 不作为默认 review 模型
没有预算上限的 Agent 系统，本质上就是裸奔。
第三层，改变使用习惯。
以后看到这些信号，立刻停：
Too many pending requests
Concurrency limit exceeded
DAILY_LIMIT_EXCEEDED
Agent stalled
response exceeded 64000 output token maximum
use SendMessage to continue this agent
不要在原 session 里继续输入“继续”。
正确做法是开新 session，并明确说：
Do not use Agent.
Do not use code-review skill.
Summarize current state from logs only.
最后
这次事故让我重新理解了一件事：
Agent 的风险，不是它不会干活。
恰恰相反。
风险是它太会干活，而且没有边界。
以前我们写程序，最怕死循环。
现在我们用 AI Agent，最怕的是：
一个会花钱的死循环。
AI 工具越强，越需要工程化护栏。
不是“少用 AI”，而是必须给 AI 加上：
- 递归限制
- 并发限制
- 预算限制
- 失败熔断
- 明确的子代理职责边界
否则，下一次你以为自己只是跑了一个代码审查。
醒来之后，账单已经替你完成了一次深度复盘。
暂无评论。