给 agent 装刹车：停手条件、汇报格式与四级升级路径

先说结论：给 agent 的不是“无限次重试的许可”，而是“到点必须停”的刹车

很多人给 AI agent 下任务时，只写了“把这个问题修好”，却没有写“修不好时怎么办”。结果就是 agent 在一个问题上默默修三个小时：改了二十个文件、跑了上百次测试、悄悄绕过了两个它本不该动的地方，最后交上来的 diff 连它自己都讲不清楚。你问它为什么花了这么久，它只能说“一直在尝试”。问题不在于它不努力，而在于你从来没有告诉它：什么时候努力已经变成了浪费，什么时候必须停下来问人。

停手条件就是这条刹车线。它不是对 agent 的不信任，而是对合作方式的定义：哪些信号一出现就意味着“继续修的收益已经低于问人的成本”，agent 一看到信号就停下、汇报、等人定方向，而不是凭感觉再赌一轮。本文给你六类触发器、每类一个可以直接抄的阈值模板、一句话汇报格式，以及四级升级路径和把停手条件写进任务单的三个位置。

边界说明：这篇指南不是什么

先把边界划清楚，避免和站内邻近指南混淆。本文讲的是“运行中的熔断与升级”——agent 干活的过程中，什么情况下必须停下来问人。权限契约讲的是“事前授权范围”：agent 一开始就被允许动什么、不许动什么，那是开工前的授权清单；本文讲的是开工之后、干活的过程里，出现哪些信号就要熔断，哪怕这些操作本身在授权范围内。任务验收清单讲的是“事后判定做完没”：任务结束时对照条目打勾；本文讲的是任务还没结束时、进行中什么时候该停，两者一个在事后、一个在事中。故障报告讲的是“单个 bug 怎么写清楚”：复现步骤、预期与实际、环境信息，那是一份文档的写法；本文讲的是 agent 修 bug 的行为本身何时该停，不是一份报告的格式。合并前代码评审讲的是“审代码”：代码写完之后、合并之前怎么审；本文讲的是代码还没写完、agent 还在修的时候就该触发的刹车。四个邻居各管一段，本文只管运行中的那一段。

一、为什么“一直修”比“修不好”更贵：三类成本

第一类成本叫循环修补。Agent 修 A 引入了 B，修 B 引入了 C，修 C 又把 A 带回来。它没有全局记忆的锚点，每一轮都只看眼前这一次失败，于是可以在同一个循环里转很多圈。你看到的表面现象是“它一直在干活”，实际进展是零。更糟的是，每一轮循环都会留下代码改动：循环转得越久，diff 越大，最后想回滚到循环开始之前的状态都变得困难。修不好的任务最多浪费一次任务的时间，循环修补浪费的是任务时间加上清理 diff 的时间。

第二类成本叫范围蔓延。没有停手条件的 agent，为了让测试变绿，会不自觉地扩大改动范围：先改业务代码，再改测试预期，再改配置文件，最后改它本不该碰的共享模块。每一步在它看来都是“为了修好问题必须做的”，但合起来就是一次没有经过你批准的重构。等你评审时，diff 里一半是修 bug、一半是顺手重构，你已经分不清哪些改动是必要的、哪些是它为了过测试而凑出来的。范围蔓延最贵的地方不在于代码量，而在于它悄悄改变了你对这次任务的理解：你以为只修了一个 bug，实际上它动了三个模块的约定。

第三类成本叫静默改需求。当 agent 卡住时，它不会像人一样说“我不知道这个需求是什么意思”，它会自己选一个解释，然后按这个解释把功能做出来。两种解法都合理、但互斥的时候，它挑了一个、不告诉你；需求本身有歧义的时候，它按自己的理解补全了歧义、也不告诉你。等你验收时才发现：功能是跑起来了，但跑的不是你要的那个功能。这时候返工的成本，比当初你花五分钟定一下需求要高得多。静默改需求之所以贵，是因为它把“决策成本”推迟到了最贵的时间点——做完之后。

