客户说完“帮我查一下订单”，电话里先静了两秒，机器人又从头念一遍欢迎词。客服主管很快会发现：这个系统的声音很好听，工单却越积越多。10月20日 ElevenLabs 推出 Eleven Realtime v1 Mini 和 v1 Max，让语音识别、轮次判断、对话推理和语音输出作为一套实时服务交付。值得购买的能力，是把交互链条的调优责任集中到一个系统；值得保留的边界，则是业务状态、工具授权、渠道接入和失败后的人工处理。把这两件事混在一起，试点时很容易听起来不错，上线后却查不到一张正确的单。[1][2]
ElevenLabs把 Mini 定位于成本敏感的助手、教育与互动角色，把 Max 定位于客服、销售线索筛选和多步任务。两款模型支持90多种语言，可在 ElevenAgents 平台使用，也提供遵循 OpenAI Realtime 事件协议的 WebSocket API。官方博文转述 Artificial Analysis 的独立评测：Big Bench Audio 的1000道语音推理题中，Max 正确率98.8%，Mini 为75.9%；首段语音的平均等待时间分别约0.57秒和0.62秒。工具任务完成率则是87.1%和60.3%。这些是公布的测试项目及统计口径，一次真实客户通话的耗时还要加上传输、检索、工单系统响应和确认操作。[1]
快不快，要从用户停嘴那一刻算起
“首段语音等待”适合回答模型何时开始说话；客服的体验还受到其他计时点支配。线路什么时候传来第一帧有效音频？用户犹豫、吸气、说“呃”时，系统会不会抢话？工具请求发出后，到后台返回一条可读的订单状态要多久？合成语音播了三秒时客户插话，它能否立刻停止并保留已经说过的内容？这些点串起来，才是一轮有效服务的延迟预算。
建议把一次通话拆成可记录的时间戳：音频进入、语音活动检出、轮次判定、首次模型输出、首次可播放音频、工具请求、工具回执、客户确认、最终业务回执。每段记录 p50、p95，另记打断后停止播报所需时间。高峰期和空闲时段都要测；把移动网络抖动、电话线路压缩、噪声和并发纳入样本。厂商公布的0.57秒值得放在模型对比表里，却不能填进企业的整通电话服务承诺。
发布材料称 Full-Duplex-Bench 涵盖停顿、轮流发言、打断和附和语，Mini 得95.8%，Max 得94.1%。这组结果很有意思：复杂任务上 Max 明显更强，轮次互动这一项 Mini 却略高。选型时就该按任务切分，不能把“高配”理解为所有指标同时占优。[1] 门店营业时间问答、课程练习陪伴可先试 Mini；查询账务、跨系统核验和多步交互再让 Max 进入对照。服务等级由本地真实对话集决定。
一套服务的内部，仍然有多个可失败的环节
ElevenLabs 的兼容指南给了一个容易被忽略的技术事实：Realtime v1 Mini 和 Max 使用经过端到端优化的级联架构，各组件仍是独立模型，并非单个融合模型。[3] 这种产品设计的好处是团队少做一堆 ASR、VAD、LLM、TTS 的选配和调参。业务侧仍须排查识别错词、轮次错判、知识库检索遗漏、工具超时与读错金额等不同原因。平台能替团队管理组件组合，不能替企业辨认自己的订单真相。
想象一通真实电话：客户报了订单尾号，背景里同事喊了一句“先别付”。系统该先确认尾号，还是把旁人的话当成客户指令？随后客户说“刚才我说错了，是另一笔”，系统必须撤销待查询状态；如果工具已准备提交退款，应要求新的明确确认。这里有会话事件与业务事件两条线。会话可以在对话中被修正；资金、权限、删除等写操作需要独立的授权、幂等键和回执。模型说“好的，已经处理”不能充当操作成功凭证。
这也解释了为什么“电话接通了”尚不足以验收。客服系统需要一个可转人工的状态包：已核验身份、客户诉求、查过哪些记录、哪些内容尚未确认、哪些动作已经提交。人工接手后不必让客户从头复述，事后还能追踪到底是谁修改了订单。语音系统若没有这一层，只会把原来在网页聊天里发生的错误带到电话里，速度更快、纠错更慢。
两个入口，意味着两套工程账
在 ElevenAgents 中选择 Realtime 模型，可以借用平台已有的电话、网页、WhatsApp、CCaaS 渠道，以及工作流、知识库、护栏、测试和监控。通过 Realtime API 接入，则是直接用 WebSocket 处理音频与事件。官方明确：目前这个 API 只走 WebSocket；既有 WebRTC 接入要迁移，且 API 本身与 ElevenAgents 平台分开，渠道和知识库等能力需要自行搭建或改用平台。[1][3]
“兼容 OpenAI Realtime”主要是事件协议和 SDK 接口层面的便利。官方迁移指南的浏览器示例要求服务端先签发短期 client secret，不把长期 API key 发到浏览器；WebSocket 下音频采集、播放需要自行接线，示例使用24kHz PCM16。迁移之前列一个清单：原客户端依赖哪些事件、音频格式、转写文本、工具结果和中断语义；逐条跑回归，再检查鉴权与日志脱敏。更换 endpoint 可以是一次小改动，让浏览器、电话桥接、录音策略和工单系统整体迁移则是一项集成工程。[3]
模型运行模式也会改变已有配置的控制权。官方文档列出，Realtime 模式由平台管理底层 LLM、推理预算、TTS、ASR 等参数；系统提示、声音、工具、知识库、轮次设置仍可用。已经深度依赖自有 LLM、特定 TTS、工作流节点覆盖模型配置的团队，可能需要维持 Custom 模式。Realtime 模式中的代理转接目前只支持同模式代理；Max 要求 token 上限至少1024或不设限制。发布时平台会校验这些约束。[2]
这不是文档角落里的“小字”。一个企业原本用自建模型承载客户知识，又把支付与工单工具接在同一套工作流上，迁到 Realtime 后若自定义模型被替换，知识权威和问责方式都变了。采购评审应让业务负责人、信息安全、客服运营一起签收“哪些设置归平台管、哪些仍归企业管”。
账单要按成功任务算
官方价格说明是 ElevenAgents 的标准每分钟费率，另加 Realtime 模型的输入、缓存输入和输出 token 费用；Max 的 token 单价高于 Mini。[2] 一个清晰的试点模型可用三个数字来算：一百通电话的总接通分钟数、模型 token 用量，以及无需人工返工的成功处理数。最后一个做分母。比如 Mini 单通费用较低，但升级转人工、二次回拨和错误重开增加，总成本可能更高；Max 在简单问答上又可能为多余推理付费。
再加几项经常遗漏的支出：电话或 CCaaS 渠道费、CRM 与知识库接口调用、历史录音抽检、身份验证、值班人员，以及监控和质量标注。运营报表应按业务类型区分成本：查询物流、解释账单、修改地址、退款申诉的人工成本差距很大。给所有来电报一个“平均每分钟价格”，财务看着整齐，部署决策却没法用。
合规也直接决定型号选择。官方 Realtime 文档显示，Mini 在美国、欧盟、印度、新加坡的数据驻留环境可用，Max 在印度和新加坡环境不可用；Zero Retention Mode 与美国/欧盟 HIPAA 适用场景仅支持 Max，Mini 不支持。[2] 采购团队应先确认自身地区、录音保存要求、敏感信息处理与合同条款，再测试功能。医院咨询、跨境客服和普通产品陪伴服务不应共用一个默认配置。NIST 的 AI 风险管理框架将设计、使用与评估阶段的风险管理放在同一工作周期，适合作为组织评审清单的依据；具体合规义务仍以实际地区法规与合同为准。[5]
一周试点，拿出能拒绝上线的证据
第一天只建小型样本集：收集经过脱敏与授权的真实通话，覆盖口音、噪音、长停顿、重复提问、强烈情绪和客户改口。为每条样本标出允许回答的问题、必须核验的字段、绝不能自动执行的动作，以及人工接管条件。第二天把任务分层，分别试 Mini、Max 与现有流程；同一问题、同一知识版本、同一后台沙箱，不让新模型占便宜。
第三天开始追踪失败路径。故意让订单接口超时、返回空结果或短暂给出互相矛盾的数据；观察代理会不会编造状态，能否清楚告知客户等待，是否重复发起写操作。另跑中途打断测试：客户说“别取消，我只是想问手续费”，系统已经发出的取消请求能否被拦截？这些记录比一百段顺畅演示更接近运营现实。ElevenAgents 文档确实提供客户端工具、Webhook、代码和 MCP 等多类工具入口；不同工具涉及不同执行位置，权限设置应逐一核查。[2][4]
第六天做一轮盲评，让客服主管听完整通话并查工单回执，评分至少分成：答复准确、轮次自然、隐私风险、业务动作正确、转人工信息完整。第七天决定只开放哪些意图。比如先开放查营业时间、查订单状态；退款只生成待审工单；支付与权限变更暂不开放。上线后保留一组人工基线和一周一复查的异常样本。
还有几种失败，演示环境里很难遇到
第一种是知识版本错位。客服刚改了退换货政策，语音代理的知识库仍保留昨天的条款。它可以流利、迅速地说出过期答案。解决办法是给业务知识源设版本和生效时间；涉及具体承诺时从权威系统读当前规则，通话记录同时保存命中的知识版本。知识库“已上传”只能说明材料在那里，不能说明索引完成、权限正确或者每个答复都引用了最新材料。
第二种是长通话的状态漂移。客户先报旧手机号，随后提供新号码；中途又替家人询问另一张订单。一个自然的声音会让人以为代理已经理解“现在查谁的订单”。应让身份与订单号成为明确的会话状态，而不是靠最近一句话猜测。跨客户切换时清除上一个人的敏感字段，重新进行身份验证。回归测试里专门放入两个订单、多个联系人和半途更改诉求的样本。
第三种是工具回执晚到。用户挂断后，工单接口才返回成功；或代理因超时重试而产生两个相同请求。每项写操作由后台生成幂等标识、保留可查询的操作状态，通话断线也能查到最终结果。给客户的承诺要和系统回执一致：受理、审核中、已办结是不同状态。运营人员还要有失败队列，能处理“语音已答应、系统未落单”的异常。
第四种是不同语言共享一个流程时的细节滑落。支持90多种语言是平台覆盖范围；中文里的同音人名、地址、金额，双语客户中途换语，以及本地口音，会直接影响业务字段。先按目标渠道建立中文和常见混合语言的专门样本。关键数字可以用复述确认或短信核对，抽检时把“语音听起来像真人”和“字段提取正确”分开评分。[1]
这四种问题对应不同所有者：知识管理员负责版本，客服运营负责状态切换规则，业务系统负责幂等与回执，测试团队负责语言样本。试点会议如果只邀请模型采购方，出了问题便没有人能签字关闭缺陷。
Eleven Realtime 的长处，是把语音交互里最费调试精力的时间敏感环节收拢到一起。它最合适的第一份工作，是接住明确、可验证、失败可回退的请求。电话另一端的人往往不在乎后台用了几个模型。他只想知道：自己说错时能改口，系统说“已办理”时真的有回执，出问题时有人接得上。
参考资料
- ElevenLabs，Min Kim，《Introducing Eleven Realtime: a simpler way to build natural voice agents》，2026-10-20；型号定位、语言、评测项目及数字、渠道与 WebSocket 限制。https://elevenlabs.io/blog/realtime
- ElevenLabs 官方文档，《Realtime models》，访问于2026-10-21；模式设置、约束、区域与数据保留适用、计费结构。https://elevenlabs.io/docs/eleven-agents/customization/realtime-models
- ElevenLabs 官方文档，《OpenAI Realtime API compatibility》，访问于2026-10-21；级联架构、短期凭证、音频接口与迁移条件。https://elevenlabs.io/docs/eleven-agents/guides/openai-realtime-compatibility
- ElevenLabs 官方文档，《Tools》，访问于2026-10-21；客户端、Webhook、代码、MCP 与系统工具类别。https://elevenlabs.io/docs/eleven-agents/customization/tools
- NIST，《AI Risk Management Framework 1.0》，2023-01-26；组织层面的设计、使用和评估风险管理。https://www.nist.gov/itl/ai-risk-management-framework