---
title: "Agent 跑得越快，越要提前告诉它什么时候停 | 行开心的颠倒世界"
description: "Agent 长任务除了完成目标，还要写明三类停点：连续尝试无改善、缺少关键事实、即将越过范围。停下汇报，比继续猜更省时间。"
canonical: "https://xingkaixin.me/posts/agent-stop-conditions/"
language: "zh-CN"
---

# Agent 跑得越快，越要提前告诉它什么时候停

Agent 长任务除了完成目标，还要写明三类停点：连续尝试无改善、缺少关键事实、即将越过范围。停下汇报，比继续猜更省时间。

2026年8月3日·1,151 字·3 分钟

[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[Agent](https://xingkaixin.me/tags/Agent/)[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)

![Agent 跑得越快，越要提前告诉它什么时候停](https://xingkaixin.me/cover/agent-stop-conditions.webp)

Eric Zakariasson 会同时跑三到五个长任务 Agent。模型实验盯分数，前端任务跑 Playwright、看截图，后端重构跑测试，性能任务看 p95。Agent 在云端继续工作，完成或者需要决定时，通过 Slack 找他。

![Eric Zakariasson 的 Human in the Loop 工作流](https://xingkaixin.me/posts/images/agent-stop-conditions/source-eric-human-in-loop.webp)

这套做法最容易被注意到的是“同时跑五个”。我反而更在意他写在循环里的两句话：连续几次没有改善就停；没有思路、被阻塞或不确定时，停下来问。

停点触发后，人才回来做下一步判断。

没有这两句，并行只会更快地产生烂摊子。

![并行任务各自盯着可观察的指标](https://xingkaixin.me/posts/images/agent-stop-conditions/agent-stop-conditions-01.webp)

## 一个红了两小时的测试

假设任务是修一条偶发失败的测试。Agent 先加等待，没好；再改重试，还是红；接着怀疑测试框架，升级依赖，又花一轮修类型错误。最初只动一个文件，最后 diff 铺到二十多个。

这种过程并不荒唐。每一步都有解释，Agent 也一直在“尝试解决问题”。可连续三次修改都没有让失败频率下降，它现在需要的是新证据：那次 CI 的日志、一个只能在生产出现的数据样本，或者人来判断这条测试到底该不该保留。

很多长任务只写完成条件：“做到测试全绿为止。”目标很清楚，受阻时怎么处理却留空。Agent 不会像同事那样看一眼时间，走过来问你一句“还值得继续吗”。它有 token、有工具，也总能再试一版。

所以停止条件需要在开跑前写进去。

## 三个停点已经够用

Eric 的原始写法很短：达到指标；几次尝试无改善；想不到办法；阻塞或不确定就问。落到普通开发任务，还应加一个范围检查。

停止条件跟失败没有关系。它决定的是 Agent 该在哪个节点把控制权交回来。

一是结果不再变好。别写“尝试多次”，给一个当前任务能观察的数。连续三次测试数量没减少，连续三版页面仍然卡在同一个交互，连续两轮性能没有提升，都算。

二是缺关键事实。拿不到日志、权限、业务决定，继续只能靠猜。此时要汇报缺什么，而不是拿一个合理假设把洞填上。

三是下一步要越界。修组件却要改公共接口，处理查询却要迁移数据结构，解决报错却要升级核心依赖。这些方案可能是对的，但已经需要人重新确认代价。

放进任务里不用写成长合同。一段话足够：“做到验收目标为止；连续三次没有改善、缺少关键事实，或下一步要改任务范围外的公共部分时，停止修改。告诉我已经验证了什么、试过什么，以及现在需要我决定什么。”

这段话比“遇到问题及时沟通”强，因为 Agent 不必猜什么程度才算问题。

阈值还得跟指标一起写。性能任务可以规定 p95 连续三轮不降就停；修测试可以看失败数量；UI 任务则看同一条操作路径是否仍然走不通。只写“效果不好”没有用，Agent 和人对“不好”的耐心并不相同。

![三个该停下来的节点](https://xingkaixin.me/posts/images/agent-stop-conditions/agent-stop-conditions-02.webp)

## 停下来以后，别把 session 原样扔回来

一句“我被阻塞了”没有省下人的时间。接手的人仍要从头读日志，弄清它试过什么。

有效的停止汇报应该很像一张故障便签：当前能确定的事实，已经排除的方向，最后一次有变化的结果，下一步缺哪个决定。Eric 让 Agent 通过 Slack ping 自己，意义也在这里。他收到的是一个需要决策的节点，不是持续滚动的工作直播。

停点定得太敏感，Agent 会每走两步就请示；完全没有停点，人又只能一直盯着。阈值要跟任务调整。十分钟的小改动不用这套规则，跑半小时以上、会循环试错或可能碰公共模块的活，才值得写。

Eric 可以同时放出去三到五个 Agent，不只是因为云端能跑，也因为每个任务知道什么时候该把控制权交回来。速度管执行，停点管失控。没有后一条，你多开的每一个 Agent，都会带着新问题回来找你。

## 版权声明

作者

XingKaiXin

标题

Agent 跑得越快，越要提前告诉它什么时候停

发布时间

2026年8月3日

文章链接

[https://xingkaixin.me/posts/agent-stop-conditions/](https://xingkaixin.me/posts/agent-stop-conditions/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览