PolicyGuard: 一种基于对话的子代理验证器，用于确保LLM代理遵循策略

TL;DR PolicyGuard 以子代理验证器形式，利用对话上下文与策略自推理，为 LLM 代理提供可执行反馈，提升多轮交互中的策略遵循性，在提高违规召回的同时大幅减少误拦截。

问题

问题背景

LLM agents 通过工具调用代表组织执行用户请求，必须严格遵守系统提示中声明的公司策略。不遵循策略可能导致财务损失、数据泄露或合规风险，因此策略遵守成为 LLM 应用落地的关键安全要求。

现有方法局限

先前工作把策略遵守建模为safeguarding问题，即通过外部检查阻塞不合规的 agent 动作。代表性方法如 ToolGuard 等参数级守卫仅检查单次工具调用的参数值，忽略完整的对话上下文与多轮交互逻辑。具体弱点包括：

• 无法感知前置依赖：例如代理应先读取用户资料才能退款，守卫只看当前调用参数，无法判断是否遗漏前置步骤。
• 无法处理确认式交互：真实流程常需用户显式确认，守卫难以从对话中判定确认是否已发生。
• 仅阻塞不修复：守卫只能拒绝调用，不能生成针对当前对话的修复建议（如“请用户确认金额后再调用”），导致代理陷入重试死循环。
• 对自然语言策略的推理不足：策略常以自然语言编写，需综合理解才可应用，单一参数检查无法覆盖。

难点与重要性

策略遵守的难度在于：对话是时序状态依赖的——同一操作在不同对话时刻可能是合规或违规的；代理需平衡响应及时性与合规严谨性；策略条款之间存在隐含优先级和冲突。业界关注度随 agent 部署增长而急剧上升，例如 OpenAI 的 Preparedness Framework 和各大模型厂商的安全对齐研究均强调 agentic 场景下的运行时安全验证。然而，缺少一种既能利用完整对话上下文、又能提供行动级反馈而非简单阻断的轻量级验证机制。

行业类比

就像自动驾驶需要一名安全驾驶员——不仅识别危险变道，更依据路况、历史轨迹和全局路线给出“减速”“等待行人”等可执行指令，而不是一味急刹；POLICYGUARD 正是为 LLM agents 设计的合规副驾，在维持对话流的同时持续纠正违规倾向。

核心洞察

• 策略遵循应从单步参数检查升级为全对话上下文推理：现有防护方法（如 ToolGuard）仅拦截孤立工具调用中的违规参数值，忽略了多轮对话中的确认、预读和协商等交互步骤。PolicyGuard 将整个对话历史与策略文本一起输入子代理，让其自推理违规点，从而捕获跨轮次、依赖对话内容的复合违规模式。
• 对话特定补救（conversation-specific remediation）是比“直接阻断”更务实的方案：阻断式防护会粗暴终止任务并破坏用户体验，而 PolicyGuard 在检测到违规时输出可操作的反馈指导代理下一轮行为（例如要求补充用户确认或补读必需信息），在保持任务流连贯性的同时修复合规性问题，代价是平均额外增加约 0.3 轮对话。
• 跨厂商模型评估证明策略验证的通用增益：在 GPT-5.4、Claude Sonnet 4.6、Gemini 2.5 Pro 上 PolicyGuard 将 Pass^4 指标分别提升 +12.0 / +6.0 / +12.0 pp，同时违规召回率更高、误拦次数减半。这说明对话根基的策略推理能适应不同底层 LLM 的行为特点，为实际部署提供了模型无关的实施方案。

方法

输入

• 对话上下文：面向用户的 LLM 代理与用户持续多轮交互的完整历史，包含每个工具调用的参数与返回结果。
• 策略文本：系统提示中规定的企业合规策略，如必须获得用户确认、必须先执行读取操作后再写入等。

核心模块：对话扎根子代理验证器 (PolicyGuard)

PolicyGuard 作为一个独立的 子代理验证器，共享主代理的上下文窗口，在代理每次规划动作前介入。其核心设计分为三部分：

1. 验证提示与配对：将策略全文与当前对话历史拼接为一个 prompt，指示 LLM 进行上下文内的 自我推理，输出结构化 YAML（包含合规判定、违规条款、修复建议）。验证器自身无额外训练，完全依赖提示工程。
2. 策略变体：为降低语言模型对长文本策略的理解歧义，原始策略被自动转化为 检查清单 (checklist) 或浓缩摘要，作为验证器 prompt 的输入，提升推理一致性。
3. 实现方式：作为一次额外的 LLM 调用，嵌入主代理的工具调用流水线中，开销可控。验证器既可只读分析当前回合，也可通过预言机方式预判未来多步后果。

输出

• 合规标签：violation 或 ok，并指明违反的具体条款。
• 可行动反馈：针对下一轮的原子指令，例如“要求用户明确确认操作”、“先执行 order_lookup 读取订单信息再修改”，主代理在生成回复或继续动作时需遵循该反馈。

与同类方法的差异

参数级门控（如 ToolGuard）仅检查单次工具调用的孤立参数值，无法感知“跨回合依赖”与“对话语义”的违规。PolicyGuard 通过 全对话上下文扎根 和 策略的显式推理，能够识别需要用户确认、多步前置读取等复杂违规，并提供对话特定的修复指导，而非简单的二进制阻拦，从而在提升违规召回率的同时，将误阻断频率降低约一半。

