💬 NLP

Safeguarding LLM Agents from Misalignment through Provenance Analysis

本文介绍了 ProvenanceGuard，这是一个基于溯源的框架，通过将工具调用与智能体上下文中的可追溯证据进行校验，与传统的 LLM-as-a-judge 基准相比，显著提高了对 LLM 智能体失调的检测能力并减少了误干预。

原作者： Yining She, Yiliang Liang, Eunsuk Kang

发布于 2026-07-03

📖 1 分钟阅读☕ 轻松阅读

原作者： Yining She, Yiliang Liang, Eunsuk Kang

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

想象一下，你雇佣了一位非常聪明、充满干劲的私人助理（一个 LLM Agent/大语言模型智能体）来协助处理日常任务。你告诉他：“请向 Daniel 要 30 美元。”由于这个助理与现实世界相连，他实际上可以发送电子邮件、转账或修改文件。

问题在于，这个助理有时过于积极，或者产生了误解。他可能没有按照你的要求去“要”钱，而是不小心把钱“汇”给了 Daniel。或者，他可能会在没有提到相关指令的情况下擅自支付一笔账单。这被称为对齐失调（misalignment）：助理执行的操作在技术上遵循了规则，但违背了你的真实意图。

这篇论文介绍了一种名为 ProvenanceGuard 的新型安全系统，旨在在错误发生前将其拦截。以下是其工作原理的简易说明：

核心理念：寻找“纸质凭证”的侦探

作者意识到，现有的安全系统就像是一个老板仅仅询问第二个同样困惑的助理：“这是一个好主意吗？”这往往会导致回答不一致。

相反，ProvenanceGuard 扮演的是一名法医侦探的角色。它不只是靠猜测，而是要求提供纸质凭证（provenance）。它会追问：“你能向我展示，是在我们对话中的哪一段，或者在哪些指令中，你找到了执行这项特定操作的具体证据吗？”

如果助理无法指出你请求中的特定句子或之前的某个事实来证明该行为的合理性，系统就会拦截该操作。

三类错误

论文将“坏主意”分为三类，并使用侦探的清单进行检查：

工具错误（工具级 - Tool-Level）：
- 场景： 你说“请求款项”。助理却尝试使用“发送款项”工具。
- 侦探检查： “这个工具匹配这项工作吗？”系统会检查工具的使用手册和你的请求。如果工具的功能描述与工作不符，操作将被拦截。
细节错误（参数级 - Parameter-Level）：
- 场景： 你说“给 Daniel 发送 30 美元”。助理使用了正确的工具，但因为猜错了名字，把钱发给了 Sarah。
- 侦探检查： “你是从哪里得到‘Sarah’这个名字的？”如果助理无法在对话中指出任何提到“Sarah”的事实，系统会判定：“未发现证据。停止。”
盲目猜测（解释级 - Interpretation-Level）：
- 场景： 你说“处理这个请求”，但没有说明具体如何处理。助理决定自动支付一笔账单。
- 侦探检查： “这是唯一的处理方式吗？”系统意识到你的请求很模糊。由于“处理”有多种解释方式（支付、拒绝或询问你），助理正在进行盲目猜测。系统会拦截该动作，并强制助理向你寻求澄清。

系统运作方式（三阶段流水线）

ProvenanceGuard 不是一个单一的问题，而是一个动作在发生前必须通过的三步安全检查站：

检查点 1（工具）： “这是这项工作的正确工具吗？”如果不是，停止。
检查点 2（细节）： “对于你使用的具体数字或名称，你有证据吗？”如果没有，停止。
检查点 3（解释）： “这是唯一的逻辑做法，还是存在其他可能性？”如果存在其他可能性，系统会认定助理在进行猜测，并停止以请求帮助。

结果：更聪明且更少干扰

作者使用两个不同的测试场景，针对 10 种不同的“大脑”模型（LLMs）对该系统进行了测试。

更少的错误： 与旧方法（仅询问第二个 AI“这是否可以”）相比，ProvenanceGuard 拦截了几乎所有的错误行为。在一项测试中，它将错误率从 43% 降低到了 2%。
更少的干扰： 一个拦截所有内容的安全性系统是毫无用处的，因为它会阻止助理完成任何有益的工作。作者发现 ProvenanceGuard 非常擅长让正确的操作通过。它不会阻碍成功任务的完成，不像其他一些方法会过度拦截正常的动作。

总结

这篇论文提出，与其猜测 AI 智能体是否在做正确的事，不如要求它证明自己。通过要求智能体展示将其行为与你实际请求联系起来的“纸质凭证”，我们可以阻止它犯下危险且不可逆的错误（如发送资金或删除文件），同时又不会减慢它本应完成的有益工作。

注：本文严格专注于防止软件智能体中出现的此类误解。它并不声称解决了所有的 AI 安全问题，也未讨论医疗或临床应用。

技术摘要：通过溯源分析保障 LLM 智能体的对齐安全性

问题陈述

随着大语言模型（LLM）智能体从对话助手演变为能够执行不可逆操作（例如转账、修改文件）的自主系统，确保其行为与用户意图对齐变得至关重要。本文将**失配（misalignment）**定义为一种现象，即智能体提出的工具调用偏离了用户意图，这并不一定源于恶意意图，而是由于对用户请求的误解或不合理的假设。

