LedgerAgent：用结构化状态让AI客服代理遵守规则

TL;DR

在客服场景中，AI代理需要跨多轮对话维护任务状态、调用工具并遵守业务策略。现有的代理架构把所有信息混在提示词中，让模型自己"重建"状态，导致策略违规和状态混乱。LedgerAgent提出了一种结构化状态管理方法——用一个显式的"账本"来维护任务状态，与提示词和工具返回分离。实验表明，这种方法在策略遵守率和任务完成率上均有显著提升，特别是在复杂多轮对话中。

论文信息

标题：LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents
作者：Md Nayem Uddin, Amir Saeidi, Eduardo Blanco
分类：cs.AI
日期：2026年6月18日
链接：https://arxiv.org/abs/2606.20529v1

研究背景与动机

AI客服代理的承诺与现实

想象你打电话给银行客服，接电话的不是真人，而是一个AI代理。你需要查询账户余额、挂失信用卡、修改账单地址——这些操作涉及多个步骤、多个系统和多条业务规则。

AI客服代理的愿景很美好：7×24小时服务、即时响应、标准化流程。但现实中的挑战远比想象中复杂。

状态管理的复杂性：一次完整的客服交互可能涉及十几轮对话。用户说"我要挂失我的信用卡"，代理需要确认身份、查找卡号、验证安全问题、执行挂失、记录原因、发送确认短信。每一步都产生新的状态信息（卡号找到了、身份已验证、挂失已执行），这些状态需要被正确维护和引用。

策略遵守的严格性：银行有严格的操作策略——"未验证身份不得执行挂失""单日挂失次数不超过3次""金额超过5万的操作需要二次确认"。AI代理必须在每一步都检查和遵守这些策略。

工具调用的可靠性：代理需要调用各种后端工具——数据库查询、身份验证、交易执行。工具的返回结果需要被正确解析和整合到任务状态中。

现有架构的根本缺陷

现有的AI代理架构通常把所有信息都塞进一个大的提示词中：

系统提示：你是银行客服代理。策略：[一长串规则]
用户历史：[所有对话记录]
工具返回：[所有工具调用结果]
当前任务：[当前步骤的描述]
请生成下一步响应。

这种方法有几个致命问题：

状态重建的开销：模型需要从杂乱的对话历史中"重建"当前任务状态。随着对话变长，这个重建过程越来越容易出错。
信息过载：提示词越来越长，模型的注意力被分散。关键的状态信息可能被淹没在大量无关的对话记录中。
策略检查的不可靠性：策略规则被放在系统提示中，但模型可能在长对话中"忘记"某些规则，或者在复杂的上下文中做出违反策略的决策。

LedgerAgent的洞察

LedgerAgent的核心洞察是：状态管理不应该交给模型的"记忆"，而应该用显式的数据结构来管理。

这就像会计记账——你不会把所有的收支记录都写在一张便签纸上，然后指望自己能随时准确地回忆起余额。你会用一个结构化的账本（Ledger），每笔交易都清晰地记录，余额自动更新。

LedgerAgent把这个思想应用到AI代理：用一个显式的"任务账本"来维护所有状态信息——已确认的事实、已执行的操作、待处理的步骤、已触发的策略。模型只需要读取账本来了解当前状态，而不需要从头重建。

核心发现

发现一：结构化状态显著减少策略违规

在标准客服对话基准测试中，LedgerAgent的策略违规率比基线方法降低了42%。主要的改善来自于：

身份验证检查：基线方法在23%的案例中跳过了身份验证，LedgerAgent降到了4%
金额限制检查：基线方法在15%的案例中忽略了金额限制，LedgerAgent降到了2%
操作顺序检查：基线方法在18%的案例中打乱了操作顺序，LedgerAgent降到了5%

发现二：状态一致性在长对话中保持稳定

基线方法在对话超过10轮后，状态一致性开始下降（模型"忘记"了早期的状态信息）。LedgerAgent因为使用显式账本，状态一致性在所有对话长度上都保持稳定。

发现三：工具调用的准确率提升

LedgerAgent的工具调用准确率比基线方法高出15%。这是因为账本提供了清晰的上下文——模型知道当前已经掌握了哪些信息、还需要查询哪些信息，从而做出更准确的工具调用决策。

发现四：推理开销降低

由于模型不需要从头重建状态，LedgerAgent的平均推理时间比基线方法降低了28%。这对于需要实时响应的客服场景尤其重要。

技术方法详解

账本的数据结构

LedgerAgent的账本包含以下字段：

事实清单（Facts）：从对话和工具返回中提取的关键事实。例如：

用户姓名：张三
账户类型：储蓄账户
卡号末四位：1234
身份已验证：是

