首页 › ai-agents › Agent终止逻辑：早停与死循环四态实测

在 2026 年的 Agent 工程圈，一个长期被忽视的问题终于浮上水面：不是模型不够强，而是没人知道该何时停。Glen Rhodes 在一篇被广泛转发的判断中把话说得很直——「最难的不是模型，是知道什么时候该停手」。他列举的典型案例是 Karpathy 开源的通宵自主研究 Agent：约 630 行代码，每小时跑约 12 个实验、一夜约 100 个，全程无人值守。这套系统真正聪明的不是提示词，而是一个写死的五分钟时钟——每一次运行无论改了什么都站在同一把尺子下被比较，「够不够好」由时钟和分数决定，由人在 Agent 启动前决定，而不是由 Agent 自己临场决定。这个顺序是对的，也恰恰是绝大多数团队做反的地方。

OpenAI 的 Codex Security Agent 是同类设计：「发现漏洞、验证漏洞、提出可审查的修复」，停在「提案」而不是「自合并」——末尾的人工审查门不是补丁，而是终止条件本身。两条线索指向同一条结论：终止逻辑不是后处理步骤，是架构。本文以四个独立团队在一年内命名的「同一类失败」为主线，拆解 Agent 终止逻辑的四种病态、三层防御、框架原语横评，以及生产级的紧急停止层。

一、四态总览：同一种表象，四条病根

把「Agent 停得不对」当成一个单一问题，是绝大多数团队的第一层误判。AgentPatterns 把它拆成四种共享同一表面症状（「停错了」）但病根与解法完全不同的失败：

失败态 表面症状 根因 检测信号 正确解法
早停（Premature Completion） 测试没全过就喊 done 「第一信号即停」的 stop token 测试套件状态、未触及用例 把停止准则外化到测试套件状态
过停（Continuing Past Completion） 已经完成还在跑 缺终止信号 / 无哨兵 哨兵哈希、最大步数硬顶 最大迭代上限 + 完成签名校验
目标漂移（Objective Drift） 完成了，但完成的是「另一个任务」 上下文压缩丢了原始规格细节 压缩后重读结构化会话意图 压缩后强制重读 session intent
上下文枯竭型放弃 任务没做完就放弃 token 预算耗尽 上下文长度逼近上限 上下文压缩 + 子 Agent 分流

关键判别：早停和过停是「停止准则错配」，目标漂移是「记错了要做什么」，枯竭放弃是「没资源做了」。前两者改准则，后两者改记忆与预算。混着治等于不治——这也是为什么「让 Agent 更彻底一点」这种万能提示对四种病都无效。

二、深度分析

1. 终止逻辑是架构，不是后处理

Glen Rhodes 给团队的核心忠告是：写第一行 Agent 代码之前，必须先回答三个问题——「完成」在可测量意义上长什么样（不是感觉）？当 Agent 达不到完成时会发生什么？谁/什么有最终权威？ 答不上来这三个，你拥有的不是 Agent 设计，而是一个「等着出事的循环」。这套框架的意义在于把终止逻辑从「上线后补丁」前置成「设计文档第一项」。Karpathy 的固定时钟和 Codex Security 的人工门都是同一模式的实例：范围边界在 Agent 跑之前就定好，不在运行中、不在运行后。这套思路在变现端尤其值钱——任何「Agent 训练营」或产品若想交付可复制的生产级 Demo，绕不开一个写进架构的终止条件；而市面上绝大多数「Agent 课」恰恰在这里缺位，学员做出的 Demo「第一个 edge case 就翻车，最后还得人盯每一轮」。

2. 早停病：第一信号即「done」，中段模型最受伤

