Termination Lag（终止滞后），指的是智能体（agent）实际上已经把任务做完了、或者已经没有任何有意义的下一步可做，却还要多跑若干轮、多花若干 token 才真正停下来的那段“多余路程”。
一个生活化的比方
家里装修，师傅其实已经把活干完了。你多问一句“师傅，确定都弄好了吗？”他于是拎着手电又挨个房间转了三圈，把每个插座按一遍、每扇门推一下，最后说“应该没问题”。活没白干，但多出来的三圈里，一锤子都没敲。
编码智能体就是这样。测试全绿了、代码也写完了，它还在：“让我再确认一下边界情况”“我再看一眼有没有遗漏”，然后重跑一遍已经跑过的命令。
它为什么会发生
- 停止判据是概率性的。判断“我完成了吗”本身就是一次模型推理，没有硬信号。谨慎的措辞——“确保正确”“充分验证”“不要遗漏”——会把它推向“再查一遍”。
- 验证信号不够硬。编码智能体本来能跑测试，但测试通过只说明“我想到的用例过了”，模型很容易怀疑“是不是还有没想到的”。于是用更多轮来换确定性。
- 工具反馈模糊。输出被截断、非零退出码没说明原因，智能体只能换着法子重试。
- 缺少显式的完成协议。如果没人告诉它“怎么算完”，它就只能靠自我感觉。
容易混淆的几个邻居
| 概念 | 差别 |
|---|---|
| 幻觉（hallucination） | 那是做错事；终止滞后是多做事 |
| 推理时扩展（test-time scaling） | 那是“还没解出来时多花算力换准确率”；这里是“已经解出来了还在花” |
| 死循环（loop） | 死循环永不收敛；终止滞后最终会停，只是晚 |
| 过早终止 | 反方向的问题：该做的没做完就收工 |
该盯哪些指标
- 达标到结束的间隔：从“测试首次全绿”或“文件 diff 达到预期”那一刻，到会话真正结束，中间多了几轮、多少 token。这是最核心的一个数。
- 无效轮占比（no-op turns）：这一轮里文件没改动、命令输出和上一轮一模一样，基本可以判定为空转。
- 重复命令率：同一条命令、同样参数被跑了第三遍。
- CI 触发次数：从第一次流水线成功到任务结束，又白白跑了几条流水线——这部分是实打实的机器成本。
- 停止原因分布：正常宣布完成、撞到最大轮数上限、超时，各占多少。后两者占比高，通常意味着完成协议没设计好。
对从业者的实际意义
终止滞后不是“小毛病”。它直接拉长延迟、占用并发额度、烧掉 token，还会把 CI 队列堵住；更麻烦的是，冗长的收尾日志会让真正关键的决策被埋掉，事后排查变难。
改法通常比想象中简单：给智能体一个显式的“完成”动作，而不是靠它自觉；用便宜的外部信号替代自我怀疑（先跑单测，别一上来跑全量）；做重复检测，同命令同输出时提示换策略或直接收尾；在预算快用完时让它主动收敛。
对普通职场人同样成立：给任务写清验收标准和停止条件，比反复叮嘱“仔细一点”有用得多。具体工具的行为细节请以官方页面为准。