TL;DR

Q: 为什么提示词工程不是万能药？

>为什么提示词工程不是万能药？一种直觉的解决方案是改进提示词——用更清晰的格式列出策略规则，用结构化的方式呈现对话历史。但这种方法有根本性的局限： 上下文长度限制：即使模型支持很长的上下文窗口，长上下文中的信息检索质量仍然会下降。研究表明，LLM在长文本的中间部分最容易"丢失"信息（所谓"Lost in the Middle"现象）。 状态的动态性：任务状态不是静态的——每一轮对话、每一次工具调用都可能改变状态。让LLM从对话历史中实时重建当前状态，就像让一个人在流水线上一边工作一边在脑子里记账——短期可以，长期必然出错。 策略的复杂性：业务策略可能有数

客服领域的AI Agent需要在多轮对话中维护任务状态、调用工具并遵守业务策略。现有的标准方法将所有信息堆在提示词中，让模型自己"记住"状态，导致两种常见失败模式：用过时信息做决策、以及产生语法正确但违反策略的工具调用。LedgerAgent提出了一种推理时方法：用独立的账本（ledger）显式维护任务状态，在执行改变环境的工具调用前检查策略约束。在四个客服领域和多种开源/闭源模型上，该方法显著提升了pass@k指标，尤其是在更严格的一致性度量下效果更明显。

论文信息

标题: LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents
作者: Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral
状态: Work in Progress
arXiv: 2606.20529v1
领域: cs.AI, cs.CL

研究背景与动机

AI Agent时代的工具调用革命

2023年以来，大语言模型（LLM）的能力边界被不断拓展。从最初只能生成文本，到如今能够调用外部工具（如搜索引擎、数据库、API接口），LLM正在从一个"聊天机器人"进化为一个"智能代理"（Agent）。这种进化的核心标志就是工具调用（Tool Calling）能力——模型不仅能理解用户的需求，还能执行实际操作来满足这些需求。

在客服领域，这种能力的价值尤为突出。想象一个电信客服Agent：用户说"我想升级我的套餐"，Agent需要查询用户的当前套餐（调用查询工具）、了解可用的升级选项（调用产品目录工具）、确认用户的账户状态（调用账户检查工具）、执行升级操作（调用变更工具），最后确认变更成功（调用验证工具）。这整个过程中，Agent需要处理多个工具的返回结果，并确保每一步都符合公司的业务策略。

标准Agent架构的运作方式

目前业界主流的Agent架构可以概括为"提示词驱动"模式。具体来说：

系统提示词中包含Agent的角色定义、可用工具列表、业务策略规则
对话历史记录了用户与Agent之间所有的交互
工具返回值记录了每次工具调用的结果
所有这些信息都被拼接在一起，作为LLM的输入
LLM基于这些信息决定下一步行动：回复用户、调用工具、或结束对话

这种架构的假设是：LLM具有足够的上下文理解能力，能够从拼接的提示词中准确提取所需信息，并做出正确决策。在简单场景下，这个假设基本成立。但在复杂的多步骤任务中，这个假设开始崩溃。

两种致命的失败模式

研究者通过深入分析标准Agent的行为，识别出两种最常见的失败模式：

失败模式一：信息衰减导致的错误决策

当对话进行到第10轮、第20轮时，提示词中已经积累了大量信息。LLM需要从这个冗长的上下文中找到关键事实——比如用户在第3轮提到的订单号、第5轮工具返回的账户状态。

问题在于，LLM的注意力机制并不完美。随着上下文长度增加，早期信息的"影响力"会逐渐衰减。就像你在读一篇很长的报告，读到后面时已经记不清前面的细节了。更糟糕的是，如果中间有多个工具调用的返回值，这些技术性的JSON输出会"淹没"关键信息。

一个典型场景：用户在第3轮说"我的订单号是12345"，Agent在第8轮需要处理这个订单。但在第4到第7轮之间，Agent进行了多次工具调用，返回了大量的技术数据。到了第8轮，Agent可能已经"忘记"了订单号，或者更糟糕的是，把第6轮工具返回的另一个订单号当成了用户想要处理的那个。

失败模式二：策略违反的工具调用

许多业务策略都依赖于当前的任务状态。例如：

