Agent 中的 Stopping Conditions
Stopping conditions 是 agent 执行闭环中的退出规则,用来控制何时成功结束、何时失败停止、何时转人工,而不是无限继续尝试。
#tech / ai
#type / concept
#status / growing
[!info] related notes
- 所属 MOC: Agent MOC, Agent Evals MOC, Coding Agent MOC
- 前置概念: Agent, Agent Runtime
- 并列概念: Agent 中的 Approval Checkpoints, Agent Guardrails
- 易混淆概念: Agent 中的人类监督
- 关系笔记: Agent 执行闭环
Agent 中的 Stopping Conditions
一句话定义
Stopping conditions 是决定自主 Agent 何时停止执行的机制,通过预算限制、成功检测、失败阈值和人类干预触发等规则,防止无限循环并控制执行成本与质量。
核心机制 / 工作原理
为什么重要
没有停止条件的 agent loop 很容易退化成:
- 一直重试同一种错误路径(无限循环)
- 消耗过多 token、时间或工具预算(成本失控)
- 在高风险环境里持续放大错误(安全风险)
- 输出质量随轮次递减但无人叫停(质量退化)
常见停止条件
| 类型 | 机制 | 示例 |
|---|---|---|
| 最大步数 | 超过轮次上限强制停止 | 最多执行 20 轮 |
| Token 预算 | 累计 token 消耗超过阈值 | 总 token 不超过 100k |
| 成功检测 | 任务完成条件满足 | 测试全部通过、构建成功 |
| 置信度阈值 | 模型对结果的信心低于阈值 | 连续 3 次不确定 |
| 连续失败 | 同类错误重复出现 | 同一测试连续失败 3 次 |
| 人类反馈 | 遇到需人工判断的节点 | 涉及生产配置修改 |
| 时间预算 | 执行时间超过上限 | 单任务不超过 5 分钟 |
实现方式
一个成熟系统通常把这些规则放进 runtime 和 orchestration 层,而不是指望模型自己判断”差不多该停了”:
class AgentRunner:
def __init__(self):
self.max_steps = 20
self.max_tokens = 100_000
self.max_consecutive_failures = 3
self.step_count = 0
self.consecutive_failures = 0
def should_stop(self, result):
if result.success:
return StopReason.SUCCESS
if self.step_count >= self.max_steps:
return StopReason.MAX_STEPS
if self.total_tokens >= self.max_tokens:
return StopReason.BUDGET_EXHAUSTED
if self.consecutive_failures >= self.max_consecutive_failures:
return StopReason.REPEATED_FAILURE
return None
最小例子
一个 coding agent 在修测试时可以设置:
- 最多尝试 8 轮
- 连续 3 次同类失败就停止
- 涉及生产配置修改时直接转人工审批
- 总 token 消耗不超过 50k
这样它就不会为了”再试一次”无限循环,也不会把预算烧光。
与 Agent 评估的关系
Stopping conditions 与 agent 评估(evals)紧密相关:
- 评估中需要记录 agent 是因哪种停止条件退出的(成功 / 超时 / 失败)
- 停止条件的设置直接影响评估指标:太松则成本高,太紧则成功率低
- 好的停止条件设计是 agent 可靠性的基础保障
边界与常见误解
- Stopping condition 不等于审批点:审批点是暂停等待授权;停止条件是决定退出当前执行
- 不等于交付标准:交付标准回答”什么算成功”,停止条件还要回答”什么时候算该停”
- 不要只设计成功路径:如果只设计成功退出、不设计失败退出路径,agent 往往最先在运行成本和错误恢复上失控
- 停止条件需要调优:初始值通常是保守估计,应根据实际运行数据逐步调整
- 分层停止:不同类型的错误应有不同的停止策略,而非一刀切
最佳实践
- 先设硬上限:最大步数和 token 预算是兜底,必须有
- 再加智能检测:连续失败、重复动作检测是更精细的停止信号
- 保留人工兜底:高风险操作(删除、部署、支付)应触发人工介入
- 记录停止原因:每次停止都应记录原因,用于后续分析和调优
- 渐进式收紧:从宽松开始,根据运行数据逐步收紧阈值