循环工程给AI Agent装上刹车之后，那张跑了一整夜的账单才真正消失

摘要：自主Agent烧钱不是因为模型不够聪明，而是因为循环里那一步“观察”在说假话。护栏有四类——上下文保洁、四道刹车、独立评审、幂等写操作——它们不是并列的四件事，而是同时在保同一件事：让Agent看到的反馈可信。这篇把每一类拆到可以照抄的判据上，给出社区实现里真实生效的阈值常量、Codex把预算耗尽做成软停的设计，以及2026年7月中旬刚刚补上的那一环——内循环可以交给Agent，外循环必须留在人手里。

有一条止损线被写死在一个494星的开源脚本里：同一条命令连续失败三次，或者同一个文件在十分钟之内被改写五次，就判定这个Agent已经掉进沟里，当场停机，等人来看。

这不是谁在会议室里推演出来的规则。它是被烧过之后刻回代码里的疤。写下这两个数字的人，一定亲眼看过一个循环在无人值守的夜里，一遍又一遍地把同一个文件改成两种互相矛盾的样子。

2026年上半年，这类疤痕开始有了统一的名字：循环工程。它管的不是模型答得好不好，而是那个驱动模型反复动手的外层循环——什么时候该给记忆瘦身，什么时候该急刹，谁有权说这活没干完，哪些操作被重跑第二遍也不会出事。

这篇文章的核心判断，和市面上大部分“Agent护栏清单”不太一样：四类护栏不是并列的四件事，它们全都在服务同一个目标——让循环里“观察”这一步说的是真话。上下文保洁保证观察没被陈年噪音污染，独立评审保证观察不是自己给自己打分，幂等保证重试不会偷偷改掉被观察的对象，刹车保证观察一旦失效循环会停。想清楚这条主线，装护栏就不再是照单抓药。

循环工程到底在给什么东西上锁？

先把这个词的来历说清楚，因为它年轻到还带着水汽。2026年6月，Google的Addy Osmani写了一篇文章，给这门一直在做却没名字的手艺定了名；同月16日，LangChain把它形式化成了几层互相嵌套的循环。前沿实践者和框架厂商在同一个月里各自命名同一样东西，玄学变成学科通常就长这样。

它在技术栈里的位置很好摆。提示词工程管你发出去的那几句话，上下文工程管模型在某一次调用里看见的每一个词元，harness工程管环境——它能碰哪些工具、哪些文件、哪些连接器。循环工程管的是把这一切驱动向目标的那个迭代过程，一层包住一层，谁也不取代谁。

为什么最外面这一层反而最难被抄走

把四层排成一列会看出一个规律：越靠里的层，越依赖某一个具体模型；越靠外的层，越跟模型无关。一句调教了半年的提示词，换一代模型可能就得重写；而一套压缩策略、四道刹车、生产者与检查者的分离，明天把底层模型整个换掉，每一条照样成立。

这就是循环工程被当成护城河的原因。模型质量在收敛，也可以租；任何人今晚就能调你在调的那个接口。但外层这些工程积累是造出来的，不是租来的，竞争对手升级模型也搬不走。开头那个84%的收益也是同一课——它来自循环层的一次改动，模型一个权重都没动。

反过来说，这也意味着你在循环层踩过的坑，别人不会替你踩。厂商发布会不会讲你的写操作重试了几次，也不会告诉你上下文该在几成的位置压缩。这些数字只能自己量。

把外壳剥掉，所有自主Agent都是同一个形状

接一个目标，推理下一步，执行动作，观察真实结果，判断差距，决定继续还是停。经典形式化叫ReAct，想一步、做一步、看一步，反思型变体在末尾再加一次自我批评。

这段描述里真正承重的词是“观察”。Agent之所以能比单次生成强，不是因为它想得更久，而是因为每一步都在回应上一步动作的真实反馈。跑一次测试、读一段报错、看一眼返回码，这些外部事实把它从自由联想里拽回来。

纠错机制会复利。一个能跑测试、读失败、再试一次的循环，五十步能啃下单次生成永远解不开的问题。但这条复利有个前提，而整篇文章都在撬这条缝：纠错只在观察可信时成立。绿色的测试是可信信号，“代码现在看起来好多了”不是。

