OpenDot：把语音 Agent 落到真实设备，这个开源平台想做硬件的 AI 身份层
OpenDot：把语音 Agent 落到真实设备，这个开源平台想做硬件的 AI 身份层
先说清楚：这个项目和 CopilotKit 的 OpenDots 没有任何关系，只是名字撞了。CopilotKit/OpenDots 是把 AI 同事放进软件里的持久化 Agent 模板；本文的 OpenDot 是 opendot.ai 的另一个项目，走的是完全相反的路线——把语音 Agent 放进真实的物理设备里。
项目地址：https://github.com/itsperini/opendot 官网：https://opendot.ai/ ｜ 文档：https://docs.opendot.ai/
数据说话：仓库 2026 年 5 月创建，采用 AGPL-3.0 协议，目前还处在 early prototype（早期原型） 阶段，GitHub 上只有个位数 Star、寥寥几个 open issue。别被官网的完整叙事唬住——它更像一份把"真机语音 Agent"整条链路摊开的开源蓝图，而不是可以直接上生产的产品。
一、它到底是什么
官网的 slogan 是 "Make every connected device agent-native"（让每一台联网设备都成为 Agent 原生设备）：
OpenDot gives physical devices identity, memory, tools, permissions, and protocols so AI agents can understand and operate them safely.
翻译过来：OpenDot 给物理设备赋予 AI 原生的"身份"——它是什么、能做什么、记得什么、暴露哪些工具和协议、谁能操作它，让 Agent 能安全地理解和操作这些设备。
但打开 GitHub 仓库，定位又变成了更具体的一句：
The open platform for voice agents on real devices 🎤🔊
这两句话不矛盾，是**"愿景 vs 当前实现"的关系：官网讲的是长期蓝图（设备身份层），仓库讲的是现在真正跑得起来的东西（真机上的语音 Agent）。当前代码的重心，就是"语音 Agent + 真实硬件"**这一条完整闭环。
一句话概括：它想把"语音助手"做成可自托管、可插拔、能真正落到硬件上的开放平台，而不是又一个封闭的智能音箱云。
二、核心特色
官网把整个产品归纳成一个五步循环：define → equip → test → bind → coordinate（定义、装备、测试、绑定、协同）。几个真正有辨识度的设计：
1. AI-native passport（AI 原生护照）
每台设备拿到一份持久身份："我是什么、我能做什么、我记得什么、Agent 该怎样对待我"。这是整个设计的锚点——Agent 操作设备前，先读护照。
2. Protocol-aware（协议感知）
显式定义端点怎么通信、暴露哪些工具、哪些交互该留在浏览器、runtime 还是设备层。官网列出的协议路径是 MQTT / WebRTC / browser tests。
3. Governed operation（受治理的操作）
权限、凭据、上下文全部显式化，Agent 可以在不突破安全边界的前提下操作真实世界的设备。核心边界是：浏览器和设备客户端不能把原始身份配置直接塞给 runtime，必须先向平台 API 换取被授权的 session 或 credential，runtime 再回平台 API 校验 token 后才加载身份配置。
4. Test before hardware（先在浏览器测，再上硬件）
这是最实用的一点：还没碰硬件前，就能在浏览器里模拟交互、检查事件、验证权限边界，把身份打磨好再绑真机。对硬件开发者来说，这省掉了大量"烧固件—试—改"的循环。
5. Sandwich 可替换管线
默认语音管线是显式的四段式，而不是一坨黑盒：
Deepgram VAD -> Deepgram STT -> OpenAI 兼容 LLM -> Deepgram TTS作者刻意让它保持"可替换的分段结构"，目标是同一套 Agent 管理流程，将来能平滑切到本地模型、自托管推理、云会话、本地网络、端侧部署，而不必改 Agent 的管理方式。这是设计上最有野心的地方。
6. 开源硬件方向
硬件不是事后补的，而是平台的一部分。当前固件跑在 Waveshare ESP32-S3-AUDIO-Board 参考板上；路线图明确要把参考板的经验沉淀成开源的 Dot 硬件需求（外壳、声学、电源、PCB、BOM、夹具）。固件里还包含来自 xiaozhi 固件项目的 MIT 授权代码。
三、架构详解
官方对架构的自我描述很精准："一个模块化单体 + 一个独立的实时语音 runtime"。
3.1 分层职责
| 层 | 当前实现 | 职责 |
|---|---|---|
| Docs | Mintlify（docs/） |
产品、安装、贡献、架构文档 |
| Web Console | React, TypeScript, Vite, TanStack Query, lucide-react | 建 Agent、调管线、浏览器测试、绑定设备、设置 |
| Platform API | Fastify, TypeScript, Drizzle | 鉴权、agents、pipelines、devices、deployments、runtime/session token |
| Database | PostgreSQL | OpenDot 自有的产品状态 + Supabase 兼容的鉴权桥 |
| Voice Runtime | Node.js, WebSocket, Deepgram, OpenAI 兼容调用 | Sandwich 会话 + 浏览器/设备的 Speech-to-speech 路径 |
| Firmware | ESP-IDF（Waveshare ESP32-S3-AUDIO-Board） | Wi-Fi 配网、激活、唤醒词、音频 I/O、显示、WebSocket 客户端 |
官网还用另一种视角拆成六层：Console（身份 + 机群上下文）→ Platform API（鉴权 + 权限）→ Database（记忆 + 产品状态）→ Runtime（已验证的交互）→ Protocols（MQTT / WebRTC / 设备 I/O）→ Firmware（真实世界绑定）。核心原则一句话："身份与运行时保持分离"——身份层管上下文和权限，runtime 与传输只在授权通过后才执行交互。
3.2 整体数据流
flowchart TB Console["Web console: agents, pipelines, browser test, binding"] -->|HTTPS| API[Platform API: auth, agents, devices, tokens] API --> DB[(PostgreSQL: OpenDot product state)] Browser[Browser Test] -->|/voice| Runtime[Voice runtime] Device[Dot device firmware] -->|/ws| Runtime Runtime <-->|verify token| API Runtime --> Deepgram[Deepgram VAD / STT / TTS] Runtime --> LLM[OpenAI-compatible LLM] Browser -.->|/realtime/client-secret| Runtime Browser -.->|native WebRTC| Realtime[OpenAI Realtime] Runtime -.->|device Opus bridge| Realtime
3.3 三条语音媒体路径
这是架构里最实的部分，三种场景走三条不同链路：
Sandwich Browser Test: 平台签发短期 voice-session token -> runtime 校验 -> 接受 /voice
Dot Device: 已激活设备用存储的设备凭据 -> runtime 校验 -> 接受 /ws
（Sandwich 走 Deepgram+LLM+TTS；S2S 走服务端 OpenAI Realtime WS 桥，固件收发 Opus）
S2S Browser Test: POST /api/runtime/realtime-browser-sessions
-> /realtime/client-secret 换取 OpenAI Realtime client secret
-> 浏览器用原生 WebRTC 直连一个关键安全设计：OPENAI_API_KEY 始终留在 runtime 内部，浏览器只能拿到短期、可回收的 client secret。OPENAI_BASE_URL 只影响 Sandwich 的 LLM 段。
3.4 设备激活与绑定（OTA bootstrap）
固件 -> runtime OTA 端点 -> 代理到 Platform API -> 创建 / 校验激活请求
-> 用户在 Dot Device 控制台认领口语验证码 -> 平台存下设备凭据
-> 已认证的 /ws 连接 -> runtime 从平台 API 加载当前绑定的 Agent 配置
-> 决定走 Sandwich 还是 Speech-to-speech3.5 数据归属
OpenDot 把产品状态放在自己拥有的 PostgreSQL 表里：app users、本地登录凭据、偏好、SDK API key、版本化的 agents 和 pipelines、devices、激活请求、设备凭据、runtime session token、设备状态、deployments、deployment device targets。Supabase Auth 只提供身份，持久化的产品数据仍归 OpenDot 自己的表。
四、快速上手
要求 Node.js 24 和 pnpm，最省事的是一把梭 Docker Compose：
cp .env.example .env
docker compose up --build
# 打开 http://localhost:5173，注册一个本地账号进入工作台在根目录 .env 里填上 provider key：
DEEPGRAM_API_KEY=...
OPENAI_API_KEY=...
OPENAI_BASE_URL=
OPENAI_MODEL=gpt-5-mini
OPENAI_MAX_OUTPUT_TOKENS=512
OPENAI_REASONING_EFFORT=low
OPENAI_VERBOSITY=low也可以拆成三个进程跑：pnpm run api（:8788）、pnpm run dev（:5173）、pnpm run runtime（ws://localhost:8787/voice）。
然后：建身份 → 进 Configuration 页 → 从 Browser Test 连接。Sandwich Agent 走本地 runtime WebSocket；Speech-to-speech Agent 走平台签发的临时 Realtime secret + 浏览器原生 WebRTC。
固件在 dot-device/firmware/，目标板是 Waveshare ESP32-S3-AUDIO-Board，用 ESP-IDF 构建，能力包括 Wi-Fi 配网、唤醒词、LVGL 显示、双麦输入 + 扬声器输出、WebSocket 连本地 runtime、OTA 激活。
仓库还自带 render.yaml Blueprint，可以把同一套容器映射到托管预览：opendot-web / opendot-api / opendot-runtime，后端接 Supabase Postgres。
五、现状与路线图
官网的口径比代码超前：官网讲 MQTT / WebRTC / 协议层 / 机群上下文，仓库的当前实现其实主要围绕 WebSocket + 浏览器 WebRTC + ESP32 语音板这条本地闭环。路线图本身很坦诚：
- Current：把本地浏览器、runtime、provider、Dot 设备的闭环做可靠
- Next：把 provider、agents、runtime 事件、后端契约、设备诊断模块化
- Later：本地/自托管全栈语音、SFU 式媒体、MQTT 式设备通信、开源 Dot 硬件、端侧推理探索
- Not yet goals（明确不做）：托管多租户 SaaS、Marketplace、企业 SSO/计费、过早的广泛硬件支持、过早的集成矩阵
它还定义了一个公开 alpha 发布门槛：只发源码、诚实标注原型、不发 Docker 镜像/npm 包/固件二进制/OTA 渠道，并要求本地 CI 通过、依赖审计无中高危漏洞、文档链接无死链、ESP-IDF 5.5.2 能构建固件、固件日志不得打印 Wi-Fi 密码/provider key/runtime secret/设备凭据、浏览器测试要完成一整轮真实语音对话。
六、总结
CopilotKit/OpenDots 是把 AI 同事放进软件里；OpenDot 是把语音 Agent 放进硬件里。 后者的价值不在成熟度（它还很早期，AGPL、原型阶段），而在于它摊开了一套"设备身份 → 权限治理 → 语音管线 → 浏览器测试 → 真机绑定"的完整开源思路，而且愿意把硬件、固件、协议层都做成源码可见、可贡献的轨道。
想自建"能落到真实设备上的语音 Agent"的开发者，它是一份不错的参考蓝图；想直接拿来当生产平台的，现在还不是时候。尤其值得学的是它那条控制边界：客户端永远拿不到能直接驱动 runtime 的原始配置，一切要先过平台 API 的授权和 token 校验。
📦 项目地址: https://github.com/itsperini/opendot 🔗 官网: https://opendot.ai/ 📚 文档: https://docs.opendot.ai/ 🔗 语言: C++（固件主导）/ TypeScript 📄 许可证: AGPL-3.0
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
