Agent Loop 与终止条件

写一个循环谁都会：调用模型、解析动作、执行工具、把结果塞回去。难的是四件事——知道它该停下来、知道它卡住了、知道它绕圈子、以及在它需要人拍板时把控制权交出去。这一章把循环从一个 while 语句升级成一个可控的执行系统。

编辑部注 · 「什么时候该停下来」是本刊认为最被低估的工程问题。绝大多数线上事故不是模型不够聪明，而是循环没有正确的刹车。

先看一个未经训练的写法：while True: plan = model(ctx); ctx += act(plan)。它的失败方式多得惊人——模型可能永远说「再查一次」，可能反复调用同一个工具，可能在一个空结果上打转，也可能已经完成了却不知道要停。这一章把每一种失败都对应上一个明确的终止条件。

一、循环的骨架

Agent 循环（Agent Loop） 的最小结构只有三步，这三步的命名在不同框架里不同，但语义一致——它们合起来就是 思考-行动-观察（Think-Act-Observe） 这三步骨架：

看起来很清晰，但工程上的麻烦几乎全部集中在「Observe → Think」这一段的回喂内容上。同一段工具结果，怎么截断、怎么标注来源、怎么标记可信度，直接决定下一轮模型会不会做出荒唐决策。

二、五类终止条件：一个都不能少

这是本章的核心，也就是 终止条件（Termination Conditions）。只写「任务完成就停」的系统，一定会以三种方式之一失控。

三、无进展检测怎么做

不要指望模型自己意识到自己在绕圈。要在 Harness 侧用可计算的判据来检测——核心是 无进展检测（No-Progress Detection）：对 (tool_name, normalized_args) 做哈希得到 调用签名（Call Signature），对工作区文件列表取 状态指纹（State Fingerprint），再配合 成本斜率（Cost Slope） 作为提前预警。常用手段按可靠性排序：

四、动手：一个带完整刹车的循环

import hashlib, json, time
from dataclasses import dataclass, field
def sig(tool: str, args: dict) -> str:
    """工具调用签名：参数做稳定序列化，避免键序影响"""
    return f"{tool}::{json.dumps(args, sort_keys=True, ensure_ascii=False)}"
@dataclass
class LoopGuard:
    max_turns: int = 15
    max_seconds: float = 300
    stall_limit: int = 3           # 连续多少轮无进展就退出
    repeat_limit: int = 3          # 同一调用签名最多重复几次
    started: float = field(default_factory=time.time)
    turns: int = 0
    seen: dict = field(default_factory=dict)     # 签名 -> 次数
    last_obs: str = ""
    stall: int = 0
    def check(self) -> tuple[bool, str]:
        """返回 (是否应继续, 退出原因)"""
        if self.turns >= self.max_turns:
            return False, "BUDGET_TURNS"
        if time.time() - self.started > self.max_seconds:
            return False, "BUDGET_TIME"
        if self.stall >= self.stall_limit:
            return False, "NO_PROGRESS"
        return True, ""
    def note_call(self, tool: str, args: dict) -> tuple[bool, str]:
        """记录一次调用；返回是否允许执行"""
        s = sig(tool, args)
        self.seen[s] = self.seen.get(s, 0) + 1
        if self.seen[s] > self.repeat_limit:
            return False, f"同一调用已重复 {self.seen[s]} 次，请换策略或结束任务"
        return True, ""
    def note_observation(self, content: str) -> None:
        """观察结果没变化 → 记为一次停滞"""
        h = hashlib.sha256(content.encode()).hexdigest()
        if h == self.last_obs:
            self.stall += 1
        else:
            self.stall = 0
            self.last_obs = h
def run(task: str, call_model, exec_tool, ask_human):
    guard = LoopGuard()
    ctx = [{"role": "user", "content": task}]
    while True:
        ok, why = guard.check()
        if not ok:
            # 关键：退出时带上已完成的部分，而不是一句失败
            return {"status": why, "turns": guard.turns,
                    "partial": summarize(ctx), "context": ctx}
        guard.turns += 1
        plan = call_model(ctx, temperature=0)
        # ① 显式完成信号（不要靠「没调工具」隐式判断）
        if plan["action"] == "finish":
            return {"status": "DONE", "result": plan.get("answer"), "turns": guard.turns}
        # ④ 需要人工：暂停而不是硬闯
        if plan["action"] == "need_human":
            return {"status": "NEED_HUMAN", "question": plan.get("question", ""),
                    "context": ctx, "resumable": True}
        # ⑤ 输出无法解析：有限次重试后才放弃
        if plan["action"] == "invalid":
            ctx.append({"role": "user",
                        "content": "上一次输出无法解析为合法动作，请只输出 JSON。"})
            continue
        allowed, msg = guard.note_call(plan["tool"], plan.get("args", {}))
        if not allowed:
            ctx.append({"role": "user", "content": msg})
            continue
        result = exec_tool(plan["tool"], plan.get("args", {}))
        guard.note_observation(str(result))
        # 副作用操作必须确认（人工介入点）
        if result.get("side_effect") and not ask_human(plan):
            ctx.append({"role": "user", "content": "用户拒绝了该操作。"})
            continue
        ctx.append({"role": "tool", "content": str(result)[:2000]})

五、Human-in-the-loop 的正确姿势

人工介入（Human-in-the-loop） 不是「弹个窗问一下」那么简单，它有三个必须设计清楚的点——其中最重要的是，暂停之后状态必须 可恢复（Resumable），否则一旦 预算耗尽（Budget Exhausted） 或用户离开，任务就彻底丢失：

第一，暂停必须可恢复。 用户拒绝或长时间不回应之后，任务不能就这么死掉。要把完整状态（上下文、已完成的步骤、待决策的问题）持久化，用户回来时能从中断点继续。

