通过溯源分析防范LLM代理失对齐
摘要
本文提出了一种基于溯源的框架和多阶段流水线\tool,用于在LLM代理执行工具调用前检测失对齐,与基于LLM作为裁判的基线相比,显著降低了错误率。
arXiv:2607.01236v1 Announce Type: new
Abstract: 随着LLM代理获得越来越强大的工具访问权限,确保其行为与用户意图对齐变得至关重要。当代理提议的工具调用偏离用户意图时(这种现象称为失对齐),可能导致难以挽回的有害后果。现有的运行时护栏依赖LLM作为裁判的范式,缺乏系统的对齐推理框架,常常产生不一致或难以审计的判断。受溯源分析启发,我们提出一个基于溯源的概念框架,将失对齐检测形式化为判断提议的工具调用是否在代理上下文中有可追踪的证据支持。基于此框架,我们提出了ProvenanceGuard,一个多阶段流水线,在执行选定工具前分析代理行为中的三种失对齐类型,仅当行为被认为与用户输入查询对齐时才允许执行。我们在两个不同基准Agent-SafetyBench和WorkBench上,使用10个骨干LLM评估了该方法。与LLM作为裁判的基线相比,ProvenanceGuard在Agent-SafetyBench上将失对齐轨迹的错误率从42.9%降至1.8%,在WorkBench上从32.1%降至17.3%;同时将任务成功轨迹上的干预负担从30.5%降至12.8%,且在对齐轨迹上未引入统计上显著的不必要干预增加。这些结果表明,结构化的基于溯源推理为保护LLM代理免受失对齐影响提供了有效且实用的基础。
查看缓存全文
缓存时间: 2026/07/03 05:39
# 通过溯源分析保护 LLM 代理免受错位影响 来源:https://arxiv.org/html/2607.01236 ###### 摘要。随着 LLM 代理对强大工具的访问日益增加,确保其行为与用户意图保持一致变得至关重要。当代理提议的工具调用偏离用户意图时——这种现象称为*错位*——可能会产生难以逆转的有害后果。现有的运行时护栏依赖于*LLM 即评判者*范式,缺乏系统的错位推理框架,常常产生不一致或难以审计的评判结果。受*溯源分析*启发,我们提出一个基于溯源的概念框架,将错位检测形式化为判断提议的工具调用是否得到代理上下文中可追溯证据的支持。基于此框架,我们提出了\\tool,一个多阶段流水线,在所选工具执行之前分析代理行为的三种错位类型,并仅在认为其与用户输入查询一致时才允许该行为执行。我们在两个不同的基准测试上评估了所提出的方法:Agent-SafetyBench 和 WorkBench,涉及 10 个骨干 LLM。与 LLM 即评判者基线相比,\\tool 在 Agent-SafetyBench 上将错位轨迹的错误率从 42.9% 降低到 1.8%,在 WorkBench 上从 32.1% 降低到 17.3%,同时将任务成功轨迹上的干预负担从 30.5% 降低到 12.8%,并且在已对齐轨迹上未引入统计上显著的不必要干预增加。这些结果表明,结构化的、基于溯源推理为保护 LLM 代理免受错位影响提供了有效且实用的基础。 ## 1. 引言 大型语言模型(LLM)的使用正从对话助手迅速向自主代理系统演进。这些系统为 LLM 配备外部工具,使其能够直接与现实世界交互:发送电子邮件、修改文件、控制智能家居设备以及执行代码(Yao 等,2023 (https://arxiv.org/html/2607.01236#bib.bib33);OpenClaw,2026 (https://arxiv.org/html/2607.01236#bib.bib38);Anysphere, Inc.,2026 (https://arxiv.org/html/2607.01236#bib.bib35);Anthropic,2026 (https://arxiv.org/html/2607.01236#bib.bib41);Birkmose 等,2025 (https://arxiv.org/html/2607.01236#bib.bib42))。与仅生成文本供人类审阅的聊天机器人不同,代理可以代表用户执行具有后果且不可逆的操作。随着代理自主性增强,其潜在影响和相关风险急剧增加(Su 等,2025 (https://arxiv.org/html/2607.01236#bib.bib32);Deng 等,2025 (https://arxiv.org/html/2607.01236#bib.bib40);Ma 等,2026 (https://arxiv.org/html/2607.01236#bib.bib39);penligent,2026 (https://arxiv.org/html/2607.01236#bib.bib36))。 代理系统的一个主要风险是代理可能执行偏离用户实际意图的操作,我们将此现象称为*错位*。例如,用户要求代理“向 Daniel 请求 30 美元”,代理却调用了“发送付款”工具,向 Daniel 支付了该金额,这与用户请求相反。“错位”一词有时也用于指代*恶意*代理行为(Lynch 等,2025 (https://arxiv.org/html/2607.01236#bib.bib10);Betley 等,2025 (https://arxiv.org/html/2607.01236#bib.bib46);Naik 等,2025 (https://arxiv.org/html/2607.01236#bib.bib8)),这是一个同样重要但不同的问题。在本工作中,我们关注的是代理并非出于恶意,而是误解或对用户通过提示表达的意图做出不合理假设的情况。此类错位可能造成重大意外伤害,尤其是当结果操作不可逆时。因此,在工具执行前检测并防止错位对于代理的实际部署至关重要。 现有研究已探索多种缓解代理错位风险的方法。训练时对齐方法,如偏好优化和监督微调(Ouyang 等,2022 (https://arxiv.org/html/2607.01236#bib.bib43);Bai 等,2022 (https://arxiv.org/html/2607.01236#bib.bib45)),可以改善代理的总体行为,但无法覆盖部署时遇到的所有工具配置、环境状态和任务上下文。提示级控制,包括精心设计的系统指令和推理框架,可以进一步引导行为,但它们仍然依赖于试图改进的同一基础模型的判断(Sahoo 等,2024 (https://arxiv.org/html/2607.01236#bib.bib12);Shinn 等,2023 (https://arxiv.org/html/2607.01236#bib.bib47);Madaan 等,2023 (https://arxiv.org/html/2607.01236#bib.bib48))。沙盒化和能力限制可以通过隔离工具执行和限制代理权限来减少伤害,但它们主要控制行为的后果,而不是判断行为是否忠实反映用户意图(Zhang 等,2025 (https://arxiv.org/html/2607.01236#bib.bib13);Wu 等,2025 (https://arxiv.org/html/2607.01236#bib.bib49))。事后验证与恢复方法在操作发生后提供有用的审计或纠正,但一旦不可逆的工具调用已经发生,它们防止伤害的能力有限(Ruan 等,2024 (https://arxiv.org/html/2607.01236#bib.bib14);Vuddanti 等,2026 (https://arxiv.org/html/2607.01236#bib.bib50))。这些局限性共同表明,LLM 代理在执行前需要运行时*护栏*(Wang 等,2025a (https://arxiv.org/html/2607.01236#bib.bib15);Xiang 等,2025 (https://arxiv.org/html/2607.01236#bib.bib17))。这些护栏位于动作生成和工具执行之间,作为一个独立的决策层,可以在错位动作对环境产生不可逆影响之前检测并阻止它们(Fang 等,2025 (https://arxiv.org/html/2607.01236#bib.bib7))。 然而,现有的运行时护栏通常依赖于*LLM 即评判者*机制来评估提议的动作是否应该被允许(Zheng 等,2023 (https://arxiv.org/html/2607.01236#bib.bib31);Luo 等,2025 (https://arxiv.org/html/2607.01236#bib.bib54);Wang 等,2026 (https://arxiv.org/html/2607.01236#bib.bib55))。缺乏系统的错位推理框架,这些判断在很大程度上仍然是主观且无指导的(Yeadon 等,2026 (https://arxiv.org/html/2607.01236#bib.bib52))。它们缺乏明确的决策标准,可能导致不同运行和模型之间的标准不一致(Wei 等,2025 (https://arxiv.org/html/2607.01236#bib.bib51);Shi 等,2025 (https://arxiv.org/html/2607.01236#bib.bib53);Lee 等,2025 (https://arxiv.org/html/2607.01236#bib.bib56))。因此,判断背后的基本原理更难以解释和审计。 参照标题 图 1. 三种错位类型的示例。 在本文中,我们提出了一个受*溯源分析*启发的系统框架来检测错位的代理动作。溯源分析是一个成熟的学科,用于追踪人工制品的来源和衍生历史(Cheney 等,2009 (https://arxiv.org/html/2607.01236#bib.bib4);Davidson and Freire,2008 (https://arxiv.org/html/2607.01236#bib.bib5))。我们方法的关键直觉是:一个动作是否与用户意图对齐应该可以通过上下文中可追溯的证据来证明,即用户请求、可用工具文档以及先前交互的历史。我们在工具调用层面发展这一思想,通过*区分三种错位类型*(图 1 (https://arxiv.org/html/2607.01236#S1.F1)):(1) *工具级错位*:选择错误的工具,(2) *参数级错位*:选择无法追溯到上下文或不适合解决用户查询的工具参数,以及 (3) *解释级错位*:在上下文中*未充分指定*的用户查询的多个可能解释中选择其中一个。我们提供了一个概念框架,形式化了代理设置中溯源的概念以及上述错位类型的定义。我们的框架作为实现护栏的理论基础,通过检查提议动作与给定上下文之间明确、可审计的溯源链接,来判断工具动作是否被视为对齐或错位。 基于所提出的框架,我们开发了 \\tool,一个多阶段流水线实现。该流水线执行三阶段分析,分别针对工具级、参数级和解释级错位。我们在两个基准测试上评估了 \\tool:Agent-SafetyBench(Zhang 等,2024b (https://arxiv.org/html/2607.01236#bib.bib1))和 WorkBench(Styles 等,2024 (https://arxiv.org/html/2607.01236#bib.bib2)),与 LLM 即评判者基线以及 \\tool 的单步变体进行比较,涉及 10 个骨干 LLM。我们的实验结果表明,所提出的基于溯源的概念框架本身相比直接 LLM 即评判者提示显著改进了错位检测,并且多阶段设计带来了显著的额外增益,尤其是在 Agent-SafetyBench 上。具体来说,\\tool 在 Agent-SafetyBench 上将错位轨迹的平均错误率从 42.9% 降低到 1.8%,在 WorkBench 上从 32.1% 降低到 17.3%。同时,这些增益并未伴随干预成本的相应增加。与基线相比,\\tool 在已对齐轨迹上并未引入统计上显著的不必要干预增加,并且将任务成功的 WorkBench 轨迹上的干预率从 30.5% 降低到 12.8%。这些结果表明,结构化的、基于溯源的推理为保护 LLM 代理免受错位动作影响提供了有效且实用的基础。 本文的主要贡献如下: - • 代理动作错位的分类法,区分工具级、参数级和解释级错位(第 3 节 (https://arxiv.org/html/2607.01236#S3))。 - • 一个基于溯源的概念框架,用于检测错位的代理动作,将对齐检查框架化为判断提议的工具调用是否得到代理上下文中可追溯证据的支持(第 4 节 (https://arxiv.org/html/2607.01236#S4))。 - • \\tool,该框架的多阶段流水线实现,作为运行时护栏运行(第 4.3 节 (https://arxiv.org/html/2607.01236#S4.SS3)),并附带在两个基准测试上 10 个骨干 LLM 的评估(第 5 节 (https://arxiv.org/html/2607.01236#S5) 和 6 节 (https://arxiv.org/html/2607.01236#S6))。 - • 一个从 Agent-SafetyBench 衍生而来的人工标注的代理执行轨迹基准(第 5.1 节 (https://arxiv.org/html/2607.01236#S5.SS1))。 ## 2. 预备知识 ### 2.1. LLM 代理工作流程 我们考虑一个典型的 LLM 代理设置,其中 LLM 与一组预定义的工具交互以完成用户任务(图 2 (https://arxiv.org/html/2607.01236#S2.F2))。在交互开始时,用户向代理提交自然语言查询。LLM 作为代理的决策核心。基于查询和当前上下文,LLM 决定调用哪个工具以及如何参数化工具调用,以获取信息或修改环境(Yao 等,2023 (https://arxiv.org/html/2607.01236#bib.bib33))。 参照标题 图 2. 带有外部护栏的 LLM 代理工作流程。护栏在执行前监控每个提议的动作。 工具调用后,返回的输出被发送给 LLM。然后模型决定下一步:它可以调用更多工具、向用户请求澄清,或者在任务完成时返回最终响应。通过这种推理、工具调用和观察的迭代循环,代理与环境交互以完成用户的请求。在工作流程中引入外部护栏模块是减少意外动作风险的有效方法(Fang 等,2025 (https://arxiv.org/html/2607.01236#bib.bib7))。该模块作为 LLM 提议的动作与实际工具执行之间的监控层。当 LLM 提议一个工具调用时,护栏评估该动作是否与用户查询一致。如果护栏确定提议的动作可能错位,它可以阻止执行,转而请求用户确认或澄清。 ### 2.2. 未充分指定 当用户与 LLM 代理交互时,自然语言查询最终对应于 LLM 代理需要执行的一系列具体动作。然而,由于自然语言的固有限制和某些上下文信息的缺失,单个查询常常可以有多种合理解释。每种解释可能对应代理可以执行的不同动作序列。但并非每种解释都与用户期望的具体动作序列对齐。我们将这种情况称为*未充分指定*。当查询中包含的信息以及可用上下文不足以唯一确定意图的动作序列时,该查询就是未充分指定的。在这种情况下,多种解释与用户请求一致,代理无法可靠地推断哪种解释反映了用户的真实意图。 未充分指定与歧义(Yang 等,2025 (https://arxiv.org/html/2607.01236#bib.bib27))密切相关,但又有区别。歧义是自然语言的固有属性:由于词汇、句法或语义因素,语言表达可以具有多种含义。相比之下,未充分指定源于查询与其上下文的交互。一个查询未充分指定不仅因为它有多个语言解释,更主要因为可用信息不足以确定哪种解释应指导代理的行为。在一个上下文中未充分指定的查询,在另一个具有额外上下文约束的上下文中可能是充分指定的。 当查询未充分指定时,选择一个合理解释并据此行动需要代理对用户意图做出假设。如果这些假设不正确,产生的动作可能偏离用户的实际意图,导致错位行为。因此,识别未充分指定的查询是确保 LLM 代理避免任意承诺某个特定解释,而是在必要时寻求澄清或推迟行动的关键步骤。 ## 3. 错位类型 LLM 代理通过调用工具与外部环境交互。这些工具调用可能产生不可逆或高影响的效果,例如转账、发送电子邮件或修改计算机中的文件。与聊天机器人通常可见且可纠正的错误文本响应不同,错位的工具执行可能在不被用户立即察觉的情况下导致意外后果。在本工作中,我们在工具调用层面定义错位。我们将错位动作分为三种类型。 ##### (1) 工具级错位 第一种类型发生在代理选择的工具与用户查询中的任务无关或不兼容时。 ##### 示例 如图 1 (https://arxiv.org/html/2607.01236#S1.F1)a 所示,当用户要求代理“请求 30 美元”,
相似文章
LLM代理中的忠实不确定性:实践中校准与效用权衡
一位从业者讨论了LLM代理中的校准与效用权衡,分享了基于验证器的流水线经验,该流水线将幻觉工具调用减少了约60%,但引入了延迟成本并丢失了简单的正确答案。
LLM代理的一致性如何?在多步骤工具调用流程中测量行为可重现性
本文系统性地测量了LLM代理在多步骤工具调用流程中的行为可重现性,涉及1140条轨迹,发现了'结构一致性,参数变异性'的模式:代理可靠地按相同顺序选择工具,但参数有所不同,并且结构一致性能够预测任务的成功。
Contract2Tool:学习前提与效果以实现可靠的工具增强型LLM代理
本文介绍了Contract2Tool,一个从工具元数据、文档和执行轨迹中自动推断轻量级工具契约(前提条件、效果、风险)的框架,为LLM代理实现可靠的因果工具过滤。实验表明,学习到的契约在下游多步骤代理任务中达到了接近黄金契约的性能,同时显著减少了token使用量。
低延迟系统中工具制作与自进化LLM代理
本文提出了一种方法,将重复的标准操作流程步骤编译为经过验证、有版本管理的工具,在部署前完成,替代推理时的代码生成。在一个配送中心的报警分类系统中,该方法将p50延迟降低了42%,端到端错误率降低了最多53%。
LLMs中的隐藏潜在状态偏移:为何当前对齐方法对真正的内部危险视而不见——尤其是在智能体场景中
本文证明,LLMs可以在保持对齐输出的同时,在连贯上下文中进入可测量的不同内部潜在状态,揭示了当前仅监控表面token的对齐方法存在盲点。Gemma-3-12B-IT实验显示出强大的残差流几何偏移,现有安全框架无法检测,这对智能体AI部署具有重要影响。