语音 Agent 真正缺的，可能是一只本地的耳朵

发表于 阅读次数： Waline： 本文字数： 3.4k 阅读时长 ≈ 12 分钟
SenseVoice 是我在开发 Filo 和 Voice Key 时被 Codex 偶然推荐的本地语音识别模型。试用后发现，它很适合做端侧语音 Agent 的“耳朵”：体积不大、中文友好、能在 CPU 上跑，也让本地语音入口更低摩擦。

过去一年，大家聊 Agent，大部分时间都在聊大模型。

谁的推理更强，谁的上下文更长，谁更会调用工具。

我一开始也没有特别关注语音识别模型。

SenseVoice 是我在做两个产品时偶然遇到的。一个是 Filo，录完屏之后要在本地生成字幕；另一个是 Voice Key，按住快捷键说话，然后把文字贴到当前输入框里。

当时我只是想找一个能用的本地 ASR：不要每次都上传音频，不要让用户填一堆 API Key，不要把安装包撑得太大，最好中文表现也别太差。

这个过程中，Codex 给我推荐了 SenseVoice。

坦白说，我第一次看到这个名字的时候没什么感觉。它不像 Whisper 那样有名，也不是那种一看就适合写成热点文章的模型。我只是按工程需求试了一下。

结果试下来发现，它还挺对。

模型不算大，能跑在 CPU 上，对中文友好，还能放到桌面应用里按需下载。更重要的是，它让我重新想了一件事：如果以后真的会有很多端侧语音 Agent，那它们最缺的可能不是更聪明的大脑，而是一只稳定、便宜、低延迟的本地耳朵。

所以才有了这篇文章。

语音 Agent 的第一道门槛，不是“会说”，是“会听”

今天我们说“语音 Agent”，脑子里很容易出现一个科幻画面：

你对电脑说一句话，它理解你的意图，打开软件，整理材料，回复消息，安排日程。

听起来最核心的是大模型。

但真实链路里，第一步其实很朴素：

1
人说话 -> 语音识别 -> 文本理解 -> 工具调用 -> 执行动作 -> 反馈给人

如果第一步听错了，后面再强也没用。

这就是 ASR 的位置。

以前很多产品会直接把音频传到云端识别。这样做当然省事，效果也常常更稳。但语音 Agent 和普通语音转写不太一样。它会听到很多更私密、更即时、更碎片化的内容：

  • 你正在写给客户的消息；
  • 你准备发出去的工作安排；
  • 你临时说出的想法、密码、项目名；
  • 你正在看的屏幕内容和会议内容。

这些东西每次都上传云端，用户心里会有一道坎。就算用户不在意隐私，延迟、费用、网络状态，也会变成产品体验的一部分。

所以端侧 ASR 的价值就出来了。

它不需要替代所有云端语音识别，但它能让语音 Agent 多一个很关键的默认能力：先在本地听懂你。

SenseVoice 到底是什么

SenseVoice 是一组开源语音理解模型。

它最常被拿来做 ASR，也就是语音转文字。但它的定位不止是转写。官方把它放在 voice understanding 这个方向里，除了 ASR，还包括语种识别、情绪识别、音频事件识别。

你可以把它理解成语音 Agent 的“耳朵”。

能力 对语音 Agent 的意义
ASR 转文字 把用户说的话变成大模型能处理的文本
语种识别 中英混说、多语言输入时减少配置
情绪识别 让 Agent 有机会知道用户是平静、疑惑还是着急
音频事件识别 未来可以感知咳嗽、笑声、背景事件等非语言信息
标点和文本规整 输出更像一句能读的自然语言，而不是一串生硬词

我这次主要关注的是 SenseVoiceSmall 的轻量版本。它没那么“满血”，但很适合端侧场景。

模型文件大约 240 MB。这个大小有意思：对网页来说太大，对服务端来说很小，对桌面应用来说刚好卡在一个可以接受但不能乱塞进安装包的区间。

也就是说，它最好不要默认打进安装包里。更合理的方式是：用户第一次启用本地语音能力时，再下载到本机。

