平时用 OpenClaw 主要接两个通道:微信和飞书。两边处理语音消息的方式完全不同。
微信通道有个反直觉的细节——openclaw-weixin plugin 从微信 API 拉消息时,语音消息已经自带 ASR 转写好的文字(微信服务端做了),直接以文本形式进入会话上下文。所以微信那边"语音消息"和"打字消息"在 OpenClaw 看来是一样的。
但飞书通道不一样——Feishu API 返回的语音消息是原始音频文件(.ogg)。处理这种音频消息其实有两条路径:
- 路径 A:让音频文件直接进入规划阶段,由模型自己判断要不要识别、怎么识别
- 路径 B:在网关层自动触发 ASR 转写,文字注入会话后再交给模型
路径 B 更快、更直接——网关层完成转写后模型拿到的就是 text,不用再处理原始音频;让模型判读音频本身就是多一层间接,速度慢、消耗 token。所以最终选了路径 B,这也正是为什么本地 ASR 必须自己搭:飞书不像微信那样帮你预转写。
一、语音转写方案的选择
方案 1:在线 API 做语音转写——主要是线上方案(OpenAI Whisper、阿里达摩院、讯飞、GPT-4o-audio、Gemini 语音输入等)。没怎么研究过——线上方案调整迭代很快,研究了也容易过时,所以没去尝试这条路。
方案 2:本地 ASR
本地 ASR 之前我也试过——用的是 OpenAI 开源的 faster-whisper tiny 模型做本地化识别,中文识别率不行,日常用根本没法看。
所以后面采用了现在这套:sherpa-onnx + Paraformer-large-zh。Paraformer 是阿里达摩院开源的专门中文大模型,CER 在 AISHELL-1 test 集 6-7%,日常沟通够用。
二、本地 ASR 方案的部署
1. 本机配置
- 系统环境:Ubuntu 24.04
- 处理器:Intel Core i5-7300U @ 2.60GHz × 4 核
- 内存:8 GB
- GPU:仅 Intel 核显(HD Graphics 620),无独立 GPU
2. 部署
装 sherpa-onnx(pip)+ 下载 Paraformer-large-zh 模型(约 230MB)+ 写个 bash wrapper 调 sherpa-onnx CLI + 音频过 ffmpeg 转 wav。三步搞定。
3. 转写速度
截取一段 17.44 秒样例音频:冷启加载 2.3 秒 + 推理 0.7 秒,端到端约 3 秒出文字。RTF 0.041(比实时快约 24 倍)。日常 5 秒语音基本 1 秒内出文字。
4. 资源占用
模型约 230MB,加载后占约 500MB 内存。推理时单核 CPU 峰值。零网络依赖、零 GPU 依赖。
三、接入 OpenClaw 网关层
部署好之后,本地 ASR 语音转写功能已经可以使用——可以接入一个新的技能或者新建一个调用,在与 AI 助手的会话中出现音频文件就调本地 ASR 转写。
但这是手动调用的方案。我需要的是 OpenClaw 的网关层自动转写——飞书语音消息到达时,网关直接调本地 ASR 转写,把文字自动注入会话,再交给 LLM 处理。
要让网关层自动做这件事,还需要一个独立的插件来实现:把本地 ASR 包装成 OpenClaw 媒体理解 provider,注册到插件系统里,让网关在处理音频消息时自动调用。
四、语音回复消息
前两步我已经实现:飞书语音能自动转成文字进会话(ASR),网关层在消息到达时自动调用转写(第三章插件)。
那 AI 回复能不能也附带语音?答案是可以——再接一个 TTS(Text-to-Speech)服务:把 LLM 生成的回复文字转成音频,和文字一起发回飞书。
我这套用的是 Microsoft Edge TTS——这是微软免费公开的云端 TTS 服务(speech.platform.bing.com,跟 Microsoft Edge 浏览器用的同一个 endpoint),中文女声"晓晓"(zh-CN-XiaoxiaoNeural)。Edge TTS 的特点是不需要申请 API key,靠 trustedclienttoken 鉴权(这个 token 是 node-edge-tts 包内置公开常量)。所以 openclaw.json 里 tts 节点只设了语言和声码,连认证字段都不用填。触发条件是 auto: "inbound"——只要对话里有语音消息进来,回复时就自动附带一个音频版本。
到这里整个回路闭环了:飞书语音进来 → 本地 ASR 转文字 → LLM 生成回复文字 → TTS 把回复文字转语音 → 文字 + 音频一起发回飞书。ASR + TTS 两条线让飞书 AI 助手实现了完全的语音对话——用户发语音,助手也回语音。
五、效果展示
文章评论