Sokuji：把双向同传塞进桌面应用和浏览器扩展的开源方案

Sokuji 解决的是哪一类会议问题

双语会议里最麻烦的不是翻译本身，而是方向切换。两个人各说一种语言，翻译工具如果只支持单向，就得有人在会话中途手动改设置。Sokuji 的 README 把它描述为「auto-detects which language is being spoken and translates it into the other」，也就是设定 Language A 和 Language B 之后，由程序判断当前说的是哪一种，再翻译成另一种。这个判断是产品要解决的核心问题。

目标用户写得很清楚：桌面端面向任何带麦克风输入的应用，README 列举了 Zoom、Teams、Discord、Slack、游戏、OBS；浏览器扩展面向网页版会议平台，列举了 Google Meet、Teams、Zoom、Yandex Telemost、Discord、Slack、Gather.town、Whereby、Jitsi Meet。两端的差别不在功能，README 的对比表里 Features 一栏两端都写「All features identical」，差别在于覆盖面：桌面应用能进任何有麦克风的应用，扩展只覆盖浏览器里的会议页面。

音频从麦克风到对方耳朵的路径

README 的流程图给出了数据流：你说话，Sokuji 接收，然后按配置走云端或本地两条分支之一。云端分支接 OpenAI、Gemini、Palabra、Doubao 等提供方，本地分支走 on-device AI，顺序是 ASR 到翻译再到 TTS，最后输出翻译后的语音，送进 Zoom、Teams、Meet、Discord 或任意应用。

双向能力来自同时捕获两路音频。README 在双向翻译一节写明「capture system audio and microphone together」，麦克风是你自己，系统音频是会议里对方的声音，两路一起进同一个会话。它还提供 live subtitles，README 建议共享屏幕让对方也能读到字幕。双向模式标注为由 Soniox two-way mode 驱动，覆盖 60 多种语言、3600 多对语言组合。这里要注意一个边界：这个语言对数量是 Soniox 云端模式的能力，本地推理的语言覆盖是另一套数字，README 在本地推理部分单独列了 99 种以上语音识别语言、55 种以上翻译语言、53 种 TTS 语言，两者不能混着看。

本地推理这条路的真实成本

本地推理是 Sokuji 和多数同类工具拉开距离的地方。README 说它由 WASM 和 WebGPU 驱动，不需要 API key，不需要昂贵 GPU，完全离线，完全私密，跑在现代浏览器的 CPU 和集成显卡上。模型清单是 44 个 ASR 模型，其中 23 个离线、10 个流式、11 个 WebGPU，涵盖 Whisper、Cohere Transcribe、Voxtral、Granite Speech；75 个翻译模型，包括 69 个 Opus-MT 语言对加 6 个多语言 LLM，涉及 Qwen 2.5、Qwen 3、Qwen 3.5、Hunyuan-MT 1.5、TranslateGemma；137 个 TTS 模型，跨 53 种语言，引擎有 Piper、Piper-Plus、Coqui、Mimic3、Matcha、MMS、VITS、Supertonic。

这些数字好看，但反过来读就是使用成本。用户要在 44 加 75 加 137 共 256 个模型里自己挑组合，README 只提供了 one-click model download with IndexedDB caching，没有给出推荐配置或默认组合。选错模型的后果是延迟或质量不达标，而 README 没有提供任何延迟或质量数据。另外，WebGPU 的可用性取决于浏览器和显卡驱动，README 把它当作前提而不是可选项，这一点在旧机器上需要先验证。

安装与从源码构建的具体命令

桌面端从 Releases 页面下载对应安装包，README 列出的文件名有规律可循：Windows 是 Sokuji-x.y.z.Setup.exe，macOS 分 Apple Silicon 的 Sokuji-x.y.z-arm64.pkg 和 Intel 的 Sokuji-x.y.z-x64.pkg，Linux 是 Debian 系 x64 的 sokuji_x.y.z_amd64.deb 和 ARM64 的 sokuji_x.y.z_arm64.deb。浏览器扩展可以直接从 Chrome Web Store 或 Microsoft Edge Add-ons 安装，也可以下载 sokuji-extension.zip 解压后，在 chrome://extensions/ 打开 Developer mode，用 Load unpacked 指向解压目录。