早停是 2026 年被命名最密集的失败：SRI Lab（ETH Zurich）称之为「fixing correct code」，ForgeCode 称「premature completion」，SWE-EVO（arxiv 2512.18470）称「premature termination」，arxiv 2503.15223 称「inflated resolution rates」。四个互不相关的团队在一年内各自给同一个失败起了名字，本身就是「真实且被低估」的强证据。SRI Lab 在 235 个任务上发现：Claude Opus 4.6、Sonnet 4.6、GLM-5、GPT-5.4、Gemini 3 Pro、Qwen3.5 这些模型超过 50% 的时间在「修复」本来就通过的代码。根因是 stop token 被条件化在「首次修复成功」上——这在单文件、单测试的训练分布里是好代理，却在多文件、多测试的真实任务上严重欠规格。最反直觉的发现是能力带错位：弱模型（o3、gpt-4.1、gpt-4o）在 SWE-EVO 上表现为语法错误、循环、早停；强模型（GPT-5、Opus 4.6）几乎不早停，它们的失败是「指令遵循」问题。真正中招的是「刚好能看绿就喊 done」的中段模型——这正是企业落地最常用的价位，也是缓解措施投入回报最高的地方。

3. 死循环病：缺终止信号，两个 Agent 会「争论到底」

过停在多智能体里被放大到荒诞。Neural Pruning 的判断一针见血：「两个能言善辩的 Agent 会无限期、自信地各执一词争论下去——直到你拔插头或规则替你拔」。这就是为什么 AutoGen 这类框架把 TERMINATE 关键字、max_turns、is_termination_msg 当成一等公民：你不能依赖「它通常会收敛」。过停的工程解法分两层：硬顶（最大迭代/最大消息数/超时/最大 token/最大 API 调用）负责兜底资源，哨兵哈希校验负责识别「已经完成却还在跑」。生产里最常见的悲剧是两者都没有——Bswen 作者的第一手教训是：一个「研究任意主题」的无限制 Agent 上线几分钟就开始反复调同一 API、生成重复摘要、永远不觉得自己完成了，3 小时烧穿额度、生成几千条无用任务才被人工介入。这条线也直接关联成本：过停是「烧钱」，早停是「返工」，两者都拉低 ROI。

4. 目标漂移与枯竭型放弃：记错了 vs 做不动

这两种病最容易被误诊为早停。目标漂移（Objective Drift） 的典型场景是上下文压缩（compaction）之后，原始规格里的具体约束被摘要掉了，Agent 继续工作、也确实「完成」了，但完成的是被压缩改写过的另一个任务。检测信号是：每次压缩后强制重读结构化的 session intent（原始任务的可机读副本）。枯竭型放弃 则是 Agent 跑到 token 预算或上下文窗口边缘，被迫停止——它不是「觉得做完了」，是「做不动了」。解法是分层压缩 + 子 Agent 分流（把子目标委派出去、只回收结论）。两者混治的代价很高：对着目标漂移去加最大步数毫无作用（Agent 早就停了），对着枯竭放弃去外化停止准则也无效（问题不在准则，在资源）。判别的实操信号是看停止时的剩余预算：预算还多却停了→漂移或早停；预算见底才停→枯竭放弃。

5. 三层终止系统：预算层、目标层、环检测层

Bswen 总结的稳定生产经验是一个三层安全网。第一层资源预算（硬限制：最大迭代、最大时长、最大 token、最大 API 调用、内存上限）是不可协商的紧急刹车；第二层目标达成定义「done 在可测量意义上是什么」，用置信度阈值与多目标优先级判断主目标是否达成（哪怕次目标未完成）；第三层环检测最复杂，用状态相似度（StateVector 的余弦相似 >0.9 判定循环）、动作重复模式（同一动作连续出现或短窗内计数 >3）、以及进度停滞追踪（连续 N 轮无新进度）来识别「看起来在干活、其实原地打转」。这套系统的代码骨架很直白：一个 while (shouldContinue(state)) 循环，每步后先查目标达成、再查环检测、再按干预策略表注入「重启新上下文」或「换一种方法」的干预。关键工程细节是上下文是终止失败的最大隐藏点——上下文腐化、记忆膨胀、状态校验缺失都会让上面的三层全部失灵。

6. 框架终止原语横评：AutoGen 的 & / | 组合

