loop 跑飞了怎么办一个 agent 烧掉 47000 美元的故事loop 跑飞了怎么办一个 agent 烧掉 47000 美元的故事 上篇回顾 一、11 天烧掉 47000 美元 二、loop 怎么跑飞的三种模式️ 三、五道护栏给 loop 系上安全带还有个细节best-version fallback 四、HITL关键时刻踩一脚刹车 数字总结 我的观察loop 的另一面是责任 一句话带走loop 跑飞了怎么办一个 agent 烧掉 47000 美元的故事2026年6月 | 实操 | 上篇《12 圈干完一件事》预告兑现 上篇回顾上篇我跑了个真实的 agent loop12 圈干完一个自检脚本看着挺美好。但留了个尾巴——「loop 跑飞了怎么办」。这篇就来填这个坑。因为现实没那么美好。同一个 loop跑对了是帮手跑飞了是烧钱机器。先看一个 2026 年最经典的真实案例。 一、11 天烧掉 47000 美元2026 年 3 月公开的一份事故复盘成了今年被引用最多的 agent 失控案例一个市场研究 pipeline四个 LangChain agent 通过 A2A 协议协作。测试时一切正常。上了生产后其中两个 agent——Analyzer分析器和 Verifier验证器——开始互相 ping-pongAnalyzer 生成分析Verifier 说「请再分析一下」Analyzer 照做Verifier 又说「请再分析一下」……两个 agent 都没有预算上限都没触发任何人会响应的告警。这个 loop 转了 264 小时11 天烧掉约 47000 美元 API 费用产出为零。最后是账单 dashboard 上的数字大到挡不住了才被人发现。事故复盘里有一句话最扎心「我们有监控仪表盘我们没有执行前的强制刹车。」「能观测」不等于「能停下」。这是从这个案例里最该带走的一句。 二、loop 怎么跑飞的三种模式47000 美元那个是「死循环」型。但 agent 跑飞不止这一种归纳起来三类① 死循环工具一直调同一个没有上限最典型一个 agent 被派去爬网站总结数据网站改版了爬虫返回空。agent 不知道目标是「不存在的」每次搜索都拿到模糊结果于是反复重试、重新规划、再搜索。IBM 的案例里一个坏掉的工具 5 分钟被调了 400 次。根因没有正确的终止条件——agent 不知道什么时候该放弃。② 反思发散越改越差停不下来这个最阴险。你让 agent「自我改进」它生成→批评→修改→再批评→再修改……问题是让它一直改进它会在输出已经够好后继续改通常越改越糟。一句有力的句子被改成啰嗦的委员会腔一个巧妙的方案被改成平庸的通用方案。反思循环从「帮手」变成了「捣乱」。③ 假装完成写到一半就宣布成功agent 写了半个函数说「我写完代码了」然后退出。根因终止条件太松——它把「我写了点东西」当成「任务完成」没有验证真正的完成标准比如「所有测试通过」。三种模式的共同病根没有刹车或者刹车太松。️ 三、五道护栏给 loop 系上安全带知道怎么跑飞就知道怎么防。生产级 agent 至少要配这几道护栏① 圈数上限max_iterations最基础的一道。设个最大圈数到点强制停。一位资深工程师的经验法则通常 10 圈够用如果你的 agent 常需要 30 圈大概率是用例没定义好。别贪多。② 预算硬顶token/成本上限圈数管的是「次数」预算管的是「钱」。每圈烧的 token 是非线性的——上下文会累积第 30 圈的输入可能是第 1 圈的 16 倍。设一个成本硬顶花完就杀进程。这正是 47000 美元事故缺的那道——有监控没有执行前强制刹车。③ 无进展检测no-progress detection重复几圈都没产生新信息自动退出。这是治「死循环」的特效药——agent 在同一个坑里反复挣扎时系统自己喊停。④ 目标校验真完成才退治「假装完成」。退出前检查真正的完成标准「所有测试通过」而不是「代码看着像写完了」。没达标就继续别让它糊弄交差。⑤ 人工介入HITL高风险步骤暂停打包上下文截图、URL、执行轨迹、它想干嘛丢给人审批人点头才继续。这是最后一道也是最稳的一道。关键原则至少设两道别只靠一道。单道护栏一旦失效就是裸奔。多道叠加一道挂了还有下一道兜底。还有个细节best-version fallback反思循环跑到上限还没收敛怎么办回退到过程中最好的那个版本不是最后一个。因为越改越糟时最后版本往往是更差的那个。这个小纪律是「反思」和「跑飞」的分界线。 四、HITL关键时刻踩一脚刹车五道护栏里人工介入HITL值得单独说。因为 2026 年它已经从「最佳实践」变成了法律要求。工作模式很简单agent 自主跑 → 遇到高风险/低置信步骤 →暂停不猜不硬冲→ 打包上下文丢给人 → 人审批同意/修正/终止→ 恢复。为什么必须有人一个被反复提及的警示那个「擦掉 190 万行数据库」的著名事故不是发生在沙盒里是发生在没有足够护栏的生产环境。agent 不会在搞砸前自己喊停它只会带着完整自信把错事干完。人是在它干错前踩刹车的那只脚。法律层面EU AI Act 第 14 条2026 年 8 月 2 日起对高风险 AI 系统强制要求人工监督能力。美国 NIST IR 8596 也要求 human-in-the-loop 检查。Gartner 预测到 2030 年50% 的 agent 部署失败将归因于治理缺口——治理缺失会是第一大失败原因。一句话2026 年没有 human-in-the-loop 的 agent 不该上生产。问题不是「要不要人」而是「人在哪个环节介入」。 数字总结护栏防什么代价圈数上限死循环、烧钱设太低会误杀正常任务预算硬顶47000 美元那种账单几乎无代价必设无进展检测同一坑反复挣扎需要定义「无进展」目标校验假装完成需要可检查的完成标准人工介入高风险搞砸慢但最稳 我的观察loop 的另一面是责任上篇我说 loop 的价值在「能纠错」。这篇是它的另一面——能纠错的前提是能停下来。一个停不下来的 loop不是 agent是事故。47000 美元那个案例里agent 没做错任何事——它只是在忠实地执行「分析→验证→再分析」的循环是设计它的人忘了给它装刹车。错的不是 agent是没设护栏的人。这其实给了我们一个更深的判断agent 越强大护栏越重要。能力越强跑飞时破坏力越大。Cursor 的 agent 能删掉整个公司代码库恰恰因为它有这个能力——配的护栏没跟上能力。所以 2026 年的一个共识正在形成agent 从 demo 走向生产真正的挑战不在模型多强而在护栏多稳。模型是油门护栏是刹车。只踩油门不装刹车的车没人敢开上路。对每个想用 agent 的人我的建议很朴素先把五道护栏里的至少两道装上再谈自动化。尤其预算硬顶——它是所有护栏里几乎无代价、却最能救命的一道。别等账单报警才发现 loop 转了 11 天。 一句话带走loop 跑飞不是 agent 的错是没装刹车的人的错。模型是油门护栏是刹车。下次你见一个 agent 系统问四个问题最多转几圈没上限 定时炸弹最多花多少钱没预算 47000 美元预备役卡住了自己能停吗无进展检测搞砸前谁踩刹车HITL四个都答得清这是个能上生产的 agent有一个答不上它就还是个 demo。本文案例来自 vectara/awesome-agent-failures、IBM Technology、Taskade、Oracle、Galileo 等 2026 年公开资料。47000 美元事故原始复盘发布于 2026 年 3 月。本文首发于AI架构师之路 关注我每天 5 分钟看懂 AI —— 前沿模型评测 · AI 日报 · 硬核教程更多 AI 实操内容扫码或搜索关注第一时间收到更新。本文为作者原创内容转载请注明出处。