一句话定义：终止条件（Termination Condition）是智能体（Agent）在“思考—行动—观察”循环里，用来判断“可以停了”的那套规则。它决定了这个循环是优雅收尾，还是无限打转。
打个比方：你在厨房做菜。什么时候算做完？三种信号都可以用——“我自己觉得好了”（主观自报）、“尝一口确认咸淡合适”（客观验证）、“闹钟响了或者锅冒烟了，必须先关火”（兜底）。一个靠谱的智能体，通常三种信号一起上。
第一类：模型自报完成
模型输出一句“任务已完成”，或者调用一个 finish / submit 之类的工具。优点是灵活，什么任务都能用；缺点是它可能“自嗨”——明明只写了半个文件，也敢说搞定了。所以自报通常只作为“请求结束”，而不是“结束生效”。
第二类：工具与环境状态
这是最可靠的一类。判断依据不在模型嘴里，而在外部世界：单元测试跑通了、接口返回了 200、目标文件确实存在、数据库里出现了那条订单。可验证的任务（写代码、跑数据、调 API）都该优先用这类硬信号当主判据。代价是需要提前把“完成”写成机器能检查的条件，也就是常说的完成定义（Definition of Done）。
第三类：步数与预算兜底
步数上限、超时时间、token 预算、工具调用次数上限。它不判断“做没做完”，只保证“不会永远做下去”。生产环境里这类兜底是必需的，一旦触发，正确的做法是标记为“未完成/需人工介入”，而不是当成成功。
第四类：人工与外部中断
涉及付款、发邮件、删数据这类不可逆操作时，常见设计是把终止权交给人类审批，或者由用户点“停止”。
| 判据 | 可靠性 | 适用场景 | 典型风险 |
|---|---|---|---|
| 模型自报 | 中低 | 开放型写作、调研 | 过早收工、谎报完成 |
| 工具/环境状态 | 高 | 可自动验证的任务 | 需要预先定义检查项 |
| 步数/预算上限 | 仅兜底 | 所有循环 | 被误当成成功 |
| 人工确认 | 高 | 高风险、不可逆操作 | 拖慢效率 |
和相邻概念的区别
“最大迭代次数（max_iterations）”只是一个参数，是终止条件里最粗糙的一种；而终止条件是整套判定策略，包含“谁说了算、什么信号算数、触发后怎么记录”。它也和“错误重试”不同：重试管的是“这一步失败了再来一次”，终止条件管的是“整件事结束了”。
对从业者的实际意义
第一，别把“模型说完成了”当唯一出口，尽量给它配上可验证的落地信号。第二，兜底触发要区分“成功结束”和“被迫结束”，日志里写清停下来的原因，否则线上排查会很痛苦。第三，循环里花掉的步数和 token 都是成本，终止条件设计得越准，账单越好看。各家框架对终止与最大步数的默认值和配置方式差异不小，具体参数以官方文档为准。
对普通职场人来说，这个概念的启示很直接：交办任务时，先把“做成什么样算完成”说清楚，比事后返工省事得多——人机同理。