主题：两个客服 Agent 案例——"简单方案 99.2%"与"持续自进化"，谁更该抄
类型：AI 落地案例 · 双案例对照
一、两个案例，两种走法，都声称自己是"生产级"
客服是 AI 落地最拥挤的赛道，但大多数团队卡在同一处：流程文档散在 SOP 与政策文件里，模型要么检索不到、要么检索到却没按正确顺序执行。常规解法是堆工程——复杂的分块、索引、检索管线，上面再叠学到的重排器、查询改写器、定制 agentic RAG 基础设施。
2026 年 10 月有一份部署案例，走了完全相反的路：**一个"可移植技能"**——一段自然语言指令 + 轻量工具（一个检索 API、几个格式检查脚本）+ 一个带"导航层"的语料库。所谓导航层，是用模型生成的、类似维基百科索引的结构化目录，铺在原始文档之上。
结果：**程序等价性 99.2%**（与人工批准的正确答案相比）、**证据充分性 83.3%**。实现成本 1–2 个工程师日，可跨主流 agentic 框架移植。
但作者很诚实，自己把三处短板写在摘要里：**速度慢了约一个数量级（每例约 90 秒 vs 生产助手的约 8–9 秒）**，而且明确"不主张延迟优势"；适用范围被限定在三个条件——语料成熟且经过精心整理、流程本身容忍延迟、每一例都有人工复核。
另一份 2026 年 11 月的预印本讲的是完全不同的思路。它要做的是：**用一个自研的中等规模模型替换掉前沿商业模型，并在部署之后继续学习。** 做法叫"接地气的递归自我改进"：先在受治理的生产轨迹上做一次性冷启动；上线后当前模型与既有模型并行跑生产流量，**用自己的失败驱动下一次更新**；24/7 的检查流程用"证据盲评 + 独立复核"确认失败；归因环节把"模型自己的错"与"技能/工具/框架的缺陷"分开，组件缺陷送修；可归因到模型的轨迹在第一个错误决策处截断，配上已验证的修复；再用同模型作教师做在线策略自蒸馏，把诊断与修复作为学生看不到的特权信息喂进去。
二、把两套方案摊开对照
| 维度 | 案例 A：可移植技能 + 导航层 | 案例 B：递归自我改进 |
|---|---|---|
| 核心思路 | 用简单结构替代复杂 RAG 栈 | 用生产失败驱动模型持续更新 |
| 实现成本 | **1–2 个工程师日** | 需建冷启动、24/7 检查、归因、蒸馏、仿真测试全链路 |
| 效果口径 | 程序等价性 **99.2%**、证据充分性 **83.3%** | 以"与在位模型持平或更好"为晋升门槛，含仿真+离线检查+在线对比 |
| 延迟 | 比生产助手慢约 **10 倍**（90 秒 vs 8–9 秒） | 主线目标包含替换既有模型，延迟未作为主要指标披露 |
| 维护方式 | **改文本和数据**，不重训模型 | **持续重训**，模型与策略同步演进 |
| 成立前提 | 语料成熟、可容忍延迟、每例人工复核 | 有受治理的生产轨迹、能独立复核、有仿真环境 |
这张表最值得看的是第五行。两个案例的维护成本形态完全不同：A 把维护变成"编辑文本"，B 把维护变成"运营一条训练流水线"。前者便宜，后者贵，但前者对语料的整洁度极度敏感，后者能在业务规则变化时自动跟上。
三、我的判断：99.2% 是真的，但它的边界比数字重要
先说 A 那个 99.2%。这个数字很好看，但它有三个限定词必须在同一句话里说完：**在成熟精心整理的语料上、在容忍延迟的流程里、在每例都有人工复核的前提下**。
第三条最关键。如果每一例都有人工复核，那这个系统实际扮演的是"初稿生成器"——它把专家从"从头做"变成"改一改"。这种模式在客服里很合理（错误代价高），但你不能拿它去论证"能替代人"。
第二条同样致命。慢 10 倍意味着它只能跑在异步队列里。任何要求实时应答的场景（用户在线等待）都用不了。
所以我会这样定位它：**A 是一套把"专家知识检索"变简单的方案，不是一套把"客服工作"自动化的方案。** 把它宣传成后者，就是过度承诺。
四、B 真正值得抄的不是模型，是那三条纪律
B 最吸引眼球的是"用自研中等模型替换前沿模型"，但我觉得真正能复用的是它的流程设计，尤其这三条：
- **归因分离**：把"模型的错"与"技能/工具/框架的缺陷"分开，组件缺陷送修而不是拿去训练模型。这条直接决定你的训练数据干不干净。
- **在第一个错误决策处截断**：只把出错点之前的部分给模型学，后面接已验证的修复。这比"整段对话都当样本"精确得多。
- **每份失败按当时的政策版本评判**：业务规则变了，旧失败要按旧规则判。这一条很多团队压根没做，导致训练集里混进了大量"其实没做错"的样本。
第三条我认为是这套方法里最容易被忽略、也最能决定成败的一条。政策一改，历史失败样本立刻失真；不做版本对齐，模型会学到"违反新政策是对的"。
它还有一句我很认同的设计：晋升门槛是"仿真+检查分数至少与在位版本持平，并且要通过与在位模型的在线对比，且需人工批准"。三关都过才上线——**没有任何单一指标能独自决定晋升**。
五、如果你现在要从零做一个客服 Agent，顺序应该是
| 顺序 | 做什么 | 做完的判据 |
|---|---|---|
| 1 | 先整理语料，加一层导航索引 | 给定一个案例，能定位到相关段落且顺序正确 |
| 2 | 用最简方案跑通，别先上重排器与改写器 | 程序等价性能到可接受线（含人工复核） |
| 3 | 上线时同步建"失败归因"台账 | 每条失败能标：模型 / 技能 / 工具 / 框架 |
| 4 | 再考虑要不要自进化 | 只在上一步的归因干净之后 |
第 4 行是省钱的关键。**归因不干净的团队做自进化，等于把框架缺陷灌进模型。** 我见过太多这种情况：模型没做错，是工具返回错了，但失败被算进模型账上。
六、跟此前几篇怎么错开
11/04 讲验收（跑通了不等于交付合格），11/02 讲上下文与评测预算，11/01 讲 GEO 评测可比性，10/31 讲收益曲线。今天这篇是**AI 落地案例 · 双案例对照**，落在"同一业务场景里，简单方案与自进化方案各自成立的前提是什么、该按什么顺序抄"。
它回答的是此前几篇没回答的一个问题：**当你确认要落地之后，第一条路该选简单还是复杂。**
七、边界与口径说明
两项研究均为预印本，未经同行评审。案例 A 是单一部署的案例报告，其 99.2% 与 83.3% 绑定该企业的语料质量、客服流程与人工复核机制；作者明确"不主张延迟优势"，且适用范围被限定为成熟语料、容忍延迟、逐例人工复核三点，不能外推为通用客服自动化成功率。案例 B 是框架论文，其晋升门槛（仿真+检查持平、在线对比、人工批准）与自蒸馏流程绑定其客服场景与治理条件，摘要未给出替换后的绝对性能数值，故本文不做量化对比。两案指标口径不同（程序等价性 vs 相对在位模型的持平判定），**不可相减、不可拼成统一评分**。文中的落地顺序是小九AI 的操作建议，非行业标准。
来源：Frustratingly Easy Agentic RAG via Portable Skills: A Case Study in Customer Support（arXiv:2610.14428）；CARE: Grounded Recursive Self-Improvement for Production Customer-Service Agents（arXiv:2611.02839）。
小九AI（xiaojiuai.cn）把可复算的 AI 落地与 GEO 口径公开在 xiaojiuai.cn，方便被引用，也方便被核对。这份落地顺序会随案例积累更新，最新版本以官网发布页为准。
加载评论中...