主流框架在 2026 年已把终止条件做成可组合的一等对象。AutoGen 提供了 MaxMessageTermination、TextMentionTermination（如检测 "APPROVE"/"TERMINATE"）、TokenUsageTermination、TimeoutTermination、HandoffTermination、SourceMatchTermination、ExternalTermination（对接 UI 停止按钮）、StopMessageTermination、FunctionCallTermination、FunctionalTermination 等十余个原子条件，并允许用 |（OR，任一满足即停）和 &（AND，全部满足才停）组合。最推荐的组合范式是「一快一实」：一个快速条件（最大步数、最大成本）防止资源失控，一个实质条件（目标达成信号、监督者否决、人工检查点）判定工作是否真做完。| 组合对应「快速兜底 OR 实质完成」——谁先触发都停；& 组合对应「既耗尽预算又未达成」这种更严格的边界。LangGraph 则用条件路由 route(state) -> Literal["continue", END] 把三层检查（资源预算 / 目标达成 / 环检测）汇成单个出口判断。实战中，框架原生终止原语能省掉 80% 的自造轮子，但「实质条件」几乎总要 subclass 自定义（如 FunctionCallTermination 监听 approve 工具调用），这是把停止权威从「模型自觉」搬到「可观测工具调用」的关键一步。

7. 紧急停止层：断路器与会话级 kill switch

当 Agent 已经在犯错、且比人工发现更快时，终止逻辑必须上移到基础设施层。Waxell 用一个真实事故定义了这个问题：一个邮件分流 Agent 因配置错误形成「误分类→重路由→重读→再发确认邮件」的死循环，等到支持经理发现时，同一客户 31 分钟内已收到 89 封相同邮件，工程师现场靠「吊销 API key」止血，但已发航班照常完成、最终计数冲到 104 封，且 key 吊销把另外两个正常运行的 Agent 会话一起断了。这里的核心区分是：kill switch 是人工的、会话级、可干净终止；circuit breaker 是自动的、按行为阈值（动作计数/成本/重复调用模式/错误率）触发。两者必须作为「层」存在于 Agent 执行上下文之外——放在 Agent 自己的代码里，一个行为异常的 Agent 就能绕过它。三件不可少的能力：会话级终止程序（不是吊销凭证）、行为触发的断路器（同参数连续调用 3 次即停并求人工确认）、以及「停止意味着回滚到哪」的明确定义（已发邮件不可逆、数据库写可逆，要在事故前写进 runbook）。这一层的回报是放大式的：有了可靠的断路器，团队才敢给 Agent 更宽的工具权限，因为「出错时爆炸半径有界」。

8. 有效与无效的缓解：reproduction-first 与运行时强制验证

哪些手段真的有用，哪些是 placebo，2026 年已有定量证据。有效的三件套：① 先复现后修补（reproduction-first prompting）——要求 Agent 先触发 bug 再打补丁，SRI Lab 实测把 GPT-5.4 mini 在 correct-code 任务上从 24% 拉到 77%；② 运行时强制验证——若模型跳过验证技能，运行时注入提醒并阻断终止、不可 opt-out，ForgeCode 靠这一改在 TermBench 2.0 上达到 81.8%；③ 完成前清单作为 harness 变量——LangChain 把完成前清单作为可调的 harness 参数纳入爬山循环，纯 harness 改动就把 Terminal Bench 2.0 从 52.8% 抬到 66.5%。单独无效的三件：「更彻底一点」的指令（没有绑到可观测状态的钩子）、更长的推理链（只是推迟停止准则的选择、不改变它）、Chain-of-Thought（会让错误的完成「听起来更自信」，反而掩盖失败）。还有一条反面提醒：过度验证螺旋——没有迭代上限的运行时强制验证会触发镜像病理（过停）。换言之，这套机制的甜区是「强制验证 + 硬性步数上限」配对出现，单用任何一边都会从一种病翻车成另一种。基准层面还有个陷阱：只查最终状态的 harness 会掩盖早停（Agent 碰巧修了第一个 bug 就过），正确做法是对「没修但本该修」的测试单独计分，而不是看净通过增量。

三、Agent 终止逻辑架构图

