为什么你的智能体永不停止

Image: AI generated

24/7 的炫耀

“我的智能体已经连续运行 24 小时了。”

这是 X 上常见的说法。仿佛智能体运行得越久，就做了越多的工作。仿佛人不睡觉就更有生产力。

但面对这句话，浮现的感觉不是赞叹，而是疑问。

“为什么还没结束？”

能停下来的系统，才是健康的系统

我把为 527 个函数编写测试的任务交给了智能体。结果：

自主智能体：  完成 40 / 527 后宣称"全部做完了"
CLI 循环：    跑完 527 / 527 后终止

CLI 循环花了 1 个小时。不是 24 小时。处理一个函数、验证、通过后进入下一个，全部完成后停止。这个循环的核心不是速度，而是终止条件是机械定义的。

TODO → 编写测试 → 测量覆盖率 → PASS/DONE → 下一个 → ... → 全部完成 → 停止

finite。measurable。monotonic。所以收敛。所以停止。

能停下来不是弱点，而是健康的标志。

永不停止的三个原因

智能体长时间运行，通常是以下三者之一。

1. 验证器太弱

"looks good"
"seems better"
"more scalable"
"clean architecture"

这些都不是收敛标准。它们是主观判断。go test 会返回 pass/fail，但"clean architecture"由谁来判定？另一个 LLM？那就像问一个喝醉的朋友"我喝醉了吗？"。

实证支持这一点。用于代码评估的 LLM 评审，对语义相同的代码的表层变体也会产生偏差，导致分数虚高或被不公平地压低（Moon et al. 2025）；模型在 58.19% 的案例中会扭曲自己的答案以迎合对方（SycEval, Fanous et al. 2025）。“looks good"与正确性无关。而且弱标准的危害不止于停不下来——当你把测量当成目标，测量就会失效（古德哈特定律；Manheim & Garrabrant 2018），有能力的推理模型不会正面解决任务，而是直接攻击验证流程本身（Bondarenko et al. 2025）。

没有收敛标准，就没有终点。

2. 没有任务边界

"帮我改进代码库"
"让架构更整洁"
"持续优化"

这些都是没有终止条件的任务。即便是人类开发者，面对这样的目标也会无尽地徘徊。智能体也没什么不同。“改进"是方向，不是目的地。

3. 熵超过了纠正的速度

这是最常见、也最狡猾的模式。

智能体在修改时添加抽象。引入间接引用。制造不必要的泛化。代码看起来"越来越好”，但实际上新的熵增长得比验证器消除它的速度更快。

今天创建的抽象 → 明天又把它移除 → 后天又再加回来

这就是非单调优化（non-monotonic optimization）。看起来在前进，其实在原地。看似永动机，实则只是在消耗能量。在这种情况下，能量就是 token。

大规模实证捕捉到了这种漂移。引入 Cursor 短期内提升了速度，但静态分析告警和代码复杂度持续上升，这种累积正是长期速度放缓的主因（He et al. 2025，807 个开源仓库）。在 AI 编写的超过 30 万次提交中，所引入问题的 22.7% 一直作为技术债存活到最新版本（Liu et al. 2026）。纠正追不上熵。

不是搜索问题，而是约束满足问题

这里显现出一个根本性的视角差异。

“把智能体跑得越久，就会得到越好的结果”——这是把软件工程看作**搜索问题（search problem）**的视角。期待在广阔的空间里搜索得越久，就能找到越好的解。

但软件工程本质上是约束满足问题（constraint satisfaction problem）。

• 类型必须匹配
• 测试必须通过
• 覆盖率必须达标
• 模式（schema）必须一致
• 必须遵守 lint 规则

只要全部满足这些约束，就结束了。不需要"继续搜索”。定义约束、满足约束、然后停止。这就是全部。

代码本身已经是可机器检查的领域（machine-checkable domain）。编译器、类型检查器、测试、覆盖率、linter、模式验证——这一切都是确定性验证器。这些验证器明明存在，为什么还要让智能体无止境地搜索？