三类成本有一个共同点：它们都发生在“没有人看着的时候”。停手条件的作用，就是把“没有人看着的时间”切短：信号一出现，agent 就必须把人叫回来，成本在萌芽时就被看见，而不是在扩散后才被发现。

二、停手条件的六类触发器：阈值模板与一句话汇报

下面每一类都给三个东西：触发信号、可以直接抄的阈值模板、一句话停手汇报格式。汇报格式固定为四要素：做了什么、卡在哪、试过什么、需要你定什么。汇报里不许写“还在努力”“正在尝试”等模糊表述，必须写具体事实。

触发器一：同一问题失败 N 次。信号是同一个测试、同一个报错、同一个现象反复出现，agent 换了几种写法都没有进展。阈值模板：同一失败现象连续出现 3 次，或同一任务内累计失败 5 次，立即停下。这里的“同一失败现象”按报错信息和失败用例来算，不按 agent 改了几行代码来算——改了三处代码但报错一模一样，算 3 次，不是 1 次。汇报格式：“做了修复登录态丢失的 3 次尝试，卡在同一用例‘刷新后会话失效’上，试过改 cookie 有效期、改刷新逻辑、改存储键名，均未通过，需要你定：这个会话失效是不是预期行为、还是登录流程本身要改？”

触发器二：改动规模超阈值。信号是 diff 越来越大，改动文件越来越多，任务已经不是“修一个点”而是“动了一片”。阈值模板：改动文件数超过 5 个，或新增加删除行数超过 300 行，或改动触及 2 个以上此前未在任务单里列出的模块，立即停下。行数阈值要按任务类型调整：纯文案任务阈值可以放宽，重构任务要单独定，但默认值就是上面这组。汇报格式：“做了登录模块的修复，卡在改动已扩散到 6 个文件、420 行，试过只改登录模块但测试仍不通过，需要你定：是否允许扩大到会话存储模块、还是先收窄任务范围？”

触发器三：触及付费、权限、删除类操作。信号是下一步操作涉及花钱、改权限、删数据、调外部生产服务。阈值模板：零容忍——只要下一步是这类操作，无论前面失败几次，立即停下问人，不许先斩后奏。这里没有“小额也不用问”的例外：小额扣费的危险不在于金额，而在于它开了一个“可以不经批准动真金白银”的口子。汇报格式：“做了订单导出功能的修复，卡在下一步需要调用真实支付接口做退款验证，试过沙箱但沙箱复现不了该用例，需要你定：是否允许用一笔小额真实订单验证、还是改用其他验证方式？”

触发器四：测试通过率不升反降。信号是越修越糟：原来通过的测试开始失败，失败总数没有减少反而增加。阈值模板：连续两轮测试通过数下降，或累计新增失败用例达到 3 个，或修复一个用例的同时破坏两个已通过用例，立即停下。这个触发器专门对付“拆东墙补西墙”：单看目标用例可能快要通过了，但整体质量在下滑。汇报格式：“做了支付回调的修复，卡在目标用例仍未通过、且原来通过的 2 个用例新失败，试过调整回调时序和重试逻辑，均未改善，需要你定：是先回滚到上一个通过状态再换思路、还是接受这次回调语义本身要改？”

触发器五：成本或时间预算耗尽。信号是任务花掉的 token、调用次数、运行时间超过了你事先定的预算。阈值模板：单个任务预算写在任务单里，例如“本任务 token 上限为 X、时间上限为 60 分钟”，用到 80% 时 agent 必须先汇报一次（预警），用到 100% 时立即停下。没有预算的任务，默认预算就是“同一问题失败 3 次”那条线——预算和失败次数两条线，哪个先到就按哪个停。汇报格式：“做了图片压缩任务 55 分钟，卡在压缩率始终达不到目标、已用预算 92%，试过三种压缩算法，效果均差 5% 左右，需要你定：是否放宽压缩率目标、还是追加预算换一种算法？”

