先思考，再行动：面向 LLM Agent 的决策门控

来源：https://arxiv.org/html/2610.38620

Yuval David^1^（IBM SIL）、Ofer Akrabi（IBM SIL）、Erez Bilgory（IBM SIL）、Ido Levy（IBM SIL）、Sami Marreed（IBM SIL）、Sergey Zeltyn（IBM SIL）、Segev Shlomov^†^（通讯作者：[email protected]，IBM SIL）

摘要

LLM Agent 越来越多地通过外部工具执行高风险操作，但它们提出的动作往往在未经独立验证策略合规性或任务完成度的情况下就被执行。我们提出 JevAct，一个运行时验证框架，在执行前拦截选定的 Agent 动作，并支持基于反馈的修正。JevAct 将领域策略编译为可执行的状态检查和结构化问题，这些问题由仅前向（prefill-only）的决策模型评估，产生基于概率的判断，而不依赖 LLM 生成。通过将工具状态事实的确定性验证与对话上下文的概率性评估相结合，该框架能够识别潜在无效动作和过早的任务终止，并为有限次数的修正提供针对性反馈。JevAct 独立于底层 Agent 模型运行，无需对其参数或工具做任何修改。我们在 τ²-bench 的 Airline 和 Telecom 任务以及 BFCL 上，对十一个 LLM Agent 进行了评估。结果表明，JevAct 在多个模型和基准上提升了 Agent 可靠性，在 Telecom 和 BFCL 上的增益尤为一致，而 Airline 上的表现较为混合。总体而言，这些发现表明将结构化决策模型与可执行验证相结合，能够提升使用工具的 LLM Agent 的可靠性。

ReAct / JevAct，τ²-Airline，τ²-Telecom，BFCL 各基准上的 pass^3 结果：

• GPT-4.1：36.0 → 46.0（Airline）、11.4 → 17.5（Telecom）、38.2 → 47.8（BFCL）
• Opus 4.6：72.0 → 76.0（Airline）、39.5 → 80.7（Telecom）、55.9 → 59.1（BFCL）
• gpt-oss-120b：42.0 → 50.0（Airline）、28.9 → 51.8（Telecom）、39.9 → 47.6（BFCL）
• Qwen3.8-27B：74.0 → 76.0（Airline）、57.9 → 81.6（Telecom）、48.1 → 49.9（BFCL）

图 1：表 2 中的 pass^3 结果（https://arxiv.org/html/2610.38620#S5.T2）

1 引言

语言模型 Agent 越来越多地使用工具来修改记录、进行预订，并引导用户完成多步骤流程。一个错误的回答有时可以在后续对话中纠正；但未经授权的写操作或过早的转交则可能更难撤销。然而，许多 Agent 循环一旦模型生成了工具调用就会立即执行。这在“生成动作“与“检查其是否适合执行“之间留下了空白。

ReAct Agent 将推理与工具使用交替进行，而 Self-Refine 和 Reflexion 等反思方法通过添加批评和反馈来改进后续的提议或尝试（Yao et al., 2022；Madaan et al., 2023；Shinn et al., 2023）。这些方法可以改善 Agent 行为，但它们本身并不能在执行前针对领域策略对特定动作进行验证。运行时约束和学习式工具调用检查则解决了这一独立问题（Wang et al., 2026；Chen et al., 2025；Mou et al., 2026；Kang et al., 2026a）。

一个单独的生成式 LLM 可以审查每个提议并解释其顾虑，类似 LLM-as-a-judge 方法（Zheng et al., 2023；Liu et al., 2023）。但自由形式的解释仍需在门控系统对其做出反应前进行解读，且使用前沿模型做出这一决策的成本很高。决策模型则针对固定问题返回选项和概率，使基于阈值的检查变得简单。它们的概率不保证经过校准或正确，因此其价值必须在 Agent 循环中通过实验验证，而非假设（TypeSafe AI, 2026；Deußer et al., 2026）。

