当AI客服“记性太差”，亿万用户的投诉就此白费？
这项由亚利桑那州立大学与亚利桑那大学联合完成的研究，于2026年6月18日发布于arXiv预印本平台，编号为arXiv:2606.20529，有兴趣深入了解的读者可通过该编号查询完整论文。
你有没有打过客服电话，把自己的订单号、姓名、问题说了一遍又一遍，最后客服还是给出了一个完全错误的解决方案？现在，越来越多的企业开始用AI客服代替真人，而这个"说了也白说"的问题，非但没有消失，反而以一种更隐蔽、更让人抓狂的方式继续存在着。
研究团队将这种现象背后的根本原因称为"状态接地失败"——说白了，就是AI客服明明查到了正确的信息，却在做决定的时候把这些信息搞丢了或者用错了。他们为此提出了一套名为LedgerAgent（账本代理）的全新方法，专门解决AI客服在复杂多轮对话中"记性差、犯规矩错误"这两大顽疾。
**一切从一个真实的烦恼说起**
以订机票退票为例。你打开AI客服，告诉它你要取消明后天的航班。AI先查了你的订单，看到了订单日期、票价、是否买了保险等所有关键信息。然后你确认取消。AI说"好的，已为您取消"。然后你发现，这张票根本不符合退票政策，AI不应该退的——但它已经退了，钱也退了，违反了航空公司的规定，造成了实际损失。
或者反过来：你完全符合退票条件，AI却查了半天之后告诉你"不能退"，因为它在做最终判断时，把之前查到的关键信息给"遗忘"了，重新从一堆聊天记录里"回忆"时出了错。
这两种情况，在当前主流的AI客服中都普遍存在。原因在于，这类AI的工作方式就像一个健忘的员工：所有的对话记录、查询结果、公司政策，都混在一起堆在他面前的桌子上。每次做决定，他都要从这堆乱七八糟的纸堆里翻找相关信息，翻着翻着就找错了，或者根本没找到。
**账本代理：给AI客服配一本专用账本**
研究团队用了一个非常直觉的思路来解决这个问题：既然AI总是从乱糟糟的对话记录里找信息容易出错，那就给它单独配一本"账本"，专门记录它在这次对话中实际查到的所有关键信息。
这本"账本"是整个LedgerAgent系统的核心，它的正式名称是"模式锚定账本"。每当AI通过工具（比如查询订单系统、查询用户信息系统）成功获取到数据，这些数据就会被整齐地存进账本，按照固定的分类路径归档。比如，用户信息放在"user"这个位置，订单信息放在"orders.订单号"这个位置，机票预订信息放在"reservations.预订号"这个位置。
账本的构建完全是自动的、确定性的，不需要AI另外"思考"一遍——就像数据库自动存储记录一样机械可靠。每次AI要做下一步决定之前，这本账本的完整内容会被直接"摆到AI面前"，让它可以清楚地看到当前这个用户、这笔订单、这次预约的实际状态，而不是费力地从几百行聊天记录里翻找。
这个设计解决的是第一个核心问题：AI明明查到了正确信息，却在后续决策时用错了或者遗忘了。
**政策门卫：在AI犯错之前拦住它**
仅仅有账本还不够。研究团队发现，即使AI能准确看到账本里的信息，它仍然可能做出违反公司政策的操作——因为它是在"建议"完操作之后，才去对照政策检查，有时就这么漏过去了。
为此，他们在账本的基础上加了第二个组件：政策门卫。
政策门卫的工作方式可以用一个场景来理解：银行柜员处理大额转账时，在真正按下确认键之前，系统会自动弹出一个检查清单，核对这笔转账是否符合所有规定。政策门卫就是这样一道"在操作真正执行前强制触发的检查"。
每当AI准备执行一个会改变外部状态的操作（比如退款、取消订单、修改套餐、更新账户信息），政策门卫就会立刻介入。它把这个准备中的操作，对照账本里已经记录的实际信息，以及预先写好的规则代码，进行一次严格核查。
核查的结果有三种。第一种是"通过"，操作正常执行。第二种是"修正"，把有问题的那个操作取消，同时告诉AI哪条规则被违反了、账本里的哪个信息和操作冲突了，让AI可以重新规划。第三种是"阻止"，直接拒绝这个操作，不给AI任何重来的机会——通常用于那种一旦执行就无法撤回的严重违规。
这些规则不是让AI用自然语言去"理解"政策文件，而是由开发者提前把政策的核心逻辑写成可执行的代码判断。研究团队在四个测试场景中，总共编写了28条这样的规则：航空场景10条，负责检查比如"这次航班搜索结果里有没有这个航班"；零售场景12条，负责检查比如"退款必须退回原始支付方式或账户内的礼品卡"；电信场景6条；医疗健康场景因政策结构不同，暂时未设置规则。
**当账本遇到真实挑战：两个具体案例**
研究论文里详细记录了两个完整的对话案例，非常清晰地展示了这套系统如何在实战中运作。
第一个案例发生在航空场景。用户Amelia Rossi要求取消一张于2024年5月11日购买的基础经济舱机票，她既没有旅行保险，航空公司也没有取消相关航班，而她提出取消请求的时间也远远超过了24小时购票退票窗口期。AI查询了订单，账本里清楚地记录了：舱位类型是基础经济舱、购买日期是5月11日、保险状态是无。当AI准备执行取消操作时，政策门卫立刻核查账本——四个允许退票的条件一个都不满足，结果是直接"阻止"。AI于是向用户解释了政策原因，并把用户转接给了人工主管。整个过程中，订单状态从未被错误修改，系统得分满分1.0。
第二个案例发生在零售场景。用户Chen Silva要退一台金色128GB平板电脑，并要求把989.70美元退款打到她名下的万事达信用卡上。但账本里清楚记录着：这笔订单当初是用礼品卡7250692支付的。当AI准备执行退款到信用卡的操作时，政策门卫核查账本发现，信用卡既不是订单原始支付方式，也不是账户里已有的礼品卡，返回"修正"指令，取消了这个操作并告知AI具体原因。AI随即向用户解释了情况，用户同意改为退回礼品卡，AI重新提交了修正后的退款操作，这次顺利通过检查，退款成功执行，系统得分满分1.0。
这两个案例分别展示了"阻止"和"修正"两种不同的工作模式：前者用于那些根本不该发生的操作，后者用于那些方向正确但参数有误的操作，给了AI一次纠正的机会。
**怎么确认这套方法真的有用？**
研究团队在四个来自真实客服场景的测试域上进行了系统评估，这四个场景分别是航空（50个任务）、零售（114个任务）、电信（114个任务）和医疗健康（20个任务）。
评估用的是一个叫做"pass^k"的指标，可以理解为"稳定通过率"。对每个任务，系统会独立跑四次试验，如果k次试验全部通过，才算这个任务真正解决了。pass^1衡量的是单次成功率，pass^4衡量的是四次全部通过的比率，后者更能反映系统是否真的稳定可靠，还是只是"偶尔蒙对"。
研究团队测试了六个不同的AI底层模型：GPT-5.2、GPT-4.1、Kimi K2.5、GLM-5、MiniMax M2.5和Qwen3-30B。每个模型都分别在加了LedgerAgent和没加LedgerAgent（基础函数调用方式）两种条件下运行，对比其表现。
以Kimi K2.5为底层模型为例，加了LedgerAgent之后，平均pass^1从54.4%提升到62.3%，提升了约8个百分点；更能说明问题的pass^4从38.3%提升到了53.9%，提升了约16个百分点。这意味着，系统不仅更容易一次做对，而且做对之后能在重复试验中保持一致，不再是"碰运气"。
GLM-5模型的数据也呈现相似趋势，平均pass^1从51.3%提升到64.6%，平均pass^4从40.9%提升到48.5%。MiniMax M2.5模型的提升更为显著，平均pass^4从16.7%跃升到36.6%，几乎翻了一倍多。
对于更昂贵的GPT系列模型，研究团队由于成本原因只在航空和零售两个场景测试。GPT-4.1和GPT-5.2作为底层模型时，LedgerAgent分别带来了12.2和15.5个百分点的平均pass^1提升，pass^4的提升幅度相近。
**与同类方法的正面比较**
除了与基础函数调用方式比较，研究团队还把LedgerAgent与一种名为IRMA的竞品方法进行了直接对比。IRMA的思路是在AI做决定之前，先用三个辅助AI帮它整理相关的领域规则和工具建议，属于"多AI协作"路线。
在零售和航空场景的综合测试中，LedgerAgent的pass^1为27.2%，IRMA为23.4%；LedgerAgent的pass^4为17.1%，IRMA为9.6%——LedgerAgent在两个指标上均占优。更关键的是，IRMA因为需要调用额外的辅助AI，总体token消耗（可以理解为"计算量"和"费用"）增加了超过50%，而LedgerAgent与基础方法相比，token消耗增加为零，因为账本的构建和政策门卫的检查都是纯计算操作，不需要额外调用AI模型。
**当任务需要真正改变外部状态时，差距最为明显**
研究团队还专门筛选出了那些"必须执行至少一次写操作（比如退款、取消、修改）"的任务，单独进行分析。这类任务在四个场景中占了绝大多数：航空50个任务中有26个，零售114个中有104个，电信114个中有94个，医疗健康20个中有19个。
在这个子集上，LedgerAgent的提升幅度整体上比全量测试更大——这符合研究团队的预期，因为LedgerAgent的政策门卫专门针对写操作而设计，账本对于"基于已查询信息做出准确写操作"这一场景的帮助也最为直接。
电信场景的提升尤为突出。电信测试是唯一一个"双控制"场景，也就是说，用户侧也可以在对话过程中主动改变共享数据库的状态，而不只是AI单方面操作。这种情况下，AI对"当前系统状态到底是什么"的把握更容易出现偏差，而账本始终记录AI实际观察到的最新状态，恰好弥补了这一弱点。在三个测试底层模型上，电信场景的写操作pass^k提升均在14到19个百分点之间。
**系统还会在哪里犯错？**
研究团队没有只看成绩单，还对LedgerAgent仍然失败的案例做了细致的错误分类分析，覆盖三个底层模型、四个场景的全部失败轨迹。
分析结果显示，70.3%的失败案例属于"漏掉了本该执行的操作"——AI在完成初步查询后，遇到一个边缘情况（比如支付方式受限、资格不符合某个条件），就直接选择把用户转接给人工客服了事，而没有继续尝试找到符合政策的替代方案。另有20.4%的失败是"操作参数填错了"——调用了正确的工具，但传入的具体参数不对。这两类合计占了90.7%的失败。
剩余9.3%的失败则由多种原因构成：未授权操作、AI推理陷入循环、政策违规（极少）、沟通失误、身份验证失败等。
不同场景的错误特征各有不同。零售场景的失败以"漏操作"为主，占比约70%，常见情况是AI在处理涉及多件商品的复杂退换时，遇到第一个障碍就放弃了，没有继续探索部分可行的方案。电信场景几乎所有失败（98.7%）都是漏操作，通常是忘记执行某个必要的权限授予步骤。航空场景的失败最多样，漏操作和参数错误各占近半，此外还有一定比例的未授权操作，往往是AI在用户施压后妥协，执行了政策明确不允许的操作。医疗健康场景参数错误率最高（约26%），反映出该场景工具接口更复杂，字段更多，AI在生成准确参数时更容易出错。
这些分析指出了下一步改进的方向：LedgerAgent已经在"不该做的事情别乱做"这个维度上取得了明显进展，但"该做的事情一定要做到"以及"复杂工具的参数要填准确"这两个维度，仍然有待提升，而这些问题更多地属于AI规划能力和工具调用精度的范畴。
**这套方法的边界在哪里？**
研究团队在论文中也坦诚地讨论了这套方法的适用范围和局限。
LedgerAgent最适合那些工具返回结构化数据、写操作有明确政策规则的场景——客服、医疗预约、电商退换、银行业务等都属于这个范畴。如果需要处理的信息主要是图片、视频、语音等非结构化内容，或者状态根本无法通过查询工具获取，账本就难以发挥作用。
账本只记录AI实际查询到的信息，不会自动推断未查询的状态。如果AI执行了一次写操作（比如成功退了款），账本不会自动更新订单状态为"已退款"——必须由AI主动再查询一次，才能把新状态存入账本。这个"观察到才算，不自动假设"的设计保证了账本的可靠性，但也意味着AI需要养成"做完写操作就重新确认一次"的习惯。
政策门卫的效果也完全取决于预先编写的规则是否覆盖到位。如果某条政策规则没有被开发者翻译成代码，门卫就不会检查它——所以门卫是对已知、可枚举政策的强制执行，而不是对"所有可能政策"的全自动合规检查。对于措辞模糊或频繁变动的政策，这套方法的适应性也有限。
此外，研究团队的测试使用的是固定的模拟用户，而非真实的、行为多变的真人用户，评估场景也集中在特定的客服领域，没有覆盖对抗性用户行为或政策快速迭代的情境。
说到底，LedgerAgent回答的是一个根本性的工程问题：当AI做决定的时候，它依赖的信息应该来自一本清晰可查的账本，而不是一大堆混在一起的聊天记录。账本不复杂，门卫不神奇，但这两件事合在一起，让AI客服从"偶尔蒙对"变成了"可以稳定依赖"。归根结底，这不是让AI变得更聪明，而是给它配了一套更好的工作工具——就像一个能干的员工，配上了一本随时可以翻查的完整记录本，加上一个在按下确认键之前强制核对规则的系统。
那么下一个问题自然就来了：如果政策本身在不断变化，甚至存在内在矛盾，门卫应该如何应对？这或许是这个方向上值得继续探索的边界。有兴趣的读者可以通过arXiv编号2606.20529查阅完整论文，研究团队在附录中还保留了更多完整的对话案例和实验细节。
Q&A
Q1：LedgerAgent账本里记录的信息是AI"猜测"的还是真实查询到的？
A：账本里只记录AI通过工具实际查询并成功返回的信息，不包含AI的推断或假设。如果AI没查，账本就不记录；如果查询失败了，也不会写进去。这种"只记观察到的事实"的设计，保证了账本内容的可靠性，避免AI基于错误假设做决定。
Q2：政策门卫的规则是AI自动学习的吗？
A：不是。政策门卫的规则是由开发者根据业务政策预先手动编写成可执行代码的，共28条覆盖四个场景。这不是AI自动生成的，也不是从自然语言政策文档里自动提取的。好处是判断确定、不会出错；局限是没有写进代码的规则不会被检查到。
Q3：LedgerAgent会不会增加很多额外的计算成本？
A：不会。账本的构建和更新是纯机械的数据存储操作，政策门卫的检查是代码逻辑判断，两者都不需要额外调用AI模型。与基础方法相比，LedgerAgent的额外token消耗为零，而对比的竞品方法IRMA因为使用多个辅助AI，token消耗增加了超过50%。