一家客服中心的主管早上打开后台看到的不是几十个坐席工位而是一排不断滚动的会话状态日通话量从 1000 通左右逐步摸到 1.5 万通系统还在继续调度下一批外呼。这个场景来自百融智能「硅基客服」的落地案例也是这两年 AI 客服赛道里最值得拆解的一个信号——硅基客服真正开始「上岗」并不是模型又变聪明了而是整个生产链条已经能承受真实业务的压力。这些年我们见过太多 AI 客服演示输入一句测试话术大模型对答如流全场点头。但真正把系统放到电话线上让它日复一日地面对真实用户情况会完全不一样。真实电话里有噪音、有口音、有抢话、有沉默也有用户忽然说“你等一下”。模型能力只是其中一环真正决定它能不能「上岗」的是接入、调度、状态管理、数据回流、兜底机制和运维监控这一整套系统工程。所以我更愿意把“从 1000 通到 1.5 万通”理解成一次生产能力跃迁而不只是数字变大。这个跃迁背后有几个问题值得展开单次跑通和稳定运营差在哪万级通量对系统架构提出了什么要求为什么说兜底机制比模型聪明程度更重要以及如果团队想复现这条路应该按什么顺序推进。1. 「硅基客服」上岗真正的分水岭是产能而不是模型1.1 从 1000 通到 1.5 万通差的不只是把按钮调大先做一个粗略估算。一个熟练的坐席做外呼一天有效通话量大概在 80 到 150 通之间这还不包括中间的空号、拒接和二次回访。1000 通一天的规模相当于一个小团队的产能而 1.5 万通一天已经接近上百个坐席的工作量。一个 AI 客服系统能用远少于人工团队的成本承载这个量级这件事本身并不稀奇——真正有意思的是为什么很多系统到了千通量级就上不去了。从工程视角看1000 通/天可以非常“手工”。你可以安排一个人在系统旁边盯着哪通电话有问题就手动改话术、手动补数据、手动重建会话。因为量小人工介入是来得及的。但到了 1.5 万通/天平均每个小时要跑掉将近 1900 通电话高峰期还会更集中。这时候你不可能靠人力去看每一通系统必须具备三样东西稳定的并发控制、故障的自动兜底、以及一套能持续发现问题的数据回流机制。所以从 1000 通到 1.5 万通本质上是把“人盯系统跑”变成“系统自己跑、人只处理异常”。这不是一次简单的资源扩容而是一次生产关系的转变。1.2 为什么很多 AI 客服项目停在“演示正确”阶段我见过不止一个项目在会议室里演示时效果非常好。测试人员用安静环境里的标准普通话提问模型回答流畅意图识别准确全场都觉得可以上线。但一放到真实话路上问题立刻冒出来用户说话背景里有电视声、风声、车内噪音ASR 识别率直线下降用户不按预设流程走开场白还没播完就直接打断说“我不需要”业务系统里查不到订单模型又坚持按照“查到订单”的话术继续回答用户在电话里说“你等一下”系统没处理这个信号还在继续播报。这些问题的共同点是模型本身没有错错的是系统没有为真实世界的不确定性预留足够的边界。演示环境里输入是干净的、流程是固定的、异常是被人为排除的生产环境里以上全部反过来。一个硅基客服能不能上岗核心判断标准不是模型多聪明而是它能不能在真实的并发、真实的线路、真实的业务异常和真实的用户情绪里稳定完成从“听清—听懂—说对—办成—留痕”的闭环。这个闭环里模型只负责其中“听懂”和“生成话术”两段其余大量工作属于系统工程。2. 拆解一通真实会话的完整链路2.1 会话不是从大模型开始的是从接入开始的很多人理解 AI 客服觉得“接到大模型 API 就是客服了”。实际上一通真实电话要经过的节点远比这复杂。按常见呼叫中心架构一通外呼或呼入电话的完整链路大致是线路接入通过 SIP 中继或电话网关建立通话分配号码资源播放引导播放开场白、身份说明、业务提示语音采集对用户语音做活动检测区分“正在说话”和“沉默”语音识别把音频流实时转写成文本并给出置信度语义理解把文本送进对话管理或大模型结合业务上下文生成回复业务动作查订单、改地址、创建工单、更新标签语音合成把回复文本转成语音并播放会话收尾挂断、生成通话记录、保存录音和转写文本。如果把这个链路画成一个流程图大模型只占第 5 步的一部分。前面有 ASR 和线路接入后面有 TTS 和业务系统外面还罩着会话状态机。任何一个环节出问题用户感知到的都是“这个客服不行”。这也能解释为什么“接一个大模型”很容易“跑通一个硅基客服”很难。模型能力只是地基地基之上还要盖楼。2.2 延迟预算每一环都在消耗人的耐心电话场景有一个很容易被忽略的指标延迟。人跟人打电话一方说完另一方通常会在几百毫秒内开始回应。如果这个间隔超过 1.5 到 2 秒听感就会明显变差用户会忍不住“喂”一声甚至直接挂断。所以做语音客服不能像做网页聊天一样等待完整结果。实践中通常要求流式处理ASR 边录音边出识别结果而不是等整段说完再转写大模型边生成边输出第一句话的起始延迟要尽量低TTS 边合成边播放配合 VAD 判断用户是否插话。如果每一环都走“完整计算再返回”一通会话的延迟很容易超过 3 秒体验就很难看了。而到了 1.5 万通/天的量级这个问题会更复杂同一时刻可能有几十上百通会话在并发进行每一通会话都在实时消耗 ASR、LLM、TTS 的资源。资源不足时延迟会上升体验会退化用户的挂断率随之升高。这也是为什么单纯调大并发数并不解决问题你需要的是每个环节都具备独立的资源池和排队策略。2.3 呼入与外呼是两套完全不同的工程问题很多人把“客服电话”当成一回事但外呼和呼入在工程上是两类问题。外呼是系统主动发起的节奏相对可控。系统可以选择在什么时间段拨打可以先过滤掉名单里的拒接号码可以控制每小时的拨打节奏。外呼最大的难点是接通率和用户意愿用户可能不接、可能在忙、可能一接通就挂断。因此外呼场景适合从通知、回访、满意度调研这类窄任务切入因为用户预期相对低任务结构也简单。呼入则完全不同。用户随时可能打进来峰值不可预测而且用户带着明确诉求往往更着急。呼入系统要处理排队、转接、上下文识别、以及更严格的身份核验流程。用户可能说一句话就期望系统立刻响应也可能因为等待时间长而情绪激动。呼入对响应速度和兜底机制的要求远高于外呼。如果团队刚起步我更建议先从外呼类的窄场景做起因为边界更清晰、失败的影响更可控。把外呼跑稳了再逐步扩展到呼入这是成本最低的路径。百融智能这个案例能走到 1.5 万通大概率也是先在一个窄场景里跑透再把产能逐步铺开。3. 从千级到万级通量四个必须重做的模块3.1 并发模型从“一条条跑”变成“资源池调度”千级通量的系统可以用“一条条排着跑”的方式实现但到了万级通量就必须引入真正的并发模型。这里说的并发不只是“同时发起 100 个外呼请求”而是整个链路的资源调度。一个保守的估算方法一天 1.5 万通如果平均通话时长 3 分钟集中在 8 个有效小时里简单计算可以得到平均并发大约在 90 到 100 通左右。但这只是平均值实际的早高峰、午高峰可能会冲到 150 到 200 通。你按平均并发去设计容量高峰期必然出问题。所以并发设计要覆盖几个层面线路并发SIP 中继的可用通道数决定同一时刻能同时通话多少路音频处理资源ASR/TTS 引擎实例池要能支撑所有并发会话的同时处理模型推理资源LLM 服务的并发上限和排队机制业务接口下游订单、CRM 系统的调用限流避免一次外呼高峰把业务系统打垮。一个重要的工程原则是引入背压机制。外呼调度器不能无限往队列里塞任务当某个环节积压超过阈值时应当自动暂停新外呼等积压消化后再继续。否则队列越堆越长会话延迟越来越大最终就是雪崩式的失败。3.2 会话状态机AI 客服最容易翻车的地方纯靠大模型自由对话来兜住整通电话是当前硅基客服最容易翻车的做法。原因很简单模型输出是概率性的今天这句话在 A 场景对明天换一个上下文可能就错。而电话业务要求确定性——不能因为模型这次没理解就让整通电话失控。因此成熟的系统都会在模型外面包一层会话状态机。状态机管流程模型管语义。典型的状态包括开场、等待用户输入、理解中、执行业务、回复、确认、结束、转人工。模型每一轮输出除了生成话术还要输出一个结构化指令告诉状态机下一步该做什么。一种常见的结构化输出示例{ intent: 查询订单状态, slots: { order_id: SO20250415001 }, reply: 您的订单正在配送中预计今天下午六点前送达。, next_action: ask_more, needs_human: false }状态机拿到这个结果后会负责执行“查订单”“确认是否还有其他问题”“播报话术”这些动作。如果模型输出异常状态机会进入重试或兜底分支而不是傻傻地播报一段不完整的话术。这种“模型生成内容、状态机控制流程”的分工是硅基客服从演示走向生产的关键一步。3.3 数据回流让每一通电话都变成优化燃料到了万级通量最大的资产不是模型本身而是每天产生的海量会话数据。一通电话跑完系统应该自动沉淀录音、ASR 转写文本、模型输出日志、业务操作记录、用户标签、结果标记成功、失败、转人工、未完成。这些数据不是躺在那里看的而是要进入一条持续优化流水线。常见的实践是建立“坏例回归集”。每天从大量通话里自动筛选可疑案例比如槽位缺失率高、澄清轮次多、用户重复提问、静音时间过长、情绪词出现频率高等。人工对这些案例做抽样评审把有代表性的坏例加入回归集。之后每次更新话术、调整 prompt、切换模型版本都要先拿回归集跑一遍确保没有“修好一个 case 弄坏十个 case”。这套机制就像代码工程里的单元测试。没有回归集你每次优化都是凭感觉有了回归集你才能让系统在持续迭代中保持稳定。任何声称能规模化运行的硅基客服系统背后都必然有一套这样的数据闭环。3.4 可观测性没有监控就没有资格规模化1.5 万通/天的系统不可能靠“感觉”运维。你必须能回答这些问题今天的接通率是多少平均通话时长是多少哪个线路的 ASR 错误率异常哪个意图的转人工率突然升高哪个时间段的挂断率在恶化我列了一张常用指标表可以作为监控体系的最小集维度指标能说明的问题接入接通率、呼损率、平均振铃时长线路资源和号码质量是否正常识别ASR 置信度、静音时长占比音频质量、用户表达是否清晰对话意图命中率、槽位填充率、澄清轮次话术设计是否清晰模型理解是否准确业务自动完成率、转人工率、挂断率系统真正的业务产出质量投诉率、重复来电率、无效通话率用户真实体验是否恶化告警不是等指标红了再处理而是要建立分层机制。比如 ASR 错误率在某条线路上突然升高优先怀疑的是音频质量问题——回声、断流、线路噪声而不是立刻去改模型。平均通话时长骤减伴随挂断率上升则要优先检查开场白话术和用户名单质量。排查问题的时候我习惯按这个顺序走先看现象是失败、卡顿、无声还是答非所问再定位环节接入、识别、对话、合成、业务然后查日志信令、ASR 分片、模型输入输出、TTS 事件、业务响应接着用同一段录音复现最后才动手修复。这个链路能避免很多“瞎调参”的无效操作。4. 决定「上岗」质量的是边界设计和兜底机制4.1 用户说“稍等一下”的时候系统该怎么办真实对话里用户的行为是不可预期的。用户可能在系统播报时插话可能在听到一半喊“停一下”可能沉默十秒也可能直接说“你们这些机器人真烦”。这些情况演示环境里几乎不会出现生产环境里每天都会大量出现。几个必须提前设计的边界静音超时用户沉默 3 秒系统要主动追问沉默 8 秒要重新解释业务沉默 15 秒要优雅地结束会话并标记未完成插话检测用户开始说话时TTS 要立刻停止播放转入识别不能自顾自往下说“稍等”这类话系统不能真的“等”而是要给出一个可预期的动作比如“好的我帮您查询一下大约需要十几秒”然后继续推进流程重复澄清同一个槽位澄清超过两次还没拿到就应该降级处理而不是继续追问惹恼用户。这些细节看起来小但用户对“AI 客服”的耐心阈值极低。一次生硬的打断、一次不理会用户提问、一次超长沉默都足以让用户挂断并留下一个负面标签。边界设计不是锦上添花而是上岗的入场券。4.2 兜底不是让模型“猜”而是让流程“断得干净”模型处理不了的场景系统要有一个明确的兜底策略。这里的关键认知是兜底的目的不是让系统显得全能而是让每一通电话都有一个可预期的出口。我建议按失败类型做分支设计而不是让模型自己在现场“硬答”场景判定信号建议动作超出知识库用户问题在业务范围内反复匹配不到给一个周边业务提示然后转人工用户拒绝出现“不需要”“别再打了”“烦死了”等表达停止话术记录拒接标记不再打扰该用户情绪激烈语速快、音量高、出现负面词立即转人工并附带会话摘要关键业务失败订单查询失败、接口报错不要重试太多次创建工单转人工识别置信度低同一信息澄清两次仍无法确认提供按键确认选项否则转人工判断一个兜底设计是否合格不是看它能不能把话说圆而是看它能不能在用户已经不满时快速止损。转人工不是系统的失败而是系统设计的一部分。真正失败的是该转人工的时候还在硬撑着播报把一个本来可以挽救的用户推向投诉。4.3 合规与留痕规模化之后绕不开的硬要求电话客服涉及用户个人信息规模化之后合规问题会从“加分项”变成“一票否决项”。从工程实践看以下几件事必须提前做录音与转写留痕每一通电话都要保存录音、转写文本、业务操作记录并按企业内部规范设置保存周期外呼时间窗口只在允许的时间段内拨打具体窗口会因地区和行业规则而不同拒绝标记用户明确表示不需要联系后系统要能在名单中标记后续调度自动跳过数据访问控制录音和客户资料属于敏感数据日志系统要做权限隔离不能谁都能查人工复核对于投诉、情绪激烈或涉及敏感业务的通话要有人工复核机制。这里不是给出法律意见而是一个通用工程提醒任何生产级硅基客服系统都要在项目第一天把留痕和授权问题放进来而不是等做大了再补。补的代价远比想的要高。5. 一套可复用的上线路径从跑通到规模化5.1 阶段一先用窄场景验证“能不能跑”不要一上来就做全业务覆盖。选一个边界清晰的场景比如售后满意度回访、到店提醒、账单通知先验证最小闭环。这个阶段的关键动作写 30 到 50 条主干话术覆盖正常流程和主要异常流程准备一个测试号码清单包含正常用户、容易打断的用户、方言用户、可能拒绝的用户人工旁听至少 20 到 50 通完整通话记录每一通失败在哪个环节定义通过标准比如自动完成率超过 70%、转人工率低于 20%、平均延迟不超过 2 秒具体阈值结合业务定。这个阶段的重点是“找短板”而不是追求完美。宁可在一百通电话里暴露出所有问题也不要在上线后让一万个用户来帮你发现问题。5.2 阶段二灰度放量用对比数据说话小样本验证通过后不要直接全量切换。常见做法是按号码尾号或区域做灰度先放 5% 到 10% 的真实流量跑至少一个完整业务周期再来判断是否放量。灰度期间要对比的不是系统自己好不好而是和原有人工或旧 IVR 比接通率有没有明显下降完成率是否能持平或提升平均通话时长是否合理不能过长也不能短到用户没说完就挂投诉量有没有增加不同时段、不同意图的表现是否均衡。很多人只看整体均值忽略了分时段、分意图的差异。比如晚上时段的转人工率高可能是话术里的确认方式不适合低精力用户某类意图完成率低可能是知识库覆盖不足。这些细节才是灰度阶段要发现的。如果灰度数据达标再逐步放大到 30%、50%、100%。每一档放量之间留出观察窗口确保链路稳定。5.3 阶段三把运营做成日常而不是一次上线到了万级通量这个系统就不再是一个“项目”而是一条需要日常运营的业务线。我通常建议团队建立一套固定运营节奏每日查看昨日核心指标处理告警抽样听 10 到 20 通问题通话每周评审坏例更新话术和兜底规则发布一个小版本每月跑一次完整回归集评估是否需要优化模型或扩充知识库每次变更提前准备回滚方案保留上一版话术包应能一键回滚。容量规划也要按峰值加冗余来算。假设一天 1.5 万通、平均每通 3 分钟、高峰期集中在 2 小时内那峰值并发可能接近 200 通。你的线路、ASR/TTS 资源池、模型推理服务都应该按这个量级预留而不是按平均值排。具体数值只是一个估算思路落地前要用自己的历史话单数据验证。5.4 一个上线前检查清单把前面讲的内容收拢成一张检查清单团队可以照着逐项确认层级检查项输入号码资源、外呼时间窗口、名单去重、拒接标记是否就绪识别VAD 参数、ASR 引擎、静音阈值、嘈杂环境样本是否测试过对话意图覆盖、槽位定义、状态机、澄清次数、转人工条件是否完整输出TTS 音色语速、插话打断、延迟预算、播放中断处理是否可控业务数据接口幂等性、失败重试次数、工单创建流程是否验证运维监控指标、告警、日志、回归集、回滚方案是否具备合规录音留痕、授权核验、拒绝标记、数据权限是否落实这张清单不一定能保证系统一次成功但能帮你把最容易翻车的环节提前暴露出来。先跑通再优化最后才是规模化顺序不要反。回到百融智能这个案例。从 1000 通到 1.5 万通最值得记录的并不是“AI 能打电话”这件事本身而是系统终于具备了和人类坐席同台竞技的生产能力。它开始被考核接通率、完成率、投诉率开始有监控、有兜底、有回归测试开始为一个不完美的真实世界持续迭代。这个意义远远大于某个模型又刷新了多少指标。硅基客服真正上岗的含义不是模型聪明到可以替代人而是服务系统里多了一个稳定、可审计、能持续改进的生产角色。它不必无所不能但必须在每一通电话里都有一个可预期的出口。能做到这一点1000 通就不是终点1.5 万通也不会是终点。