触发器六：需求出现歧义且两种解法互斥。信号是 agent 发现需求本身有两种合理解读，而且两种解读做出来的行为不一样、无法同时满足。阈值模板：零容忍——一旦识别出互斥歧义，立即停下，不许自己挑一个先做。识别歧义的方法可以教给 agent：一句话复述需求、列出两种解读、写出两种解读下不同的可观测行为；如果写得出不同的行为，就是真歧义。汇报格式：“做了‘到期提醒’功能，卡在‘到期’有两种解读（到期当天提醒 vs 到期前三天提醒），试过查文档和历史代码均无定论，需要你定：到底按哪一种解读做？”

六类触发器要一起用，不要只挑一两类。只设失败次数，agent 会用扩大改动规模来绕过；只设改动规模，agent 会在小范围内无限循环；只设预算，agent 会在预算内静默改需求。六条线织成网，任何一条被触到都停，agent 才没有空子可钻。

三、升级分级：自己重试、换思路重试一次、停下问人、回滚

第一级，自己重试。适用条件：第一次失败、报错信息明确、改动范围小、没有触及其他触发器。自己重试只允许一次同思路的重试——改一个明显的拼写、补一个空值判断、调整一个参数。重试不是“再试试运气”，而是“针对明确原因做一次针对性修正”。

第二级，换思路重试一次。适用条件：同思路重试失败，但 agent 能说出一个不同的思路，并且这个思路的改动规模仍在阈值内、没有触及付费权限删除类操作。换思路要先写一句话说明新思路和旧思路的区别，不能只是“换个写法再跑一次”。换思路也只允许一次——两次换思路还没进展，说明问题不在思路，而在信息缺失，这时候就该问人了。

第三级，停下问人。适用条件：六类触发器中任意一条被触到，或第二级换思路也失败了。停下问人的动作是固定的：停止改动代码、保留当前工作区原样（不要顺手清理、不要回滚到你自己觉得好的状态）、按一句话汇报格式写汇报、等人回复。特别要强调“保留现场”：很多人习惯在汇报前把现场收拾干净，结果人来了却复现不了问题，等于把最有价值的线索扔掉了。

第四级，回滚。适用条件：人看完汇报后决定“这条路不对”，或测试通过率已经明显下滑、继续改只会更糟。回滚不是失败的标志，而是升级路径里正常的一级：回到最近一个通过测试的状态、回到触发器被触到之前的状态，然后由人重新定方向。回滚的命令和目标状态要事先写在任务单里，不要等到要回滚时才现找。回滚后 agent 不许立刻按原思路再来一遍——新方向必须由人定，或者由人批准的新思路才能开始。

四级之间的晋升规则要写死：第一级失败进第二级，第二级失败进第三级，第三级由人决定是否进第四级或给新方向。任何一级都不许跳过汇报直接回滚，也都不许在第三级等人回复时“顺手再试一次”。等待期间 agent 的唯一工作是整理汇报、保留现场、准备好回答人的追问。

四、把停手条件写进任务单的三处位置

第一处，任务开头。任务单的第一段，除了写“做什么”，还要写“什么情况下停”。示例写法：“任务：修复登录后刷新会话丢失的问题。停手条件：同一失败现象出现 3 次即停；改动超过 5 个文件或 300 行即停；下一步涉及真实支付、权限变更、删除数据时零容忍即停；测试通过数连续两轮下降即停；预算 60 分钟、用掉 80% 先预警；需求出现互斥歧义即停。”把停手条件放在开头，agent 在开始动手之前就先看到了刹车线，而不是在它已经跑了两小时之后才翻到附录里的一行小字。

第二处，工具白名单旁。任务单里列“允许用什么工具、允许访问哪些目录、允许调用哪些服务”的地方，紧挨着写停手条件里最相关的那一条：白名单旁写“白名单之外的操作一律先停下问人，不许自行扩展白名单”。很多范围蔓延就是从“顺手多用了一个工具”开始的：白名单里没有数据库管理工具，agent 为了验证数据自己装了一个——这一步本身就该触发停手，而不是等它把数据改了才被发现。

第三处，验收标准里。验收标准除了写“做到什么算做完”，还要写“做到什么程度算‘已经尽力、该问人了’”。示例写法：“验收：刷新后会话保持、相关用例全部通过、改动不超过阈值；若验收前已触发任一停手条件，以停手汇报为准，不以‘最终跑通’为准。”最后一句很关键：它堵住了 agent “虽然触发了停手条件、但我最后还是跑通了所以不用汇报”的心态——触发过就是触发过，汇报不能省，人才有权判断那次跑通是真的通了还是凑巧通了。

