PolicyBank：为LLM智能体演进策略理解

# PolicyBank: 为 LLM 智能体演化策略理解
来源: https://arxiv.org/html/2604.15505

redacted\correspondingauthorjihye@cs\.wisc\.edu, jinsungyoon@google\.com

Jinsung YoonGoogle CloudLong T\. LeGoogle CloudSomesh JhaUniversity of Wisconsin\-MadisonTomas PfisterGoogle Cloud

###### 摘要

在组织策略下运营的 LLM 智能体必须遵守通常以自然语言指定的授权约束。在实践中，这类规范不可避免地包含歧义、逻辑或语义缺陷，导致智能体的行为系统性地偏离真实需求。我们的问题是：通过让智能体在部署前测试中通过交互和纠正反馈来**演化**其策略理解，能否自主地完善其解释以弥补规范缺陷？我们提出了 PolicyBank，一种维护结构化、工具级别策略洞察并迭代精化它们的内存机制——与将策略视为不可变真实来源、强化"符合但错误"行为的现有内存机制不同。我们还通过在流行的工具调用基准上扩展受控策略缺陷来贡献一个系统性测试平台，这隔离了对齐失败与执行失败。虽然现有内存机制在策略缺陷场景上的成功率接近零，但 PolicyBank 可将多达 82% 的缺陷缩小到人类预言机的程度。

## 1 介绍

随着大型语言模型 (LLM) 智能体在生产环境中发挥越来越重要的作用，它们被越来越多地委以通过外部工具执行复杂工作流的职责，同时在严格的行为边界内运营。其行为受到**策略**（例如企业规则、监管约束和业务逻辑）的管理，这些通常由领域专家以自然语言 (NL) 指定。例如，航空公司客户服务智能体不仅必须修改航班（即，所请求的任务），而且必须严格按照"如果航班延迟且客户请求修改，则提供 50 美元赔偿"等策略进行。

参见图 1：演化策略理解。标准智能体将书面策略 (π_spec) 视为不可变指令，当规范偏离真实需求 (π_req) 时导致系统性失败。PolicyBank 使用任务轨迹和开发者反馈迭代精化智能体的策略解释，无需手动规则重写即可缩小规范缺陷。

越来越多的工作通过在智能体动作级别提出护栏和验证来解决策略合规问题。虽然在强制执行约束方面很有效，但这些方法共享一个关键假设：**书面策略是完整、明确的真实需求代理。** 在实践中，这个假设很少成立。上述策略意外地将赔偿与修改意图耦合：严格遵循它的智能体将拒绝仅报告延迟而未请求更改的客户赔偿，然而组织的意图是为任何受影响的客户提供赔偿。这样的缺陷很普遍，因为 NL 规范本质上受到歧义、不足规范和逻辑矛盾的困扰。即使识别出各个缺陷，维护完全一致的策略也不可扩展；瓶颈不在于编辑策略文本，而在于**识别**微妙的规范-需求分歧并**推理**如何解决它们（跨越不断增长的工具和边界情况空间）。这激发了自动化该过程：一个能够通过经验检测和纠正自己的策略误解的智能体。

本文探讨**演化策略理解**（图1）：智能体能否通过交互和反馈自主精化对不完美策略规范的解释？我们将其基于实际工作流：在部署前，**受信任的开发者或质量保证工程师**测试运行智能体，当智能体的行为由于不完美规范而非推理失败而偏离预期时提供纠正反馈。现有用于智能体演化的内存机制专注于改进任务执行能力，将输入策略视为不可变真实来源。当面对规范缺陷时，它们强化"符合但错误"的行为，而不是质疑规范本身。

为了支持系统性评估，我们使用受控**策略缺陷**（即，书面策略偏离地面真实需求的场景）和**姐妹任务**扩展 τ-Bench，以隔离对齐失败与执行失败。我们提出 PolicyBank，一种维护工具级别策略洞察结构化银行的内存机制。一个专门的策略智能体在任务轨迹和开发者反馈上推理，迭代精化这些洞察，将模糊的 NL 规范转换为精确的工具调用前提条件，无需手动规则重写。我们的贡献：

1. **问题**：我们识别和形式化**演化策略理解**，区分**执行失败**（能力缺陷）与**对齐失败**（规范缺陷）并识别三个策略缺陷的结构类别（§3）。
2. **方法论**：我们提出 PolicyBank，一种通过专用反馈循环维护精细、工具特定策略洞察的内存机制（§5）。
3. **评估**：我们提供扩展 τ-Bench 的严格测试平台（§4）。虽然当前内存机制在策略缺陷场景上的准确率接近零，但 PolicyBank 可将多达 82% 的缺陷缩小到人类预言机的程度（§6）。

## 2 相关工作

**策略约束下的 LLM 智能体。** 一直有关于基准测试智能体策略合规的积极研究：τ-Bench 针对特定领域策略评估对话工具调用智能体，ST-WebAgentBench 为网页智能体引入安全维度，AgentHarm、Agent-SafetyBench 和 DoomArena 衡量对有害或对抗动作的易感性。另一条研究线提出在运行时拦截动作的强制机制：GuardAgent 使用基于 LLM 的守卫，ShieldAgent 执行可验证的安全推理，VeriGuard 将 NL 策略转换为可执行代码守卫，Progent 为工具级别权限控制引入 DSL，PCAS 将 Datalog 衍生的规范编译为确定性参考监视器。所有强制框架假设规范是**完整和正确的**；当策略包含缺陷时，它们忠实地强制执行有缺陷的规范。我们的工作解决了这个在 NL 级别未探讨的假设，即规范的来源。这两种方法是互补的：PolicyBank **精化**规范，而验证层**强制执行**它。

