PolicyGuard:基于对话的子代理验证器,用于保障LLM代理的政策合规性 PolicyGuard: A Dialogue-Grounded Sub-Agent Verifier for Policy Adherence in LLM Agents
提出对话感知验证器,解决LLM代理流程政策遵循问题,在航空任务提升PASS4达12个百分点
前置知识
LLM Agent(大语言模型代理)
LLM Agent是能够自主规划、调用工具并执行多轮对话的智能系统。典型的架构是ReAct范式,模型通过reasoning产生动作,通过acting调用外部工具,如搜索航班、预订、修改订单等API调用。Agent的核心能力是理解用户意图、拆解任务、在多轮对话中维护状态,并通过工具调用与真实环境交互来完成任务。工具调用分为只读调用和变更调用,后者需要严格的合规性控制。只读调用如搜索航班、查询用户详情,变更调用如预订、取消、修改订单。变更调用直接影响环境状态,如果违反政策可能导致企业损失或法律风险。
本文研究的问题直接依赖于LLM Agent的工作机制。Agent通过工具调用执行实际操作,这些操作必须遵守组织的政策文档。理解Agent如何调用工具、如何与用户多轮交互,以及政策检查在工具调用循环中的位置,是理解POLICYGUARD方法的基础。POLICYGUARD在Agent和Environment之间插入Verifier,拦截所有变更调用进行验证,这种架构假设理解了Agent的工具调用机制和对话循环。
政策合规性验证
政策合规性验证是指确保AI代理的行为符合组织制定的政策文档。公司政策通常是一个多页面的规则手册,规定了Agent在执行每个变更操作前必须验证的前置条件、必须提供的服务选项以及必须获得的用户确认。例如航空政策可能规定:预订前必须搜索航班、提供保险选项、列出完整预订摘要并获得用户明确同意;退款前必须验证身份、确认取消原因、计算补偿金额。验证失败会导致企业损失、法律风险或监管处罚。政策通常分为全局规则和per-tool规则,per-tool规则又分为约束(硬规则,如最多5名乘客)和要求(命名项目,如obtain_user_id、offer_insurance)。
这是本文的核心研究问题。与安全防护不同,政策合规性关注的是流程层面的正确性,即Agent是否按政策要求的步骤执行,而非内容是否有害。理解这一区别有助于理解POLICYGUARD与现有安全工具的不同定位。安全防护如Llama Guard针对有害内容分类,而政策合规性针对流程步骤的完整性。本文识别出政策验证需要三个核心能力,现有工具最多具备其中一两个,POLICYGUARD是第一个同时具备三个能力的系统。
流程级验证vs参数级验证
参数级验证只检查工具调用的参数值是否满足预定义规则,如年龄是否大于18、金额是否在合法范围内、舱位等级是否一致。这类验证可以通过Python代码、SMT公式或规则引擎在运行时快速完成,因为所需信息都包含在工具调用的参数中。流程级验证则需要检查对话历史或前置工具调用的结果,例如用户是否在看到完整预订摘要后确认了预订、Agent是否在退款前调用了get_user_details验证身份、Agent是否在取消前确认了取消原因。这类验证无法从单次工具调用的参数中判断,必须理解开放式的自然语言对话。论文中统计,τ 2-BENCH-airline政策的67.4%即29/43项要求是流程级的。
这是本文的核心洞见。现有工具如TOOLGUARD、SOLVER-AIDED只能做参数级验证,但真实企业政策的主体是流程级要求。理解这一区别就能理解为什么POLICYGUARD需要读取完整对话,以及为什么它在两个-thirds的政策空间上有独特优势。论文作者通过手工分类航空政策文档的43个原子要求,发现29个是流程级需要对话或前置工具调用的,只有14个是参数级可以从工具参数判断的。这意味着TOOLGUARD等参数级守卫在理论上无法满足67.4%的政策要求。
τ 2-BENCH评测基准
τ 2-BENCH是评估对话式Agent能力的基准测试,包含航空、零售、电信三个领域,每个领域有50个任务。任务分为PV和Mut两类。PV任务是policy-violating任务,用户请求违反政策,正确的Agent行为是拒绝该请求,例如要求为已起飞航班退款、要求为不存在的乘客预订。Mut任务是mutation-required任务,用户请求合法但Agent必须在满足所有前置条件后执行变更操作,例如预订航班、修改乘客信息、申请退款。Agent使用工具调用与模拟环境交互,环境检查数据库状态和自然语言断言来判定任务成功。关键指标是PASS4即在4次独立试验中都成功的任务比例,衡量Agent在最坏情况下的可靠性。PASS1是单次试验平均成功率,PASS2到PASS4反映稳定性。
本文的主要实验在τ 2-BENCH-airline上进行。理解任务类型PV和Mut的区别、指标PASS4和PASS1的含义以及模拟环境的工作方式,才能理解POLICYGUARD的实验设计和结果解读。论文报告PASS4作为headline指标,因为它衡量最坏情况下的可靠性,这对企业部署至关重要。同时论文还报告PV和Mut两个轴的PASS4,展示POLICYGUARD在两个轴上的表现,确保没有牺牲任一轴来提升整体PASS4。PG-CHECKLIST是唯一在三个Agent上都不降低任何单一政策轴且提升整体PASS4的配置。
研究动机
现有LLM代理政策遵循方法存在根本性缺陷。前沿的ReAct代理在τ 2-BENCH-airline上的PASS4性能严重不足:GPT 5.4仅46%,Claude Sonnet 4.6仅72%,错误覆盖了两大类型,即拒绝任务和变更任务。拒绝任务要求Agent识别并阻止违规用户请求,但Agent可能错误地执行了如为已起飞航班退款、为不存在的乘客预订。变更任务要求Agent在满足所有前置条件后执行操作,但Agent可能跳过了如未验证身份就发布退款、未提供保险选项就预订航班、未获得用户确认就修改订单。这些失败不是内容安全问题,用户是诚实的、Agent也是诚实的,而是流程层面的政策违规。现有解决方案如TOOLGUARD只能做参数级验证,检查工具调用的参数是否满足预定义规则,但论文分析显示航空政策的67.4%是流程级要求,需要检查对话历史或前置工具调用结果,这是参数级守卫根本无法处理的。
本文的目标是本文的目标是解决LLM代理遵循公司流程政策的问题,特别是那些无法从单个工具调用参数中判断的流程级合规要求。作者希望构建一个验证系统,能够读取完整的Agent和用户对话上下文,基于政策文档进行自我推理,而不是依赖预编译规则,以及在阻止操作时提供具体可执行的补救消息指导Agent下一步该做什么,而不是返回静态错误。该系统需要在三个前沿模型上提升PASS4,且不降低任何单一政策轴的性能。具体指标目标是提升PV拒绝召回到100%,同时保持或提升Mut变更任务的成功率。作者希望证明POLICYGUARD是唯一同时具备对话感知、自我推理、行为驱动补救三个能力的系统,且在三个Agent上都有效。
与已有工作不同的是,本文的独特切入角度是将政策合规性视为一个与安全防护不同的问题。安全防护假设存在恶意用户,失败模式是有害内容或恶意参数,例如仇恨言论、暴力内容、prompt injection攻击。政策合规性假设各方都是诚实的,失败模式是跳过了流程步骤,如未验证身份、未获得确认、未提供必需选项。现有工作如Llama Guard、Constitutional AI、TOOLGUARD都针对安全防护,无法处理流程级要求。更关键的是,作者识别出政策验证需要三个核心能力,即对话感知、自我推理、行为驱动补救,且没有任何现有系统同时具备这三个能力。PCAS最接近但需要手动将自然语言政策转换为脆弱的关键词匹配,TOOLGUARD效率高但对参数级守卫无法访问对话历史。POLICYGUARD填补了这个空白,是第一个同时具备这三个能力的系统。
核心方法
POLICYGUARD在Agent和Environment之间的工具调用循环中插入一个Verifier子代理。每次Agent尝试调用变更工具时,该调用会被拦截并路由到Verifier,而不是直接执行。Verifier读取完整的Agent和用户对话历史,和Agent看到的一样,以及原始政策文档和为该工具生成的检查清单。Verifier对每个要求进行评估,返回PASS或BLOCK verdict。如果是BLOCK,返回一个具体可执行的补救消息,该消息被包装成ToolMessage并返回给Agent,Agent可以据此修正行为。只读调用绕过Verifier,无验证成本。方法分为两个阶段,离线阶段用四步LLM管道从原始政策生成per-tool清单,在线阶段在每个变更调用上进行验证。离线阶段包括工具分类、Per-tool YAML生成、通用规则生成和审查通过四个步骤,生成每个变更工具的YAML文件包含约束和要求。在线阶段Verifier接收三个输入,即pending action、政策规范、格式化的消息历史,输出per-requirement列表和verdict。
核心创新点是同时提供对话感知、自我推理、行为驱动补救三个能力。对话感知意味着Verifier读取完整的Agent和用户对话,包括自然语言回合和工具调用历史,这使得它能够判断流程级要求,如用户是否在看到摘要后确认。自我推理意味着Verifier是LLM,能够在对话上下文中对政策进行推理,而不是依赖预编译规则。行为驱动补救意味着BLOCK消息不是静态错误,而是根据对话内容生成的具体指导,如你需要先提供保险选项,然后询问用户确认。与TOOLGUARD等参数级守卫不同,POLICYGUARD能够处理流程级政策,且补救机制允许Agent在同一轮次中恢复,而不是盲目重试。另一个关键创新是政策规范结合原始政策文本和LLM生成的per-tool清单,清单提供焦点,原始政策保留权威性。清单采用advisory而非strict verdict,避免过度阻塞,因为单个NOT MET不会自动强制BLOCK如果在上下文中不适用。
方法步骤详情
方法分为离线和在线两个阶段。离线阶段执行一次,包括四个步骤。第一步是工具分类,LLM将工具注册表分为变更和只读两类,变更工具会在运行时路由到Verifier,只读工具绕过Verifier。第二步是Per-tool YAML生成,对每个变更工具,LLM生成YAML文件,包含约束和要求。约束是硬规则,如最多5名乘客、不能预订已起飞航班,要求是命名项目,如obtain_user_id、offer_insurance、user_confirmation。每个要求有验证提示和类型标记,数据验证需要引用特定只读工具,流程验证需要引用对话谓词。第三步是通用规则,单个general_rules.yaml捕获跨工具规则,如每次会话验证一次身份、对话规范、转移规则。第四步是审查通过,审查者LLM检查每个生成的YAML,根据源政策文本捕捉遗漏或过度规范,进行内联编辑。在线阶段在每个变更调用上执行,Verifier接收pending action、政策规范和格式化的消息历史,输出per-requirement列表和verdict。如果是PASS,环境执行调用。如果是BLOCK,弹出AssistantMessage并路由ToolMessage给Agent。
技术新颖性
技术新颖性体现在多个方面。这是第一个将政策合规性定义为与安全防护不同问题的工作,明确区分了恶意用户加内容有害与诚实用户加流程错误的失败模式。Verifier的输入设计很独特,同时使用原始政策文本和LLM生成的per-tool清单,清单提供焦点,原始政策保留权威性。清单采用advisory而非strict verdict,避免过度阻塞。Verifier采用paired-verifier协议,Verifier模型与Agent同厂商同层级,确保性能差异归因于方法而非更强的Verifier。实现采用orchestrator patch,在Agent到Env转换处拦截,BLOCK时弹出AssistantMessage并路由ToolMessage给Agent,使从未发生成为轨迹的语义。评估方法也很新颖,引入verdict view和runtime view,区分Verifier决定和Agent实际执行。轨迹成本分析使用agent加user turn而非消息总长度,更准确地反映用户体验成本。实验设计包括三个关键ablation,对话ablation证明对话是causal输入,政策文本ablation证明政策文本是augmenting而非causal,小规模ablation探索cost tradeoff和weak agent transfer。
实验结果
实验在τ 2-BENCH-airline上进行,包含50个任务,其中24个PV拒绝任务和26个Mut变更任务,每个设置进行4次试验。PG-CHECKLIST是唯一在三个Agent上都不降低任何单一政策轴且提升整体PASS4的配置。在GPT 5.4上,PASS4从0.460提升到0.580即提升12.0个百分点,PV拒绝从0.750提升到1.000即24个任务全部完美拒绝,Mut执行保持在0.192。在Sonnet 4.6上,PASS4从0.720提升到0.780即提升6.0个百分点,PV拒绝从0.958提升到1.000,Mut执行从0.500提升到0.577。在Gemini 2.5 Pro上,PASS4从0.480提升到0.600即提升12.0个百分点,PV拒绝从0.750提升到1.000,Mut执行从0.231保持不变。TOOLGUARD在GPT 5.4上有提升即提升6.0个百分点但在Sonnet 4.6和Gemini 2.5 Pro上严重退化即分别下降14.0和4.0个百分点,因为对强代理的合法变更过度阻塞是净成本。PG-CHECKLIST的Mut PASS4达到substrate ceiling,这是在没有流程级验证的情况下仅靠系统提示指令能达到的上限。Per-call分析显示PG-CHECKLIST有最高的政策违规召回率,且阻塞频率只有TOOLGUARD的一半。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 航空客服任务(τ 2-BENCH-airline) | PASS4即四试全通过率 | 0.580在GPT 5.4上,0.780在Sonnet 4.6上,0.600在Gemini 2.5 Pro上 | 0.460在GPT 5.4上,0.720在Sonnet 4.6上,0.480在Gemini 2.5 Pro上 | 提升12.0个百分点在GPT 5.4和Gemini 2.5 Pro上,提升6.0个百分点在Sonnet 4.6上 |
| 政策违规拒绝(PV任务) | PASS4召回率 | 1.000即100%在三个Agent上都达到完美 | 0.750在GPT 5.4和Gemini 2.5 Pro上,0.958在Sonnet 4.6上 | 提升0.250在GPT 5.4和Gemini 2.5 Pro上,提升0.042在Sonnet 4.6上 |
| 变更任务执行(Mut任务) | PASS4成功率 | 0.192在GPT 5.4上,0.577在Sonnet 4.6上,0.231在Gemini 2.5 Pro上 | 0.192在GPT 5.4上,0.500在Sonnet 4.6上,0.231在Gemini 2.5 Pro上 | 无退化即0在GPT 5.4和Gemini 2.5 Pro上,提升0.077在Sonnet 4.6上 |
| 每调用政策违规召回 | PV召回率即TP除以TP加FN | 100%在GPT 5.4上,75%在Sonnet 4.6上,94.7%在Gemini 2.5 Pro上 | 80.0%在GPT 5.4上,66.7%在Sonnet 4.6上,31.2%在Gemini 2.5 Pro上 | 提升20.0个百分点在GPT 5.4上,提升8.3个百分点在Sonnet 4.6上,提升63.5个百分点在Gemini 2.5 Pro上 |
| 阻塞频率 | Block rate即阻塞尝试数除以总尝试数 | 44.1%在GPT 5.4上,37.1%在Sonnet 4.6上,57.8%在Gemini 2.5 Pro上 | 59.0%在GPT 5.4上即PG-RAW,13.7%在Sonnet 4.6上,37.5%在Gemini 2.5 Pro上 | 比TOOLGUARD低约一半,阻塞频率更低意味着更精准验证 |
局限与改进
作者承认多个局限性。评估范围方面,仅在τ 2-BENCH-airline上评估,这是唯一结合书面公司政策和多轮对话前置条件的τ 2-BENCH领域。其他Agent基准不适合此研究,如WebArena和CRMArena没有书面政策或多轮合规表面,GUARDAGENT和SHIELDAGENT针对不同威胁模型。推广到临床合规、法律合规等需要流程级验证的领域以及非英语对话尚未研究。单厂商清单生成方面,per-tool清单由GPT 5.4一次性生成并跨三个Agent重用,在Gemini 2.5 Pro上Verifier读取清单更字面化,对Mut PASS4有可测量成本。per-Agent重新生成可能会缩小差距,但作者故意固定substrate以使跨厂商差异归因于Agent加Verifier。触发和成本方面,POLICYGUARD继承TOOLGUARD的预执行触发,只对变更工具触发,只读调用和口头承诺不被限制。per-turn或per-policy-section触发会扩大覆盖范围但增加Verifier调用。概率性强制方面,POLICYGUARD是LLM验证器,24除以24 PV召回是经验性的非可证明的。需要形式保证的领域如药物警戒和安全关键控制超出范围。对抗鲁棒性方面,LLM验证器读取与Agent相同的用户供应内容,因此间接prompt注入攻击的目标。作者在实验中探测了三种超出范围的攻击,综合覆盖仍是未来工作。
独立分析的弱点
独立分析的弱点包括多个方面。单厂商清单生成在不同Agent间表现不一致,Gemini 2.5 Pro上Verifier更字面地读取清单导致性能下降,改进方向是per-Agent清单重新生成或清单风格自适应。预执行触发无法覆盖只读调用后的口头承诺,Agent可能承诺退款但不调用工具,改进方向是增加per-turn触发或承诺检测模块。对间接prompt注入防御有限,A3攻击通过工具响应注入SYSTEM NOTE绕过只信任工具结果规则,改进方向是增强工具响应的字段级验证。跨域泛化未充分验证,零售领域Agent主要是对话指导而非事务执行,电信领域工具在用户设备上Agent无法调用,改进方向是domain-aware验证策略或流程级跟踪的更通用形式。Verifier cost虽然较低,PG-CHECKLIST相比Baseline每个试验增加0.35到0.80美元,但仍在累积,改进方向是轻量级Verifier模型或异步验证管道。Per-call PV召回在不同Agent间差异较大,Sonnet 4.6上只有75%,原因是Sonnet 4.6倾向于upstream拒绝导致denominator小,改进方向是调整Verifier prompt以处理Agent提前拒绝的情况。
未来方向
未来研究方向包括多个方面。作者提出的方向包括全面对抗鲁棒性评估,如CRAFT、tau-break、多turn梯度攻击、跨厂商攻击。推广到临床合规、法律合规等需要流程级验证的领域。非英语对话的政策遵循研究。形式方法配对,对需要可证明保证的子集使用确定性监视器。基于成果可延伸的方向包括per-Agent自适应清单生成,为每个Agent定制清单风格和详细程度。承诺检测模块,验证Agent的口头承诺是否被兑现,如Agent承诺退款但未调用工具。多层级验证,快速参数级守卫加慢速流程级Verifier,在参数级守卫捕获明显违规的同时让Verifier处理复杂流程。解释生成,向最终用户解释为什么被阻止,提高透明度和用户体验。政策版本管理,政策变更时的热更新机制,无需重新生成清单。跨Agent验证,多个Agent协作时的全局一致性检查,确保不同Agent的操作符合统一政策。从单验证器到验证器集群,不同Verifier专攻不同政策片段,用voting或meta-verifier协调决策。
复现评估
复现评估方面,作者承诺发布Verifier、per-tool清单生成管道及其所有step级别提示、推理时Verifier提示、以及论文每个headline cell使用的LLM生成航空清单,连同三个配置的runner代码和cell级别配置文件。预期用途是复现headline配置即paired-verifier协议和per-tool清单一次性生成并跨厂商重用,以及支持在不同领域、Agent或生成模型上的后续工作。论文提供了详细的附录包含所有提示模板、YAML schema、orchestrator patch伪代码、统计显著性测试、每试方差、混淆矩阵、运行时统计、隐藏只读调用分析、跨域审计、复现指南、测量成本、对抗鲁棒性payload和讨论。per-trial PASS1方差报告显示PG-CHECKLIST在每个Agent上有最低或并列最低的std,反映cross-trial一致性机制。总测量花费约680美元,涵盖跨厂商主结果、对话ablation、政策文本ablation、小规模ablation和零售电信审计。唯一未开源的是实际使用的LLM API keys,但所有配置固定且种子固定,给定相同API keys应能复现。论文还提供了per-call verdict confusion matrix、trajectory cost analysis、call-level near-miss rate等细粒度分析,帮助理解POLICYGUARD的行为机制。
论文图表
这张图展示了POLICYGUARD的整体架构和与现有方法的对比。左侧对比了安全防护和政策合规性两个问题的范围,它们只在拒绝和身份检查上重叠,而流程级要求如同意、前置读取、摘要、排序占τ 2-BENCH-airline要求的约三分之二,位于安全防护范围之外。中间展示现有守卫如TOOLGUARD仅从工具调用决定PASS或BLOCK,对话对他们不可见。右侧展示POLICYGUARD是一个子代理验证器,读取完整对话,在上下文中推理政策,返回特定于对话的补救消息。图中间用例子说明,用户要求预订JFK到LAX的10am航班,Agent找到320美元座位准备预订,现有守卫只看到tool call而不知道没有提供保险选项和用户确认,POLICYGUARD读取完整对话后BLOCK并返回提供保险选项然后询问用户确认。
这张图对理解论文至关重要,因为它清晰定义了POLICYGUARD解决的问题即流程级政策合规性,而不是安全防护。展示了与现有方法的根本区别即对话感知vs对话盲区。用具体例子说明了POLICYGUARD的工作方式和补救机制。这是论文的核心贡献可视化,帮助读者快速理解POLICYGUARD的定位和价值。