第二，问题必须包含决策所需的信息。 问「是否继续？」是没用的；问「我准备删除 orders_2025 表（共 12 万行，最后访问 3 天前），确认删除还是先备份？」才是可决策的。把选项和后果一起给出来。

第三，不是所有事都要问。 该自动化的自动化，该问的才问。判据是「可逆性 + 影响范围」：

六、常见误区与追问

6.1 误区：装了 max_turns 就算装了刹车

错在哪：把轮数上限当成终止条件的全部。为什么自然：一行代码就能加上，加上之后最吓人的「无限循环」确实不再发生，容易产生「刹车已装好」的错觉。判据：它只覆盖五类出口的第②类，保证的是「一定会停」，不是「停在该停的地方」——模型第 3 轮就完成了却继续重试、两个工具互相调用、连续几轮返回同一个空结果，这三种情况它都会跑满。算一笔账：上限 15 轮、每轮新增 4k token 输入，从第 4 轮空转到第 15 轮，累积输入约 45.6 万 token，全是浪费。

6.2 误区：无进展检测越灵敏越好，阈值设成 1

错在哪：把「漏检」当成唯一要防的错，于是把容忍度压到最低。为什么自然：漏检会烧钱，宁枉勿纵看着总是安全的。判据：合法任务里「一轮没变化」极其常见——先写文件、下一轮才校验；先检索、下一轮才用结果。阈值取 1 时，这些任务会在真正推进之前被杀掉，完成率反而下降，日志里只有一行「因无进展退出」。建议取 3，且只在「调用签名重复」与「观察结果哈希不变」同时成立时计数。代价对比：连续 3 轮的容忍成本约 12k token，而一次误杀意味着整个长任务重跑一遍。

6.3 误区：人工介入就是弹一个「是否继续？」

错在哪：把人工介入当成一个确认弹窗，而不是一个可恢复的状态。为什么自然：写起来最简单，两个按钮就能交差。第一，确认信息里没有决策依据：用户看到「是否继续？」只能猜，40 分钟前看过的上下文早就忘了，唯一理性的选择就是「否」；可决策的问法必须自带上文，例如「将删除 orders_2025（12 万行），不可逆；确认／先备份／跳过」。第二，暂停后状态没落盘，用户一离开任务就死。判据：把进程杀掉再拉起来，任务能不能从暂停那一轮继续，且等待期间不计入轮数与时间上限。

6.4 误区：退出时返回一句失败就够了

错在哪：把异常退出当成「任务不存在」，而不是「任务停在中途」。为什么自然：失败就是失败，抛个错误码最省事。判据：预算耗尽、需要人工、系统异常这三类退出，返回值里都必须带 partial——已完成的步骤、中间产物、未完成的原因、下一步该做什么。算一下：一个 12 轮的任务在第 11 轮因预算退出，一句 failed 意味着重跑要再花 12 轮，而带上 partial 续跑通常只需 1–2 轮。只有 partial 才能让用户判断该重跑还是该补预算。

6.5 误区：重试是无害的兜底

错在哪：把重试当成「多试一次不亏」的手段，既不分类也不设上限。为什么自然：重试在只读接口上几乎零成本，这个经验被带到了所有工具上。判据：重试前必须先分类——超时、限流、上游 5xx 可重试（指数退避 + 最多 2–3 次）；参数错误、权限不足、业务拒绝不可重试，重试多少次都是同一个错，正确动作是改参数、换方案或上报。数字：每次重试都带完整历史时，三次无效重试就是 12k token 的净损失；更糟的是对不可逆操作重试——把「可能已执行」变成「执行了两次」。

七、自测

八、小结

循环的上限由模型的推理能力决定，循环的可靠性由刹车决定。而线上事故绝大多数出在刹车上。本刊编辑部

刹车装好了，下一章处理最容易出问题的那一层：工具。因为工具是模型唯一能真正改变世界的手。

九、参考与延伸

「什么时候该停下来」这件事没有一条公式可背，最好的材料是别人的实现和别人的评测。下面这几份按「先看结构、再看实现、最后看怎么量」排好。全站不做原文转载，这里只登记链接与「为什么值得读」。

先看结构（一个循环该有哪些部件）

• Anthropic · Building Effective Agents —— 它把「循环 + 工具 = Agent」讲成一个最小定义，并且反复提醒：大多数任务其实不需要自主循环，编排好的工作流更可控。读本章第二节之前先读它，你会更容易接受「五类终止条件不是过度设计」——它把循环的每一步都当成一个必须显式设计的部件。

再看实现（别人怎么装刹车）

• LangGraph · Durable Execution —— 把「暂停—持久化—恢复」做成框架级能力：每个节点之后落检查点，进程被杀也能从断点继续，并明确了恢复时如何避免重放已完成步骤。本章第五节说「暂停必须可恢复」，这里给出的是它在工程上长什么样（检查点粒度、状态写在哪、恢复时谁负责去重）。
• OpenAI Agents SDK 文档 —— 一个刻意做小的实现：显式动作、工具调用、任务移交、护栏各占一个概念，整篇读完就能在脑子里跑一遍。适合对照本章第四节那份 agent_loop.py 看：同样是刹车，别人把它放在了框架的哪一层、你又把它放在了哪一层。

最后看怎么量（刹车有没有效）

• τ-bench（sierra-research/tau-bench） —— 多轮工具任务上的评测，把「任务完成」与「是否违反规则」「是否该澄清」分开统计。要证明你的终止条件没有误杀，就需要这类分层指标；只看成功率会把「刹车踩过头导致中途放弃」和「模型确实做不到」混成一个数。