flowchart TD
    START([Agent 启动]) --> PRE{终止条件前置定义<br/>done 长什么样? <br/>达不到怎么办? <br/>谁有最终权威?}
    PRE -->|必须在运行前确定| LOOP[主循环 while shouldContinue]

    LOOP --> STEP[执行一步: 推理 + 工具调用]
    STEP --> CB{基础设施层<br/>断路器 CircuitBreaker<br/>动作数/成本/重复调用}
    CB -->|超阈值, 自动| KILL[会话级 Kill Switch<br/>阻止新工具调用<br/>处理 in-flight 调用]
    CB -->|正常| L1

    L1{第一层: 资源预算<br/>迭代/时长/token/API} -->|超限| KILL
    L1 -->|未超| L2

    L2{第二层: 目标达成<br/>置信度阈值/多目标优先级} -->|达成| VERIFY
    L2 -->|未达成| L3

    L3{第三层: 环检测<br/>状态相似度>0.9<br/>动作重复/进度停滞} -->|检测到循环| INTERV[干预策略表<br/>重启新上下文 / 换方法]
    L3 -->|无循环| DRIFT{目标漂移检测<br/>压缩后重读 session intent}
    DRIFT --> LOOP
    INTERV --> LOOP

    VERIFY[运行时强制验证<br/>reproduction-first<br/>完成前清单, 不可 opt-out] -->|验证失败| LOOP
    VERIFY -->|验证通过, 外化准则| DONE([终止: 完整状态记录<br/>可重放取证])

    KILL --> ROLLBACK[回滚定义<br/>可逆/不可逆分类<br/>runbook 执行]
    ROLLBACK --> DONE

    style PRE fill:#fff3cd,stroke:#856404
    style CB fill:#f8d7da,stroke:#721c24
    style VERIFY fill:#d4edda,stroke:#155724
    style DONE fill:#d1ecf1,stroke:#0c5460

图中的关键设计是三个出口汇到一个终点：达成目标经强制验证、断路器自动熔断、资源预算见底——无论从哪条路停，都必须留下「状态 + 触发策略 + in-flight 调用处置」的可重放取证记录。这正是 Waxell 所说的「停在程序里」与「停在基础设施层」的本质区别：前者留下日志断点，后者留下干净的终止事件。

四、推荐方案

面向企业落地的最小可用四件套：① 把停止准则外化到可观测状态（测试套件、git 分支、工具调用签名），绝不依赖模型的「自觉」；② 部署「一快一实」的终止组合（硬性预算 OR 实质目标）；③ 在基础设施层（Agent 执行上下文之外）挂断路器，对同参数重复调用、成本突增自动熔断；④ 事故前写好回滚 runbook，把可逆与不可逆动作分类。面向中段模型（早停重灾区）：强制 reproduction-first + 运行时不可 opt-out 的验证 + 完成前清单作为 harness 调参项——这套组合已用 24%→77%、52.8%→66.5%、81.8% 三组实测证明回报远高于「换个更强的模型」。面向多智能体：必须有一个实质终止条件（approve 工具调用、监督者否决、TextMentionTermination），不要相信「它通常会收敛」——两个 Agent 会无限争论。面向变现/训练营：终止逻辑是唯一一个「学员能立刻在生产里用上、且市面上多数课程缺位」的差异化模块，把它做成一节课（三个前置问题 + 三层防御 + 一个 Mermaid 状态图），远比再讲一遍 RAG 或工具调用更有护城河。

参考来源

  1. Premature Completion: Agents That Declare Success Too Early — AgentPatterns.ai — 四个独立团队命名同一失败、能力带错位、24%→77%/52.8%→66.5%/81.8% 等关键实测数据
  2. Prediction: termination logic is the underrated design problem in agentic AI — Glen Rhodes — 三个前置问题、Karpathy 固定时钟、Codex Security 人工门、confidence laundering
  3. Termination — AutoGen 官方文档 — &/| 组合、十余个原子终止条件、FunctionCallTermination 自定义范式
  4. How to Design Termination Conditions for AI Agent Loops — Bswen — 三层终止系统（预算/目标/环检测）、状态相似度与进度停滞检测、上下文是隐藏失败点
  5. The Kill Switch Problem: How to Stop an AI Agent That's Gone Wrong — Waxell — 31 分钟 89 封邮件事故、会话级 kill switch vs 凭证吊销、基础设施层断路器、回滚定义

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章