这点很重要。端侧 AI 产品最怕一上来就吓退用户。

为什么它让我想到端侧语音 Agent

我以前对语音 Agent 的想象，更多是“语音输入 + 大模型”。

看完 SenseVoice 之后，我的想法变了。语音 Agent 不只是把麦克风接到 ChatGPT。它需要一个更贴身的语音前端。

这个前端至少要解决四件事。

第一，常开或高频使用时，成本不能太高。

如果每次按住说话都走云端识别，单次成本不一定高，但高频使用会累积。更麻烦的是，用户会开始犹豫：这句话值不值得发给云端识别？一旦用户犹豫，语音入口就失败了一半。

第二，延迟要低到不打断思路。

语音输入的体验很脆。你说完一句话，等 5 秒，心气就断了。端侧模型不一定永远比云端快，但它少了网络往返，也更容易做成稳定的体验。

第三，它要听得懂中文用户真实的说话方式。

中文用户不是照着播音稿说话。我们会停顿、重复、夹英文、说半句话又改口。一个中文优先的端侧 ASR，比一个“什么语言都支持但中文体感一般”的模型更适合做日常 Agent。

第四，它要能和大模型分工。

ASR 不需要负责理解一切。它只要尽量把声音变成干净文本。后面的整理、改写、行动规划，可以交给大模型。SenseVoice 的价值就在于，它把“听”这件事做得足够轻，足够本地化。

两个小案例：它在产品里可以怎么用

我手上刚好有两个项目都接触过这个模型，一个偏内容，一个偏输入。

这里不展开技术细节，只讲它们用到了 SenseVoice 的什么能力。

案例一：录屏工具里的字幕和剪辑

第一个项目是 Filo，一个录屏工具。

它的需求不是“把音频转成一段文字”这么简单。用户录完屏之后，想生成字幕，还想按文字剪视频。

这时 SenseVoice 提供的就不只是转写能力，还有时间信息。哪句话大概从哪里开始，到哪里结束，后面才能变成字幕，甚至变成可剪辑的文本块。

对这种产品来说，ASR 的意义不只是“识别准确率”，而是把视频变成可编辑的结构。

你可以想象一下：

1
2
3
4
5
一段视频
  -> 本地识别出字幕
  -> 每句字幕带时间
  -> 用户删掉几句话
  -> 视频也跟着剪掉对应片段

这已经不是传统意义上的字幕工具了。它更像是“让视频可以被文字操控”。

放到语音 Agent 里，这个思路也很重要。未来 Agent 不只是听你一句命令，还可能理解一整段录音、一段会议、一段屏幕讲解，然后把它拆成可以处理的任务。

案例二：语音输入工具里的本地听写

第二个项目是 Voice Key，更像一个语音输入工具。

用户按住快捷键说话，松开后，文字直接出现在当前输入框里。后面可以再接一个大模型，把口语整理成更适合发送的文字。

这类产品对 ASR 的要求很朴素：

  • 不要每次都让用户填 API Key；
  • 不要每句话都上传；
  • 不要等太久；
  • 不要占太多安装包体积；
  • 出问题时不要让整个应用崩掉。

SenseVoiceSmall 的轻量版本在这里的价值，是让“本地听写”变成一个可选但很自然的能力。模型 240 MB 左右，用户愿意用本地模式时再下载。平时说话先在本机识别，再交给大模型润色或执行。

这就是我觉得它适合语音 Agent 的原因：它不抢大模型的戏，但它让大模型更容易进入日常工作流。

端侧语音 Agent 需要的不是一个巨大的模型

现在很多人做 AI 产品，会下意识追求“更大、更强、更全”。

语音 Agent 反而不一定。

端侧场景里，模型越大，用户越难开始；依赖越多，故障越多；配置越复杂，普通用户越容易放弃。

我更愿意用下面这张表理解 SenseVoiceSmall 的位置：

