[!info] related notes

• 所属 MOC: Agent MOC, Agent Evals MOC, Coding Agent MOC
• 前置概念: Agent, Agent Runtime
• 并列概念: Agent 中的 Approval Checkpoints, Agent Guardrails, Evidence Acquisition Policy
• 易混淆概念: Agent 中的人类监督, Agent 的 Fallback、Abstain 与 Escalate
• 关系笔记: 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

停止原因不等于风险结论

在 evidence acquisition 场景里，BUDGET_EXHAUSTED、MAX_STEPS 或数据源不可用只说明：

当前获取路径应该停止。

它们不证明：

critical gap 已关闭
risk 已变成 LOW
AUTO 已重新变得安全

因此必须区分：

StopReason
→ 为什么不能继续当前执行/取证

DecisionOutcome
→ 停止以后应该 AUTO / FALLBACK / ABSTAIN / ESCALATE 哪一种

如果 critical evidence gap 仍为 OPEN，预算耗尽后应交给版本化 policy 决定受控退路，而不能把“没预算继续查”解释成“已经查够了”。

最小例子

一个 coding agent 在修测试时可以设置：

• 最多尝试 8 轮
• 连续 3 次同类失败就停止
• 涉及生产配置修改时直接转人工审批
• 总 token 消耗不超过 50k

这样它就不会为了”再试一次”无限循环，也不会把预算烧光。

一个高风险判断 Agent 则可能是：

critical gap OPEN
→ 最多 2 次 targeted acquisition
→ budget exhausted
→ StopReason = EVIDENCE_BUDGET_EXHAUSTED
→ policy chooses ABSTAIN or ESCALATE

这里停止的是取证循环，不是把未知状态强行改成“安全”。

与 Agent 评估的关系

Stopping conditions 与 agent 评估（evals）紧密相关：

• 评估中需要记录 agent 是因哪种停止条件退出的（成功 / 超时 / 失败）
• 停止条件的设置直接影响评估指标：太松则成本高，太紧则成功率低
• 好的停止条件设计是 agent 可靠性的基础保障
• 高风险 eval 还应验证 stopping reason 与最终 decision mode 是否匹配，例如 critical gap 未关闭时不得因为预算耗尽转为 AUTO

边界与常见误解

• Stopping condition 不等于审批点：审批点是暂停等待授权；停止条件是决定退出当前执行
• 不等于交付标准：交付标准回答”什么算成功”，停止条件还要回答”什么时候算该停”
• 不等于最终风险判断：预算耗尽或最大步数只是停止原因，不是安全证明
• 不要只设计成功路径：如果只设计成功退出、不设计失败退出路径，agent 往往最先在运行成本和错误恢复上失控
• 停止条件需要调优：初始值通常是保守估计，应根据实际运行数据逐步调整
• 分层停止：不同类型的错误应有不同的停止策略，而非一刀切

最佳实践

1. 先设硬上限：最大步数和 token 预算是兜底，必须有
2. 再加智能检测：连续失败、重复动作检测是更精细的停止信号
3. 保留人工兜底：高风险操作（删除、部署、支付）应触发人工介入
4. 记录停止原因：每次停止都应记录原因，用于后续分析和调优，并可写入 DecisionTrace
5. 停止后再做政策路由：将 StopReason 与 Fallback / Abstain / Escalate 分开建模
6. 渐进式收紧：从宽松开始，根据运行数据逐步收紧阈值

Related notes

• Agent MOC
• Agentic Systems
• Agent 执行闭环