七个 AI agent 互相返工 16 次后，我才补上最朴素的熔断
这篇事故复盘最核心的一句是：多 agent 系统里，如果没人负责喊停，再合理的分工也能变成整夜空转。
那晚最夸张的不是某个任务失败，而是几个任务在 planner、executor、reviewer 之间来回返工十几次，像在自动化流水线上互相打架。每个角色都在“按流程办事”，结果系统整体却完全没前进。
所以后面我想重点讲三件事：返工循环到底是怎么形成的、为什么原来的角色分工天然缺一个“刹车”，以及我最后为什么会加一个看起来很土但特别必要的熔断机制。
那个凌晨四点的灾难
executor cron 按计划启动，去检查有没有待处理的任务。发现有7个任务卡在”返工”状态，于是忠实地把它们全部重新执行了一遍——状态从 rework 改成 in_progress。
然后 reviewer cron 也启动了。它看了一眼这些任务，觉得不太行，又给打回了 rework。
executor 再来一轮。
reviewer 再打回。
等我早上8点打开电脑，日志里清清楚楚地写着：跑AI分析那个子任务，返工了16次。即刻爬虫返工14次。部署上线返工12次。七个任务的 rework_count 全在两位数。
两个 cron job 就这么从凌晨一直空转到天亮，烧了一堆 API 调用，啥也没干成。
问题出在哪
说白了就一句话：没有人喊停。
reviewer 的判断标准是基于 acceptance 字段的——你写了”爬取50条帖子”，我只看到20条，不通过。但它不关心”你已经尝试16次了是不是该换个人来”。executor 也不关心，它只管”有任务要返工，我来执行”。
就像一个工厂流水线上，质检员永远说不合格，工人永远按同样的方式重做，没有主管过来看看是不是图纸有问题。
熔断：最简单粗暴的解决方案
加了两处改动：
第一处在 rework 接口。每次有人把任务打回返工，rework_count 加1。加到5次的时候，服务端直接把状态改成 blocked，不允许继续循环。你在 API 层面就过不去，不是靠 agent 自觉。
第二处新增了一个 /unblock 接口。planner 角色可以把 blocked 的任务重置回 pending，清零返工次数，清空认领人。相当于人工介入，审视一下到底是任务描述有问题、验收标准太高、还是执行方式不对。
改完重启服务，世界清净了。
后来想了想，这其实是个普遍问题
不只是我的系统。任何自动化的流程都有这个风险——你设计的时候想的是”正常情况”，但生产环境跑起来全是”异常情况”。
爬虫被反爬了，你不加重试限制就会无限重试。API 返回错误了，你不加超时和降级就会无限等待。AI agent 之间的协作也一样，你不加熔断机制，它们就会按照你写的逻辑一直转圈，直到把配额烧完。
特别是 agent 数量多了以后。我后来跟饭团聊，他说想搞一个 HR 角色——专门管 agent 的”绩效”。哪个 agent 老是返工、哪个任务分配不合理、哪些该人工介入，都由 HR agent 来判断。
说实话这个想法挺有意思的。你给 AI 分了工，下一步自然就是给 AI 分管理层。planner 管方向，executor 管执行，reviewer 管质量，HR 管人效。到最后，一个”一人公司”的组织架构图，全是 AI agent。
但不管架构怎么花哨，熔断机制这种底层保护是不能省的。就像不管你公司文化多好，劳动法还是得有。
顺便踩的其他坑
那天晚上除了返工循环，还遇到了好几个有意思的问题：
create-next-app 跟你对话。 子 agent 去搭 Next.js 项目，npx create-next-app 一直弹交互式问题——要不要用 TypeScript？要不要 Tailwind？agent 不知道怎么处理，卡住了。后来试了各种 pipe 方式传参数：echo "n"、printf "n\nn\n"，都不太行。最后只能手动建项目。
PostgreSQL 密码带特殊字符认证失败。 在腾讯云服务器上建了数据库用户，密码里有个 @ 符号。连接的时候死活认证不过去。折腾了半天发现是用户缺 LOGIN 权限——ALTER USER app WITH LOGIN 才解决。改密码的时候 shell 里的引号嵌套也是一言难尽。
即刻 RSSHub 实例全挂了。 爬虫原本从 RSSHub 拉即刻的帖子，结果几个公共实例全都超时。后来发现即刻移动端网页还能直接抓——从 RSS 内容里提取帖子链接，再逐个访问移动端页面用 __NEXT_DATA__ 拿数据。算是个降级方案，但请求频率得控制好，不然号没了。
写在最后
搞 AI agent 系统最有意思的一点是，你会看到”自动化”的边界在哪。它能帮你省掉大量重复劳动，但一旦出问题，排查起来比手动操作还累——因为你得翻好几个 agent 的日志，理清它们之间的交互时序。
熔断、超时、降级、限流——这些传统后端的保命手段，在 AI agent 系统里一个都不能少。
不要相信 agent 会自己停下来。它们不会的。