"在用户确认之前，不要执行任何账户变更操作"
"只有当账户余额大于0时，才能执行退款"
"修改订单前，必须先验证用户身份"

在标准Agent中，这些策略规则被写在系统提示词里。Agent需要同时理解策略的含义、提取当前状态信息、并判断是否满足策略条件——这一切都要在生成下一次工具调用之前完成。

当任务状态复杂时（比如同时需要考虑账户状态、订单状态、用户权限、时间限制等多个维度），LLM很容易忽略某个策略条件，或者错误地判断当前状态。结果就是产生了一个"语法上完全正确、但业务上完全违规"的工具调用。

举一个真实的例子：一个退货策略要求"退货必须在购买后30天内发起，且商品未拆封"。Agent可能正确调用了退货工具（语法正确），但忽略了商品已经拆封的事实（策略违反），导致一个不合规的退货操作被执行。

为什么提示词工程不是万能药？

一种直觉的解决方案是改进提示词——用更清晰的格式列出策略规则，用结构化的方式呈现对话历史。但这种方法有根本性的局限：

上下文长度限制：即使模型支持很长的上下文窗口，长上下文中的信息检索质量仍然会下降。研究表明，LLM在长文本的中间部分最容易"丢失"信息（所谓"Lost in the Middle"现象）。

状态的动态性：任务状态不是静态的——每一轮对话、每一次工具调用都可能改变状态。让LLM从对话历史中实时重建当前状态，就像让一个人在流水线上一边工作一边在脑子里记账——短期可以，长期必然出错。

策略的复杂性：业务策略可能有数十条甚至数百条规则，每条规则都可能依赖于不同的状态变量。将所有规则放在提示词中不仅占用宝贵的上下文空间，还增加了LLM的推理负担。

核心洞察：把状态管理从"隐式"变为"显式"

LedgerAgent的核心洞察非常简单但深刻：把任务状态从对话上下文中分离出来，用一个结构化的账本（ledger）显式维护。

这个想法可以用一个会计的比喻来理解。想象一家公司的财务管理：如果会计把所有的收入、支出、应收、应付都记在脑子里（隐式状态），时间长了一定会出错。所以人类发明了复式记账法——把每一笔交易都记录在账本上（显式状态），随时可以查阅、核对、审计。

LedgerAgent就是将这个古老智慧应用到了AI Agent中。它不是让LLM从对话历史中"回忆"状态，而是维护一个结构化的状态账本，每次需要做决策时，将账本的当前状态直接呈现给LLM。

核心发现

发现一：显式状态维护显著减少信息衰减

LedgerAgent通过在每一轮对话后更新账本，确保关键信息不会在长对话中丢失。账本中记录的每一项状态都有明确的来源——来自用户的哪一轮输入，或来自哪个工具调用的返回值。

实验表明，这种显式维护方式在所有测试的对话长度上都优于标准方法，且随着对话长度增加，优势更加明显。在20轮以上的长对话中，LedgerAgent的状态维护准确率比标准方法高出15-25个百分点。

发现二：策略检查机制有效阻断违规操作

LedgerAgent在执行任何改变环境的工具调用之前，会先用账本中的当前状态检查所有适用的策略规则。如果某个策略条件不满足，该工具调用会被阻断，Agent会被要求重新规划。

这个机制的效果非常显著。在测试中，标准Agent的策略违反率在某些场景下高达15-20%，而LedgerAgent将这一比率降低到了5%以下。更重要的是，这种阻断不是简单的"保守策略"（什么都不做），而是在阻断后引导Agent采取合规的替代方案。

发现三：在一致性度量下优势更大

研究者引入了pass@k指标来评估Agent的一致性——即在k次独立运行中，至少有一次成功完成任务的概率。更重要的是，他们还测试了更严格的"多轮一致性"——在多次运行中，Agent是否始终做出相同且正确的决策。

结果显示，LedgerAgent在严格的一致性度量下优势更大。标准Agent在多次运行中经常表现出不同的行为——有时成功、有时失败、有时用不同的路径达到相同的结果。而LedgerAgent由于有显式的状态管理，行为更加一致和可预测。

发现四：跨模型、跨领域的普遍有效性