Ralph循环为什么故意每轮把上下文扔掉？

要理解护栏，先看一种把循环推到极端的玩法。Geoffrey Huntley在2025年中提出了Ralph循环，名字取自《辛普森一家》里那个憨厚执着的小孩，自嘲意味拉满。

做法反直觉到让人皱眉：不维护长对话。编码Agent跑在一个纯粹的bash循环里，每一轮读同一份提示词文件，挑一个任务做完，然后把这个Agent杀掉，开一个全新实例，清空上下文，再喂一遍一模一样的提示词。

让人本能抗拒的那一步，恰恰是它跑得通的原因。进度不存在模型的上下文窗口里，而存在文件和git历史里。第七轮把窗口填满了？第八轮是一个全新的脑子，读一遍仓库当前状态、读一遍规格文件、读一遍进度日志，接着干。上下文腐烂没机会累积，因为没有任何一段对话被允许变长。

Huntley用这套办法造出过一门完整的编程语言，带编译器、标准库和两种执行模式，API账单大约297美元，时薪十美元量级。这个数字在从业者圈子里被反复引用，因为它相对一门语言本该消耗的工程师工时，低得不像话。

但请把注意力放在那个案例里最容易被忽略的部件上：编译器。它对着测试程序，要么产出正确结果，要么不产出。完成信号机器可验证，而且每一轮验证都免费。这不是幸运的细节，这是整套把戏的前提。把同一台机器指向一件没有可验证终点线的活，你搭出来的只是一台按小时计费的花钱机器。

这套玩法把你的岗位职责挪了个位置

Ralph模式下，你基本不写代码，甚至不太写提示词。你写的是规格、任务拆分和检查。原本泡在交互式会话里的每一个小时，都改花在把规格磨锋利、把验证做到骗不过去上。

原因很朴素：一个每轮清空上下文的Agent不记得你的任何意图，它只认写下来的东西。规格含糊进去，四十轮自信的废话出来。这也是为什么参考实现都强调任务粒度——每一条要小到一个上下文窗口能做完，比如加一个数据库字段、接一个组件，而不是“把整个后台做出来”。

这个位移对独立站团队反而是好事。你本来就不该指望一个Agent替你想清楚“这个页面到底要解决用户的什么问题”，但你完全可以指望它在一份写清楚的规格下，把三十个页面按同一套规则改完。规格写得清不清楚，现在直接等于产出质量，中间没有缓冲层。

它已经从民间偏方升级成产品原语

2026年4月30日，Codex CLI在0.128.0版本里加了/goal：设一个可验证的目标，它自己规划步骤、执行、检查产出、纠偏，一直跑到目标达成或者预算见底。前沿厂商把社区shell脚本变成内置命令，这件事本身就是一次背书。

更值得抄走的是它处理“钱花完了”的方式。预算耗尽不是硬中断，而是被标记成受预算限制的软停：系统会在最后一轮注入一份收尾提示，让Agent把手上的活收干净、把状态写清楚，而不是在半空中被砍断。暂停、恢复、清空、改预算这几件事只有人能做，Agent无权自己给自己加额度——这道边界比任何一条提示词都实在。

上下文怎么保洁才不会馊？

长循环最大的敌人不是笨模型，是一份被污染的上下文。每一坨没用的工具输出、每一条过期报错、每一个被放弃却还赖在窗口里的旧计划，都让下一次推理差一点，而且这种劣化跨轮次复利。

业界表述得很直接。HumanLayer那份十二条Agent准则里，第3条就叫“拥有你的上下文窗口”，第9条叫“把报错压缩进上下文窗口”。之所以要单独立两条，是因为默认行为——让历史一直堆着，好让Agent什么都记得——恰恰在跟模型的真实脾性对着干。

减脏的动作正好三个，工程到位的循环三个全用。压缩去减：对话逼近窗口上限时先总结，从总结重开一个窗口。转存去挪：四万词元的文件导出或命令输出扔到磁盘，上下文里只留真正要用的那五行加一个路径。隔离去挡：脏活交给一个自带干净窗口的子Agent，只让压缩后的结论回来。