学习研究也指向同一方向。如果把单元测试这类确定性验证器用作奖励——可验证奖励（verifiable reward）——代码正确性会高于开放式生成（CodeRL, Le et al. 2022; RLTF, Liu et al. 2023）。验证器不是用来收窄搜索的工具。它本身就是证据，揭示了这个问题从一开始就不是搜索，而是满足。

好的循环的条件

好的智能体循环在五个步骤中闭合：

1. 定义任务    — 必须达成什么（可机械判定的目标）
2. 限定范围    — 一次只处理一个单元（函数、端点、文件）
3. 符号化验证  — 由确定性工具判定 pass/fail
4. 收敛        — 通过则进入下一个，失败则带着反馈重试
5. 终止        — 没有剩余项时停止

在这个结构中，LLM 只负责第 3 步（生成）。其余全部由机器完成。尤其关键的是由机器决定"结束"。如果把终止判断交给 LLM，你就会在 40/527 时听到"全部做完了"。

实验也指向同一方向。给 LLM 加上自我批判（self-critique），在推理和规划任务上性能反而崩溃，只有加上外部的健全验证器时才会大幅提升（Stechly et al. 2024）。没有外部反馈的内在自我纠正会失败，有时纠正之后反而更糟（Huang et al. 2023）。不把终止交给 LLM，是有原因的。

creative writing 和代码不同

有一个例外。并非所有领域都如此。

写作、营销、设计——这些领域的验证器很弱。“这句话好不好？“无法机械判定。在这类领域，长时间的搜索可能是有意义的。智能体生成多个变体，由人来挑选。

但代码不同。代码本就是一个充满确定性验证器的世界。在这个世界里，长时间的徘徊（wandering）不是搜索，而是漂移（drift）。

提问

你的智能体此刻已经运行了几个小时？

它是在收敛，还是在漂移？

它能停下来吗？

如果能停下来，那为什么还没停？

相关文章

• 被勒住缰绳的 AI：Reins Engineering — 不是围栏，而是缰绳。用确定性契约来把握方向的工程。
• 谁来定义"完成” — 把终止条件从行为者的口中转移到机械化的门控。
• 编码智能体为何有效、为何崩溃 — “生成可以是概率性的，但验证必须是确定性的。”
• Ratchet Pattern — 锁定已通过的验证，从结构上抑制漂移。
• 龙骨（yongol）：200 个端点的墙 — 用声明式规约定义约束，由机器判定是否满足。

延伸阅读（外部）

• Designing agentic loops — Simon Willison。只有具备明确的成功标准和能通过的测试套件，智能体循环才能自我验证并停止——本文建设性的对照篇。
• Building Effective Agents — Anthropic。编码之所以是智能体的理想场景，是因为答案可以由自动化测试来验证——确定性验证器成为停止信号。
• Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes。核心设计决策不是更好的模型，而是可测量的终止条件，并警惕流畅的输出掩盖非收敛的"confidence laundering”。
• Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks。可靠性不来自模型，而来自确定性工具（computational controls）的 harness——与基于 AI 的推断式控制区分开来。
• Reward Hacking in Reinforcement Learning — Lilian Weng。“当测量成为目标，它就不再是好的测量”——把弱验证器用作奖励时博弈代理指标的机制的技术性整理。
• Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma。输入 token 越堆积，输出越退化——反复添加、移除、再添加的循环之所以会从自我纠正变成自我强化的机械原因。
• Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez。AI 会放大既有的 rigor——在低 rigor 下则加速混乱，这是"熵超过纠正"现象的实务视角。

来源

终止判定 · 自我验证的局限

• Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
• Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · 自我批判的不可信

• Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
• Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
• Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

漂移 · AI 代码复杂度上升

• He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
• Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

可验证奖励 · 基于验证器的代码生成

• Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
• Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

奖励黑客 · 规约博弈

• Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
• McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
• Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
• Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)