Agent 跑得越快，越要提前告诉它什么时候停
Eric Zakariasson 会同时跑三到五个长任务 Agent。模型实验盯分数，前端任务跑 Playwright、看截图，后端重构跑测试，性能任务看 p95。Agent 在云端继续工作，完成或者需要决定时，通过 Slack 找他。
这套做法最容易被注意到的是“同时跑五个”。我反而更在意他写在循环里的两句话：连续几次没有改善就停；没有思路、被阻塞或不确定时，停下来问。
停点触发后，人才回来做下一步判断。
没有这两句，并行只会更快地产生烂摊子。
一个红了两小时的测试
假设任务是修一条偶发失败的测试。Agent 先加等待，没好；再改重试，还是红；接着怀疑测试框架，升级依赖，又花一轮修类型错误。最初只动一个文件，最后 diff 铺到二十多个。
这种过程并不荒唐。每一步都有解释，Agent 也一直在“尝试解决问题”。可连续三次修改都没有让失败频率下降，它现在需要的是新证据：那次 CI 的日志、一个只能在生产出现的数据样本，或者人来判断这条测试到底该不该保留。
很多长任务只写完成条件：“做到测试全绿为止。”目标很清楚，受阻时怎么处理却留空。Agent 不会像同事那样看一眼时间，走过来问你一句“还值得继续吗”。它有 token、有工具，也总能再试一版。
所以停止条件需要在开跑前写进去。
三个停点已经够用
Eric 的原始写法很短：达到指标；几次尝试无改善；想不到办法；阻塞或不确定就问。落到普通开发任务，还应加一个范围检查。
停止条件跟失败没有关系。它决定的是 Agent 该在哪个节点把控制权交回来。
一是结果不再变好。别写“尝试多次”，给一个当前任务能观察的数。连续三次测试数量没减少，连续三版页面仍然卡在同一个交互，连续两轮性能没有提升，都算。
二是缺关键事实。拿不到日志、权限、业务决定，继续只能靠猜。此时要汇报缺什么，而不是拿一个合理假设把洞填上。
三是下一步要越界。修组件却要改公共接口，处理查询却要迁移数据结构，解决报错却要升级核心依赖。这些方案可能是对的，但已经需要人重新确认代价。
放进任务里不用写成长合同。一段话足够：“做到验收目标为止；连续三次没有改善、缺少关键事实，或下一步要改任务范围外的公共部分时，停止修改。告诉我已经验证了什么、试过什么，以及现在需要我决定什么。”
这段话比“遇到问题及时沟通”强，因为 Agent 不必猜什么程度才算问题。
阈值还得跟指标一起写。性能任务可以规定 p95 连续三轮不降就停；修测试可以看失败数量；UI 任务则看同一条操作路径是否仍然走不通。只写“效果不好”没有用，Agent 和人对“不好”的耐心并不相同。
停下来以后，别把 session 原样扔回来
一句“我被阻塞了”没有省下人的时间。接手的人仍要从头读日志，弄清它试过什么。
有效的停止汇报应该很像一张故障便签：当前能确定的事实，已经排除的方向，最后一次有变化的结果，下一步缺哪个决定。Eric 让 Agent 通过 Slack ping 自己，意义也在这里。他收到的是一个需要决策的节点，不是持续滚动的工作直播。
停点定得太敏感，Agent 会每走两步就请示；完全没有停点，人又只能一直盯着。阈值要跟任务调整。十分钟的小改动不用这套规则，跑半小时以上、会循环试错或可能碰公共模块的活，才值得写。
Eric 可以同时放出去三到五个 Agent，不只是因为云端能跑，也因为每个任务知道什么时候该把控制权交回来。速度管执行，停点管失控。没有后一条，你多开的每一个 Agent，都会带着新问题回来找你。