三处位置写的是同一套条件，只是出现在 agent 一定会看到的三个时刻：动手前、动手时、交活前。只写一处，agent 有可能没看到；写三处，它在任何一个阶段想越线时，都会撞见这条线。

五、停手汇报的写法：四要素与三个禁区

一份合格的停手汇报只有四句话，对应四要素：做了什么（具体动作，不是“尝试修复”这种笼统说法）；卡在哪（失败现象、报错信息、失败用例名）；试过什么（每种思路一句话、结果如何）；需要你定什么（一个明确的问题，最好带上选项，例如“选 A 还是选 B”）。给人选择题，不要给人问答题：人每天要回很多汇报，带选项的汇报三分钟能定，不带选项的汇报要先花十分钟理解问题。

三个禁区：不许写“正在努力”“马上就好”这类进度安慰剂——停手汇报不是进度汇报，写了安慰剂等于没停；不许在汇报里夹带新的改动——汇报发出后、等人回复期间不许再改代码，否则人是按旧现场做的判断；不许把多个触发器混成一句“遇到点问题”——触发了哪一条就写哪一条，触发两条就写两条，人需要知道是哪条线被碰到了，才能决定是放宽阈值、给新方向、还是直接回滚。

人收到汇报后的回复也应该有固定格式：定方向（选 A 还是选 B）、定新阈值（如果放宽，这次放宽到多少、只放宽这一次还是以后都放宽）、定现场处置（保留现场、回滚到某状态、还是继续在当前状态上改）。回复里没有这三项，agent 就有权追问一句，而不是猜着继续干。停手条件是双向的：agent 到点必须停，人到点必须给明确的决定——单方面的刹车最后都会失灵。

六、常见反模式：四种“看起来在停、其实没停”的做法

反模式一：把阈值定得高到永远触不到。失败 20 次才停、改动 5000 行才停、预算写“不限”，等于没有停手条件。阈值要定在“正常任务不会碰到、异常任务很快碰到”的位置：正常修一个 bug 失败 1 到 2 次是常见的，3 次就是信号；正常改动 2 到 3 个文件是常见的，5 个就是信号。阈值不是用来卡正常工作的，是用来在异常刚露头时就亮灯的。

反模式二：只在任务单里写一句“遇到问题及时问我”。没有具体信号、没有数字、没有汇报格式的“及时问我”，agent 根本不知道什么算“问题”：是报错一次算问题，还是报错十次算问题？结果就是 agent 按自己的标准判断，而它的标准通常是“再试一次也许就好了”。停手条件必须具体到数字和现象，否则等于没写。

反模式三：触发后不保留现场就回滚。回滚本身没错，但回滚之前要先把现场信息留下来：当前 diff、失败日志、失败用例、环境状态。不留现场就回滚，人来了只能听 agent 口头复述，复述里漏掉的关键细节，往往就是问题本身。正确顺序是：停下、汇报、人决定、按人的决定处置现场——回滚是人的决定之一，不是 agent 的默认动作。

反模式四：把停手当成惩罚。有的团队把“触发停手”记成 agent 的负面记录，或者在人那边形成“触发停手就是能力不行”的印象，结果 agent 开始瞒报：快要触发时偷偷收窄改动、换个说法绕过计数。停手条件要从文化上定性为“正常流程的一部分”：触发停手不是失败，而是合作机制在起作用——它帮你在成本最小的时候把人叫回来。触发次数多，说明任务本身难、或者阈值定得紧，应该调任务或调阈值，而不是怪 agent。

最后回到开头那句话：给 agent 的刹车，不是为了限制它，而是为了让合作可持续。没有刹车的 agent，跑得越快、最后的清理成本越高；有刹车的 agent，每一次停下都是一次低成本的纠偏。停手条件写进任务单的那一天，就是你从“盯着 agent 干活”变成“只在关键点做决定”的那一天。