90 天把 Agent 接入客服流程：一份真实的一线复盘

过去三个月，我们把一个基于大模型的 Agent 接入了真实客服流程。这不是 demo，是每天在跑的线上系统。这篇文章复盘整个过程，重点讲三个关键决策、踩过的坑，以及最后量化的收益。

一、我们为什么做这件事

客服是一个典型的「高频、标准化、可拆解」场景。真正的挑战不在模型能力，而在如何把不确定性收敛到业务可接受的范围。

核心判断：Agent 的价值不是「替代人」，而是「把人从重复劳动里解放出来」。

二、三个关键决策

1. 从「端到端」退到「半自动」

一开始我们想做全自动闭环，两周后就退回来了。原因很简单：全自动的失败成本不可控。最终采用「Agent 起草、人工确认」的半自动模式。

2. 把工具调用的权限收敛到最小

Agent 能调用的 API 越少，越容易排查问题。我们严格限制它的写权限，读权限按场景白名单开放。

3. 用评测集当「上线门槛」而不是「事后指标」

我们建了一套包含 500 条真实客服对话的回归评测集，任何 prompt 或模型的改动，先过评测集再上线。

三、踩过的坑

• 幻觉在长链路里会放大：单步准确率高，不代表整条链路可靠。
• 成本不是线性的：上下文越长，成本增长越快，需要主动做摘要与截断。
• 监控要跟着业务走：模型层面的指标和业务指标经常对不上。

四、量化的收益

首响时长：8min → 0.5min
人工介入率：100% → 42%
单通对话成本：¥3.2 → ¥0.7
客户满意度（CSAT）：4.1 → 4.3

五、给后来者的建议

先把「人机协作」做扎实，再谈「全自动」。模型的进步会不断抬高天花板，但工程和产品的功课，一件都省不了。