第五讲：飞书语音控制 Codex 桌面版
前四讲让寅宾具备了搜索、记忆和 Skill。最后一讲要把这些能力连到实际开发任务：在飞书里说一句话，让 Codex 在桌面开发环境中执行任务，再把进度和结果发回来。
先纠正最容易混淆的一点：
“通过飞书控制 Codex 桌面版”默认不是让机器人移动鼠标点击界面，而是通过 Codex app-server 控制原生线程。
学完这一讲，你应该能够回答：
| 问题 | 本讲给出的答案 |
|---|---|
| Codex 桌面版负责什么 | 提供 Codex 原生线程、认证、模型、工具续跑、压缩和开发执行能力 |
| OpenClaw 负责什么 | 接收飞书消息、管理会话、选择模型、控制权限、展示过程并回传结果 |
| 两条路线是什么 | 默认使用 app-server 原生线程；Computer Use 仅在需要操作图形界面时使用 |
| 语音如何变成任务 | 飞书接收音频，OpenClaw 下载并转写，再用转写文本执行任务 |
| 如何继续一个任务 | 在同一个飞书会话继续，或通过 /codex resume <thread-id> 恢复线程 |
| 为什么需要审批 | 代码修改、命令执行和外部操作必须受工作目录、工具权限和人工确认约束 |
一、先分清两个系统
OpenClaw 与 Codex 不是互相替代，而是各自承担不同职责。
| 能力 | Codex 桌面版 / app-server | OpenClaw / 寅宾 |
|---|---|---|
| 原生线程 | 创建、恢复、续跑、压缩 | 选择并绑定当前线程 |
| 模型认证 | 使用 Codex 账户和原生配置 | 也可以在消息渠道选择模型 |
| 开发执行 | 读写项目、运行命令、调用工具 | 配置工作区、审批和可见性 |
| 消息渠道 | 不负责飞书等外部渠道 | 接入飞书并管理会话 |
| 身份与权限 | 提供 Codex 自身权限模型 | 增加渠道、用户、工具和审批边界 |
| 媒体与回传 | 以开发任务和工具结果为主 | 发送文字、卡片、图片、文件和进度 |
| 上下文 | Codex 原生 thread 与 compaction | 渠道历史、工作区文件、Skill 和记忆 |
一句话概括：
Codex 是执行开发任务的智能体；OpenClaw 是把飞书、语音、权限和 Codex 连接起来的控制面。
1.1 桌面版 Codex 的基本使用
Codex 桌面应用（用户常称 ChatGPT 桌面版）可以按四个动作理解：
- 选择项目。 打开一个本地代码目录，并确认当前分支和允许访问的范围。
- 创建线程。 一个线程对应一个连续任务，例如“修复移动端溢出”或“审查这次发布”。
- 描述任务。 写清目标、范围、约束、验收命令和交付格式，让 Codex 先调查再修改。
- 审查结果。 查看工具过程、文件差异和验证结果；遇到命令执行或高风险动作时进行审批。
桌面版的优势是可视化：项目、线程、工具调用、差异和审批都在同一个界面中，适合人工深度参与。它的限制是入口固定在桌面应用，离开电脑后不方便继续操作。
接入 OpenClaw 后，线程仍由 Codex 原生执行，但入口可以扩展到飞书。桌面版适合“坐下来详细审查”，飞书适合“随时提交、查看进度、补充方向和处理审批”。两边连接的是同一类核心能力，不是两套互不相关的系统。
二、默认路线：Codex app-server 原生线程
官方 @openclaw/codex 插件通过 Codex app-server 执行嵌入式智能体回合。它使用 Codex 的原生线程、恢复、工具续跑、压缩和 app-server 执行机制，而不是模拟用户点击桌面窗口。
2.1 请求如何流转
- 用户在飞书发出文字或语音。
- 飞书插件接收消息；如果是语音，则下载音频并生成媒体附件。
- OpenClaw 调用配置好的语音转写能力，把音频转成文字。
- OpenClaw 识别用户、渠道、工作区和权限，构造任务。
- Codex 插件通过 app-server 创建新线程，或恢复已有线程。
- Codex 在指定项目目录中执行任务，必要时请求审批或补充信息。
- OpenClaw 把状态、问题、审批请求和结果送回飞书。
- 完成后，原生线程保留，可继续追问、恢复或压缩。
2.2 两种传输方式
Codex 插件可以采用两种 transport：
| 传输方式 | 工作方式 | 适合场景 |
|---|---|---|
stdio | OpenClaw 在本地启动 codex 进程并与其通信 | 单机部署、配置简单 |
websocket | 连接一个已经在运行的 Codex app-server | 共享服务、已有 app-server 管理流程 |
第一次上手通常从 stdio 开始，确认链路后再考虑连接长期运行的 app-server。
2.3 homeScope：共享还是隔离
Codex 插件中的 appServer.homeScope 决定它使用哪一套 Codex 主目录：
| 取值 | 使用的目录 | 影响 |
|---|---|---|
agent | 智能体隔离目录 | 默认更安全，认证、配置和线程与桌面版隔离 |
user | 原生 $CODEX_HOME 或 ~/.codex | 可共享原生认证、配置、插件和线程 |
如果希望 OpenClaw 看到并使用 Codex Desktop 的原生线程、登录状态和配置，需要认真评估 user 范围。共享也意味着权限和上下文影响面更大，不应在未确认的情况下直接开启。
三、安装与基础配置
3.1 安装插件
openclaw plugins install @openclaw/codex如果 OpenClaw 配置里使用了 plugins.allow 白名单，需要把 codex 加入允许列表，否则插件不会启用。
3.2 登录模型供应商
openclaw models auth login --provider openai实际供应商名称和登录流程以当前版本为准。已经通过 Codex 原生登录、且 homeScope 配置为共享时，也应先检查账户与权限是否符合预期。
3.3 最小配置示例
{
plugins: {
entries: {
codex: {
enabled: true
}
}
},
agents: {
defaults: {
model: "openai/gpt-6-astra"
}
}
}如果还需要指定 app-server 传输和共享范围，可在 Codex 插件配置中补充。不要从网上直接复制来路不明的完整配置，先确认字段与当前版本一致，再用最小配置逐步验证。
3.4 验证状态
在支持命令的渠道中发送：
/codex status
/codex models
/codex account期望结果分别是：插件与 app-server 状态正常、能看到可用模型、账户认证有效。任何一项失败时，先解决这一项，不要继续往下连接飞书。
四、常用线程命令
Codex 插件提供了一组以 /codex 开头的控制命令。它们用于管理线程和运行状态，而不是代替正常任务描述。
| 命令 | 作用 |
|---|---|
/codex status | 查看插件、app-server 和当前绑定状态 |
/codex models | 查看可用模型 |
/codex threads [filter] | 列出原生线程 |
/codex resume <thread-id> | 恢复指定线程 |
/codex compact | 压缩当前线程上下文 |
/codex review | 对当前工作发起审查 |
/codex account | 查看账户状态 |
/codex mcp | 查看 MCP 连接状态 |
/codex skills | 查看 Codex 可用技能 |
/codex binding | 查看当前渠道与线程的绑定 |
/codex detach | 解除当前绑定 |
/codex stop | 停止当前运行 |
/codex steer <text> | 在不中断当前任务的情况下补充方向 |
4.1 为什么有时无法恢复
一个原生线程同一时间只能被一个 Codex 进程安全地推进。如果桌面版或其他进程正在运行该线程的回合，OpenClaw 不能强行 resume 或 branch。正确做法是：
- 等待当前回合结束。
- 在持有线程的客户端完成或停止任务。
- 再通过
/codex resume <thread-id>继续。 - 原生子线程不能直接恢复时，回到父线程继续。
不要通过重复发送命令来“抢占”线程。这只会制造更多状态冲突。
五、接入飞书渠道
5.1 登录飞书渠道
openclaw channels login --channel feishu飞书文档要求 OpenClaw 版本不低于 2026.5.29。生产使用前先确认版本和渠道配置已通过升级验证。
默认情况下，飞书可以使用 WebSocket 事件传输，不要求服务器暴露公网 URL。Webhook 是可选方式，适合已有统一回调网关的部署。
5.2 为什么飞书能接收语音
飞书渠道可以接收文字、富文本、图片、文件、音频、视频和贴纸。收到语音时：
- 入站音频先被规范化为媒体附件。
- 配置音频处理后，OpenClaw 下载语音文件并尝试转写。
- 如果飞书 payload 已经带有 transcript，则直接使用，不再重复运行语音识别。
- 如果没有任何转写能力，智能体只会看到类似
<media:audio>的占位符和附件，无法可靠理解语音内容。
自动转写会按当前可用能力选择候选，包括回复模型、已配置的供应商认证、常见云端语音服务和本地语音识别工具。OpenAI 常见默认模型包括 gpt-4o-transcribe，也支持更轻量的 gpt-4o-mini-transcribe。具体顺序和可用项取决于版本、配置和账户。
5.3 推荐的首次连通测试
先不用语音，按下面顺序排除问题：
- 在飞书发送
/codex status，确认文字链路和插件正常。 - 发送“列出当前工作区路径”，确认会话绑定的是预期项目。
- 发送一段十秒语音：“请回复你收到的测试编号是一二三。”
- 查看回复是否准确转写数字；如果不准确，先检查语音识别配置。
- 最后再提交一个只读任务，例如“读取 README，用三句话总结项目目标，不要修改文件”。
只有文字、语音、只读执行三条链路都正常后，才适合开放写文件和运行命令。
六、用自然语言提交开发任务
接入完成后，飞书里的表达可以尽量自然，但最好包含五个要素：
| 要素 | 示例 |
|---|---|
| 目标 | 修复移动端导航栏溢出 |
| 范围 | 只修改 src/components/Reader.astro |
| 约束 | 不改变桌面端样式，不升级依赖 |
| 验收 | 390 像素宽度下无横向溢出，pnpm check 通过 |
| 交付 | 给出改动摘要、验证结果和未验证项 |
可以这样直接说：
请让 Codex 检查教程站的移动端导航。只修改相关组件和样式，不要升级依赖。验收标准是 390 像素宽度下页面没有横向溢出，
pnpm check和pnpm build通过。完成后给出文件列表、测试结果和需要我确认的事项。
6.1 任务进行中如何补充要求
如果任务方向基本正确，只是需要增加约束，使用 steering，而不是重新发一个互相冲突的任务：
/codex steer 首页不要改，只处理教程详情页如果任务目标已经错误，先停止：
/codex stop然后再重新描述任务。不要在一个已经跑偏的线程上连续叠加矛盾要求。
6.2 审批如何回到飞书
Codex 在运行命令、修改文件或访问外部系统时，可能触发自己的权限请求。OpenClaw 可以把这些请求转成飞书中的可读消息。
批准前至少检查：
- 执行的是哪个工作区，路径是否正确？
- 命令是否会删除、覆盖、发布或付款？
- 是否使用了生产凭证？
- 影响范围是否只在当前项目？
- 是否可以先在测试环境执行？
- 如果不批准，有没有更小、更安全的替代步骤？
审批不是确认“机器人很聪明”，而是确认具体动作及其后果。
七、可选路线：Computer Use
只有在任务必须操作用户图形界面时，才需要 Codex Computer Use。例如：
- 点击一个没有 API 的桌面应用。
- 查看只存在于屏幕上的窗口状态。
- 操作浏览器图形界面中的交互流程。
- 在没有其他连接器的环境下完成点击和输入。
这条路线与 app-server 原生线程不同。它通常需要 macOS 屏幕录制、辅助功能等系统权限，也更依赖窗口位置、分辨率和应用状态。
常用命令：
/codex computer-use status
/codex computer-use install7.1 为什么不把它作为默认方案
| 风险 | app-server 原生线程 | Computer Use |
|---|---|---|
| 依赖界面布局 | 否 | 是 |
| 速度 | 较快 | 受截图和点击影响 |
| 可观测性 | 线程与工具事件清晰 | 需要观察屏幕与应用状态 |
| 故障类型 | 认证、线程、工具错误 | 权限、焦点、弹窗、坐标、分辨率 |
| 批量自动化 | 更适合 | 容易受界面变化影响 |
| 安全控制 | 工作区和审批规则明确 | 可能拥有更广的桌面操作范围 |
能用原生工具和连接器完成的任务，优先走原生路线。Computer Use 是补缺口，不是万能入口。
八、一次完整的语音任务演示
下面把全过程串联起来：
- 用户在飞书按住语音说：“让 Codex 在教程站项目里检查所有旧链接，修复能确认的失效链接。先列出计划，不要改依赖，完成后运行构建并把结果发给我。”
- 飞书把音频交给 OpenClaw，OpenClaw 下载并转写。
- OpenClaw 识别项目、工作区和当前飞书会话，恢复上次绑定的 Codex 线程，或创建新线程。
- Codex 扫描 Markdown 链接，列出计划和拟修改文件。
- OpenClaw 把计划发回飞书。
- 用户回复“按计划执行，第三方链接只报告不修改”。
- Codex 修改本地链接，运行检查与构建。
- 如果构建失败，OpenClaw 发回失败原因和下一步建议。
- 构建通过后，Codex 汇总文件、验证结果和未验证项。
- 用户继续追问“把这次经验写进项目文档”，同一个线程在保留上下文的情况下继续工作。
这条链路的价值不是“用语音代替键盘”，而是让任务入口、执行环境、审批和结果回传保持在同一个可追踪会话中。
九、故障排查
按从近到远的顺序检查，不要同时修改多个层。
| 现象 | 优先检查 | 处理方向 |
|---|---|---|
| 飞书收不到回复 | 飞书渠道状态、机器人权限、事件订阅 | 先测试普通文字消息 |
| 文字正常，语音无内容 | 音频下载、媒体处理、转写供应商 | 检查媒体附件与转写日志 |
/codex status 失败 | 插件、白名单、app-server | 确认插件启用和进程状态 |
| 看不到桌面版线程 | homeScope、账户、线程归属 | 评估共享用户目录，不强行切换 |
resume 失败 | 线程是否被桌面版占用 | 等当前回合结束后重试 |
| 修改了错误目录 | 会话与项目绑定 | 停止任务，检查 cwd 和权限 |
| 命令一直等待审批 | 飞书卡片、审批消息、超时 | 在渠道内查看原始请求 |
| Computer Use 无法操作 | 屏幕录制、辅助功能、焦点 | 检查系统权限和当前窗口 |
十、安全边界
把飞书、语音、Codex 和桌面能力接在一起后，影响范围明显扩大。必须坚持：
- 每个用户或群组绑定明确的工作区和权限。
- 不用语音处理密钥、密码和生产凭证。
- 删除、发布、付款、权限变更必须人工确认。
- 外部网页和语音转写文本都不能成为绕过权限的指令。
- Codex 的任务范围应在项目目录内，不能默认获得整台电脑的无限权限。
- 审批消息要显示具体命令、路径和影响，而不是只问“是否允许”。
- 任务结束后检查改了哪些文件、哪些命令运行过、哪些结果没有验证。
- 定期清理线程绑定、过期凭证和不再使用的渠道权限。
十一、课堂练习
完成一次从语音到代码结果的闭环：
- 在飞书发送
/codex status，确认插件正常。 - 发送一条语音，让 Codex 只读一个项目 README，并总结三条要点。
- 查看飞书返回的转写结果是否完整。
- 用文字补充一个文件修改任务，明确范围、验收命令和禁止事项。
- 观察 Codex 的审批请求，分别记录一次允许和一次拒绝。
- 在任务完成后要求它列出改动文件、验证结果和未验证项。
- 同一个飞书会话继续追问，确认线程上下文得到保留。
- 最后检查
/codex binding，确认渠道与线程绑定符合预期。
十二、本讲小结
- 默认路线是 Codex app-server 原生线程。 它保留 Codex 的线程、恢复、压缩和工具执行能力。
- OpenClaw 是控制面。 它连接飞书、语音、身份、工作区、审批和结果回传。
homeScope决定共享还是隔离。 共享原生 Codex 目录能力更强，但权限和上下文影响也更大。- 语音链路包含接收、下载、转写和理解。 任何一步缺失，语音都不能稳定成为任务。
- Computer Use 只处理必须操作界面的场景。 能走原生工具链时，优先走原生工具链。
- 所有执行都要有边界。 工作区、命令、审批、日志和回退路径缺一不可。
实践课结语
五讲连起来，就是一条完整的智能体工程路径：
| 讲次 | 解决的问题 |
|---|---|
| 第一讲 | 建立 OpenClaw、智能体与寅宾的整体认知 |
| 第二讲 | 从网络获取可靠信息 |
| 第三讲 | 用上下文文件形成长期协作人格与记忆 |
| 第四讲 | 用 Skill 沉淀可复用工作方法 |
| 第五讲 | 用飞书语音把 Codex 接入真实开发任务 |
下一阶段可以从自己的一个高频、低风险场景开始：先跑通，再把规则写进上下文，把流程沉淀成 Skill，最后接入一个稳定的渠道。不要第一天就追求“全自动接管”。
课程： 智能体工程导论
讲师： Job Zhao
公司名称： 青岛火一五信息科技有限公司
联系邮箱： postmaster@huo15.com
