客服自动回复的“首条延迟”该压到多少？一次速度与拟人化的取舍

做客服自动回复系统，团队最初的指标很朴素：把首条回复延迟压短。链路拆完、逐段优化之后，我们确实做到了全链路一秒内出话。但上线后的对话数据给出了相反的结论：回得太快的对话，反而更早终结。这篇是一次"速度与拟人化"取舍的工程复盘。

一、全链路拆解：压进一秒在技术上完全可行

一套典型的自动回复链路由四段组成，每段都有明确的优化空间：

• 消息捕获：轮询聊天窗口变化，拿到"有新消息"事件。500ms 的轮询间隔意味着平均约 250ms 的等待，换成事件驱动监听后可压到 50ms 以内。
• 内容读取：只有截图可用时走 OCR，一张聊天截图约 300-500ms；能直接读控件文本则只需几毫秒，这一步的选型差距比换模型还大。
• LLM 生成：带上下文的短回复，首 token 通常在 300-800ms；换更小的模型、砍 prompt 长度、改流式输出，都还有余量。
• 窗口回填：模拟键盘输入按 20ms/字符计，一条 50 字的回复要 1 秒；改成剪贴板粘贴加回车，可压到 100ms 以内。

逐段做完，整条链路一秒内出话在工程上完全可行。这套优化花了两周，最后却发现真正的问题不在链路里。

二、实测数据：秒回是机器特征，不是服务质量

有位买家 23:47 发来一句"这个多少钱，能便宜点吗"。一秒后，他收到一条带完整报价、阶梯价与售后说明的回复。他的下一句是："机器人吧？"这条对话没有再继续。

复盘时我们回放了一批同类 case，模式相当一致：响应在一两秒内、且首条就是完整答案的对话，买家发出第二句的比例明显偏低。原因不难理解——真人客服不可能秒回。"收到消息、看清问题、想出答案、打字发出"这件事存在生理下限，秒回等于把"我不是人"写在对话里。更麻烦的是，完整答案本身也在帮倒忙：价格、阶梯、售后一次给全，买家问一句得到一页内容，接话的钩子全被堵死了，对话自然就在"收到报价"这一步结束。

后来我们做了对照：两个版本各跑数千条真实询盘，A 版秒回加完整答案，B 版先延迟 8-15 秒、先回一句"在的，稍等"，隔几秒再发正式答案，统计口径就一条——买家是否发出第二句话。结果 B 版的对话继续率明显更高，差距大到不需要显著性检验来说服任何人。买家在等待里完成了一次心理确认：对面有人在。而"在的，稍等"恰好还原了真人客服接到消息后的第一反应。

三、提速的正道：砍工程段，而不是压模型

这里有一个常见误区值得纠正：想让响应更快，性价比高的方向往往不是压 LLM 推理延迟——每次调用省一两百毫秒已经非常吃力——而是砍链路里的工程段。模型换代的收益是线性的几十毫秒，工程段砍掉的是数量级的等待。同理，OCR 换文本读取省几百毫秒，剪贴板替换逐字输入省一秒，这些"不起眼"的工程段加起来，往往比换任何模型都值钱。

以我们自身为例。早期版本里核心逻辑是一个 35000 行的单包结构，任何一处改动都要全量重编译，一次 164 秒。调延迟参数时改一行等三分钟，没人有耐心多试几组，所谓调优实际上是在猜。后来把纯逻辑核从工程中拆出，单独增量编译，同样改一行只要 3.4 秒——164 除以 3.4，48 倍的差距。改完到验证的循环从"泡杯咖啡"变成"一眨眼"，调参才真正变成调参。

这件事的意义不在编译本身：开发迭代速度决定了响应速度优化的上限。改一次配置要等三分钟，你只会试一次；三秒就能见效，你才会把延迟从 500ms、300ms、150ms 一路试下去，找到对话继续率的拐点。很多团队的延迟优化做不动，瓶颈不在模型，而在缺少一条能快速验证的反馈回路。

四、最终取舍：延迟不是一个数，而是一张分层表

回到标题的问题：首条延迟该压到多少？我们的答案是：故意不压。首条回复拟人优先，保留 8-15 秒的自然延迟，并拆成"在的，稍等"加正式回答两段；后续消息则尽快回，因为对话进行中真人客服也是越聊越快的。

策略固化为分层配置：

latency_policy:
# 首条回复：拟人优先，保留打字与思考时间
first_reply:
delay_s: [8, 15] # 随机区间，避免固定值
ack_message: "在的，稍等"
answer_delay_s: [4, 10] # 正式答案再隔一段
follow_up:
delay_s: [2, 6] # 对话进行中，快但留间隔
long_question_extra_s: [1, 3] # 长问题加"读题时间"
long_answer:
simulate_typing: true # 长回复按字符数模拟输入耗时
cps: 8 # 每秒约 8 字，接近真人手速

对应到"什么该快、什么该慢"，我们内部用一张表对齐认知：

这套分层的背后只有一条原则：回复节奏对齐真人客服的工作节奏，而不是对齐机器的性能上限。机器该快的部分全部压短，作为内部耗时藏起来；机器不该快的部分——人对人的反应时间——明确保留出来。上线后这套分层没有再动过：技术指标上它"变慢"了，业务指标上它活了下来。

另外两点经验值得记下。其一，延迟区间必须是随机的，固定 10 秒和固定 1 秒一样是机器特征，真人的响应时间天然带着抖动。其二，深夜时段可以适当放宽区间，凌晨咨询的买家对"人还在不在"更敏感，一段符合作息的等待反而更像真人在岗。如果只记住一件事，那就是：秒回不是能力，是特征。

参考文章

延迟分层里用到的报价组织与询盘应答节奏，两篇文章有更细的展开：微信 AI 客服价格与报价拆解 讲报价内容如何组织，售前咨询自动化：询价砍价场景的应答策略 讲询价砍价的应答节奏，与本文的延迟分层放在同一套策略里看会更完整。