从源码构建的命令 README 给得很短：先 git clone https://github.com/kizuna-ai-lab/sokuji.git，然后 cd sokuji && npm install，开发用 npm run electron:build 之外的 npm run electron:dev，生产构建用 npm run electron:build。仓库主语言是 TypeScript，构建走 Electron 路径。需要提醒的是，README 没有说明 Node 版本要求，也没有列出构建产物之外的依赖约束，实际构建前值得先看仓库里的构建配置。

什么情况下 Sokuji 是错的工具

最明显的一条是本地推理并非零配置。README 说它不需要 API key、不需要联网，但模型要一个个下载并缓存到 IndexedDB，这是一个需要用户主动完成的前置步骤，不是安装完就有的能力。如果使用场景是临时在别人机器上开一次跨国会议，走云端提供方更省事。

第二条与部署形态有关。浏览器扩展只覆盖网页版会议平台，README 的列表里全是浏览器内的服务。如果对方用的是原生客户端，或者你要翻译的是游戏语音、OBS 里的音频，扩展帮不上忙，必须换桌面应用。反过来，桌面应用要捕获系统音频，这在不同操作系统上的实现路径并不相同，README 没有给出各平台的具体差异说明，也没有列出已知限制。

第三条来自许可证。项目采用 AGPL-3.0，README 里只挂了 LICENSE 链接，没有额外的授权说明。如果你的使用方式涉及把修改后的版本作为网络服务提供，AGPL-3.0 的条款会要求你向用户提供对应源码。这里不做法律判断，但选型时必须先让法务确认你的分发方式是否落在触发条件里。

和只做单向翻译的工具差在哪

更常见的做法是单向翻译工具，你选一个源语言和一个目标语言，工具只往一个方向翻。这类工具在讲座、单人口播、看外语视频的场景里够用，实现也简单，不需要语言检测。Sokuji 的差异在于它把语言检测放进了流程：README 强调 auto language detection 和 no manual switching mid-conversation，两路音频同时进会话，方向由程序判断。代价是引入了检测错误的可能，而 README 没有说明检测失败时会怎样降级，也没有给出置信度或手动纠正的机制描述。

另一类替代方案是自己拼装管线，用单独的 STT 服务加翻译 API 加 TTS 服务。这样能完全控制每一环，但双向切换、系统音频捕获、字幕叠加这些工作都要自己写。Sokuji 的价值在于把这些整合成一个可安装的应用，而不是在某一环上提供更强的模型。如果你的需求只是把一段录音转成字幕，用 Sokuji 属于过度配置。

维护节奏与升级需要留意的东西

从仓库信息看，最近三个版本是 v0.40.3、v0.40.2、v0.40.1，发布时间分别是 2026 年 9 月 7 日、9 月 5 日和 9 月 5 日，主分支最后一次推送是 2026 年 9 月 10 日。版本号已经到 0.40.x，说明迭代频繁，小版本之间间隔可能只有一两天。对使用者的含义是升级会来得比较勤，桌面端需要重新下载安装包，浏览器扩展需要等商店审核或重新加载解压目录。

升级成本主要落在本地模型上。README 提到模型通过 IndexedDB 缓存，但没有说明版本升级后缓存是否失效、是否需要重新下载。如果你的环境带宽有限或者依赖离线部署，这一点值得在升级前确认。另外项目提供了日文和中文 README 译本，文档维护看起来是跟得上的，但技术细节仍然集中在英文主 README 里。

编辑结论

适合需要在双语会议里做双向同传、又不想把音频交给第三方云服务的团队，也适合想在自己机器上跑 ASR、翻译、TTS 全链路的人。不适合只想装完即用、不愿管理模型下载与缓存的人，因为本地推理的 44 个 ASR、75 个翻译、137 个 TTS 模型都要自己选。接入前先确认两件事：一是 AGPL-3.0 是否与你的分发方式兼容，二是桌面端捕获系统音频在你所用平台上的实际表现。

官方来源

1. kizuna-ai-lab/sokuji on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases