💻 computer science

When May an Agent Stop? Evidence-Carrying Termination for Tool-Using LLMs

本文引入了证据携带终止（Evidence-Carrying Termination, ECT），这是一种针对使用工具的 LLM 智能体的创新框架，它要求在完成前必须通过类型化证书将答案主张与有效的、可重现的追踪证据进行绑定，并在受控实验中证明了与现有的基于批评者（critic-based）的方法相比，该框架实现了零不安全完成，并显著减少了过早的无支持终止。

原作者： Jason Liu

发布于 2026-08-26

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jason Liu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在人工智能领域，一种新型软件已经出现：自主智能体（autonomous agent）。与等待指令的简单计算器不同，这些智能体被设计为能够思考、规划和行动。它们可以浏览网页、运行代码或查询数据库来解决复杂问题，就像人类研究人员收集信息一样。然而，这种新能力带来了一个根本性的困境：机器如何知道何时停止？如果智能体无休止地工作下去，会浪费资源并增加错误累积的风险；如果它停止得太早，则可能提交一个不完整或基于误解的答案。多年来，工程师们一直试图通过让 AI 简单地声明自己已完成，或者让第二个 AI 判断答案看起来是否良好来解决这个问题。但这些方法依赖于机器自身的信心，而这种信心可能是错误的。真正的挑战不仅在于要求智能体停止，而在于证明“停止”这一决定是基于坚实的、不可更改的证明，即确保答案的每一个部分都是被真正找到并计算正确的。

加州大学圣迭戈分校的一位研究人员通过一个名为“携带证据终止”（Evidence-Carrying Termination）的系统解决了这一问题。该系统并非让智能体根据感觉或简单的清单来决定何时停止，而是要求智能体在完成任务前必须生成一份正式的证书。可以将这份证书想象成一份收据，智能体必须为最终答案中的每一个主张生成收据。智能体不能只说“我找到了答案”，它必须展示究竟是哪次工具调用提供了数据，证明该数据与所提特定问题相关，并演示最终的数字或事实是如何使用一套严格且不可更改的规则推导出来的。如果证明过程中的任何部分缺失，或者当对照原始数据进行检查时数学逻辑不成立，系统就会强制智能体继续工作。它就像一个守门人，在智能体展示完所有详细作业之前，拒绝让其离开房间。

为了测试这种严谨的方法是否真的有效，研究人员创建了一个受控环境，其中包含四十八个不同的任务，范围从查找特定事实到执行复杂的数据聚合。随后，他们在这些任务中引入了八种特定的错误，例如给智能体错误的证据、隐藏工具调用失败的情况，或在它找齐所有必要信息之前要求它停止。他们将这个新系统与一种标准方法进行了对比，在标准方法中，一个批评者 AI 仅对答案进行判断。结果非常悬殊。在涉及近三百个故障场景的测试中，标准系统未能发现错误，并在两百五十二例中允许智能体带着错误或缺乏支持的答案停止。相比之下，新的“携带证据终止”系统实现了零次不安全完成。它成功识别了每一个缺陷，并强制智能体继续工作，直到证明过程变得稳固。

研究人员并未止步于静态测试；他们转向了一个更具动态性的闭环实验，涉及数百次模拟旅程，在这些旅程中，智能体必须实时从错误中恢复。在这里，目标是观察严格的证明要求是否会导致智能体过早放弃或无法完成有效任务。新系统再次表现优于传统方法。在六十六个关键实例中，它阻止了智能体过早停止，而旧系统在这些实例中失败了四十次。至关重要的是，新系统并没有因为过于谨慎而阻碍有用的工作；它完成受支持任务的速率在统计学上与旧系统持平，这证明了要求证明并不意味着牺牲进度。当智能体陷入困境时，系统能够在六十六次尝试中的十八次引导其进行恢复过程，其中十七次最终导向了成功的、经过验证的结论。

这项工作并不声称能让智能体变得无懈可击，也不保证其答案在现实世界中是真实的。该系统仅验证智能体是否遵循了其自身的规则，以及最终答案是否与它收集到的证据相匹配。它是对过程的检查，而非对外部真理的保证。然而，研究结果为更安全的 AI 指明了一条清晰的路径。通过将提出答案的行为与证明答案的行为分离，并通过要求对每一步进行确定性的重演，研究人员表明，构建能够确切知道何时结束的智能体是可能的。研究结论指出，智能体不应仅仅因为觉得完成了或答案听起来合理就停止。它应当仅在能够呈现出一条完整的、 unbroken 的证据链，以验证其提出的每一项主张时，才能停止。

技术摘要：面向工具使用型 LLM 的证据携带终止机制 (Evidence-Carrying Termination)

问题陈述

利用工具的交互式智能体面临一个关键的控制挑战：确定精确的停止时机。虽然现有系统采用了用于门控终端成功、认证执行轨迹或强制运行时策略的机制，但它们往往缺乏对受控终止故障边界的严谨设计。当前的停止信号（例如，发出 DONE 标记、启发式检查或 LLM 评论家判断）通常缺乏强有力的基础。它们可能无法识别哪些特定的观测结果支持了最终结论，或者该证据是否覆盖了请求的实体与时间范围，亦或是派生值是否可以进行确定性重放。这种差距带来了可扩展监督方面的风险，因为过早终止可能会将不受支持的中间状态转化为最终答案，而无限期的持续运行则会浪费资源并增加风险。

方法论：证据携带终止 (ECT)

本文提出了 证据携带终止 (Evidence-Carrying Termination, ECT) 框架。在该框架下，智能体只有在满足以下条件时才能返回“完成”状态：一份类型化的证书将每一个要求的答案声明与有效的、在范围内的轨迹证据绑定，并且通过确定性重放能够重建所声称的值。

核心组件

契约 ( $R_t$ )： 一个受信任的需求集，列举了要求的答案槽位、允许的转换、实体/时间范围、证据基数、可空性以及数值容差。智能体在运行期间不会编写此契约。
账本 ( $E_t$ )： 一个收据账本，将任务、调用和工具标识符与参数及响应的哈希值进行绑定。它记录了源路径、值哈希、执行状态和结构化范围。
证书 ( $C_t$ )： 一个提议的终端声明，包含任务标识、冻结任务描述符的摘要、归一化账本摘要，以及以 (槽位, 值, 证据 ID, 转换) 形式呈现的具体声明。
确定性验证器： 一个类型化验证器，用于根据受信任的契约和不可变账本检查证书。它执行以下操作：
- 绑定检查： 验证任务描述符和账本摘要的有效性。
- 覆盖检查： 确保每个强制要求的槽位都存在，且不存在禁止的额外项。
- 证据检查： 验证引用的收据是否存在、属于该任务、执行成功且经过验证。
- 范围检查： 确认实体、属性、层级和日期范围符合要求。
- 重放检查： 执行一种封闭的、非可执行的转换语言（包括恒等、集合、聚合和集合操作），以确定性地重建声称的值。

如果任何检查失败，系统将返回 continue 并附带具体的错误代码。该系统被设计为是“相对可靠的”：如果验证器返回 complete，则表示该声明在既定的契约和适配器假设下，可以从绑定的轨迹中重建，但并不保证外部真实性或安全性。

主要贡献

本文的贡献包括：

一种针对完成特定任务的类型化验证器： 结合了任务描述符与账本摘要的绑定、收据级验证（值、路径、状态、范围）以及精确的封闭转换重放。
2.一个受控基准测试： 一个包含 6 个家族、48 个完全合成任务以及 8 种特定终止故障（如：虚假完成、无关证据、范围不匹配、伪造引用）的基准测试。
严谨的评估协议： 针对经过检查的评论家核心 (critic core)、其忠实控制器 (faithful controller)、全轨迹 LLM 评论家以及其他基线模型，进行了预设且冻结的静态与闭环对比。

实验结果

静态评估（留出故障）

在对 36 个任务中的 288 个留出故障快照进行研究中：

不安全完成： ECT 产生的非安全完成次数为 0/288，而经过检查的终止评论家核心为 252/288。
统计显著性： 差异为 −87.50 个百分点（95% 任务簇区间 [−87.50, −87.50]），且 $p < .05$ ，满足主要假设 (H1)。
干净快照： 在 36 个干净的快照上，ECT 的错误持续次数为 0，与评论家核心持平。

闭环确认 (V2 研究)

一项使用 22 个主要留出任务簇中的 576 条轨迹进行的最新研究，将 ECT 与忠实控制器及其他基线进行了对比：

过早的无支持终止： ECT 在来自不完整检查点的轨迹中产生的过早无支持终止次数为 0/66，而忠实控制器为 40/66（差异为 −60.61 pp，95% 区间 [−78.79, −40.91]）。
受支持的完成： ECT 实现了 97/132 次受支持的完成，而控制器为 92/132（差异为 3.79 pp，区间 [0.00, 9.09]），满足了预设的 −10 点非劣效性界限 (H3)。
恢复能力： ECT 在 18/66 个符合条件的未完成轨迹中执行了成功恢复，其中 17 个随后在有支持的情况下完成 (H4)。
成本： 与控制器相比，ECT 产生了更高的开销（约 0.90 个额外的决策轮次、4,653 个额外的 token 以及每条轨迹 0.00246 美元的额外成本）。

意义与声明

本文声称 ECT 建立了一种使终端支持在声明的假设下是可检查的机制。

保证范围： 系统证明了终端声明在绑定的轨迹下，在受信任的契约和适配器假设下是可重建的。它明确不证明外部真实性、通用任务成功、安全性或对齐性。
控制 vs. 监督： 通过将生成（智能体提出证书）与授权（确定性验证器）分离，ECT 提供了一个具体的类型化终端声明验证器，能够在不依赖执行过程中外部“金标准”答案的情况下，防止不支持的完成。
谦逊态度： 作者指出了局限性，包括生成的环境并未覆盖实际部署流量、平衡故障是干预而非流行度估计，以及封闭转换语言不涵盖任意语义推理。研究依赖于单一的规划器/模型堆栈和合成工具，且由于敏感材料，完整的开发库未予发布，但提供了脱敏后的产物。

总之，ECT 表明，智能体不应仅仅因为它们声称已完成或其答案看起来合理就停止；相反，终止应当要求在受信任边界内具有可验证的证据和确定性的可重现性。