LedgerAgent: 面向策略合规工具调用代理的结构化状态

TL;DR LedgerAgent 在工具调用代理中显式维护结构化账本记录任务状态，并以此对写操作执行策略门控检查，直接杜绝状态过时或策略违反导致的失败模式。

问题

问题背景

语言智能体越来越多地被用于需要持续交互的多轮工具调用场景，如客户服务、任务执行等。这类智能体必须在对话中调用外部 API 并严格遵循领域策略（如权限校验、流程顺序、数据约束）。

现有方法的局限

主流方案将对话历史、工具返回及策略说明全部压入提示（prompt），让模型在每一步从冗长的上下文中自行推断当前任务状态。这种隐式状态管理带来两大典型失败模式：

• 状态过时或丢失：智能体前期正确获取了关键事实，后续决策却建立在过时、缺失或错误的信息之上。
• 策略违反：工具调用语法正确，但因忽略当前状态相关的策略约束而导致违规（例如未完成身份验证就执行敏感操作）。 本质上，缺乏一个独立、持久的结构化状态表示，使智能体在长对话和复杂策略下难以可靠追踪任务进展。

困难与重要性

任务状态由对话中动态涌现的事实、标识符、约束和条件组合而成，无法预先固定 schema；策略约束又往往依赖于这些状态的组合条件，要求智能体在「写操作」类工具调用前进行实时校验。一旦出错，不仅任务失败，还可能引发合规风险。金融、医疗、电商等领域的客服智能体已进入实际生产，严格策略遵守成为基本合规要求，任何违规都可能造成严重业务与信誉损失。

行业类比

就像数据库事务管理器必须维护锁表与约束以确保并发操作不违反 ACID 性质，面向客户服务的工具调用智能体也需要一个专门的「状态账簿」来跟踪任务状态并拦截策略违规。

核心洞察

• 将任务状态从 prompt 的混合上下文中显式分离为独立 ledger，使状态管理由隐式重构变为显式维护，从而避免因上下文过长或注意力稀释导致的状态错误。传统工具调用代理将历史对话、工具返回、政策说明全部塞入 prompt，模型每次必须重新定位并推断当前状态，容易取用过期或不完整的信息。LedgerAgent 通过结构化吸收、更新和渲染 ledger，确保模型始终基于最新且完整的状态做出决策，这比单纯优化 prompt 工程更根本地解决了状态一致性问题。
• 在生成工具调用后、执行前插入**政策门控**，利用 ledger 对状态依赖的约束进行形式化检查，将策略执行从模型推理层面转移到可验证的规则层面。标准代理仅依赖模型自身理解政策文本来决定工具调用是否合规，容易产生语法正确但语义违规的操作。LedgerAgent 将关键策略编码为门控条件，在涉及环境修改的调用前进行硬性拦截，既提升了策略遵循率，又减少了因政策误解导致的回滚，为高可靠性客户服务场景提供了一种轻量、可审计的保障机制。

方法

LedgerAgent 在推理时引入显式、结构化的任务状态管理，将标准工具调用代理的“观察→提示构建→行动生成”流水线拆分为三个紧耦合模块：

输入

• 多轮对话历史（用户消息、助手历史回复）
• 外部工具返回（如数据库查询结果、API 响应）
• 领域策略定义（描述工具调用必须满足的状态依赖约束）

关键模块

1. 账本状态与更新（Ledger State & Updates）
   每个对话轮次，从用户消息和工具返回中抽取与任务相关的事实、标识符、约束条件和时间窗口等，存入一个独立于提示的结构化账本。账本持续累积，并支持对过期或冲突条目的覆盖与删除。

2. 账本引导的生成（Ledger-Grounded Generation）
   在决定下一步动作前，将账本中当前有效状态条目渲染为自然语言片段，与原始对话历史、领域策略指令一起拼入提示（prompt）。这使得模型无需从长对话中“回忆”分散的状态，直接基于显式陈述的状态生成工具调用或自然语言响应。

3. 策略门（Policy Gate）
   对于会改变外部环境状态的动作（“写”操作，如创建订单、退款、修改记录），在执行前，策略门用硬约束检查器对比账本状态与领域策略。若工具调用参数与当前状态下的策略不兼容，则阻断执行，并可触发重新生成或输出修正式工具调用。

输出

• 经过策略验证的工具调用（仅当通过门控检查）
• 或对用户的安全合规响应（当操作被阻止时给出解释/替代方案）

与同类方法的差异点：不同于仅依靠长上下文窗口隐式维护状态的 Prompt Engineering 方案（如历史拼接、策略注入），LedgerAgent 将状态与策略检查外化到独立模块，硬性防止了状态混叠和基于过期信息的决策，在需要跨轮次严格策略遵循的场景中显著提高一致性。

实验

实验设计

论文在四个客户服务领域（具体名称未公布）上评估 LedgerAgent，任务需要多轮交互、工具调用和策略遵循。实验采用了开源与闭源模型的混合组，与标准基于提示的工具调用代理（Standard Prompt-based Agent）进行对比。核心指标为 pass^k，衡量 k 次独立运行中任务完全成功的比例，重点考察一致性与鲁棒性。还对环境改变型任务（如写入操作）进行了专项分析。

关键发现

LedgerAgent 在所有领域上均提升了平均 pass^k，并且在更严格的多试验一致性指标下增益最为明显。这种提升源于显式的分类账状态维护，有效避免了从冗长历史中重建状态时产生的遗忘或错误。策略门控在环境改变前以硬约束形式拦截违规工具调用，显著降低了策略违反率，同时不会损害任务完成度。

