「未来，消费者更可能倾向于与 AI 沟通，而非人工客服，因为这将成为解决问题的最高效途径。」投资机构 Bessemer Venture Partners 在报告里预测。
过去五年，Y Combinator 总共孵化了 80 家语音 AI 项目，其中有近一半共 37 家项目与语音 AI 客服相关，涉及电话外呼、智能客服、餐馆酒店预定、招聘等诸多企业服务场景。
本期 meetup 我们邀请到来自云蝠智能、RustPBX、FreeSWITCH 中文社区、Magics.ai 迈吉客科技、TEN Framework 等项目的创始人和开发者。主题覆盖语音 AI 客服、智能呼叫、SIP 技术、语音智能体框架等话题。
期待这期回顾能给你带来一些启发和帮助。
本期分享嘉宾：
魏佳星（云蝠智能创始人兼产品经理）
沈金堤（RustPBX 创始人）
杜金房（FreeSWITCH 中文社区创始人）
Leody 伏英娜（Magics AI 创始人）
Halajohn（TEN Framework 创始人）
主持人： 傅丰元（RTE 开发者社区负责人）
本次活动的微信群将持续开放，作为 AI 语音客服主题的长期交流平台，欢迎加入我们的社区～🎉
以下内容基于会议纪要音视频整理，难免出现错漏和不严谨。如有疑问，欢迎评论留言，我们很乐意联系分享者确认交流。
魏佳星（云蝠智能）
AI 客服还不够聪明，但已经超过月薪五千的人类
大家好，我叫魏佳星，是云蝠智能的创始人，但我更喜欢的身份是产品经理，因为我大多数时间都在研究产品。今天，我想和大家聊聊大模型和 AI Agent 在语音客服行业的应用。我将从两个方面展开：首先，探讨语音智能在电话呼叫中心的应用潜力与市场规模；其次，分享云蝠智能的一些产品实践。
云蝠智能自 2018 年起深耕「电话机器人」领域，七年间历经六代产品迭代，从最初的关键词匹配，到向量数据库 NLP，再到如今的完全生成式方案，我们的核心目标始终如一：让大模型能够接打电话。至今，我们已服务近 3 万家企业。
有一个数据很有意思：我们的收入从零增长到几千万的过程中，从未下降过。即便面对疫情、行业转型或「双减」政策，也从未出现下滑。这充分证明了语音市场需求的旺盛。
大家可能没去过呼叫中心的职场，那里的普遍状态是把人训练成机器人，上百甚至上千人坐在一起，管理成本极高，所以基本上都是让员工背稿子。在这种情况下，即使是上一代的关键词命中匹配型 AI，也已经具备了相当的商业价值和复购率。
AI 语音客服市场有多大？
###
有研报指出，全球约有 2000 万就业人口从事呼叫中心（Call Center）行业。仅在中国，从事电话呼叫相关职业的人口就可能超过 1000 万。我举一个很小的垂直赛道——催收。国内仅通过打电话催还款的从业者就有 50 万人。这个职业的就业数量，可能比外卖员和出租车司机还要多，而这类高度重复性的工作被 AI 模型替代的可能性极高。
###
为什么 AI 语音客服有优势？
- 首先是成本
一个普通客服月薪五千元左右，加上五险一金，而一个人一天有效通话大约 80 通，算下来一通电话的人力成本是五到六元人民币，在欧美大约是三美金。AI 的成本远低于此。
- 其次是服务能力
人类一般是「五天八小时」工作制，而 AI 可以实现「七天二十四小时」全时段服务，并且支持高并发呼叫。
- AI 具备全面的记忆存储能力
更重要的是，我们认为 AI 能超过月薪 5000 元的人类客服。AI 具备全面的记忆存储能力，包括每一次通话的上下文。例如，云蝠的平台每月处理近 5000 万通接通电话，我们会通过声纹大致判断用户的性别年龄，这些记忆会形成一个「泛记忆池」，让 AI 在下一次通话时更精准。由于具备长期记忆和自我迭代能力，我们认为 AI 的成长性是持续的。它的参考系不是博士或硕士，而是一个月薪四五千元的职场人。
- 特殊业务的匹配能力，如多语言服务
此外，AI 还具备超人的能力，比如多语言服务。一家做外贸的公司需要跨境语言互动，AI 可以轻松实现，但一个小型呼叫中心很难具备多国语言服务能力。所以我的总结是：在特殊业务上，AI 要超过人类；在常规业务上，AI 要取代人类。
从产品形态上看，简单的通知类业务，基于规则的传统产品依然有价值。
它的逻辑从过去的关键词匹配，升级为可以利用大模型来理解上下文意图，再进行规则命中。
而更复杂的场景则适合生成式 AI。我们会为每个用户构建一套动态的 Prompt（提示词），这个 Prompt 会基于客户画像和特定事件来生成，从而实现「千人千面」的互动。
什么样的场景适合 AI Voice Agent ？
总的来说，就是需要读取客户画像、并基于历史记忆实时生成对话的场景。
以政府热线为例，系统能够读取市民多次来电的历史记录和工单信息，提供连贯、高效的服务。在汽车 APP 的场景中，大模型技术突破了传统变量处理的局限，能够根据用户浏览的车型实时生成个性化互动内容。
我们一个政府热线的智能体，4 月份刚上线时，AI 平均通话时长是 146 秒。随着 AI 不断学习和构建用户长期记忆，上个月这个数字达到了 163 秒。我们认为，产品优化能提升几秒，但核心的增长来源于上下文记忆的建立。
而且我们发现，AI 可以承接传统人工客服无法覆盖的时段。
当然，目前的 AI 和真人录音相比，在情感和拟人度上还有差距。真人录音的情感表现力始终是最好的。但 AI 在对话结束后，可以自动提取时间、地点、诉求等信息，并打上标签，完成后续的数据处理。
完整的 AI 语音客服流程应该包含四个环节：
设计智能体： 大多数用户不会写提示词，所以需要一个更强大的模型来帮助用户构建和设计智能体；
执行对话： 执行端的 AI 对延迟要求极高，所以需要轻量、快速的模型；
分析结果： 对话后生成报告和洞察；
反馈优化： 分析结果反过来优化智能体的设计，形成闭环。
###
AI 语音客服的核心挑战与应对
##
语音客服的核心挑战在于通话轮次短、对时延和拟人度要求极高。这里的拟人度不单指语音合成，更涵盖对话情感与环境感知能力，例如有效屏蔽背景噪音、避免 AI 幻觉。
在智能体的构建上，我们主要通过优化提示词和强化自然语言处理来提升效率。我们特别注重对 Function Call Plugin 和 MCP 的引用。例如，我们将「转人工」设计为一个 AI 插件，使 AI 能够智能判断最佳转接时机，而非仅仅通过关键词触发。
在数据层面，我们主要处理几种类型的数据：
RAG（检索增强生成）：为了解决传统 RAG 因数据量过大导致的问题，我们采用了知识提取的策略。我们会将客户提供的大量文本资料，通过像 DeepSeek 这样的大模型进行处理，将其提炼成高质量的问答数据集，再交给 RAG，这显著提升了数据命中率，并能为 FAQ 提供更丰富的联想。
FAQ 和用户记忆：除了 FAQ，我们还特别关注用户自身的记忆，包括生物特征（如年龄、性别）和历史沟通记录，形成了横向和纵向的用户记忆体系。
在业务流程中，我们强调分析、反馈与执行的闭环：
分析：我们负责对话总结、工单总结和实时数据报告。未来的目标是让 AI 承担报告分析工作，从而形成一个完整的内部反馈机制。
执行：即使客户不使用我们的系统，我们也能将结论通过企业微信、钉钉或飞书等平台推送给相关人员。
我们有一个「加速引擎」，它能在语音活动检测前就向模型大量发送请求，预先生成答案，有效缩短响应时间。
另外，我们还引入了「宽容时间」机制，当 AI 即将说话时，如果用户突然又说了一句，系统会撤回 AI 的回答，将两段用户语音合并后重新响应。
最后，我想反思一下，云蝠的产品目前还过于 SaaS 化，我们正在努力进行 AI Native 的产品重构。
同时，我们发现用户的反馈不一定是最佳方案，过度关注零散需求可能会稀释研发精力，用户的操作体验和产品的流畅性远比那些「锦上添花」的功能更重要。
###
Q&A 环节：
Q：为什么智能体对话流程中没有反问，实际拨打却出现了反问？
魏佳星：在对话启动时，我们会向 AI 预设一个类似于「喂，你好」的默认提示词，模拟用户接听电话时的自然开场。我们利用如 DeepSeek 等大模型，通过优化提示词，使其能主动构建反问事件。
另一个关键点是处理用户沉默。当用户三秒内没有回应时，我们会向 AI 发送一个「用户沉默」的提示。这个提示的意义会根据具体场景而变化。例如，在针对自闭症儿童的心理干预中，「小朋友不说话」这一信息会引导 AI 采取特定的干预策略并给出相应的回应。
Q：除了多语言之外，还有哪些 AI 超越超人的场景？
魏佳星：在我看来，当前 AI 在呼入场景的表现已经天然地超越了人类。我刚才展示了实际通话时长，AI 的通话时间可以达到三分钟，而人类平均只有两分钟。这是因为在呼入场景下，人工客服长期接触的多是负面信息，这使得人类本能地倾向于尽快结束通话。而模型则不同，它天生倾向于持续交流，这种特质使其在客服岗位上更具天赋和优势。
Q：大模型用的是哪个？微调了吗，以及先验知识怎么获取？
魏佳星：我们目前整合并测试了多个生成式大模型，主推智谱和通义的方案，但它们是经过我们组合优化的。
我们没有直接对大模型进行微调，目前微调的速度还跟不上技术的快速迭代。我们进行了大量的工程化处理。例如，在轮次检测方面，我们采用了 TENTurn Detection。
在实时对话过程中，有多个 AI 模型协同工作。比如，当用户说「你慢点讲，我听不清」时，一个独立的模型会动态调整 TTS（文本转语音）的速度。这些模型负责持续感知对话环境，并对对话内容进行细微的、实时的调整。****
Q：报修流程里面，AI 怎么处理地址的准确性
魏佳星：我们会进行二次核验，因为实际操作中语音识别难免出现误差。
在热词处理方面，我们会针对物业相关的专业热词进行专门优化，建立一个专门的热词组。但这还不够。我认为最直接有效的方式就是二次核验。
Q：在金融领域或者保险领域，大模型呼叫可以解决合规问题吗？
魏佳星：客观来说，在金融领域，银行确实存在一些合规方面的顾虑，所以我们目前更多地专注于处理不良资产这类业务。
我们采用了一种非侵入性的解决方案——浏览器插件。它不需接入客户的核心业务系统，仅通过获取屏幕信息即可发起 AI 呼叫，实现了业务逻辑共享，同时避免了获取用户手机号，且为本地化运行，有效规避了部分合规风险。****
Q：无论是构建 prompt 或者对话过程中，成本都要比规则时代太很多，这块有哪些优化措施？
魏佳星：我们必须部署缓存，并确保其高效命中。举个例子，在刚才的演示中，模型是实时构建的。如果能再快一分钟，甚至可以让模型提前进行大量的自我对话，比如让它模拟用户和 AI 互聊一万遍，这样就能预先构建大量的缓存。
按频率采集，低频率的直接忽略，包括记忆也可以走缓存。缓存可以通过向量或者 turbo 模型去做命中。
我觉得现在的模型成本并没有那么高。虽然模型相比传统规则类产品成本更高，但考虑到我们能够因此向客户收取更高的费用，整体来说是可接受的。
Q：如何更好的处理语音识别结果？
魏佳星：多试试更好的模型，不过需要做前置的降噪、回音消除和人声增强，在数据上做处理，比如 vad 对识别的影响可能比 asr 还大。
Q：现在用下来 STT 和 TTS，最好的分别是哪家的？
魏佳星：TTS 比较推荐 MiniMax 和豆包；ASR 比较推荐豆包和阿里。
Q：有没有那些外呼的场景，用大模型是属于伪需求的？还说全场景大模型都可以取代 human？
魏佳星：cold call 不需要大模型。客户只要没有拒绝，逻辑就是需要。但是这是规则产品就可以做的很好的。
呼叫没有什么场景是 LLM 做不到的，除了深入交流会议等场景。
外呼中：会员服务、需要不同的用户画像实时互动的，举个例子：某个 app，大模型可以实时读取并分析用户画像，推荐最匹配的产品或服务。再举个例子：某个市监局，LLM 能够理解用户的原始诉求和案件办理结果，方便对用户进行回访。
Q：如何保障 Agent 执行 SOP（如多轮反问）的稳定性？
魏佳星： SOP 的稳定性确实是一个挑战。我们目前正通过重构 RAG（检索增强生成）系统和加强测试环节来解决这个问题。
Q：如何保障 LLM 外呼的高并发与低延迟？
魏佳星：
技术架构优化： 在高并发方面，可以借鉴 FreeSWITCH 等成熟方案；
模型性能「作弊」： 通过一些优化手段来提升性能。例如，将开场白预先合成，可以有效分散每秒查询次数（QPS）的压力。同时，可以充分利用云厂商提供的 API 服务，提高并发限制；
用户体验优化： 针对 LLM 响应时可能出现的抖动或延迟，我们可以通过插入语气附和词或添加背景音来巧妙地缓解卡顿感，从而降低用户对延迟的感知。
沈金堤（RustPBX）
Voice Agent 通讯方式的三种主流方案
大家好，我叫金堤，算是个行业老兵了。我从 2004 年开始做 SIP 协议栈，后来负责过钉钉的后端和滴滴云的产品技术。最近几年一直在做通讯相关的创业，目前在做 Voice Agent 的底层框架。
今天我想给大家科普一下市面上 Voice Agent 在通讯方式上的三种主流方案，并介绍一下我们正在做的事情。
第一种方案：WebSocket 语音流方案
这是最简单、最受欢迎的一种方案，因为技术门槛低。原理是客户端通过 WebSocket 连接到 Voice Agent 服务器，通过文本信令完成握手后，将 PCM 或 PCMU 等格式的音频流通过 WebSocket 的二进制帧进行传送。很多嵌入式设备和物联网设备都采用这种架构。
比如，一个典型的应用案例是小智机器人，它正是基于这种架构来开发的。小智的产品易用性主要体现在设备层面，特别是嵌入式设备的开发门槛相对较低。Twillio 也支持 WebSocket 语音流，其最大特点是对信令的需求非常少，甚至发两个 JSON 就能完成握手。
语音智能体服务器后端调用云服务（ASR/TTS），例如腾讯云和阿里云，它们也都是通过 WebSocket 方式进行数据传输的。
****
第二种方案：WebRTC 方案
WebRTC 的核心是 实时通信（RTC）。它之所以普及，主要是因为所有现代浏览器都原生支持。
核心特点：
协议复杂性： WebRTC 协议复杂，本质上是一种 P2P（点对点）方案。
传输方式： 音频流主要通过 UDP 协议 直接在点对点之间传输，但在网络穿透困难时，需要中继服务器 (TURN) 辅助。
信令协议： 信令协议可以是标准化的，也可以是自定义的，例如 Matrix IM 的 Call 功能就基于 WebRTC 设计了自有的信令协议。
主要优势：
浏览器原生支持： 这是 WebRTC 成为网页音视频功能首选方案的主要原因。包括腾讯会议、Zoom 在内的许多会议工具都基于它；
强大的传输能力： 采用 SRTP 协议传输音频流，具有出色的抗网络抖动能力；
内置声学处理： 提供优秀的降噪和回声消除功能；
应用广泛： 许多现代框架，如 TEN、Pipecat 和 LiveKit，都是基于 WebRTC 体系构建的。****
第三种方案：SIP + RTP 方案
第三种方案是 SIP/RTP 方案。前面云蝠智能提到的电话系统，就是典型的 SIP+RTP 方案。中国的电信系统现在基本上都采用 SIP 信令。
主要特点与优势：
兼容性强： SIP 遵循标准规范，与传统电话系统对接时兼容性良好；
抗网络抖动： 具备强大的抗网络抖动能力，适合运营商级别的通信需求；
呼叫中心主流： SIP 是呼叫中心业务中的主流技术，许多产品（如 FreeSwitch）都基于此构建。
缺点：
协议复杂： SIP 协议极为复杂，相关的 RFC 文件多达约 20 个。其严格的规范使得实现和调试都非常困难；
缺乏加密： 在大多数情况下，SIP 方案不提供加密功能。
WebRTC 与 SIP/RTP 互通
这三种方案各有利弊。典型的需求是实现 WebRTC 与 SIP 的互通。比如，一个坐席人员需要通过浏览器与电话用户通话，这就需要一个 WebRTC 到 SIP 的网关。
WebRTC 网关作为中间件，负责协议转换和音频格式的转码。例如，浏览器通常可能使用 Opus 编码，而电话系统可能是 PCMU 格式，这就需要在网关上进行格式转换和重采样。
网关层面需要完成从简单协议到复杂信令的转换，以及音频流的转换。虽然有时不需要完全的转码，但由于一边是加密、一边不加密，或者两边的加密状态不兼容，大多数情况下还是需要进行一次编解码操作，这使得网关的开销相对较大。
###
我们正在做的事：RustPBX
我们正在开发一个名为 RustPBX 的项目。现有的 PBX 系统（如 FreeSWITCH）是为人工坐席设计的，其核心是 IVR（交互式语音应答）和呼叫中心模块，对于 ASR、TTS 等 AI 能力的集成，无论在延迟还是易用性上都做得不够好。
RustPBX 有几个特点：
面向 AI 设计： 把 ASR、TTS 这些 AI Pipeline 作为一等公民，内置了先进的 VAD、降噪等深度学习算法；
高性能： 用 Rust 语言重写了整个协议栈，包括底层的编解码器。Rust 的内存安全和高性能特性，使我们单核就能支持 160 路并发语音，远超传统基于线程模型的 PBX；
易用性： 我们希望将所有复杂性封装起来，包括 WebRTC、SIP 和 AI 能力，让开发者开箱即用。
我们的市场定位是全新的增量市场，也就是面向 AI Agent 的开发者，而不是去抢夺传统呼叫中心的存量市场。RustPBX 可以作为一个分机，注册到现有的呼叫中心系统上，与 FreeSWITCH 并行工作，专门处理 AI 的流量。
###
Q&A 环节：
Q：RustPBX 的未来发展路线是怎样的？如何才能吸引大家来使用？
沈金堤：长远目标是完全替代 FreeSWITCH。我认为 FreeSWITCH 虽然强大，但它是面向呼叫中心和人工座席设计的，主要应用于呼叫中心等需要人工操作的场景。
RustPBX 走的是一条完全面向 AI 语音智能体的路线，与 FreeSWITCH 面向人工操作的路径不同。目前，该产品主要作为分机使用，注册到现有电话系统或呼叫中心中，以语音智能体的模式来服务客户。
Q：如何处理高并发，以及能否完整兼容 FreeSWITCH，以实现平滑迁移？
沈金堤：方案在协议层面实现了兼容。只要电信规范标准要求兼容，我们就能兼容。此外，我们的方案可以与 FreeSWITCH 并行或以级联的方式工作，因此能够与 FreeSWITCH 进行串联或级联集成。
Q：方案相比 FreeSWITCH 的明显优势在哪里？
沈金堤： 主要优势体现在性能、安全和面向 AI 这三个方面。
性能：通过重写整个协议栈（包括 PCM、u-law 和 g722 等），RustPBX 的性能显著提升；
安全：RustPBX 对 SIP/编解码/RTP 等方面进行了优化，从而增强系统的安全性；
面向 AI：RustPBX 的核心目标是成为一个面向人工智能的基础产品。
Q：RustPBX 和 Janus 有什么异同？除了协议转换之外，更多的是在 AI 方面吗？
沈金堤：Janus 是一款用 C 语言编写的优秀产品，但它需要复杂的配置和管理，包括端口分配等。
RustPBX 的设计理念则是 「开箱即用」。它的核心思想是将 WebRTC、RTP 和 AI 等功能打包成一个高度集成且易于使用的产品。用户只需进行简单的配置就能上手，无需处理复杂的底层细节。
我们未来的目标是让 AI 大模型来帮助我们进行产品配置，从而让管理员无需具备太多专业知识，就能轻松使用我们的产品。
圆桌讨论
嘉宾：魏佳星、沈金堤、杜金房、Leody 伏英娜、Halajohn
Leody 伏英娜：我是 Magics AI 的创始人。我们最早是做数字人相关的能力，致力于开发全模态的实时互动 AI。由于语音是数字人的一个子模态，我们去年也推出了语音模态的产品线。与同类产品不同的是，我们专注于大客户，并提供整体的平台能力。
Halajohn：我是 TEN Framework 的创始人。TEN 是一个为开发者设计 AI Agent 的框架，旨在实现极高的弹性和应用性。它支持 AI 在 Linux、Windows、Mac 甚至 IoT 等不同平台运行，并且能够实现云、边、端算力互融。
TEN Framework 的优势在于：
低成本
高隐私性
低延迟
该框架支持多种编程语言，包括 C++、Python、Go 和 JavaScript/TypeScript 等，并且不同语言编写的模块可以在同一个进程中运行，而不仅仅是通过微服务的方式。TEN 的内核是用 C 和 Rust 编写的，目前两者比例各占一半。未来我们计划逐步提高 Rust 在内核中的占比，因为 Rust 相比 C 有更多优势。我们的目标是为开发者提供一个能实现本地化、云边端互融、多设备、多语言互融的 AI Agent 开发框架。
TEN Framework 目前是否可以支持电话（如 SIP）相关的应用？
###
Halajohn： TEN Framework 可以实现与 SIP 的融合。虽然目前没有开箱即用的 SIP 扩展模块，但如果需要，开发者可以基于 TEN 的标准开发流程来构建。在我们的内部路线图中，SIP 扩展模块的开发一直在讨论中，预计不久的将来会发布。我们计划首先在 TEN 的开源版本中发布 SIP 扩展，之后可能会考虑将其进行商业化，以提供更高品质和应用性的部署方案。
RustPBX 相比 FreeSWITCH 的优势是什么？
Leody 伏英娜：RustPBX 更多地是考虑存量市场的升级换代，还是增量市场？对于存量市场，RustPBX 相比 FreeSWITCH 的优势和迁移成本如何？对于增量市场，RustPBX 针对 AI 开发者的策略是什么？
沈金堤：我们的产品 RustPBX 主要面向的是全新的增量市场，即语音智能体领域。我们目前的客户将 RustPBX 当成一个工具或组件来使用，而不是像 PBX 那样去替换 FreeSWITCH 的存量市场。我们认为 FreeSWITCH 在传统的呼叫中心等存量市场已经做得非常好，且这类业务的思考模式是以「坐席」为中心，复杂度高，由 IT 和运营两个部门协同。我们不打算与 FreeSWITCH 直接竞争。
Leody 伏英娜：RustPBX 相比 FreeSWITCH 的优势在于能够高效、低成本地接入 AI 能力吗？
沈金堤：是的，这正是我们的核心优势。在传统的框架中，如果开发者要构建一个 Voice Agent，他们需要具备非常专业的知识，比如 WebRTC、音频处理以及如何处理每 20 毫秒一帧的音频数据。这对于大多数业务开发者来说是一个极高的门槛。
FreeSWITCH 是否计划提供一些端侧插件？****
魏佳星：在新的技术周期中，FreeSWITCH 是否计划为开发者提供一些新的、可供使用的端侧插件或套件，以应对 AI 应用中出现的 VAD（语音活动检测）打断等新变化？
杜金房：FreeSWITCH 虽然有很多开源的东西，但我们的 AI 模块都是闭源的，因为我们要考虑差异化和生存。我们也有为 FreeSWITCH 社区贡献代码，但作为一家公司，我们需要有自己的商业产品。
我们实际上已经在 FreeSWITCH 上解决了你提到的所有 AI 相关问题，无论是三段式还是多模态，都可以轻松实现。
****
企业客户在语音端到端模型的应用场景和效果怎么样？
魏佳星：我们发现了一些现实问题：
成本高昂：端到端方案的成本大约是级联方案的近十倍；
时延不可控：端到端方案的时延并不稳定。
我们认为，在级联方案下实现「伪端到端」效果是更现实的选择。级联方案的好处在于我们可以通过对 TTS 进行动态调值、利用「边说边想」等技术来优化时延和用户体验，从而达到类似端到端的共情和环境感知能力。
Leody 伏英娜： 我补充两点。除了成本，还有幻觉率和微调的问题。纯粹的端到端音频模型很难解决 TO B 场景中混合文本模态的需求，比如指令微调、内容审核等。****
沈金堤： 我也同意。端到端模型还有一个问题是缺乏灵活性。比如在客服场景中常见的「转人工」需求，目前的端到端模型没有开放这样的接口。AI 无法百分之百替代人，必须有人工兜底的通路。
如何评估语音智能体效果？
****
Halajohn： TEN Framework 在平台侧提供了完善的监控能力，主要包括 Log（日志）、Trace（追踪）和 Metric（指标）这三大类。它提供统一的跨语言接口，开发者可以在不同语言的模块中调用这些接口，将日志和追踪信息汇总，从而快速定位问题。Metric（指标） 方面，平台提供与 Prometheus 兼容的接口，使开发者能轻松监控端到端延迟，并细致地了解 ASR、LLM、TTS 等每个环节的耗时。未来，平台还会推出图形化界面，让开发者可以直观地看到数据在 Agent 内部的执行路径。
魏佳星：从业务角度出发，除了技术指标，更应关注能直接反映业务成果的北极星指标，例如通话时长或转化率。通过创建一个「六边形战士」评估模型，可以基于开场白、倾听反馈、异议处理等多个业务维度，利用一个强大的模型对每次通话进行打分。这种方法不仅能评估效果，还能通过数据指导提示词优化，形成一个持续迭代的闭环。
Leody 伏英娜： 我认为评估要分两个维度。一是技术维度，包括延迟、准确率等细节指标；二是业务维度，呼出场景看转化率，呼入场景看首解率等。我们的经验是，把一个功能跑通（从 0 到 1）和把它做到能支撑大规模高并发应用（从 10 到 100），中间有巨大的鸿沟。这需要一整套监控系统，包括自动的故障检测和恢复机制，才能保证服务的稳定和可靠。
除了电话客服，语音智能还有哪些未被充分开发的高价值场景？
魏佳星： 我最近一直在关注 Play AI，它展示的都是高价值场景。我认为通话不一定只发生在电话端。电话线路只有 8K 带宽，而网页端可以达到 16K 甚至 32K。比如，我们可以为看完某个视频的用户提供一个语音互动，像我们正在合作的一个自闭症干预项目，小朋友看完动画片后，AI 会基于动画片内容提出问题，对他进行引导和干预，这个场景就非常有价值。
Leody 伏英娜： 我觉得机会在于打通业务闭环。Voice Agent 只是其中一个环节。用户呼入可能是语音模态，后续生成工单、内部流转是文本模态，最后回访又变回语音模态。如何将视觉、语音、文本等不同模态在整个业务流程中无缝衔接，形成一个完整的闭环，这是 TO B 领域一个非常重要的机会。另外，多语言场景也是 AI 的巨大优势，一个 AI 可以支持多种语言，这是任何人类客服都无法比拟的。
Lightning Demo
AccuNote AI（by 5Y）：为知识密集型音频打造的深度笔记工具
****
一款为播客、专家访谈等知识密集型场景打造的 AI 笔记工具。它区分了 Summary 和 Note 的概念，致力于生成高度非标化、低信息损失的深度笔记。用户可以通过上传范例来定制个性化的笔记模板，产品能保证 40% 以上的信息留存率和 99% 的准确率，并且所有笔记内容均可溯源。
链接：https：//accunoteai.com/
****
线下场景 AI Agent（by 游威）： 专为线下消费场景打造的数字人 AI 应用
一个专注于酒馆、茶馆等线下消费场景的 AI 应用。项目从数字人切入，这个数字人可以介绍饮品、与顾客对话点单、玩塔罗牌或划拳等，为线下空间提供新颖的交互体验和价值。
Clio Voice（by Jetson）： 离线运行、支持高度定制化的语音输入软件
####
一款对标 Wisper Flow 和 Willow 的语音输入软件。它支持离线模型，用户可以根据不同应用编写自定义 Prompt 来后处理 ASR 的输出，并添加热词。该产品旨在提供比国外同类产品更优化、更具性价比的本地化语音输入体验。
链接：www.cliovoice.com
****
Pandahoho（by NEO 周磊）： 「Real-time Social」帮助自由行用户实时结伴
一款面向自由行旅客的 AI 旅行伴侣。它提出了「Real-time Social」的概念，希望利用 AI Agent 帮助自由行用户实时结伴。产品目前基于 Discord 进行交互，用户可以在官网上基于景点和路线一键发起结伴，信息会同步到社区，促进实时社交。
链接：https：//pandahoho.com/
Voice Agent 垂直行业应用（by YC.D）
他之前在一家初创公司工作了一年，该公司声称开发了世界上第一个用于数字营销的 AI 智能体。他正在开发一个利用 语音 AI 颠覆一个传统行业的垂直应用。他正在为这家位于硅谷的美国初创公司招聘年轻、有潜力、并对语音 AI 充满热情的工程师。
主题分享、圆桌对谈、demo 分享、分组自由讨论——感谢大家的参与，我们下一次 RTE Meetup 再见！！
阅读更多 Voice Agent 学习笔记：
了解最懂 AI 语音的头脑都在思考什么 https://www.rtecommunity.dev/
