靠 prompt 记住的规则 200 轮后全忘了——LedgerAgent 用“账本“替代隐式记忆

qcx23

242人浏览 · 2026-06-21 22:58:17

qcx23 · 2026-06-21 22:58:17 发布

论文：LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents
来源：arXiv:2606.20529（2026-06-18）
作者：Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

📌 为什么你现在应该读这篇论文

你的 Agent 有多少条"红线规则"？写在 SOUL.md 里的、写在 system prompt 里的、写在注释里的——你觉得 Agent 真的每条都遵守了吗？

LedgerAgent 用实验证明了一个残酷事实：靠 prompt 隐式记住规则，在长程任务中必然失败。 换成显式账本 + 前置策略检查，一致性显著提升。

而且——这是推理时方法，不需要重训模型。今天看完，明天就能用。

两条反直觉发现

1. “语法合法” ≠ “策略合规”

Agent 调用了一个工具，参数类型完全正确，语法 100% 合法——但它违反了业务约束。比如：在"用户已取消订单"的状态下仍然调用"发起退款"工具。语法没问题，策略违规。

传统 Agent 只检查语法，不检查策略。因为策略依赖当前任务状态，而状态藏在 prompt 里——Agent 要"想起来"才能检查。

2. 越严格的标准下，LedgerAgent 优势越大

在简单的"单次通过"评测中，LedgerAgent 和标准方法的差距不大。但在"多试验一致性"指标（pass^k）下——也就是要求 Agent 每次都做出相同决策——LedgerAgent 全面超越。说明显式状态管理对可靠性优先的企业场景尤为关键。

当前 Agent 的两种高频失败

失败模式一：信息 Grounding 失败

Agent 检索到了正确事实（“用户在 6 月 1 日取消了订单”），但后续决策用过时信息（“用户订单仍在进行中，发起退款”）。

根因：任务状态没有被单独表示。观察结果、工具返回值、策略指令全部塞进 prompt，Agent 每次决策都要从 prompt 中重建相关状态。200 轮之后，关键信息被淹没在上下文海洋中。

失败模式二：策略违规

Agent 调用的工具语法完全合法，但违反了依赖当前任务状态的领域策略。比如：

用户已取消订单，仍调用"发起退款"
账户已被冻结，仍调用"执行转账"
工单已关闭，仍调用"添加处理记录"

根因：策略约束写在 prompt 里，Agent 需要"记住并推理"才能遵守。但在复杂任务中，策略推理被任务执行挤压，规则被"遗忘"。

LedgerAgent 的解法：三个组件

组件一：Ledger（账本）

将任务状态显式分离存储在独立的结构化账本中：

账本字段	内容	例子
Facts	相关事实	“用户订单 #1234 已于 6 月 1 日取消”
Identifiers	关键标识符	“order_id: 1234, account_id: 5678”
Constraints	活跃约束	“已取消订单不可发起退款”
Conditions	当前条件	“账户状态: 正常”

账本是 Agent 的"外部记忆"，不是 prompt 的一部分。每次工具调用后，账本被精确更新——不是靠 Agent “记住”，而是靠系统"写入"。

组件二：状态渲染

将账本中的状态显式注入到 prompt 中，供 Agent 决策使用。

关键区别：不是把所有历史塞进 prompt（信息过载），而是只渲染当前账本状态——精炼、准确、无歧义。

组件三：策略预检

在执行有副作用的工具调用前，基于账本检查策略合规性。

Agent 想调用: initiate_refund(order_id=1234)
                    ↓
策略预检: 账本显示 order #1234 状态=已取消
         约束: 已取消订单不可发起退款
                    ↓
结果: 🚫 阻止调用，返回策略违规信息

核心：策略检查发生在执行前，不是执行后审计。违规操作被阻止，不是"事后发现"。

核心交互效应

交互关系	方向	实际含义
显式账本 × 策略检查	✅ 协同	账本提供可检验状态，策略检查基于状态做合规判断
显式账本 × 信息 grounding	✅ 消除	消除"从 prompt 重建状态"的歧义
策略检查 × 工具调用	🚫 前置拦截	不合规调用被阻止在执行前
账本持久化 × 长程任务	✅ 基础前提	200 轮后账本仍精确——prompt 早已丢失关键状态
账本 × 误进化记忆路径	⚠️ 缓解	状态变更可审计，错误经验累积可被检测

最后一条特别重要——LedgerAgent 的账本机制和 Misevolution 论文的"记忆误进化"直接对应。有了可审计的账本，记忆的漂移可以被检测和回滚。

实验结果

在 4 个客户服务领域评测，使用混合模型面板（开源 + 闭源权重模型）：

指标	标准方法	LedgerAgent	提升
平均 pass^k（宽松）	基线	优于基线	中等
平均 pass^k（严格多试验一致性）	基线	显著优于	最大

核心发现：越严格的评估标准，LedgerAgent 优势越大。这说明——

显式状态管理提升的是可靠性，不只是能力
对于"必须每次都做对"的企业场景，LedgerAgent 的价值最大
一次通过的评测掩盖了隐式状态管理的不稳定性

工程实现指南：今天就能做

Step 1：识别你的 Agent 的"策略关键工具"

找出那些有副作用的工具调用——写数据库、发消息、执行交易、修改文件。这些是需要策略预检的入口。

Step 2：为每个工具定义状态依赖的策略

工具: initiate_refund
前置条件: order.status != "cancelled"
状态来源: 账本.order_status

Step 3：实现账本 + 策略检查层

伪代码：

class LedgerAgent:
    def __init__(self):
        self.ledger = {}  # 结构化状态存储
        self.policies = []  # 策略规则
    
    def before_tool_call(self, tool_name, params):
        # 1. 从账本获取当前状态
        state = self.ledger.get_relevant_state(tool_name)
        # 2. 检查策略合规性
        for policy in self.policies:
            if not policy.check(tool_name, params, state):
                return PolicyViolation(policy.reason)
        return OK
    
    def after_tool_call(self, tool_name, params, result):
        # 3. 根据结果更新账本
        self.ledger.update(tool_name, params, result)