我们提出 JevAct，一个在执行前检查选定提议的框架。离线阶段，一个编译器将领域策略转化为问题、规则、针对工具状态的可执行检查，以及（如需要时的）转交清单。运行时，代码检查工具记录中可获得的事实，Kev（一个开源的 Jev 类决策模型，TypeSafe AI, 2026）回答依赖于对话的问题。通过检查的提议继续执行；被标记的提议则连同针对性反馈返回给 Agent，获得有限次数的修正机会。Agent 仍然负责提出动作；Kev 不选择动作。这使 JevAct 区别于将动作选择委托给决策模型的以决策为中心的运行时（ZJUNLP, 2026）。

本工作的核心问题是：决策模型能否作为基于概率阈值的验证器，与可执行的工具状态检查协同工作？我们将 JevAct 与使用相同 Agent LLM 的 ReAct 框架进行对比，在 τ²-bench 的 Airline 和 Telecom 任务以及 BFCL 的多轮函数调用任务中进行评估（Barres et al., 2025；Patil et al., 2025）。在 Telecom 上，所有八个 Agent 在至少一次成功和三次全部成功两种指标上均有提升。在 BFCL 上，所有九个 Agent 在三次全部成功上均有提升，但至少一次成功的结果较为混合。Airline 的效果较小且因 Agent 而异（见图 1）。由于 JevAct 增加了编译后的检查和修正机会，这些比较评估的是完整框架，而非孤立的评判器。

本文的贡献有三：

• 我们提出 JevAct，将针对工具状态的可执行检查与基于概率阈值的对话上下文决策模型判断相结合，在选定动作执行前进行验证。
• 我们为一种工作流奠定基础，将领域策略编译为问题、决策规则、可执行状态检查和决策模型门控所需的转交清单。
• 我们在三个基准场景中将该框架与同模型 ReAct 基线进行对比评估，并附带组件和评判器消融实验，以及任务成功率、可重复性和估算评判器成本的结果。

2 相关工作

2.1 LLM Agent 与测试时反馈

ReAct 将模型推理与环境动作交替进行（Yao et al., 2022）。Self-Refine 和 Reflexion 在测试时添加批评或反馈，以改进后续提议和尝试，而无需更新模型权重（Madaan et al., 2023；Shinn et al., 2023）。这些方法为给 Agent 修正机会提供了动机，但它们本身并不在执行前检查一个高风险工具调用是否满足领域策略。

2.2 运行时策略执行

多个系统在 Agent 执行周围施加了显式控制。GuardAgent 使用一个单独的 Agent 从用户定义的保护需求生成并执行验证代码（Xiang et al., 2024）。Zwerdling et al. 将公司策略编译为可执行的守卫，在工具动作前检查合规性（Zwerdling et al., 2025）。AgentSpec 将运行时表示为触发器、谓词和执行动作；ShieldAgent 从策略文档中推导可验证规则；CUGA 在执行图上应用治理干预（Wang et al., 2026；Chen et al., 2025；Shlomov et al., 2026）。ToolSafe 使用学习式护栏评估提议的工具调用并返回反馈，而 PolicyGuard 和 PolicyGuide 使用基于模型的验证器进行策略遵从和工作流引导（Mou et al., 2026；Kang et al., 2026a；Kang et al., 2026b）。相关方法还包括验证器驱动的运行时调解，使用可执行的程序化检查来选择干预措施（Yabusaki, 2026），以及 ToolFence，将确定性授权与基于评判器的能力授予相结合（Li et al., 2026a）。CaMeL 则通过分离可信控制流和不可信数据来保障安全（Debenedetti et al., 2026）。JevLoop 将动作和控制决策交给决策模型；JevAct 则将提议留给 ReAct LLM，并将 Kev（一个开源的 Jev 类决策模型）置于选定动作提交前的独立验证步骤中（ZJUNLP, 2026）。我们聚焦于使用固定选项决策模型的概率阈值验证，结合针对工具状态事实的可执行检查和基于反馈的修正。

2.3 LLM 评判器与决策模型