实验

实验设计

在 τ^2-bench airline 多轮对话基准上测评 PolicyGuard 子代理验证器，集成 GPT-5.4、Claude Sonnet 4.6 和 Gemini 2.5 Pro 三个供应商，每个设置进行 4 次独立试验。主要指标为 PASS4（4 次试验均合规的通过率），辅以每次调用的 策略违规召回率 与 拦截频率，并对比参数级守卫（argument-level guards）的基线。

关键发现

• PASS4 显著提升：在三个供应商上分别取得 +12.0 pp、+6.0 pp、+12.0 pp 的绝对提升，证明 PolicyGuard 跨模型泛化有效。
• 更高召回率，更低误拦截：逐调用分析显示，相比参数级守卫，PolicyGuard 在检测策略违规时 召回率更高，同时拦截次数 约减少一半，表明其利用完整对话上下文和自我推理能减少误报。
• 消融实验证实：对话基础 是因果性关键（移除后性能骤降），而 策略文本 仅起增强作用，说明方法的核心价值在于对话级推理而非简单文本注入。

与基线对比的深度解读

传统参数级守卫独立检查单个工具参数值，缺乏对对话历史的把握，常导致 过度拦截 或 漏检。PolicyGuard 以子代理形式共享完整对话视图，对当前对话 自我推理 并生成针对性的 对话级修复指导，使主代理的下一回合动作直接对齐策略。这种 "验证-反馈" 闭环使合规检查从静态阻断转向动态协同，对多轮、多前提的真实工作流更具工程实用性。在 违规召回与误拦截的权衡 上，PolicyGuard 同时优于参数级守卫，证明对话上下文与策略上下文联合推理是更优的架构选择。

行业影响

落地场景

PolicyGuard 面向多轮对话中需严格遵循业务规则的 LLM 代理，典型的落地场景包括：航空客服（退改签需核对票价规则、行李政策）、金融顾问（贷款申请必须执行合规流程）、电信客服（套餐变更需确认合约条款）、电商售后（退换货需判别时间窗口与凭证有效性）。这些场景的共同特征是代理决策依赖完整对话上下文，而非单一参数，PolicyGuard 的对话接地推理与即时修复机制可让代理动态规避违规。

商业价值

PolicyGuard 将策略违规处理从“直接拦截”转变为“引导修复”，从而提升自动化任务完成率（如 PASS^4 指标在多供应商平均提升约 +10 pp）。它降低了因违规操作导致的直接成本（罚款、退款）与间接成本（人工审核介入、品牌声誉损害），并减少了对高敏感场景的人工监督依赖。更流畅的合规体验还能提高用户对自助服务的信任与采纳意愿。

与现有产品/工作流的接口

PolicyGuard 作为子代理验证器可嵌入现有 LLM 编排框架（例如 LangChain、AutoGen 或自建工作流引擎）。它在代理输出动作前，消费系统策略文本与对话历史，生成合规判定及动作修正建议。集成形态类似中间件，与现有参数级 guardrails（如 NeMo Guardrails）互补：后者执行粗粒度拦截，PolicyGuard 提供对话级上下文推理与修复指导，两者可叠加使用。策略配置采用 YAML 声明式描述，降低定制成本。

具体落地 use case

• 机票预订与售后：用户要求修改含特殊字符的预订姓名，代理须先执行姓名验证读取；PolicyGuard 可检测遗漏并提示代理先完成该步骤，避免后续信息错配。
• 金融开户咨询：代理辅助用户开户，需遵循 KYC（了解你的客户）及 AML（反洗钱）政策，PolicyGuard 确保代理在对话中按要求收集身份文件、确认风险披露声明，并在遗漏时给予补全指引，防止合规缺口。

局限

• **评估范围受限且泛化性未验证**：论文仅在 `tau^2-bench` 的航空场景下测试，且只针对 GPT-5.4、Claude Sonnet 4.6、Gemini 2.5 Pro 三个具体模型版本，结论无法直接推广到其他领域（如零售、电信仅做简要审计）或不同模型版本。检查表生成流程依赖单供应商策略模板，面对多供应商或动态更新的策略时可能失效。作者在结论中也指出评估范围、单供应商检查表生成是主要局限，并提及触发成本与概率性执行等工程问题尚待解决。
• **验证器本身依赖 LLM 推理，引入额外成本与不确定性**：PolicyGuard 通过子代理 LLM 调用实现策略推理，每次对话回合都需要额外的 API 请求，显著增加了延迟和开销，不适合对实时性要求极高的生产环境。其判断准确率受限于底层 LLM 的能力，对模糊策略或需深层语义理解的情况可能产生误报或漏报。提示工程与检查表的有效性同领域强绑定，迁移到新领域需要重新设计，缺乏自适应或自动化的策略解析机制。
• **相比参数级守卫，工程代价更高且未突破形式化边界**：参数级守卫（如 ToolGuard）仅检查单个 API 参数值，计算轻量且易于部署；PolicyGuard 虽在违反召回率上更优，但需要维护完整的对话上下文和多步推理，计算复杂度和存储开销更大。该方法本质上仍是基于 LLM 的软验证，没有引入形式化方法或确定性的对话状态跟踪，对于需要严格控制的关键任务，其概率性执行和潜在的对抗样本脆弱性（论文已初步探测）可能成为安全隐患。