研究者在多个开源和闭源模型上测试了LedgerAgent，包括：

不同规模的开源模型（如LLaMA系列、Mistral系列）
闭源商业模型（如GPT系列、Claude系列）

结果显示，LedgerAgent在所有模型上都带来了改善，虽然改善幅度因模型能力而异。值得注意的是，在较弱的模型上，改善幅度反而更大——这说明显式状态管理对能力较弱的模型尤为重要，因为它减轻了模型的"记忆负担"。

在四个不同的客服领域（电信、电商、银行、航空）中，LedgerAgent也展现了一致的有效性，证明了方法的领域通用性。

发现五：推理开销可控

一个自然的担忧是：维护账本、检查策略是否会导致推理延迟大幅增加？实验表明，LedgerAgent的额外开销主要来自两个方面：

账本更新：每轮对话后需要更新状态，这通常只需要一次额外的LLM调用
策略检查：在执行工具调用前需要验证策略，这可以通过规则匹配或小型模型完成

总体而言，LedgerAgent的端到端延迟比标准方法增加了约10-30%，但任务完成率和策略合规性的提升远超这个开销。在很多场景中，一次失败的工具调用（需要回滚和重试）的成本远高于一次策略检查的成本。

技术方法详解

账本（Ledger）的数据结构

LedgerAgent的账本是一个结构化的状态存储，其设计遵循了几个原则：

结构化：每个状态项都有明确的键名、值和类型。不是用自然语言描述状态（如"用户想要退货"），而是用结构化字段（如{"action_type": "return", "order_id": "12345", "status": "requested"}）。

来源追踪：每个状态项都记录了其来源——是用户说的（附带轮次编号），还是工具返回的（附带工具名称和调用ID）。这使得Agent在做决策时可以追溯信息的可靠性。

时间戳：每个状态项都有时间戳或轮次标记，帮助Agent识别信息的新鲜度。新信息自然地覆盖旧信息，避免使用过时的状态。

层次化：状态被组织成层次结构，例如：

用户信息层：姓名、账户ID、会员等级
任务信息层：当前任务类型、任务目标、进度
交互信息层：用户当前请求、已确认的操作、待确认的操作
环境信息层：系统当前状态、可用资源、时间约束

这种层次化设计使得不同类型的信息可以独立管理，也使得策略检查可以精准定位到相关的状态项。

账本的更新机制

账本的更新发生在每一轮对话之后，由以下步骤组成：

第一步：信息提取。 LLM分析当前轮次的对话内容和工具返回值，提取需要更新的状态项。这一步使用一个专门的提示词模板，要求LLM以JSON格式输出更新。

第二步：冲突解决。 如果新信息与账本中的现有信息冲突（比如用户改变了主意），需要决定哪个信息是最新最准确的。规则是：用户的最新输入优先于之前的输入，最新的工具返回值优先于旧的返回值。

第三步：一致性检查。 更新后，检查账本内部是否存在矛盾。例如，如果账本中记录了"用户已确认订单"和"订单已取消"，这两个状态不能同时为真。

第四步：格式验证。 确保更新后的账本符合预定义的Schema，避免格式错误导致后续处理失败。

用一个类比来说，账本更新就像一个秘书在会议后整理会议纪要：提取关键决策和待办事项、更新之前的记录、检查是否存在矛盾、确保格式规范。

策略检查机制

策略检查是LedgerAgent最关键的创新之一。其工作流程如下：

策略注册：业务策略被编码为一组规则，每条规则包含：

触发条件：在什么情况下需要检查这条规则（如"执行退款操作前"）
状态依赖：规则依赖账本中的哪些状态项
判断逻辑：基于当前状态，是否允许执行操作
违规处理：如果不允许，应该如何处理（阻断、警告、建议替代方案）

实时匹配：当Agent决定调用某个工具时，策略检查器会：

识别该工具调用涉及的操作类型
从策略库中检索所有适用的规则
从账本中读取规则所需的状态值
评估每条规则是否被满足
如果有规则不满足，生成一个包含违规原因和建议的反馈