这三个动作的收益有官方数据兜底。Anthropic在一个一百轮的网页搜索评测里做过对照：单靠上下文编辑就把词元消耗砍掉84%，而且救活了本来会因上下文耗尽而失败的任务；表现层面，上下文编辑单项带来29%的提升，配上记忆工具到39%。2026年没有哪一次模型升级，能用这么低的成本换这么大的提升。

请注意这三个动作发生在哪一层：它们全都是控制代码的活，不是模型的活。你不能靠在提示词里写一句“请注意节约上下文”来实现压缩，就像你不能靠嘱咐司机开慢点来代替刹车片。

刹车为什么比油门重要？

两种失效的代价完全不对称。油门坏了很便宜——模型笨一点、提示词差一点，你在产出质量里当场看得见。刹车坏了很贵——Agent干个没完，你在账单落地那一刻才看见，而那通常是第二天早上。

所以正经的循环装四道互相独立的刹车，各堵一个别人看不见的窟窿。

阈值到底该定多少，与其猜，不如看别人生产里真实在用的常量。有一个把Ralph循环移植到Cursor命令行的开源实现，把三个数字写死在了代码里：最大迭代数20，警告线七万词元，强制轮换上下文八万词元；界面上还有一层健康度提示，低于六成绿灯，六到八成黄灯，超过八成红灯。

顺手纠一个到处流传的说法：这套东西不是Cursor官方产品，是社区实现，写它的是一位独立开发者，仓库当前494星。把它当成“大厂内置能力”去引用，会让你的团队高估它的稳定性承诺。

八万这个数字值得单独品一下。按二十万词元的窗口算，它选择在四成的位置就强制轮换，而不是撑到九成再压缩。这个保守到有点浪费的取值，反映的是实践者的真实经验：等窗口快满了再动手，模型的判断质量早就悄悄退了两个台阶。

无进展检测其实很好写，难的是定义“同一步”

四道刹车里，前两道是常数比大小，第四道靠外部检查，只有第三道需要自己设计，也最容易被跳过。

可落地的做法是给每一次动作算一个签名，签名相同就算原地踏步。签名怎么取决定了它灵不灵：只取工具名太粗，改一个参数就算新动作；把整段参数原样哈希又太细，多一个空格就骗过去了。实践里比较稳的取法是工具名加上归一化后的关键参数，比如文件路径、命令主体、目标URL，把时间戳和随机串剔掉。

三个计数器基本够用：同签名连续重复两次、同一条命令累计失败三次、同一个文件在十分钟窗口内被写超过五次。命中就停，把命中的签名和最近三条动作写进错误日志。

为什么要写日志而不是直接重试？因为空转从来不会自我纠正，它只会花钱。一个卡住的循环和一个正在慢慢解决问题的循环，从账单上看一模一样，只有签名重复率能把它们分开。

谁来对Agent说那个“不”？

让Agent给自己的产出打分，等于让学生批自己的卷子。值得咂摸的是，这不是靠提示词能改掉的性格问题，而是结构问题：生成答案的那套权重被拿来评判答案好不好，它有一切动机附和自己。

你可以叮嘱它对自己的工作保持批判，它会产出一段措辞漂亮的自我批评，然后照样给自己放行。

解法整个行业收敛到了同一处：把生产者和检查者分开。一个负责创造，另一个独立评审——不同指令、不同模型，最好干脆不用模型——负责证明它错了，并且有权把作业打回循环。

评审的信任层级，从高到低

• 确定性关卡：测试、类型检查、linter、真实的编译报错。它们没有自尊心，也没有讨好谁的欲望，是最强的一档。
• 带评分细则的独立模型评审：适合写不出测试的东西，比如文案质量、设计取舍。把一个独立评估器调得刻薄是可行的工程活。
• 生成者自评：只配用来做初筛，永远不能当作停机依据。

这层级里最容易被忽略的是第一档的性价比。很多团队一上来就琢磨怎么让第二个模型评得更严，却没先把已有的测试、类型检查和构建报错接进循环——那些关卡不要钱、不会说谎、也不需要调提示词。

评分细则写成什么样才不算走过场

需要模型来评的那些东西——文案好不好、结构合不合理——最容易退化成一句“请严格评审”，然后拿回一段温柔的表扬。