**自然语言策略规范的挑战。** 产生完整、明确的 NL 规范的困难是公认的，维护正确的授权策略已在访问控制中广泛研究：RBAC、灵活访问控制机制和**策略更新问题**都在形式语言中解决策略管理，然而即使验证策略变更是否安全也在计算上是棘手的。我们的工作将这个经典问题适应于 NL 规范下的 LLM 智能体，使用结构化内存作为既是机器可操作的又是人类可审计的中间表示。

**自演化智能体和智能体内存。** 现有智能体演化机制针对我们所称的第 I 类（执行）失败（第3 节）。基于轨迹的方法，例如 Synapse、AWM、Voyager，从成功中学习，强化"如何把事情做好"但无法纠正规范缺陷，其中符合 π_spec 的行为违反 π_req。基于反思的方法，例如 Reflexion、ExpeL、ReasoningBank，可以从失败中学习，但存储**任务级别**洞察而非**工具级别**约束洞察，关于哪些授权规则不正确。生产内存系统提供存储基础设施，但对存储内容不可知。PolicyBank 是第一个为实际但未充分探讨的策略演化问题探索演化智能体内存的潜力，其中智能体必须通过交互和反馈自主精化其对不完美规范的解释。

## 3 问题设置：演化策略理解

我们通过借鉴形式方法和访问控制中的经典**策略更新问题**来形式化**演化策略理解**的问题。在该文献中，授权策略将主体、对象和动作映射到许可/拒绝决策；**策略更新**（或**策略修复**）问题询问在给定不正确决策证据的情况下如何精化这样的策略。当策略编码为形式语言（例如，Datalog 或 XACML）时，即使验证正确性也是棘手的，修复通常需要领域专家进行手动检查和规则编辑。我们将这个研究充分的抽象适应到一个新的设置：LLM 智能体，其授权约束以 NL 而非形式逻辑指定，其"策略修复"必须因此在 NL 解释而非符号规则集上运作。

**工具调用智能体中的策略合规。** 考虑配备一组工具 F={f₁,...,f_m} 的工具调用智能体 A，其中每个工具 f_i: X_i → Y_i 将输入映射到输出。智能体在由以下组件定义的环境上运营：

- **Σ** 是**状态空间**，捕获确定动作有效性的环境背景：数据库记录（例如，用户配置文件、预订详情）、对话历史和系统配置。状态 σ ∈ Σ 代表此背景的特定快照。
- **A_F** 是**动作空间**，具体工具调用集合及特定参数（例如，cancel_reservation(id="R123", refund=true)）。对于每个用户任务 t，智能体产生**动作轨迹** τ=(a₁,a₂,...,a_k)，其中每个动作 a_i ∈ A_F 在状态 σ_i ∈ Σ 中执行。

智能体的行为由**策略**管理，一个授权函数，决定在给定状态中哪些工具调用是允许的，遵循访问控制中的标准表述：

ψ: Σ × A_F → {permit, deny}    (1)

动作轨迹 τ 被策略 ψ **接受**，如果每个动作在其执行的状态中被许可：∀i, ψ(σ_i, a_i) = permit。任务成功当智能体产生既被策略接受又履行用户请求的轨迹。

**规范-需求缺陷。** 在实践中，智能体在两个可能偏离的不同策略下运营：

- **指定策略** (π_spec)：由提供给智能体的 NL 策略文档、系统提示和业务规则引起的授权函数。这是明确（但通常不完整或不精确的）标准智能体尝试遵循。
- **需求策略** (π_req)：代表环境真实行为需求的地面真实授权函数（例如，实际业务逻辑、监管合规、用户满意度标准）。

当 π_spec 和 π_req 在所有状态-动作对上一致时，规范是**完整的**：遵循书面规则保证正确行为。然而在实践中，NL 规范本质上是不精确的，包含歧义、未表述的假设和逻辑缺陷，导致两个策略偏离。

###### 定义 3.1 (策略缺陷)

**策略缺陷**存在于指定和需求策略在至少一个状态-动作对上不同时：

Gap(π_spec, π_req) = {(σ, a) ∈ Σ × A_F | π_spec(σ, a) ≠ π_req(σ, a)}    (2)

这个缺陷引起两个根本不同的失败模式：

- **(第 I 类) 执行失败**：智能体产生被 π_spec 拒绝的轨迹。由于推理限制（例如，不正确的工具规划、未能检索相关规则或遵循指令），它无法遵循甚至书面规则。大多数关于智能体自我改进的先前工作针对此模式。
- **(第 II 类) 对齐失败**：智能体忠实地遵循 π_spec，但轨迹违反 π_req。它做完全了所被告知的事，然而所被告知的事是错误的。这是策略缺陷的直接后果。

###### 定义 3.2 (具有演化智能体的策略更新)

给定智能体 A 在 π_spec 下运营，任务流 T=(t₁,t₂,...)，以及相应的纠正反馈流 Φ=(φ₁,φ₂,...)，其中每个 φ_t 指示智能体在任务 t_t 上的行为偏离 π_req 的位置，**策略更新问题**是产生精化策略解释的序列 π_spec^(0), π_spec^(1), ... 使得策略缺陷逐步减少：

Gap(π_spec^(t), π_req) →(t→∞) ∅    (3)

我们的工作提问：**配备结构化内存的 LLM 驱动智能体能否通过交互和反馈自动化策略更新过程，而无需手动规则编辑？**

**实践动机。** 我们在部署前工作流中基础我们形式化的问题：**受信任的开发者或质量保证工程师**测试运行智能体并提供纠正反馈，例如二元结果信号以及选择性地补充说明。