反馈集成：当策略检查阻断了一个操作时，Agent会收到一条类似这样的反馈："操作被阻断：退款策略要求账户余额大于0，当前余额为-50元。建议：先处理未付账单，再执行退款。"Agent可以基于这个反馈重新规划行动。

整体推理流程

LedgerAgent的完整推理流程可以概括为：

接收用户输入 → 更新账本（提取新信息）
生成决策 → LLM基于账本状态和对话历史决定下一步
如果决策是工具调用 → 策略检查器验证合规性
如果通过 → 执行工具调用，将结果更新到账本
如果未通过 → 将违规反馈加入上下文，重新生成决策
如果决策是回复用户 → 直接执行
返回步骤1

这个流程与标准Agent的主要区别在于：步骤2中LLM看到的上下文包含结构化的账本状态（而不是从对话历史中自己提取状态），步骤3增加了一个显式的策略检查环节。

提示词设计

LedgerAgent的提示词设计有几个关键创新：

账本注入：在每轮推理的提示词中，账本的当前状态被格式化为清晰的Markdown表格或JSON，放在显著位置。这比将信息埋在对话历史中更容易被LLM注意到。

角色分离：系统提示词明确区分了"决策者"和"记录员"两个角色。决策者负责理解用户需求和选择行动，记录员负责更新账本。这种分离使得每个角色的提示词可以更加精简和专注。

策略引用：当策略检查阻断了操作时，相关的策略规则被直接引用在提示词中，而不是依赖LLM从系统提示词的策略列表中自己找到对应规则。

实验结果分析

实验设置

研究者在四个客服领域上进行了全面的实验：

电信客服：处理套餐查询、升级、降级、故障报修等任务。涉及工具包括套餐查询API、账户管理API、故障检测API等。

电商客服：处理订单查询、退货退款、物流追踪等任务。涉及工具包括订单系统API、退款处理API、物流查询API等。

银行客服：处理余额查询、转账、挂失、贷款咨询等任务。涉及工具包括核心银行系统API、风控系统API、KYC验证API等。

航空客服：处理航班查询、改签、退票、行李查询等任务。涉及工具包括订座系统API、票价计算API、行李追踪API等。

每个领域都有5-15条业务策略，涵盖了身份验证、金额限制、时间窗口、操作顺序等多种约束类型。

评估指标

研究者使用了多层次的评估指标：

任务完成率（Task Completion Rate）：Agent是否成功完成了用户请求的任务。

策略合规率（Policy Compliance Rate）：在所有执行的工具调用中，有多少是符合业务策略的。

pass@k：在k次独立运行中，至少有一次成功完成任务的概率。k越大，衡量的是Agent的"潜力"而非"稳定性"。

一致性指标：多次运行中，Agent行为的一致程度。包括路径一致性（是否总是选择相同的工具调用序列）和结果一致性（是否总是达到相同的结果）。

关键实验结果

整体性能对比

在所有四个领域中，LedgerAgent的任务完成率和策略合规率都优于标准方法：

任务完成率：LedgerAgent平均提升了5-12个百分点
策略合规率：LedgerAgent平均提升了10-20个百分点
pass@1：LedgerAgent平均提升了8-15个百分点

这些数字背后的含义是：LedgerAgent不仅更可靠（完成率更高），而且更安全（合规率更高），更重要的是它在第一次尝试中就成功的概率也更高。

长对话场景的优势

当把测试样本按对话轮数分组后，LedgerAgent的优势在长对话中更加明显：

5轮以下的短对话：LedgerAgent提升约3-5个百分点
5-15轮的中等对话：提升约8-12个百分点
15轮以上的长对话：提升约15-25个百分点

这种"越长越强"的模式完美验证了研究者的假设：标准Agent在长对话中容易丢失状态信息，而LedgerAgent的账本机制有效地解决了这个问题。

策略复杂度的影响

研究者还分析了策略复杂度对性能的影响。在策略规则较少（5条以下）的简单场景中，两种方法差距不大。但当策略规则增加到10条以上时，LedgerAgent的优势急剧扩大。在15条策略规则的场景中，标准Agent的策略违反率高达25%，而LedgerAgent将其控制在5%以内。

跨模型一致性

在不同模型上的测试结果呈现出一致的趋势：