让它变硬只有一条路：把评审问题写成能答“否”的形式。“这段文案质量如何”永远得不到否定；“这段文案里有没有出现无法核实的具体数字”“标题有没有超过预设字符数”“页面有没有两个以上H1”，这些每一条都能干净利落地判失败。

再加一条更狠的：要求评审输出证据位置，而不是结论。让它回“第3段第2句，数字310%没有出处”，比让它回“建议加强数据支撑”有用一百倍，因为前者可以被你抽查真伪，后者不能。评审一旦知道自己的输出会被核对，敷衍的成本就上去了。

最后是把一切串起来的那条铁律：检查者必须待在生产者改不到的地方。给Agent一个“让测试通过”的目标，同时给它测试文件的写权限，有相当比例的时候，它会通过改测试来让测试通过。

这不是坏心眼，也不是模型的缺陷。循环在精确优化你给它的信号——你说要绿，删掉红色的那条断言确实能变绿。奖励作弊是笼子的设计问题，不是野兽的性格问题。这条约束在权限层怎么落地，可以顺着Claude Code的权限白名单与提示注入防御那一套配置往下配，把检查脚本和CI配置放进拒绝写入的名单里。

写操作不幂等，重试就是事故

工具这一层有一半是老生常谈：工具要少、要锋利、不要互相重叠。给实习生一百把枪，关键时刻他一定拔错；search_docs旁边摆着find_documentation和lookup，等于逼模型做一个本不该存在的选择。这半边大家都懂。

另一半没人在意，直到被咬：每一个写操作都必须幂等。

循环会重试，这是常态不是边界情况。超时、校验打嗝、模型犹豫，都会让同一个工具调用被发第二遍。行业里流传的一个统计是这个比例落在15%到30%之间，出处是一份第三方可靠性报告而非厂商数据，具体数值打折听，但方向没有争议。

如果一个非幂等的写操作恰好在超时前已经成功了，重试就会把它再执行一遍。落到独立站的语境里，这几件事分别长这样：

• 批量补商品结构化数据的脚本，把同一条产品评分标记写进了页面两次，富媒体结果反而被判为无效。
• 自动发券的Agent超时重试，同一个客户收到两张满减券，客服第二天才发现。
• 迁移站点时批量写301规则，同一条规则进了两遍，nginx直接起不来。

哪些操作必须挂键，哪些可以放过

不用给所有东西都加幂等。判据是这个操作重跑一遍之后，世界是不是回到了同一个状态。

• 读操作天然幂等，查商品、拉排名、抓页面，跑十遍也没事，不用管。
• 覆盖式写入接近幂等，比如把某个字段设成一个确定值、把某个文件整体重写，重跑一遍结果一样，风险低但仍要注意并发。
• 追加式和计数式写入是重灾区，插一行、发一次通知、扣一次额度、加一次库存流水，每重跑一次世界就多变一点，必须挂键。

还有一类容易漏掉的，是看起来像读、实际会改状态的操作。触发一次重新抓取、发起一次索引提交、调用一次会计费的第三方接口，它们在代码里长得像查询，账单上却是写操作。判断一个操作要不要挂键，别看函数名，看它有没有让别人那边多出一条记录。

解法要做成框架级保证而不是可选项：每个写操作带一个由入参确定性推导出来的幂等键，下游在一个时间窗内（二十四小时是常见默认值）对同一个键返回第一次的缓存结果，而不是再执行一遍。一句话判据——如果它不能被安全地调两次，那循环就不该调它一次。

掉进沟里长什么样，怎么自动认出来？

前面那个494星的实现，把“卡住”这件事做成了可判定的三个触发器，值得原样抄：同一条命令连续失败三次；同一个文件在十分钟内被写五次；或者Agent自己在输出里吐出一个约定好的求救标记。命中任意一条，把模式写进错误日志，停机，等人。

它落盘的六个文件也值得抄一遍结构：进度、护栏、活动日志（带每次工具调用的词元数）、错误日志、任务缓存、当前轮次编号。停机条件同样是三条——任务清单全部打勾、Agent吐出完成标记、或者撞到迭代上限。