操作历史（Operations）：已执行的操作记录。例如：

查询余额：返回10,000元
验证安全问题：通过
发送验证码：已发送至138****1234

策略状态（Policy State）：每条策略的当前状态。例如：

身份验证策略：已通过
金额限制策略：当前操作金额5,000元，限制10,000元，未触发
操作频率策略：今日已操作2次，限制5次，未触发

待办事项（Pending）：下一步需要执行的操作。例如：

等待用户输入验证码
确认挂失原因

账本的更新机制

每轮对话后，账本通过一个专门的"更新器"模块来维护。更新器接收三个输入：

当前账本状态
用户的最新输入
工具调用的返回结果

更新器使用一个经过微调的语言模型来解析这些输入，并生成账本的增量更新。这比让主模型直接处理所有信息更可靠——更新器只需要关注"什么信息改变了"，而不是"当前状态是什么"。

策略检查的分离

策略检查被从主模型中分离出来，成为一个独立的模块。这个模块在每次操作前运行，检查当前账本状态是否满足所有策略条件。

这种分离的好处是：

策略检查是确定性的——不会因为模型的"注意力分散"而漏检
策略可以独立更新——不需要重新训练主模型
策略违规可以被精确定位——知道是哪条策略在什么条件下被违反

与主模型的交互

在每轮对话中，主模型接收两个输入：

精简的上下文：最近N轮对话（不是全部历史）
当前账本：结构化的状态信息

主模型基于这两个输入生成响应。如果需要调用工具，账本会记录工具调用的结果。如果需要检查策略，策略模块会给出明确的通过/拒绝结果。

这种设计让主模型的负担大大减轻——它不需要记住所有历史，不需要重建状态，不需要检查所有策略。它只需要根据当前状态做出决策。

实验结果分析

实验设置

数据集：银行客服对话数据集（包含500个对话，平均12轮）
策略数量：15条业务策略
工具数量：8个后端工具（查询余额、身份验证、交易执行等）
评估指标：策略违规率、任务完成率、工具调用准确率、推理时间

关键结果

指标	基线方法	LedgerAgent	改善
策略违规率	18.3%	10.6%	-42%
任务完成率	76.2%	89.1%	+17%
工具调用准确率	81.5%	93.7%	+15%
平均推理时间	2.3s	1.7s	-28%

消融实验

去掉账本（只用精简上下文）：策略违规率上升到15.2%
去掉策略分离（策略放在提示词中）：策略违规率上升到14.8%
去掉更新器（让主模型直接更新账本）：策略违规率上升到13.1%

每个组件都有贡献，但账本的影响最大。

与现有工作对比

与ReAct/Reflexion的对比

ReAct和Reflexion是流行的代理推理框架，但它们没有显式的状态管理。所有信息都在推理链中，模型需要自己维护状态。

与ToolFormer的对比

ToolFormer关注工具调用的准确性，但没有考虑策略遵守。LedgerAgent在工具调用的基础上增加了策略检查层。

与数据库驱动代理的对比

有些系统用数据库来存储状态，但数据库的更新需要手工定义的规则。LedgerAgent的账本更新器是学习到的，更灵活。

潜在应用与影响

金融客服

银行、保险、证券等金融机构有严格的操作策略。LedgerAgent的结构化状态管理可以显著降低策略违规风险。

医疗问诊

医疗AI代理需要维护患者的完整病史、用药记录和检查结果。账本结构可以确保信息不遗漏。

法律咨询

法律AI代理需要追踪案件的每个细节。结构化状态可以确保逻辑一致性。

IT运维

AI运维代理需要维护系统的当前状态、已执行的操作和待处理的任务。账本结构天然适合这种场景。

局限性与未来方向

账本的结构设计

当前的账本结构是手工设计的。不同应用场景需要不同的账本结构。未来可以探索自动化的账本结构学习。

更新器的可靠性

账本更新器本身也是一个语言模型，可能犯错。如果更新器错误地记录了状态，后续的所有决策都可能出错。

多代理协作

当前的LedgerAgent是单代理架构。未来可以扩展到多代理场景，每个代理有自己的账本，通过共享账本来协作。

总结

LedgerAgent通过引入结构化的任务账本，解决了AI代理在多轮对话中的状态管理和策略遵守问题。它的核心贡献在于：把状态管理从模型的"隐式记忆"转变为显式的数据结构，把策略检查从模型的"推理过程"转变为独立的确定性模块。

实验结果表明，这种方法在策略违规率、任务完成率和工具调用准确率上均有显著提升。对于需要严格策略遵守的行业应用（金融、医疗、法律），LedgerAgent提供了一个实用且可靠的解决方案。