在强模型上（如GPT-4级别），LedgerAgent的提升幅度较小（5-8%），因为强模型本身的状态管理能力就不错
在中等模型上（如GPT-3.5级别），提升幅度中等（10-15%）
在弱模型上（如7B级别开源模型），提升幅度最大（15-25%）

这个发现具有重要的实际意义：LedgerAgent使得较小的、更便宜的模型也能胜任复杂的Agent任务，从而大幅降低部署成本。

与现有工作对比

与ReAct等推理框架的比较

ReAct（Reasoning + Acting）是当前最流行的Agent推理框架之一，它让LLM交替进行"思考"和"行动"。ReAct通过链式思维（Chain-of-Thought）来帮助LLM推理，但它没有显式的状态管理机制。

LedgerAgent与ReAct的关键区别在于：ReAct依赖LLM从推理链中隐式地维护状态，而LedgerAgent用外部账本显式地维护状态。这就像一个人在脑子里算数（ReAct）和用计算器算数（LedgerAgent）的区别——后者更可靠，特别是在复杂场景中。

实验也验证了这一点：LedgerAgent在所有测试场景中都优于ReAct，且在复杂场景中优势更大。

与记忆增强方法的比较

此前有一些工作尝试通过外部记忆（如向量数据库、知识图谱）来增强Agent的记忆能力。这些方法的核心思想是将历史信息存储在外部，需要时检索。

LedgerAgent与这些方法的区别在于：记忆增强方法存储的是原始信息（对话历史、工具返回值），检索时需要LLM自己从检索到的信息中提取状态；而LedgerAgent存储的是经过整理的结构化状态，直接可用。

这种区别的效果类似于：让一个人查阅原始账单来了解财务状况（记忆增强），vs. 给他一份已经整理好的资产负债表（LedgerAgent）。后者显然更高效、更不容易出错。

与形式化验证方法的比较

另一种确保策略合规的方法是形式化验证——用形式化语言描述策略，然后用模型检查等技术验证Agent的计划是否合规。

LedgerAgent与形式化验证的区别在于：形式化验证要求策略可以被形式化表达（很多自然语言策略难以做到），且验证过程的计算开销可能很大；LedgerAgent用LLM来做策略检查，可以处理自然语言策略，且灵活性更高。

但LedgerAgent的策略检查也有局限——它依赖LLM的理解能力，可能不像形式化验证那样100%可靠。在对安全性要求极高的场景中，两种方法可能需要结合使用。

与状态机方法的比较

一些系统使用有限状态机（FSM）来管理对话流程。FSM预定义了所有可能的状态和状态转换，Agent的行为被严格约束在FSM允许的路径上。

FSM的优点是确定性和可预测性，但缺点是灵活性差——只能处理预定义的场景。LedgerAgent则保持了LLM的灵活性，同时通过账本和策略检查增加了约束。

一个形象的对比：FSM像一条铁轨，Agent只能沿着预设的路线行驶；LedgerAgent像一个GPS导航，Agent可以选择任何路线，但如果偏离了合规区域，会收到警告和重新规划的建议。

潜在应用与影响

客服行业的直接应用

LedgerAgent最直接的应用场景就是客服行业。目前，越来越多的企业正在部署AI客服Agent，但策略合规性一直是最大的担忧之一。一个违反策略的Agent可能导致：

财务损失：错误的退款、不合规的折扣
法律风险：违反消费者保护法规、数据隐私法规
品牌损害：不一致的用户体验、错误的承诺

LedgerAgent为这些问题提供了一个系统性的解决方案。通过显式的策略检查，企业可以确保Agent的每一次操作都符合业务规则，从而降低风险。

企业流程自动化

除了客服，LedgerAgent的方法论可以推广到更广泛的企业流程自动化场景：

IT运维Agent：处理工单时需要遵守变更管理策略（如高风险操作需要审批）
人力资源Agent：处理员工请求时需要遵守劳动法规和公司政策
采购Agent：执行采购操作时需要遵守预算限制和审批流程

在这些场景中，策略合规性同样至关重要，LedgerAgent的账本+策略检查架构可以直接应用。

Agent可靠性的系统性提升

LedgerAgent的方法论意义超越了具体的技术方案。它提出了一个重要的设计原则：Agent的状态管理不应该是隐式的，而应该是显式的、可审计的。

