引言：从「跑起来」到「停得下」
过去两年，Agent 的叙事重心一直放在「能跑起来」上：更长的上下文、更全的工具集、更花哨的规划链。可一旦 Agent 真正进入生产环境，一个朴素得多的问题就会浮出水面——它什么时候该停？a16z 近日发布文章《Knowing When to Stop: The Art of Making a Loop Converge》，把「让循环收敛」单独拎出来当作一门手艺来讨论（原文，Hacker News 讨论）。选题本身就是个信号：Agent 工程的瓶颈，正在从油门转向刹车。
事件要点：停止是设计出来的，不是天生的
现代 Agent 的运行时骨架大同小异：接收任务、规划、调用工具、观察结果、再规划——一个不断自转的循环。听起来很自然，难点全在最后一步：谁来宣布「完成」？
从标题的用词就能读出立场：作者把收敛称为「艺术」（art）。言下之意，它不是模型能力提升后自动附带的赠品，而是需要刻意设计的系统属性。这与社区的普遍体感一致：同一个模型，套进不同的循环设计里，产出稳定性和 token 消耗可以差出数倍。
背景：循环的三种死法
实践中，跑不稳的 Agent 循环大致有三种典型失败模式：
- 过早收敛。模型在结果「看起来对」时就自信收工，缺少独立验证，错误被体面地包装后交付。
- 永不收敛。自我审查无限递归，一轮比一轮挑剔，token 烧穿预算，最终产出反而离题更远。
- 振荡。在两个方案之间来回横跳——像数值迭代里步长过大导致的不收敛震荡，改 A 破 B，改 B 又破 A。
工程师们其实已经摸出一批现实可用的「刹车」：硬性预算上限（步数、token、时间）；让验收测试当裁判，以测试套件是否通过充当收敛判据——SWE-bench 这类基准早已把「测试通过」隐式定义为停止条件，只是真实用户不会像基准框架那样替 Agent 兜底；diff 约束，要求每次修改相对上一版的差异单调缩小；还有把「停止」本身做成一个显式的工具调用，训练模型学会举手。
有意思的是，这与数值计算形成了对照：迭代法有「残差足够小、步长足够小」这样成熟且可证明的收敛准则，而 Agent 循环至今缺少公认的「残差」度量——任务完成度究竟怎么量化，仍是个开放问题。
影响：终止条件正在变成显学
对成本而言，停止条件直接决定单位任务的 token 消耗，Agent 产品的经济性一半系于刹车是否灵敏；对评测而言，主流基准用外部 harness 替 Agent 做了停止决策，掩盖了这个维度，也让榜单成绩与真实体验出现脱节；对工程文化而言，重心正从「提示词工程」转向「循环工程」——终止条件、验证器、回滚策略开始成为与提示词平级的一等公民。各家编码 Agent 纷纷把「完成的定义」写进系统设计，恰恰说明行业已经在这个坑里交过学费。
点评
模型能力每上一个台阶，收敛问题就更容易被误认为已经顺带解决。但「何时停止」本质上是在给「任务完成」下定义，而定义权恰恰是系统设计者的责任边界。眼下会跑的 Agent 不缺，缺的是知道何时收手的那一类——把刹车做好，或许比再踩一脚油门更接近值得托付的生产环境。