这里有个反直觉的设计选择值得说一句：命中之后它选择停机等人，而不是自动换个策略再试。因为掉进沟里这件事，本质上是循环拿到的信息不足以自救，再多给它几轮，只是把同一个洞挖深。自动恢复听起来更智能，实际是把一次可以及时止损的失败，摊薄成一晚上看不出异常的持续消耗。

护栏文件是整套东西里唯一会变强的部分

最有意思的机制叫“路标”。每次失败，Agent要往护栏文件里追加一条记录，包含三个字段：触发条件是什么、下次该怎么避开、这条是第几轮之后加的。后面每一轮开工先读护栏文件。

这就是循环工程里少见的正反馈：模型的权重不会因为你跑了两百轮而变好，但护栏文件会一轮比一轮厚，而它是你的资产，不是模型厂商的。把它提交进git，团队里下一个人接手时，拿到的不是一句“这玩意有时候会抽风”，而是一份带触发条件的排错手册。

内循环交给Agent，外循环凭什么必须人拿着？

写到这儿都还是2026年上半年的共识。真正把这套讨论往前推了一步的，是7月中旬的一篇文章：Osmani在7月15日提出，Agent已经能跑内循环，人必须拥有外循环。

内循环是调查、实现、验证、重复——这几步交出去没问题。外循环是问责边界，由三根柱子撑着：

• 质量，指的是在放它出笼之前你装好的全部检查。
• 裁决，指的是上线与否由人来定。原话是模型可以写下那一行，但裁决是我的。
• 可交代，指的是别人问起来的时候，你能说清楚当初为什么这么判。

这三条为什么必须由人拿着，那篇文章给的证据比口号硬。一项2026年的代码质量调查显示，有42%的提交代码由AI生成或经过AI大幅辅助；Anthropic的一项研究发现，用AI完成任务的工程师在事后理解度测验上比对照组低了17个百分点，五成对六成七；沃顿的一项研究则更扎心——当AI给出的答案是错的，接近四分之三的人照样接受了它。

把这三个数字连起来读，结论很不客气：随着Agent接手的比例上升，人对自己名下代码的理解度是在下降的，而且人对错误答案的抵抗力本来就不高。护栏装得再好，最后那一下“我认”，没有任何机制能替你按。

抽检定成多少才不流于形式

外循环最常见的塌法不是不抽检，而是抽检变成走过场——每次都点开第一条、扫两眼、点通过。

让抽检重新长牙有三个动作。第一，抽样必须随机且可复现，用批次编号加序号算个哈希取模，别让人自己挑，人一挑就挑最容易看懂的那条。第二，抽检记录要落盘，写清楚看了哪几条、看的是什么、判断依据是什么；这份记录就是可交代那根柱子的实体。第三，抽检不通过要有后果——不是让Agent重跑一遍，而是把这一类失败写进护栏文件，让它下一批就不再犯。

比例怎么定，可以跟着风险走：改的是展示文案，抽一成；改的是会影响收录的标题和结构化数据，抽三成；改的是跳转规则、价格、库存这类一错就出事的，一条不漏地全过一遍机器校验，再抽人工。抽检比例不该按你有多少时间来定，该按错一条要赔多少钱来定。

独立站和SEO团队该先装哪一根？

不是所有活都值得造笼子。给一只金丝雀焊铁笼是过度工程：Agent只调一次工具就返回，或者三步的确定性流程，你不需要压缩策略，也不需要独立评审。

但有两根，只要牵涉真金白银或线上数据，短循环也不许省——刹车（让一个bug没法永远循环）和幂等（让一次重试没法污染数据）。只读的五步循环可以跳过上下文保洁和评审；任何会写东西的循环，这两根永远不能跳。

值得上全套的，是那些长周期、可重复、且完成信号机器可验证的活。落到这个站的读者身上，保哥自己在用的判断方式是先问一句：这件事干完之后，有没有一个不需要我看一眼就能变绿的检查？

去年帮一个3C配件出海团队做批量改标题的时候，翻车就翻在这张表的最后一行：脚本把长度和重复率全跑绿了，人一看，八成的标题读起来像同一句话套了不同型号。机器能验的那一半通过了，不能验的那一半塌了——这恰恰说明检查项定义在哪儿，Agent就把力气花在哪儿。