LLM-as-a-judge 方法使用生成模型来比较回答（如 MT-Bench），或应用显式评分标准（如 G-Eval）；这类判断也可能对回答顺序敏感（Zheng et al., 2023；Liu et al., 2023；Wang et al., 2024）。Jev 引入了返回类型化选项、分数和概率而非生成文本的决策模型（TypeSafe AI, 2026）。初步评估研究了其闭集标签决策和基于标准的评分（Deußer et al., 2026）。最近两篇预印本评估了 Jev 作为评判器的表现：Li et al. 报告了在偏好和基于证据的事实性上具有竞争力的结果，但在需要推导的场景下表现较弱；Rao 和 Callison-Burch 报告了混合的标准评分结果以及与 LLM 评判器的重叠错误（Li et al., 2026b；Rao and Callison-Burch, 2026）。这些研究评判的是已完成的输出。JevAct 则不同，它在线使用 Kev（一个开源的 Jev 类模型），在选定动作执行前运行，将其固定选项判断与程序化状态检查和修正反馈相结合（Palmer, 2026）。

3 方法

在本工作中，我们提出 JevAct，通过在消息提议与执行之间插入选择性检查阶段来增强 ReAct Agent 的框架（Yao et al., 2022）。检查可以推迟执行，并在固定修正预算内请求 LLM 提出修订方案并附带临时反馈。Agent 的 LLM、基础提示词和工具保持不变。

3.1 概览

场景设定

在每个步骤 t，LLM 读取对话历史并提出一条消息，其中可能包含面向用户的文本、工具调用或两者。框架通常执行该提议，并将其及任何工具结果加入历史。在受策略管理的任务中，JevAct 在执行前检查选定的提议，因为某些错误难以撤销。一个写调用（write call）会改变环境，例如预订、取消或修改设置。一次转交（hand-off）结束 Agent 的尝试，方式可以是将用户转交给人工，或告知用户无法进一步处理。当没有书面策略可用时，相同的运行时设计也可以应用通用检查。

组件

我们的方法 JevAct 包含四个主要组件，如图 2 所示。（1）决策循环：与 ReAct Agent 类似，每个步骤由四个阶段组成：提议、触发、检查以及提交或修正。触发器为写调用或转交选择一项检查；其他提议按 ReAct 方式直接执行。通过检查的提议被提交；被标记的提议则连同反馈返回给 Agent 以便修正。（2）编译器：离线阶段，LLM 将每个领域的策略转化为是非问题、组合答案的规则、从工具结果计算事实的代码，以及（如需要时的）转交清单。（3）评判器：一个决策模型以概率回答问题，使得检查仅基于有把握的答案做出动作。（4）检查：写门控（write gate）测试提议的写调用是否被策略允许。转交检查（hand-off check）寻找尚未完成的必要故障排查步骤。对于写调用，代码计算可从工具记录中确定的事实；评判器回答依赖于对话的问题。转交检查使用评判器来评估适用的问题和已解决的清单步骤。尽管各组件相互依赖，但每个组件都是模块化的，可在后续工作中独立替换或改进。

图 2：JevAct。离线（上），LLM 将策略编译为检查。在线（下），Agent 的提议经历四个阶段：(1) 提议，(2) 触发，(3) 在需要时检查，以及 (4) 提交或修正。不含写调用或转交的提议按 ReAct 方式执行。被标记的提议被丢弃，LLM 在临时反馈下重新提议。

3.2 决策循环

在步骤 t，Agent 经历四个阶段：

1. 提议。LLM 在给定历史 h_t 下提出消息 m ~ π(· | h_t)。
2. 触发。若 m 包含写调用，则适用写门控。若 m 进行转交，则适用转交检查。其他消息直接提交。
3. 检查。检查返回通过或标记。标记时附带一段反馈文本 f，指出问题所在。
4. 提交或修正。通过的消息按 ReAct 方式执行并加入历史。被标记的消息被丢弃：它永远不会被执行，也永远不会被存储。LLM 随后提出