AI 已经回复了，为什么积压还在增长？

AI 已经回复了，后面发生了什么？

官网客服案例的起点是：系统一直在处理，积压却还在增长。调查首先要分清，系统执行了一个有用的动作，和客户问题完成闭环，是不是同一件事。

这次离线回放使用 20,000 张合成工单、224,260 条事件，包含乱序、重复、字段缺失、转交和重开。流程模式由生成器预设，用于反复检验指标和状态处理，不作为客户生产业绩。

同一份历史中，18,000 张工单选中过知识卡，但只有 4,000 张满足确认关单规则。两个计数都没有算错，错误在于把前者当成后者。

先还原每张工单，再计算比例。

一张工单可能先回复、再转交、得到确认，然后重新打开。直接数事件行，或者取最后导入的一条记录，都会丢掉这些区别。

回放先固定快照时间，只读取此前创建的工单；事件按发生时间、事件 ID 和行 ID 排序。事件必须有有效 ID、关联已知工单、属于已识别类型，且不早于工单创建时间。快照之后的事件不计入，重复事件 ID 只保留一次。

本次剔除 2,220 条重复事件、40 条无效事件，剩余 222,000 条有效唯一事件。数据库以只读方式打开，前后核对 SHA-256 指纹；建议动作单独输出。

“已解决”会开启新的确认周期；只有已解决之后的确认才有效，只有同时满足解决和确认才接受关单。重开则清空旧的解决、确认、关闭状态，避免用上一次确认关闭这一次问题。

问题解决 → 已解决；清空旧确认和关闭状态
客户确认 → 仅在已解决时记录确认
执行关单 → 仅在已解决且已确认时记录关闭
问题重开 → 清空解决、确认、关闭状态
工单转交 → 当前负责人置空

同一个积压数，藏着五种状态。

在这个预设数据集中，五个状态各有 4,000 张工单。把它们合成一个“未关单”数字，就看不到各自需要的下一步。

关键是分开“行政关单没完成”和“客户问题没解决”。一张工单开着，不一定代表客户还在等答案；系统选中了答案，也不代表问题已经解决。

不能为了降低积压，把工单全关掉。

找到关单缺口后，最省事的做法似乎是：把看起来已经解决的工单全部关闭。我们没有采用这条规则。没有客户确认的解决事件，必须留在另一个状态里；重开之后，也不能沿用旧确认。

补负责人和执行关单同样分开。前者回答“谁负责”，后者代表一个客户结果。如果把它们合成同一个成功标记，就又回到了最初的问题。

还有一个选择是继续改进答案选择。这个回放没有随机分单实验，也没有新的客户反馈，因此不能断言更好的答案对未解决工单没用。它能说明的更具体：对已经确认解决的那组，缺的是后续关单动作，改上游选择不会自动执行这一步。

所以动作清单按状态分别建议：确认后关闭、补齐负责人、请求确认。这些都只是待审查建议；本次没有联系客户，也没有更改生产工单。

只改规则，不换历史记录。

四种确定性规则使用同一批重建状态，分母始终是 20,000 张工单。这是离线方案模拟，不是对真实客户开展的随机 A/B 实验。

补齐负责人后，责任覆盖率提高，关单率却不变。这个负结果同样有用：分配一个人，不能凭空制造一次解决或一次客户确认。组合方案还会提出确认请求，但发出请求不计作已获确认。

新增关闭全部来自已经解决且获确认的工单。模拟假设建议的关单动作能执行，没有估计人员产能、客户回复概率和确认失效。这些要在实际试点中验证。

让每个汇总数都能被复查。

交付包含工单级发现表、建议动作表、结构化统计和报告。建议动作保留工单标识、依据状态以及模拟标记；审核者可以从汇总数字追到具体状态，不必改动生产记录。

记录中的 16 项检查覆盖样本数量、事件清理、状态分类、原始数据完整性、模拟关闭、责任归属，以及“分配负责人不能虚构关单”这条约束，全部通过。整理本文时，我们直接对保存的 SQLite 数据库重新回放，复现了状态统计，原始文件指纹保持不变。

这一轮规模验证是借助 Codex 编写的确定性实现，没有新启动 Polaris 自主模型任务。另一次较小的关单口径实验有 22 次模型调用、小范围与扩大检查、最终复核记录；两次实验不能拼成一个自主运行成果。

进入真实系统，首先要确认“解决、确认、重开、关闭”事件的语义是否一致，并检查确认有效期，再审核小范围动作。检索改进可以有价值，但它本身补不上后续缺失的关单步骤。