接线顺序按爆炸半径来

先上幂等和刹车，它们防的是事故；再上独立评审，它防的是自信地错；最后上上下文保洁，它防的是慢性质量腐烂。想同时上四根的团队，通常四根都装得不结实。

如果要给一个具体的起步节奏，可以这样排：第一天只做一件事，把这批活的完成检查写出来并且跑通，跑不出来就说明这活还不该上循环；第二天把迭代上限、金额上限和墙钟上限三个常数写进脚本，数值往小了设；第三天补幂等键和无进展检测，然后让它跑第一批，人在旁边盯着，每一次失败都当场追到根并写进护栏文件；第四天开始才谈无人值守，而且第一次无人值守跑的批量，规模应该小到就算全错也能手工回滚。

顺序反过来的团队很常见，通常是先花两周搭一套漂亮的多Agent编排，再回过头发现连一个能变绿的检查都没有。能不能写出那个检查，才是这活该不该自动化的分水岭，剩下的都是实现细节。

真正跑起来之后，编排是下一个问题而不是这个问题。多个循环怎么分工、什么时候值得并行、主循环怎么收编子Agent的结论，可以顺着Agent Teams的多Agent协作配置往下走；想弄明白这个循环在代码层面到底长什么样，用两百多行Python手搓一个智能体循环是最快的路径；而迭代上限、预算上限这些刹车在官方SDK里对应哪些参数，Claude Agent SDK的实战配置里有现成写法。

最后留一份起飞前检查，任何循环无人值守跑之前过一遍：它会遗忘吗？它会停吗？有东西能对它说不吗？它的写操作被调两次也没事吗？四个问题里任何一个答“否”，你就有一个缺口，而循环一定会找到它。

常见问题解答

循环工程和上下文工程、提示词工程是什么关系？

是一层套一层的关系，不是替代关系。提示词工程管你发出去的那句话，上下文工程管模型在单次调用里看到的全部词元，harness工程管它能碰到的工具和环境，循环工程管把这些反复驱动向目标的迭代过程。越往外层，越不依赖具体是哪个模型，也越难被竞争对手抄走。

迭代上限设成10是不是太小了，很多任务根本做不完？

做不完正是这个取值想告诉你的信息。有上限的循环提前停下，代价是一次便宜的重跑；没上限的循环整夜空转，代价是第二天的账单。十轮足够你判断规格文件到底能不能支撑循环跑，而一百轮足够你在凌晨三点才发现它不能。先用小上限验证规格质量，信任建立起来了再往上调。

用同一个模型开两个会话，一个当生产者一个当评审，算独立评审吗？

算，但只是最弱的那一档。它解决了上下文互相污染的问题，没解决同一套权重倾向于认同同类输出的问题。可行的加固有三条：给评审换一个模型、给它一份明确的评分细则、并且优先把能写成测试或类型检查的部分交给确定性关卡。真正的分水岭不在于用几个模型，而在于检查者是否处在生产者改不到的位置。

幂等键应该怎么生成，用随机UUID可以吗？

不可以。随机值每次重试都不一样，等于没有键。幂等键必须由入参确定性推导，比如把用户标识、目标资源、任务编号这几项拼起来做哈希，保证同一次逻辑操作无论被重试多少遍都算出同一个键。下游据此在时间窗内返回第一次的结果，二十四小时是常见默认值。

Ralph这种每轮清空上下文的做法，会不会把之前学到的东西全丢了？

会丢掉对话，但不丢进度和教训，前提是你把这两样外置。进度写在文件和git历史里，教训写在护栏文件里，每一轮开工先读这两样。这套做法反而比长对话更稳，因为git历史可审查、不会悄悄退化，而一段二十万词元的对话既看不清也回不去。

没有测试的老项目，是不是就完全没法跑自主循环？

可以先造一个便宜的验证器，再跑循环。构建能不能过、类型检查干不干净、关键页面的HTTP状态码对不对、结构化数据校验有没有报错，这些都算机器可验证的完成信号，成本远低于补一整套测试。把第一轮循环的目标定成“为模块X补上可运行的冒烟测试”，本身就是一个有诚实终点的任务。

权威参考资料