正在加载，请稍候
把客服智能体放进小程序端，难点不在模型而在链路预算：首响、会话状态、记忆分层、消息通道边界与转人工兜底，五道取舍都在这里。
某零售客户的客服负责人给我们提了一个指标：用户在对话框里发出第一句之后，如果 1.5 秒内看不到字，他大概率就退出了。
这句话把一个「AI 客服 Agent 搭建」的问题，从模型选型变成了链路预算问题。下面是我们把客服智能体放进小程序端时，反复权衡过的五道取舍。
该客户是小程序商城的售后入口，大促期间人工客服排到 8 人。我们接手前拉了一版进线分类：物流进度、退换货规则、优惠券能否叠加这三类问题，占了全部进线量的七成左右。
这几类问题答案固定、上下文浅、用户等不了，正好是能交出去的部分。
下面是上线前后的区间估算。需要说明：这些数字来自我们 2026 年上半年几个零售类小程序的交付复盘，是区间而非单一客户的精确统计，正式立项时请以贵方自己的埋点为准。
| 指标 | 上线前（区间估算） | 上线后（区间估算） |
|---|---|---|
| 客服入口日会话量 | 300–600 | 1200–2600 |
| 转人工占比 | 100% | 18%–32% |
| 夜间时段可服务性 | 无人工在线 | 智能值守，高优才转人工 |
| 首响 P95 | 人工 40–120 秒 | 1.2–1.8 秒 |
会话量涨了三到四倍而人力没有增加。原因不是转化变好，而是进线门槛被拆掉了——用户不再需要先排队等一个真人，才愿意把问题打出来。
这条从工单接入一路走到自动解决率的完整路径，我们之前做过一次更细的拆解，可以对照看 那篇交付复盘。
下面五条，每条我们都试过两端，最后大多落在中间。
| 取舍点 | 端侧做法 | 云侧做法 | 我们的落点 |
|---|---|---|---|
| 会话状态 | 本地缓存加内存态 | 服务端会话表 | 最近若干轮落端，全量落云 |
| 首响预算 | 端侧话术直出 | 服务端预取加流式 | 端侧兜底，主链路走流式 |
| 记忆分层 | 单会话内存 | 知识库加用户画像 | 会话层、用户层、业务层三层 |
| 能力边界 | 页面内组件 | 订阅消息、客服消息 | 应答在会话内，触达走订阅 |
| 人工兜底 | 前端规则判断 | 服务端灰度开关 | 双置信度触发，开关在服务端 |
小程序的运行环境决定了端侧状态不可靠：用户切后台、杀进程、冷启动，内存态全部丢失。
我们早期把最近 6 轮对话存在本地缓存，冷启动读回来接着拼上下文。上线两周就发现问题——同一用户换设备或清缓存之后，会话直接断掉，机器人像失忆一样重新问「您遇到什么问题」。
最终落点是最近若干轮落端、全量落云。端侧那份只用于渲染和兜底，丢了不影响业务连续性；服务端保存完整会话，用于后续分析与转人工交接。
包体是第二个约束。把提示词模板、知识切片、示例样本打进主包，主包很快膨胀到必须分包，而这类内容更新频繁，打包进客户端意味着每次改知识都要重新提审。我们把它留在服务端，靠接口下发。
首响由三段组成：网络往返、检索、模型首字节。
等用户发问之后再走检索，等于把三段串成一条链，任何一段抖动都会直接叠到用户脸上。
我们的做法是拆成两路。进入客服页时，服务端按用户画像与最近订单预取一批候选切片，这一次请求不阻塞输入；用户真正发问后，检索只在候选集里重排，检索耗时和输入长度都小一个量级。
端侧同时保留一组固定话术做即时直出。它的作用不是回答问题，是让用户确认系统还活着——这一步对跳出率的改善，往往比把模型换快 200 毫秒更明显。
把整段历史一股脑塞进上下文，成本和延迟都会随轮次上涨，而且到十几轮之后模型反而更容易跑偏。
我们按生命周期分了三层。会话层装本次对话，短 TTL，读写最频繁；用户层装订单、会员等级、历史工单，落库长期保存；业务层装退换货规则、运费说明这类共性知识，走检索而不是走上下文。
「什么时候该落到服务端知识库」的判断标准其实很好定：这条信息下一次会话还可能用到，就落库；只对本次对话有效的，就跟会话一起过期。按这条标准筛一遍，绝大多数项目的记忆量会掉一个数量级。
这一条最容易被低估。小程序侧能做什么是分通道的，通道选错，功能会在审核或运行时被卡住。
官方文档把面向用户的消息分成两条线。一条是会话消息：用户主动发起会话后，服务端下发回复，并提供客服输入状态这类交互能力。另一条是订阅消息：需要用户显式订阅，模板必须从类目下的公共模板库中选用，不能自己随意写文案。
两条通道的触发条件、时限和配额都不一样，接入前请以官方文档当次版本为准逐条核对，不要照抄二手博客里的参数。这两份文档分别是 小程序客服消息 与 订阅消息开发指南，服务端下发接口见 发送客服消息 API。
内容安全同样要在链路里留位置。官方服务端 API 提供了文本与多媒体内容安全识别接口，我们把它放在「模型输出到用户」之间做一次过检，命中风险词就降级成安全话术并转人工，而不是直接静默丢弃。
另外注意端侧推理的成熟度。官方文档目录中，端侧 AI 推理能力仍标注为 Beta，并附带算子支持列表与模型量化说明。这意味着不要为了省一次网络往返，就把主推理链路押在端上。
转人工不能只靠一句「转人工」的关键词匹配，那样用户稍微换个说法就转不过去。
我们用双置信度触发：模型自评置信度偏低，或者检索相似度低于阈值，任一命中就转；两条同时命中则优先转，并自动带上会话摘要给人工坐席，避免用户把问题重述第二遍。
灰度上先走白名单放量：内部账号、单个城市、最后全量。灰度开关放在服务端配置，端侧不参与判断——出问题只改一个开关，不需要重新提交小程序审核。这套思路和我们另一篇里总结的 从演示脚本走到可治理产线 是同一条线。
站内另一篇讲 AI 能力集成选型的文章，回答的是「一个系统里要接几种模型能力、怎么选、成本怎么摊」；本篇只回答一个问题：客服这个场景，会话链路怎么走。
换句话说，那篇管选型，这篇管会话。如果你还在纠结用哪家模型，建议先读选型那篇；如果模型已经定了、卡在首响和上下文上，本篇的五道取舍可以直接拿去对表。
另外，小程序端本身的架构层面还有一组独立的取舍（分包策略、端侧能力边界、渲染方式），细节写在 小程序三种架构对比 里，本篇不重复展开。
我们踩过最贵的一个坑在早期版本：为了「回答准确」，把整份售后知识库大约两百多篇文档直接拼进系统提示词。
结果是三件事同时发生。输入长度涨到几万字符，模型首字节时间从 1 秒级掉到 4 秒以上，用户等不下去直接退出；单次会话成本随上下文线性上涨；更麻烦的是，库里同时存在新旧两版规则，模型在互相矛盾的上下文里反而答错了本来能答对的问题。
改成检索之后，同一批问题的答案准确率没有下降，首响回到目标区间，单次成本也降下来了。教训可以浓缩成一句话：知识不该进提示词，该进索引。
一个能上线的小程序端客服智能体，我们通常按下面五块交付。工期是区间估算，实际取决于知识库整理质量与是否需要对接既有坐席系统。
整体 4 到 8 周是常见区间。知识库本身脏乱的项目，光是把同一规则的新旧版本合并，就可能占掉一半时间——这部分工作没有捷径，也最值得先做。
端侧只负责渲染和兜底，检索与推理建议放服务端。原因有三个：小程序运行环境的包体与内存有限；会话状态在冷启动后会丢；模型密钥不能放在端上。
我们把 1.5 秒内的首字输出当作目标线，2.5 秒以上用户流失明显。建议先埋点测出你当前的人工首响，再据此定目标，不要直接抄行业数字。
不是。前者是会话内的应答能力，后者是主动触达通道。两者的触发条件完全不同，主动推送必须走用户已订阅的模板，不能拿会话内的授权去推。
取决于三件事：知识库整理量、是否需要对接既有坐席系统、是否需要多渠道覆盖。三者排列组合下来差别很大，建议直接提供现有工单样本，按样本估比按功能清单估准得多。
不建议一开始就设低目标。更稳的路径是先让机器只答能答的那部分，等转人工率稳定之后，再按类别逐类收口。
如果你正在评估小程序端客服方案，可以把现有工单样本发我们一份，我们按样本给一版链路设计和工期估算；也可以先看 完整案例 里同类项目的交付清单，或者直接 私信询价。