与基线的对比解读

标准代理将政策、工具返回和历史全部塞入提示，状态管理完全依赖模型自身的生成能力，容易在长上下文中出错。LedgerAgent 通过结构化状态抽象将状态维护与生成分离，并用策略门控提供确定性约束，取代了纯文本提示中的“软”建议。与近期通过优化提示顺序或注入记忆片段的上下文工程方法相比，这种硬约束机制在需要严格策略遵循的场景中更具工程可靠性，尤其对于高风险操作，它提供了可验证的安全保障。

行业影响

落地场景

LedgerAgent 主要面向需要严格遵循业务规则的对话式 AI 产品，尤其适合 客户服务自动化 领域，例如：

• 金融客服：处理账户查询、争议交易、贷款申请等需核对多轮对话状态（用户身份、账户余额、交易历史）并强制满足合规策略的场景。
• 电商售后：处理退货、退款、换货等流程，必须根据订单状态、用户信誉、时效策略等条件裁决，任何违反策略的工具调用（如错误执行退款）都可能造成直接经济损失。
• 医疗保险助手：在预授权、理赔提交等环节，需严格基于已获取的患者信息、保单条款和诊疗记录状态，避免因遗漏信息导致的错误决策。
• 企业 IT 服务台：执行密码重置、权限变更等环境修改操作时，需确保前置条件（如用户身份验证、审批状态）已满足。

商业价值

• 降低风险与错误成本：通过在工具调用前增加 策略门控 (Policy Gate)，LedgerAgent 能直接阻止违规操作，减少人工审核和纠错开销，这在金融、保险等监管严格行业价值尤为突出。
• 提升自动化率与用户体验：传统 agent 在复杂多条件决策中容易迷失状态或违规，导致转人工；LedgerAgent 使 agent 更可靠地完成端到端任务，首次解决率 和 多轮一致性 显著提升，直接降低服务成本并改善客户满意度。
• 合规即服务：对 B2B 软件供应商而言，将策略遵循能力内建于 agent 平台，可成为差异化的竞争优势，尤其面向重视合规性的企业客户。

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

LedgerAgent 是一种 推理时增强方法，不依赖模型训练，可无缝嵌入现有 LLM agent 框架：

1. 账本维护 (Ledger Management)：从对话和工具返回中抽取结构化状态条目（如事实、约束、标识符），可用轻量级解析器或小模型实现，与现有的记忆 (Memory) 和上下文工程管道集成。
2. Prompt 构造增强：框架在每一轮生成 prompt 前，自动将当前账本状态以自然语言或键值形式注入，确保模型永远基于最新、一致的状态进行推理。
3. 工具调用拦截 (Gate)：在工具执行前，通过策略检查模块校验账本中的状态是否满足工具对应的约束条件，这可以包装成中间件，覆盖所有环境变更类工具。

具体落地 Use Case

1. 电商退货退款自动化

某大型电商平台的退货助手需要处理用户请求：“我买的鞋子尺码不对，要退款。”相关业务规则：仅当订单状态为“已签收”且退货请求在签收后 7 天内，且商品在可退列表中时，才允许发起退款。标准 agent 可能在多轮对话中忘记签收日期，或错误地对不可退货商品调用退款工具。LedgerAgent 在每一轮更新账本条目：order_state: delivered; delivery_date: 2026-06-10; item_sku: SH-2049; returnable: false。当 agent 准备调用 initiate_refund 时，策略门控检查 returnable == true 且 current_date - delivery_date <= 7，条件不满足则 自动阻塞，并提醒 agent 向用户说明不能退款的原因，避免资金损失和客服事故。

2. 保险理赔预授权处理

一家健康险公司的会员助手处理投保人的 MRI 检查预授权请求。规则要求：必须确认保单有效、未超过年度检查次数上限、且已收集主治医生开具的 necessity 证明。传统 agent 可能在未收到证明的情况下提前调用 submit_authorization，导致流程回退。LedgerAgent 维护状态：policy_active: true; mri_count_this_year: 2; max_mri: 3; necessity_form_received: false。在调用提交工具前，门控发现 necessity_form_received == false，阻止执行并指引 agent 先向用户索要证明，确保后续自动审核流程前端无缺失信息，大幅减少人工跟进。

局限

• **领域知识工程依赖**：LedgerAgent 的状态槽位和策略规则需要针对每个客户服务领域手动定义，例如预约、退款等场景下的特定标识符、约束和条件。这种依赖专家标注的状态模式设计限制了方法的可扩展性，当业务规则变更或扩展到新领域时，必须重新编写账本结构和门控逻辑，自动化程度有限。
• **泛化性与鲁棒性不足**：实验仅在四个结构化的客户服务领域进行，任务交互序列相对固定，且假设观测信息完整可靠。在更开放或嘈杂的环境（如多意图对话、工具调用结果不完整）中，账本吸收机制可能会传播错误状态，导致后续门控误判。同时，方法未验证对长期依赖和动态变化策略的处理能力，在代码生成或自主代理等复杂工具使用场景的适应性未知。
• **推理延迟与严格门控的权衡**：LedgerAgent 在每次决策前增加了状态渲染和策略检查步骤，论文未给出端到端延迟数据。对于高并发客服系统，额外的提示上下文扩展和约束验证可能成为实时性瓶颈。此外，策略门控虽然阻止违规操作，但也可能因规则过于僵化而拒绝边缘合法请求，影响用户体验，缺少平衡安全与灵活性的自适应机制。