语音 Agent 是 2026 年下半年企业落地里最被高估也最被低估的领域——高估在于很多人以为"接 STT、调 LLM、接 TTS"就完成了,低估在于真正把语音 Agent 推到生产时才发现,STT/LLM/TTS 三层每个月都有新模型,选型一旦定下来就再没人重测,生产环境里跑的是上个季度的版本。YC S26 出身的 Speko 把这件事做成了 Voice AI 界的 OpenRouter,根据用户的精度/延迟/成本约束自动选最优组合并附带回放评分;9 月初开源的 Egma 则补上另一块基础设施——语音 Agent 的仿真测试平台,允许自带 STT/LLM/TTS keys 做大规模场景回放。两个项目从"模型路由"与"测试验证"两端,共同把语音 Agent 从"一次性集成"推到"持续可治理"的工程形态。
一、语音 Agent 的真实形态:三层模型而非一个模型
很多人对语音 Agent 的第一印象停留在"一个会说话的 AI",工程上这完全是误解。一个生产级语音 Agent 实际上是三层模型的级联:STT(speech-to-text)把用户的语音转成文字,LLM 接管文字做意图理解与决策,TTS(text-to-speech)把 LLM 的回复转回语音。这三层各自有不同的供应商生态——STT 有 Deepgram、AssemblyAI、Whisper、Azure Speech 等十几家;LLM 有 GPT、Claude、Gemini、Mistral 等多家;TTS 有 ElevenLabs、Cartesia、PlayHT、OpenAI TTS 等。
这种三层架构带来两个具体的工程挑战。第一,选型一旦定下来就再没人重测。Speko 创始人在 HN 上描述了一个非常普遍的现象:"几乎所有人评估一次,选一套自己的栈,然后再也不重测,因为换一个供应商意味着又一次集成、又一次参数争论。"这意味着生产环境里跑的语音 Agent 往往用的是上个季度甚至更早的模型,而新模型可能更便宜、更准、更适合业务场景。
第二,生产环境的真实表现与基准测试经常不一致。基准测试通常跑 30 秒的清晰音频,生产环境跑的是第 8 分钟的噪声、自发语音、专业术语、方言、混合语言。一个团队的 STT 在测试集上错误率 5%,在生产真实电话上错误率 20%+,这种差距只能靠持续测试才能发现。Speko 的客户故事里就有团队在用 Speko 之前完全不知道自己的 STT 在真实通话里错误率偏高。
二、Speko:Voice AI 界的 OpenRouter
Speko 的核心定位是把"模型路由"这件事从 LLM 层(STT、TTS 还没有成熟路由)扩展到整个语音栈。用户发送一个请求,带上优化目标(精度、延迟、成本或平衡)、语言、地区等约束,Speko 的路由器从所有公开 benchmark 的候选模型里筛选、对比、选出最优组合,返回响应时在 headers 里附带供应商名、模型名、评分。
这套设计的几个工程细节值得展开。第一,benchmark 数据完全公开。Speko 把同样的输入在某一地区、在不同日期跑多轮,把成绩公开成 leaderboard,包括自家选择输给替代方案的场次。这种"主动暴露失败"的姿态是路由层基础设施的关键——用户必须信任你的评分是真的,而不仅仅是你推荐的组合。第二,网关层 prefetch signed session plans——新会话直接从内存拨号供应商,不需要控制面往返。这意味着用户感知的延迟不会因为多了一层路由器而增加,只有首次冷启动可能有额外开销。第三,failover 仅在连接建立阶段——如果首选供应商拒绝连接,系统立刻切换到次选,不打断已建立的会话。
Speko 的客户故事非常具体。一个房产管理 AI 团队用 LiveKit + Python 跑语音 Agent,自上线后从未更新过 STT 和 TTS——他们根本不知道自己的 STT 在生产电话里错误率高,也不知道有更好的选择,因为"换供应商看起来像一个 R&D 项目"。另一个医疗团队不知道哪个 STT 处理医学词汇最准。还有西班牙语场景下的选型困惑。这些故事反映的共同模式是:语音 Agent 的选型不是技术问题,而是"不知道该看什么、不知道该信什么"。Speko 的价值是把这件事变成 API——给一个端点、要什么约束、拿什么结果。
三、Egma:语音 Agent 的仿真测试基础设施
如果说 Speko 解决的是"选哪个模型",Egma 解决的则是"选的模型在真实场景里到底行不行"。Nischal 和 Naman 兄弟在 2026 年 9 月初开源的 Egma(github.com/egma-ai/egma),定位是语音 Agent 的仿真测试平台。
Egma 的设计动机非常直接——两位创始人自 2024 年初开始做语音 Agent 项目,踩过太多测试相关的坑。最让他们抓狂的是"反复打同一个电话、复述同一段脚本去测试 Agent 行为",以及"生产环境里冒出来的问题,事前完全没模拟到"。这两类痛点的共同根因是缺乏系统化的仿真测试能力——开发者只能手动打几个测试电话,无法在 CI 里跑数千个场景、无法在模型变更后立刻看到回归、无法在生产前发现真实环境特有的问题。
Egma 的工程方案是开源 + 0% markup。已有平台能做语音 Agent 仿真测试,但都在推理成本上加了很高的溢价。Egma 的判断是:行业如果真想把仿真测试规模做起来,就不能再加溢价,而应该提供基础设施让仿真本身可以规模化。具体做法是允许用户自带 STT/LLM/TTS provider keys,也可以选择 Egma 直接提供推理(0% 加价,免去多 key、多 rate limit 的烦恼)。这种"开源 + 透明定价"的姿态与 Speko 的"公开 benchmark 主动暴露失败"是同源思路——让用户能验证、能复现、能信任。
Egma 创始人在 Show HN 里明确写出了他们对"开发者如何信任自己部署的语音 Agent"的回答:第一,你需要一种方式测试 Agent 在生产会面临的主要场景;第二,你需要持续跑这些测试,在每次模型变更后立刻看到回归。这两个需求在 Egma 之前都需要昂贵的人工测试或昂贵的 SaaS 平台,现在可以用开源、自托管、可控成本的方式实现。
四、两套设计的共同底层逻辑
Speko 和 Egma 看起来在做不同的事——前者是模型路由,后者是测试基础设施——但它们共享三个底层逻辑。
第一个逻辑是"持续优于一次性"。Speko 强调"选一次定终身"的反模式,提供持续重测的能力;Egma 强调"打几个电话"的人工测试不够,提供 CI 里跑数千场景的能力。两者都把语音 Agent 的工程化从"项目交付时定一次"推到"每次模型变更、每次新数据、每次新场景都重新评估"。
第二个逻辑是"透明优于黑盒"。Speko 公开 benchmark、包括自己失败的场次;Egma 开源整个平台、0% markup。两者都不希望用户只能接受供应商的判断——Speko 让用户能查为什么选这个模型,Egma 让用户能跑自己的仿真场景。
第三个逻辑是"基础设施优于应用"。Speko 不试图做"更好的语音 Agent",而是为所有语音 Agent 提供模型路由层;Egma 不试图做"更聪明的测试用例生成器",而是为所有语音 Agent 提供测试基础设施层。这种"做底层、不做应用"的定位,让两个项目都有机会成为行业标准组件,而不是与具体应用竞争。
五、企业落地时该选哪条路
这两个项目不是互斥的,而是覆盖语音 Agent 工程化的不同阶段。Speko 适合"已经在跑语音 Agent、想持续优化模型选型"的场景;Egma 适合"正在上线新语音 Agent、需要在生产前做大规模仿真测试"的场景。一个成熟的语音 Agent 团队通常会同时使用两者——用 Speko 选模型、用 Egma 测试模型。
对企业架构师而言,优先级通常是先有测试能力,再有路由能力。路由能力是在多个模型中选最优,但前提是知道"最优"的定义是什么。测试能力是定义"最优"的基础——通过仿真场景跑出真实环境下的延迟、错误率、用户满意度,才能让路由有据可依。先把 Egma 这类测试基础设施搭起来,跑出稳定的"测试 → 评估"工作流;再把 Speko 这类路由能力接进去,让模型选型变成持续可优化的流程。
具体到实施阶段,有三条经验值得参考。第一,把语音 Agent 的三层模型分开评估——不要把 STT、LLM、TTS 当作一个黑盒,各自有各自的供应商、更换节奏、评估指标。第二,把测试用例库当作一等公民——语音 Agent 的常见失败模式(自发语音、专业术语、噪声、长会话、情绪变化)需要显式建库,持续在 CI 里跑回归。第三,把成本与延迟作为硬指标——语音 Agent 的单位经济模型(每次通话的 STT/LLM/TTS 成本、首次响应延迟)是选型的关键参考,而不是只看准确率。
六、组织层面的工程纪律
技术选型之外,语音 Agent 的落地还需要组织层面的纪律。一个常见误区是"语音 Agent 是 AI 项目而不是通信项目"——把 STT、LLM、TTS 当作普通 AI 服务接入,不关注电信级的要求(通话建立、SIP 协议、QoS、跨网络抖动)。语音 Agent 的延迟容忍度比纯文本 LLM 低得多——一次电话 30 秒里 5 秒的延迟是 17% 的用户体验损耗,这种损耗在文本对话里几乎不可感知。
另一个常见误区是"换一次模型就能解决所有问题"——发现 STT 错误率高就立刻换供应商,不评估切换成本、回归风险、用户感知差异。Speko 的客户故事里"上线后从未更新过 STT 和 TTS"的团队,某种程度上是因为切换成本太高——换一次意味着重新集成、重新测试、重新调参,这些成本在生产环境里被高估,导致"维持现状"反而成为默认选择。
最后一个值得强调的点是合规与隐私。语音 Agent 处理的对话内容可能涉及用户隐私、医疗信息、金融数据。STT/LLM/TTS 供应商的合规姿态、数据保留策略、跨地域传输限制,这些都必须纳入选型评估。Speko 的"带 headers 返回供应商名"的设计在这种场景下特别有价值——用户能精确知道哪段对话经过了哪些供应商,便于合规审计。
七、结语:语音 Agent 的下一步,是基础设施层的成熟
把语音 Agent 推到生产环境,让它能听、能想、能说是第一步,让它持续跑在新模型上、持续通过仿真测试验证、持续满足合规要求是第二步。Speko 用持续模型路由 + 公开 benchmark 让这件事变成可能;Egma 用开源测试平台 + 0% markup 让这件事变得可负担。两者结合,才能让企业的语音 Agent 从"一次性集成"走到"持续可治理"。
这也是为什么 2026 年下半年这两个项目值得企业架构师关注:它们都不是在做更聪明的 LLM,而是在做让语音 Agent 在生产环境里可路由、可测试、可治理的基础设施。当这套基础设施逐步成熟,企业级语音 Agent 的下一个阶段——从单点客服到全链路语音交互——才有真实落地的可能。