问题 端侧语音 Agent 的真实需要 SenseVoiceSmall 的匹配度
模型体积 不能太大，最好按需下载 约 240 MB，可接受
运行环境 普通 CPU 能跑 可以 CPU 推理
中文体验 中文优先，中英混说可优化 中文、粤语、英文等覆盖实用
隐私 默认不上传音频 本地运行天然适合
产品复杂度 用户不想选模型、配参数 适合做成一个默认本地选项

这里面最关键的不是某一个指标，而是整体平衡。

如果一个模型很准，但必须上云，它不适合做默认端侧入口。

如果一个模型很小，但中文体验不行，它也很难成为中文语音 Agent 的耳朵。

如果一个模型很强，但安装包直接多几 GB，用户还没体验就走了。

SenseVoiceSmall 不是完美答案，但它在这些限制之间找到了一个不错的位置。

我自己测到的一点体感

我没有做严肃测评，只做了一个很小的本机测试。

在一台几年前的 Intel i7 Windows 笔记本上，识别一段 5.6 秒中文样音，热启动后大约 1.2 秒出结果。

这不是官方性能结论，只能代表这台机器、这种运行方式和这段样音。

但它给了我一个直观判断：它不是只能在服务器上跑的模型。

当然，端侧模型也有代价。模型文件 240 MB 左右，加载后内存占用会明显上去。对一个录屏工具来说，这不算大问题；对一个长期常驻的语音 Agent，就要设计好什么时候加载、什么时候释放。

还有一个现实问题：Windows 上一定要实测。

我之前在 Voice Key 的早期方案里遇到过一次本地运行环境崩溃。用户不会关心这是 CPU 指令集问题还是二进制兼容问题。用户只会觉得：本地语音识别坏了。

这件事提醒我：端侧 AI 产品不能只关心模型效果，还要关心模型怎么安全地跑在用户机器上。

语音 Agent 可能会分成两层

如果沿着这个方向继续想，我觉得未来很多语音 Agent 会变成两层架构。

第一层在端侧，负责听、初步整理、隐私保护、低延迟反馈。

第二层在云端或本地大模型里，负责复杂推理、长期记忆、工具调用和多步骤任务。

1
2
端侧语音层：听清楚、转成文本、保留时间和上下文
智能决策层：理解意图、调用工具、完成任务

SenseVoice 这种模型更像第一层。

它不需要回答所有问题。它只要让 Agent 能稳定地听到人说话，并且尽量少打扰用户。

这件事听起来不性感，但很关键。

因为真正日常化的 Agent，不会每次都等用户打开一个聊天框，再认真输入一段 prompt。它更可能藏在系统里、输入法里、会议工具里、录屏工具里、笔记工具里。

这些地方都需要一个轻量、可靠、隐私友好的“耳朵”。

我现在对 SenseVoice 的判断

如果你是做语音 Agent、桌面工具、会议记录、录屏剪辑、语音输入，我会认真考虑 SenseVoiceSmall。

它最吸引我的地方不是参数，也不是榜单，而是它的产品气质：

  • 足够小，可以被用户接受；
  • 足够快，可以进入日常工作流；
  • 中文友好，不只是英文 demo；
  • 能本地跑，天然适合隐私敏感场景；
  • 不需要抢大模型的位置，反而能帮大模型更自然地进入语音入口。

它也有明显限制：

  • 240 MB 对端侧仍然不算小，需要按需下载；
  • 情绪识别、音频事件这些能力，在很多产品里还没真正用起来；
  • 端侧运行环境会遇到兼容性问题，尤其是 Windows；
  • 真正的用户体验还取决于后处理、降噪、分段、润色和产品交互。

所以我不会把它吹成“语音 Agent 的终极答案”。

但我会说，它是一个值得认真看的开始。

过去我们做 Agent，太容易把注意力全部放在“大脑”上。可如果 Agent 要走进日常，它还需要眼睛、耳朵、手，以及足够低的使用摩擦。

SenseVoice 做的就是其中一个很基础、但很重要的部分：

让机器在本地听见你。

延伸资料