AI智能体何时该停下？被低估的停止条件设计

在设计AI智能体（Agent）时，我们花了大量精力思考它"下一步该做什么"：该调用哪个工具？该检索哪些信息？要不要询问另一个智能体？要不要重试？但有一个看似简单、实则棘手的问题常常被忽略——智能体究竟应该在什么时候停下来？

这个问题的分量，往往被整个行业低估了。真正成熟的自主性，不只是赋予智能体持续行动的能力，更是赋予它判断"何时继续行动已经没有意义"的能力。

停得太早与停得太晚，都是问题

智能体的停止时机是一个两难权衡。停得太早，它可能遗漏关键证据，给出不完整甚至错误的结论；而停得太晚，则会浪费时间、推高成本、重复劳动，甚至把一个本来不错的答案越改越糟。

原文用了一个很有代表性的例子：一个事故调查智能体（incident investigation agent）。它会检查最近的部署记录、服务依赖关系、已知问题、历史事故以及当前的运维手册（runbook）。在某个节点，它其实已经掌握了足够证据，可以给出合理的处置建议。

但如果它继续搜索下去，可能会翻出症状相似的陈年旧事故、早已废弃的文档，或是毫不相关的边界情况。关键在于：更多信息并不总是让决策变得更好，有时反而制造了更多混乱。

这也说明，"停止"应该是智能体设计中的一等公民，而不是事后补丁。

步数上限：有用但不够深刻

最简单直接的做法，是设定一个最大步数。比如规定智能体最多调用八次工具，之后必须返回结果。

这种硬性限制能有效防止无限循环，是一道必要的安全阀。但它回避了更深层的问题：如果正确答案在第三步就已经清晰可见，为什么还要白白耗到第八步？反过来，如果八步根本不足以得出结论，又该怎么办？

换句话说，固定步数是一种"一刀切"的保护机制，它关心的是"别跑太久"，却不关心"任务到底完成了没有"。

更好的标准：证据充分性

原文提出了一个更有洞察力的停止条件——证据充分性（evidence sufficiency）。智能体应该在以下三种情况之一出现时停止：

• 已经掌握了足够可靠的信息来回答问题；
• 继续行动不太可能改变最终决策；
• 剩余的不确定性需要人类介入，而非更多的工具调用。

还是回到那个事故调查的例子：如果智能体发现某次部署恰好发生在事故前五分钟、受影响的服务依赖于被改动的组件、某个已知问题的症状与之吻合、且当前运维手册建议回滚——那么此时继续搜索几乎不会带来任何新价值。系统完全可以停下来，直接返回建议。

证据充分性让停止决策从"数够了没有"升级为"证据够不够"，这才是贴近真实决策逻辑的判断方式。

证据充分性的概念在认知科学与决策理论中有深厚根基，对应的是"满意解"（satisficing）原则——诺贝尔经济学奖得主赫伯特·西蒙提出，理性决策者不必寻找最优解，而是在信息足够支撑一个"够好"的决定时就应停止搜索。将这一原则引入AI智能体设计，意味着智能体需要具备某种元认知能力：不仅要处理信息，还要评估当前信息集合对决策目标的覆盖程度。在工程实现上，这通常通过让模型在每一步推理后输出一个"置信度"或"完成度"的自评估，或者在提示词（system prompt）中明确定义"足够"的判断标准来实现。值得注意的是，证据充分性并非一个固定阈值，它高度依赖任务的风险等级——医疗诊断类任务所需的证据充分度远高于日常信息检索。

"我不知道"也是一种成功的停止

与证据充分同样重要的，是相反的情形。假设智能体检查了部署、依赖和监控数据，但证据始终不完整、相互矛盾，这时它绝不应该抱着"再查下去也许确定性就出现了"的幻想无限调用工具。

在这种情况下，正确的动作恰恰是明确承认：

"我没有足够的证据，需要人工介入调查。"

原文特别强调，这同样是一种成功的停止条件。一个会在恰当时机交还控制权、承认自身局限的智能体，远比一个硬要给出答案的智能体更值得信赖。

重复行为：工作流卡住的信号

另一个值得关注的停止信号是重复动作。如果一个智能体反复用措辞略有不同的查询调用同一个搜索工具，却得到几乎一模一样的结果，那么这个工作流很可能已经陷入了死胡同。

应用层可以主动检测这类情况——重复的工具调用、始终不变的返回结果、缺乏实质进展——并据此中断循环。这类"原地打转"往往是智能体推理陷入局部循环的早期征兆。

模型负责推理，系统负责兜底

文章最有价值的工程启示在于：模型可以判断什么时候该收手，但确保它真正停下来，是周边系统的责任。

大模型或许能推理出"下一步做什么合理"，但传统软件工程的护栏依然不可或缺。应用代码应当强制执行这些限制：

• 最大步数（maximum steps）
• 超时控制（timeouts）
• 重复动作检测（repeated-action detection）
• 成本预算（cost budgets）
• 人工升级规则（human escalation rules）

这是一种清晰的分工：模型在语义层面"推理何时完成"，而确定性的工程代码在系统层面"保证它确实停止"。两者缺一不可——只靠模型自觉容易失控，只靠硬限制又太过僵硬。

这种分层设计思想来自于经典的"防御性编程"（defensive programming）理念，并与AI安全领域的"多层防御"（defense in depth）原则一脉相承。在大型语言模型作为推理核心的智能体架构中，模型本身是一个概率系统，其行为具有不确定性；而外围的工程护栏则是确定性的规则引擎。两者形成互补：模型提供灵活的语义判断，工程代码提供可预期的边界保障。超时控制防止因外部API响应缓慢或模型陷入冗长推理链而无限等待；成本预算则在Token消耗或API调用费用层面设置硬性上限，这在生产环境中尤为重要，因为单次失控的智能体运行可能产生远超预期的开销。人工升级规则（human escalation）的设计，本质上是将"不确定性超过阈值"的情形路由给人类处理，这也是当前AI系统在高风险场景下维持可靠性的核心机制之一。

好的智能体，也要懂得"没有下一步"

自主性常被理解为"让智能体不停地行动"，但原文给出了一个更完整的视角：真正的自主，还包括一套可靠的机制，让智能体知道何时继续行动已不再有用。

一个优秀的AI智能体，不应该只知道"下一步做什么"，更应该知道什么时候"根本不该有下一步"。在智能体系统日益复杂的今天，把"停止"当作设计的核心环节而非事后考量，可能是区分可靠系统与失控系统的关键一笔。