现有的运行时护栏通常依赖于**“LLM 作为评判者（LLM-as-a-judge）”**范式，即使用单个 LLM 提示词来评估是否允许某项操作。作者认为，这种方法缺乏一个系统的推理对齐框架，导致判断不一致、理由主观且难以审计。此外，传统的安全措施（如沙箱机制）仅限于限制后果，而非防止最初的失配行为发生；而事后验证也无法撤销已执行的不可逆工具调用。

方法论

1. 概念框架：基于溯源的护栏

受溯源分析（provenance analysis，研究人工制品的起源及衍生历史）的启发，作者提出了一个框架：只有当一项操作由其上下文中的可追溯证据支持时，才被视为是对齐的。该上下文包括用户查询 ( $q$ )、工具文档 ( $d$ ) 和交互历史 ( $h$ )。

该框架通过将失配归类为三种不同的类型来形式化失配检测，每种类型都对应于在建立特定溯源关系方面的失败：

工具级失配（Tool-Level Misalignment）： 智能体选择了一个与任务无关的工具。
- 溯源检查： 所选工具 ( $t$ ) 的文档 ( $d_t$ ) 是否与子任务 ( $s$ ) 相关（RelevantTo），且该子任务是否**有助于（ContributesTo）**用户查询 ( $q$ )？
参数级失配（Parameter-Level Misalignment）： 智能体选择了正确的工具，但分配的参数并非基于上下文。
- 溯源检查： 参数赋值 ( $a$ ) 是否可以从查询或历史中的事实证据 ( $e$ ) 中**衍生（DerivedFrom）而来？此外，实例化的工具（带有参数 $a$ 的工具 $t$ ）是否能够处理（CanAddress）**该子任务 ( $s$ )？
- 注：框架区分了可衍生参数（需要溯源）和生成式参数（例如起草邮件正文，不需要直接的溯源追踪）。
解释级失配（Interpretation-Level Misalignment）： 当存在多种合理的解释时，智能体在未进行澄清的情况下，武断地采纳了一种解释来解决不明确的查询。
- 溯源检查： 提议的操作是否是上下文中唯一符合溯源要求的候选方案？如果多个不同的操作均受上下文支持，则说明查询是不明确的，在未进行澄清的情况下直接提交其中之一即属于失配。

2. 实现：ProvenanceGuard

作者将该框架实现为 ProvenanceGuard，这是一个拦截工具调用并在执行前进行处理的多阶段运行时流水线。与单步式的“LLM 作为评判者”不同，ProvenanceGuard 将决策分解为三个连续阶段：

第一阶段（工具级）： 过滤环境变更类工具，并验证所选工具是否与智能体当前的子任务计划相关。
第二阶段（参数级）： 识别哪些参数是可衍生的，并验证其值是否可以追溯到上下文，以及它们是否正确地实例化了用于该子任务的工具。
第三阶段（解释级）： 询问 LLM（不透露智能体已选定的操作以避免偏差）是否存在其他符合溯源要求的操作。如果存在多个候选方案，则该操作将被拦截，因为它依赖于未经证实的假设。

该系统利用 LLM 来评估特定的溯源关系（如 RelevantTo、DerivedFrom），但其构建的推理过程比整体性的提示词更加显式且可审计。

核心贡献

失配分类法： 建立了工具级、参数级和解释级失配的正式区分。
基于溯源的框架： 一个概念模型，将对齐检查框架化为确定工具调用是否基于可追溯证据的过程，并通过特定的二元关系进行形式化。
ProvenanceGuard： 该框架的一个多阶段流水线实现，作为运行时护栏运行。
基准测试： 在两个基准测试（Agent-SafetyBench 和 WorkBench）以及包括 Agent-SafetyBench 手动标注轨迹在内的 10 个骨干 LLM 上进行了评估。

实验结果

作者将 ProvenanceGuard 与 DirectPrompt 基线（标准的 LLM 作为评判者）和 单步溯源提示（ProvePrompt，在单次传递中使用框架概念） 进行了对比评估。

失配检测（错误率）：
- 在 Agent-SafetyBench（侧重于不确定性问题）上，ProvenanceGuard 将失配轨迹的错误率从 42.9%（基线）降低到了 1.8%。
- 在 WorkBench 上，错误率从 32.1% 降至 17.3%。
- 多阶段设计（ProvenanceGuard）始终优于单步变体（ProvePrompt），尤其是在 Agent-SafetyBench 上，这表明了分解推理过程的价值。
干预成本（误报/不必要的干预）：
- 在 Agent-SafetyBench（对齐轨迹）上，与基线相比，ProvenanceGuard 未引入统计学意义上显著的不必要干预增加。
- 在 WorkBench（任务成功轨迹）上，ProvenanceGuard 将干预率从 30.5%（基线）显著降低至 12.8%，表明它在允许正确操作继续执行方面比基线更精确。

意义与主张

本文声称，结构化的、基于溯源的推理为保障 LLM 智能体提供了一个有效且实用的基础。其意义在于：

系统化推理： 从主观的、整体性的判断转向基于动作与上下文之间显式、可审计依赖关系的框架。
处理不确定性： 该框架专门解决了智能体在面对不明确查询时做出未经证实的假设这一风险，而这正是标准安全过滤器经常遗漏的失配原因。
平衡性能： 多阶段方法在实现高精度检测失配行为的同时，并未在阻断有效的、成功的智能体任务方面产生过高的代价。

作者总结道，虽然该框架无法检测纯生成式参数（如自由文本生成）中的失配，且依赖于智能体自身的计划（该计划理论上可能也是失配的），但它为防止智能体系统中发生不可逆且脱离上下文的动作提供了一种鲁棒的机制。