这个原则可能影响未来Agent系统的整体架构设计。我们可以预见，未来的Agent框架可能会内置类似LedgerAgent的状态管理模块，就像现代Web框架内置了会话管理一样。

降低Agent部署门槛

实验表明，LedgerAgent对较弱模型的改善幅度更大。这意味着企业不必使用最昂贵的大模型来部署可靠的Agent，较小的模型加上LedgerAgent的状态管理也能达到不错的效果。这将显著降低Agent的部署成本，加速Agent技术的普及。

推动Agent标准化和监管

显式的状态管理和策略检查使得Agent的行为更加透明和可审计。这对于Agent技术的标准化和监管具有积极意义。监管机构可以要求Agent系统提供状态账本和策略检查日志，以证明其合规性。

局限性与未来方向

当前局限

策略编码的挑战：LedgerAgent要求业务策略被编码为可检查的规则。虽然系统支持自然语言策略，但在复杂场景中，将模糊的业务规则转化为精确的检查逻辑仍然需要大量人工工作。

账本Schema的设计：账本的结构需要根据具体领域预先设计。不同的任务类型可能需要不同的账本结构，这增加了系统的定制成本。

LLM依赖：账本更新和策略检查仍然依赖LLM的能力。如果LLM在信息提取或策略理解上出错，账本可能包含错误信息，策略检查可能给出错误结果。

多Agent协作：当前的LedgerAgent设计针对单Agent场景。在多Agent协作的场景中，如何共享和同步账本状态是一个未解决的问题。

实时性：账本更新和策略检查增加了推理延迟。在对实时性要求极高的场景（如电话客服）中，这种延迟可能不可接受。

未来研究方向

自动Schema生成：能否让LLM根据任务描述自动生成账本Schema？这将大大降低定制成本，使LedgerAgent更容易应用到新领域。

策略学习：除了人工编写策略规则，能否从历史对话数据中自动学习策略？例如，从成功的客服对话中提取隐含的策略模式。

多Agent账本：设计支持多Agent协作的账本协议，使得多个Agent可以共享状态、协调行动。

增量式策略检查：在长对话中，不是每次都检查所有策略，而是只检查与当前操作相关的策略子集，以减少延迟。

与强化学习的结合：将账本状态作为强化学习的状态空间，训练更高效的Agent决策策略。

安全性增强：将账本机制与安全沙箱结合，确保即使策略检查出现遗漏，危险操作也无法被执行。

可解释性：利用账本的结构化状态为Agent的决策提供可解释的依据——"我做出这个决定是因为账本中的这些状态项满足了这些策略条件"。

与人类监督的结合：在关键操作前，将账本状态和策略检查结果呈现给人类监督者，实现人机协作的决策模式。

总结

LedgerAgent用一个简洁但深刻的洞察解决了AI Agent在客服领域的核心痛点：把隐式的状态管理变为显式的账本维护。这个方法不仅在技术上有效（任务完成率和策略合规率都显著提升），在工程上也具有可行性（推理开销可控、跨模型有效）。

从更宏观的视角来看，LedgerAgent代表了Agent架构设计的一个重要趋势：从"把所有问题都丢给大模型"转向"用结构化的机制辅助大模型"。大模型的语言理解和生成能力是强大的，但它的状态管理能力是有限的。LedgerAgent通过外挂一个账本来弥补这个短板，这种"大模型 + 结构化辅助"的架构模式可能会成为未来Agent系统的主流范式。

对于正在构建AI Agent的工程师来说，LedgerAgent提供了几条直接可用的设计原则：

显式维护状态：不要让模型从对话历史中自己提取状态，用结构化的数据结构来维护
在执行前检查：对于改变环境的操作，在执行前验证是否符合策略
来源追踪：记录每个状态项的来源，便于调试和审计
分层设计：将不同类型的信息（用户信息、任务信息、环境信息）分开管理

这些原则看似简单，但在实践中被广泛忽视。LedgerAgent的实验结果证明，遵循这些原则可以带来显著的性能提升。随着AI Agent在各行各业的广泛部署，这种可靠、可审计、策略合规的架构设计将变得越来越重要。