语音 Agent 驱动实体显示

语音 Agent 驱动实体显示 是本库对 OpenAI 开发者博客《Bringing my LED display to life with GPT-Live-1 and Codex》一文中架构的归纳视角，不是官方术语。它讨论的问题是：如何把一块只有 128 × 64 像素的 LED 墙，从只会显示航班的礼物，变成可以用「Hey Jack」随时使唤、可以随时打断、还能常驻通电的语音助手。

文章是作者 Sid Rampally 2026 年 9 月发布的个人项目复盘：Raspberry Pi + 128 × 64 HUB75 LED 面板 + GPT-Live + Codex。本词条抽取其中可迁移的架构分工，硬件细节与开发过程按来源保留。

三层分工

项目最终稳定下来的形态是三层，各层只做自己擅长的事：

flowchart LR
    U["用户\n「Hey Jack」"] <--> P["Raspberry Pi\n语音服务 + 本地渲染器"]
    P <--> G["GPT-Live-1\n倾听与说话（全双工）"]
    P -->|"Task（客户端委派）"| L["GPT-5.6 Luna\n研究 + 工具（low reasoning）"]
    L -.->|"Result"| P
    P -->|"Pixels（DDP 帧）"| W["LED wall\n128 × 64 像素"]

层	承担者	职责
对话层	GPT-Live-1	维持打开的对话、边听边说、接受打断，判断一次请求是否需要对话之外的能力
研究 / 工具层	GPT-5.6 Luna（low reasoning，由 Pi 发起 client-side Responses API 请求）	公网搜索、只读日历连接、Wikimedia Commons 找图（含 license / attribution 检查）、决定用哪种场景
确定性渲染层	Pi 上的本地渲染器	校验场景 JSON，把场景转成精确的 128 × 64 RGB 帧，经 DDP 发给控制器

这与 AI 受限层与确定性系统分工是同一条原则：模型负责理解和选择（选场景、写场景描述），像素怎么画、发多少帧由校验过的确定性代码完成。GPT-Live-1 只是「我说话的对象，不是画墙的对象」——作者的原话。

硬件与数据通路

组件	作用
Raspberry Pi	常驻主机：麦克风/扬声器、语音服务与渲染器
128 × 64 HUB75 RGB 面板	显示终端；像素极少，逼着排版反复迭代
ESP32 控制器 + WLED-MM	接收帧并驱动面板；分辨率配置为 128 × 64
DDP（局域网协议）	渲染器把 RGB 帧发给控制器的传输层
PipeWire + WebRTC 回声消除	Pi 上的本地音频处理；采集 24 kHz PCM 流

文章对开发过程的记录有一条对硬件新手很友好的分工：Codex 负责研究与排障（甚至直接在作者拍的电路板照片上标注关键连线），作者负责物理接线并回报异常。

从 Mac 原型到常驻设备

第一个可用版本的语音交互跑在 ChatGPT 桌面端、渲染器跑在作者的 Mac 上；笔记本一睡眠，墙就没用了。迁移目标是「下班回家不用开电脑」。迁到 Pi 后常驻两个服务：

服务	职责
voice service	麦克风、PipeWire 音频、WebRTC 回声消除、唤醒/休眠、打断、GPT-Live-1 连接、客户端委派
renderer service	动画待机屏、天气与 MTA 地铁到站刷新、脱敏日历数据、场景 JSON 校验、帧流式发送

迁移本身也按 Agent 工程惯例收尾：代码放私有仓库，配好备份与回滚路径，Codex 负责看日志、把服务跑起来。

关键设计决策

客户端委派（client-side delegation，文章用语）。需要研究或改墙时，GPT-Live-1 产生一次委派，由 Pi 自己发起 Responses API 请求调用 GPT-5.6 Luna，推理档位为 low；工具集也由 Pi 侧决定，而不是把所有工具挂在对话模型上。前台对话因此不被后台研究和渲染阻塞，用户可以随时打断、补充，研究与渲染继续在后台进行。

场景复用优先，未知请求才新建。Luna 从已有场景（天气、日程、消息、倒计时）里选合适的；用户要的东西不在模板里，才创建新场景描述，交给渲染器校验。这把「每次从零画屏」降为少数几个可维护场景的组合。

委托上下文必须带历史。一个早期 bug：用户先问纽约天气，再说「Show that on the wall」，模型不知道 “that” 指什么——排查发现是应用发起委派时只发送了最新一条请求。修复是把手头的近期对话和先前结果一起带过去。这是 Context Engineering（上下文工程）里「对话历史属于委派上下文」的最小现场案例。

能力要显式接到工具面上。渲染器一直支持显示图片，但语音助手没有找图工具，助手就直接回答「做不到」；补上 Wikimedia Commons 查找（顺带校验许可与署名）后能力才打通。参见面向 Agent 的工具设计。

小屏约束反过来塑造渲染器。128 × 64 像素装不下多少内容，文本、图片、天气、日程、地铁到站的排版靠作者描述「哪里不对」、Codex 调渲染器、再试一轮的循环迭代；图片按比例缩放进 128 × 64，不拉伸变形。

演示视频中的场景

来源附带的 55 秒演示视频（抽帧确认）显示了两类场景：

待机仪表盘：日期时间大字（WED AUG 26 / 2:11 PM）、天气（SUNNY 82°F）、地铁到站行（站名与 UP / DN 方向、DUE 6M 等倒计时），常驻循环刷新。
请求后的专用天气场景：整屏太阳图形 + 79F + SUNNY NOW，伴随助手语音确认「Done. It’s on the wall.」

视频印证了正文的两点：场景系统确实是「复用已有场景」而非每次现画；语音回应与上屏动作解耦，先答「Sure. Checking.」，结果就绪后再报完成。

可迁移的结论

全双工对话、研究/工具、确定性渲染拆成三层后，每层可以独立替换：换模型不动像素通路，改渲染器不动对话逻辑。
常驻设备的关键迁移不是换更强的机器，而是把整条链路从可睡眠的开发机挪走，并补上日志、备份与回滚。
委派上下文要携带足以解析指代的历史；工具面要覆盖系统真实具备的能力；两者都是「对话模型看起来变笨了」的常见真因。
作者没有 HUB75、ESP32、树莓派或语音模型经验，项目靠「不会就问 Codex」推进——这是 Codex 作为陌生领域入门路径的一手案例。