--- id: EXP-001 sequence: 1 number: "001" kind: experience slug: mobile-codex label: 经验 001 category: AI 协作 topics: - Codex - 手机 - 飞书 - 微信 - 远程协作 audience: 想离开电脑后，仍能用手机继续同一项 Codex 工作的人 read_minutes: 20 title: 手机直连 Codex：我修了十天，才明白“能回消息”根本不算打通 subtitle: 官网能做的先用官网；自建只补官网不知道的那一小段 summary: 手机收到一句回复，只能证明聊天软件还活着。小龙哥用十天真实故障，把一条微信、飞书到 Codex 的链路修到隔天、息屏和重启后仍可用，也整理出一套普通人能照着排查的方法：先用官方能力，再补同一任务、可靠收件、精确恢复和真实验收。 published_at: "2026-07-26" updated_at: "2026-08-12" version: v3.1 verification: verified visibility: public publication_state: published legacy_path: /kits/001/ public_url: https://aixlg.com/exp/mobile-codex/ wechat_url: https://aixlg.com/kits/001/?from=wechat source_href: https://aixlg.com/exp/mobile-codex/ source_cta: 进入完整手机直连经验 article_state: 经验包终版已发布；真实手机隔天使用已由小龙哥确认通过 takeaways: - 能用 OpenAI 官方 Remote 就先用官方，不要为了显得厉害重复造一套远程控制 - 自建桥接时也先升级并复用 GolemBot 的渠道、重连和续跑能力，只补它不知道的本地业务边界 - 微信和飞书必须回到同一条 Codex 任务；标题给人看，稳定 threadId 才是机器身份 - 飞书消息接入和飞书业务操作是两层：前者走可靠网关，后者走国内版官方 CLI / OpenAPI - 收到、保存、执行、完成和送达是五件事，失败绝不能包装成“稍后会继续” - 息屏经常只是表面现象，归档、旧服务重启复活和双写手才可能是真根因 - 单测、健康接口和本机回归都不是终点，隔天真实手机使用正常才算用户验收 deliverables: - 官方 Remote、GolemBot 与本地最小补丁的清楚边界 - 一张手机直连 Codex 的完整关系图 - 十天真实故障时间线和每次误判的原因 - 普通人可照着走的十分钟排查顺序 - 从消息到结果的可靠状态与最终验收清单 - 可直接交给其他 AI 的施工、排障和验收提示词 source_refs: - https://learn.chatgpt.com/docs/remote-connections - https://github.com/openai/codex/blob/main/codex-rs/app-server/README.md - https://github.com/openai/codex/issues/26159 - https://0xranx.github.io/golembot/channels/feishu - https://github.com/0xranx/golembot/releases/tag/v0.48.4 - https://github.com/larksuite/cli replaces: [] revisions: - version: v3.1 date: "2026-08-12" note: 补清飞书消息通道与飞书业务控制面的边界；接消息仍由网关负责，联系人、消息、任务、文档等操作统一走国内版官方 CLI / OpenAPI，不以客户端界面遥控代替。 - version: v3.0 date: "2026-08-09" note: 写入最终真实验收，纠正“息屏是根因”和“本地补丁越多越稳”的误区；补全官网优先、GolemBot 当前边界、十分钟排查法和隔天重启验收。 - version: v2.0 date: "2026-08-07" note: 结合手机入口完整故障史，补入同一任务架构、归档恢复、旧服务复活、可靠消息状态与真实验收。 - version: v1.2 date: "2026-08-01" note: 增加固定旧地址与公众号回链；原详情页和三套提示词保持不变。 - version: v1.1 date: "2026-07-30" note: 纳入连续经验目录；原详情页和三套提示词保持原地址。 - version: v1.0 date: "2026-07-26" note: 首次公开手机直连 Codex 的官方路线、进阶路线与验收提示词。 audio: - label: 播客版 · 最终复盘 note: 宁宁 × 明明｜9:45｜高配版，机器质检通过 src: /exp/audio/mobile-codex-final-20260809.mp3 --- > 一句话结论：先用 OpenAI 官方 Remote。确实需要微信或飞书时，再用成熟开源网关接渠道。自己只补官网和通用工具不知道的那一小段：哪条任务是唯一入口、消息有没有真的落盘、归档后能不能精确恢复、失败有没有说真话。 ## 我想要的，其实只是出门后还能补一句话 这件事一开始听起来很简单。 我在 Mac 上让 Codex 做事，走开以后突然想到一句补充，就在微信或飞书里发给“豆豆”。家里的电脑继续原来那件事，做完再把结果发回来。 不是在手机上再开一个 AI，也不是远程看电脑屏幕。我只想回到同一张工作台：原来的项目、文件、规则和对话都在，手机只是多了一个入口。 OpenAI 已经有 Remote。官方文档写得很清楚：手机可以继续电脑上的现有对话、补充要求、处理确认、看输出。主机睡眠、断网或退出应用后，远程访问会停止。只要你的网络和账号环境合适，这就是第一选择，配置少，也不用自己维护消息通道。 我在中国大陆长期使用微信和飞书。它们打开更快，语音、图片和日常聊天也顺手，所以才做了本地桥接。这里要先把话说透：本地桥接不是比官方高级，只是更贴合我的日常入口，代价是可靠性和安全都要自己负责。 ## 先别写代码，看看官网已经做了什么 这次最值钱的教训，不是某一段修复代码，而是先停下来查官网。 OpenAI app-server 已经提供 `thread/resume`、`thread/archive` 和 `thread/unarchive`。任务被归档后，继续请求会被拒绝；正确动作是恢复原任务，再续接。服务器拒绝一个已归档任务，不是它坏了，反而是在守边界。 GolemBot 已经负责飞书长连接、断线重连、图片和文件转发，也有官方续跑能力。我们一度自己写过相似的 watchdog 和续跑逻辑，后来对照新版才发现，官网已经修了。那部分本地代码应该删，不该继续背着两套实现。 截至 2026 年 8 月 9 日，GolemBot 的 GitHub 与 npm 最新稳定版是 0.48.4。这个版本只更新了模型供应商预设，没有增加“固定 Codex 任务被归档后自动恢复”。这也说明了边界：通用工具知道怎样接飞书、微信和 Codex，却不知道你家里哪一条任务是不能归档的基础设施。只有这部分，才值得做最小的本地补充。 以后碰到类似问题，我会先问三句： 1. 官网现在有没有现成能力？ 2. 当前安装的是不是已经包含修复的版本？ 3. 我准备写的代码，是通用能力，还是只有我的业务才知道的规则？ 前两项能解决，就升级和配置。只有第三项才自己写。 ## 接消息和操作飞书，不是同一层 这里很容易再绕一次弯路。 飞书长连接或 GolemBot 负责把小龙哥的一句话送到豆豆；豆豆真的去查联系人、发消息、改任务、读文档、操作知识库时，应该使用国内版飞书的官方 `lark-cli` 或 OpenAPI。前一层是消息入口，后一层是业务控制面。 控制面不依赖飞书桌面窗口，也不靠坐标点击。每次操作都显式写清 `user` 还是 `bot`，先解析精确对象，写入支持时先 dry-run，创建或发送带幂等键，成功后按返回 ID 回读。CLI 报错、OAuth 过期或权限不足时，就修 CLI 和权限；不能悄悄换机器人身份，也不能退回界面“点一下试试”。完整开箱方法见[把飞书交给豆豆：国内版、CLI、本人身份一次打通](/exp/feishu-cli-doudou/)。 ## 正确关系：手机只是门，不是第二间办公室 ![手机直连 Codex 的正确关系：微信和飞书只是入口，统一网关把消息送进电脑上的同一条 Codex 任务](/exp/images/mobile-codex-one-thread.svg "两个入口只负责送消息，统一网关把它们收回同一条 Codex 任务。") 稳定结构可以用一句话说完：两个入口，一道网关，一条固定任务，一个写手。 - 微信和飞书收消息、回消息。 - GolemBot 处理渠道连接和通用消息格式。 - 本地可靠层先保存，再排队、去重和记录状态。 - 稳定的 threadId 把消息送回电脑上的同一条 Codex 任务。 - Codex 继续读原项目和原文件，同一任务同一时刻只允许一个写手。 标题不是身份。标题可以改名，也可能重名；threadId 才是那条任务的身份证。 如果微信和飞书各开一条新任务，手机上照样会收到漂亮回复，但电脑里原来的工作没有继续。更糟的是，两边同时改一个文件，最后谁覆盖谁都说不清。那不叫远程协作，只是两个人拿着同一份稿子各改各的。 ## 我们为什么修了十天 手机反复出现“这条消息没处理完”，看起来每次都一样。真实情况是，同一句话背后换了好几个根因。 | 发生了什么 | 当时以为 | 后来查到 | | --- | --- | --- | | 手机能回，电脑原任务没变化 | 已经接通 | 后台另开了影子任务 | | 息屏后失败 | 屏幕黑了，程序看不见 | 桥接把桌面界面当成唯一入口 | | 屏幕亮着也失败 | 还是息屏补丁不完整 | 固定任务没渲染在侧栏，UI 查找失效 | | 隔一阵又失败 | 网关不稳定 | 桌面驱动被内存压力终止，缓存也丢了 | | 修好后隔天再失败 | 修复没生效 | 固定手机任务被当成普通任务归档 | | 微信重启后又抢消息 | 新网关有问题 | 旧启动项只是停过，重启后又复活 | 这张表有个共同点：表面都像“息屏坏了”，实际故障分别发生在身份、桌面界面、任务生命周期和系统启动项。 最容易犯的错，是看到一个现象就给它起名字，然后所有补丁都围着这个名字写。真正的排查要沿着消息走：平台有没有收到，是否保存，送进了哪条任务，谁在执行，结果有没有送回来。走到哪一步停了，根因才在哪一层。 ## 最后一轮到底修了什么 最终复发时，主机在线，飞书消息也已经收到。可靠 Inbox 里有原消息，网关进入了无界面续接，随后 OpenAI app-server 明确返回：目标任务已经归档，不能继续。 这不是息屏，也不是服务宕机。那条长期手机入口在几天前清理侧栏时被归档了。 我们没有新建一条同名任务糊弄过去，而是使用 OpenAI 官方能力恢复原 threadId，再校验返回的仍是同一个编号，然后 `resume`。这条任务同时被置顶，并写进侧栏整理规则：普通任务可以归档，固定手机入口不能被批量清理、改名或迁移。 同一轮又查到，两个旧微信 LaunchAgent 以前只做过 `bootout`。这只能让它们当下停止，并没有持久禁用。电脑重启后，旧微信服务和旧 app-server 一起复活，重新和统一网关抢消息。最终处理是保留可回退配置，但对旧启动项执行持久禁用，再重启复核进程和端口，确认只剩一个网关、一个执行入口。 最后的自愈很窄：只有登记过的固定手机 threadId 遇到官方“已归档”错误，才允许 `unarchive → 同 ID 校验 → resume`。认证失败、网络失败、普通任务归档都保持失败。自动化不是权力越大越聪明，条件越精确才越安全。 修复后，定向测试、完整回归、真实绑定任务的本机回归都通过了。但当时我们仍没有说“彻底好了”。因为这些只能证明候选没有明显坏，不能代替小龙哥从真实手机使用。 隔天再次在真实入口使用，链路仍然正常。小龙哥明确确认：“最后一次终于把它修好了。”到这一步，才从机器通过升级为用户验收通过。 ## 普通人照着走的十分钟排查法 下次手机又不回，先别重装，也别立刻改代码。按顺序查。 ### 1. 主机真的可用吗 确认电脑在线、没有睡眠、网络正常，ChatGPT 或 Codex 主程序仍在。息屏和睡眠不是一回事：屏幕黑着，主机可以继续工作；真正睡眠后，官方 Remote 和本地桥接都会停。 ### 2. 渠道收到消息了吗 去渠道日志找这条消息的 messageId。飞书 WebSocket 或微信轮询都没收到，问题在渠道连接；不要去改 Codex 任务。 ### 3. 消息保存了吗 看到消息不等于保存成功。可靠 Inbox 里应该有原文、来源、messageId、附件和当前状态。没有落盘就先修存储，否则进程一崩，连“丢了什么”都不知道。 ### 4. 它进了哪条任务 用 threadId 查，不要靠标题猜。若生成了新任务，先修绑定；若原任务已归档，走官方 unarchive；若任务仍在运行，检查是不是另一个写手已经拥有它。 ### 5. 结果停在哪个状态 一条消息至少要分清：收到、已保存、执行中、已完成、待回送、已送达、失败、已安排重试。 ~~~text received → persisted → running → completed → delivered ↘ failed / retry_scheduled ~~~ “机器人回了一句话”和“Codex 做完了”没有必然关系。系统若说稍后会继续，后台就必须有真实的重试记录；没有就老实报失败。 ### 6. 重启后是不是又多出一套 查启动项、进程树和监听端口。停止一个旧进程不代表永久下线。真正完成要看重启以后旧服务没有复活，同一消息只有一个消费者。 这六步跑完，通常已经能确定故障在哪一层。还没找到，再写最小复现和最小补丁。 ## 真正容易漏掉的四件事 ### 附件必须先保存 图片和文件不能只留下 `(image)` 或 `(file)`。要保存真实文件，或者保存后续仍能下载的 mediaId。平台过期以后，只有占位符的旧消息通常救不回来。 ### 同一任务只能有一个写手 微信和飞书可以同时进来，不代表同一条 Codex 任务可以并行写。跨任务能并行，同一 threadId 要排队，并用租约或锁防止桌面和后台双写。 ### 失败要说人话，也要说真话 “刚才没处理完，你继续发，我会接着处理”听着很温柔。后台若已经记成 `done`，这句话就是假的。友好文案不能覆盖真实错误，更不能替代重试队列。 ### 安全边界不能跟着手机入口一起放大 入口只开放给本人或白名单。付款、发布、删除、验证码、实名和不可逆操作仍要本人确认。方便发消息，不等于给任何聊天联系人一把整机钥匙。 ## 怎样才算真的打通 我现在用下面这组标准验收，不再看一句“服务在线”就宣布完成。 1. 微信发自然消息，进入指定的同一条 Codex 任务，结果原路返回。 2. 飞书再发一条，仍是同一个 threadId，没有影子任务。 3. 电脑息屏但不睡眠时再测，确认不依赖桌面 UI。 4. 重启电脑后再测，进程树里只有一个网关和一个执行入口。 5. 人工归档固定入口，确认只恢复这个精确 threadId；普通任务不会被擅自恢复。 6. 人为制造失败，后台只能显示 `failed` 或真实 `retry_scheduled`，不能显示 `done`。 7. 发送图片或文件，Codex 收到真实附件，不是占位词。 8. 隔一天正常使用仍然通过，再由真实用户确认体验。 单元测试通过、健康接口返回 200、本机回归成功、正式服务已重启、真实手机可用、用户确认满意，是六层不同的证据。少一层，就按真实状态写，别把“候选”说成“彻底修好”。 ## 可直接交给 AI 的提示词 ~~~text 请把“手机直连 Codex”当成可靠消息系统，不要只检查机器人能不能回话。 先查官网： 1. 核对 OpenAI 当前 Remote 与 app-server 的官方能力； 2. 核对所用网关的最新稳定版、更新记录和已实现的重连/续跑能力； 3. 官网已有的能力优先升级或配置，不重复实现。 再沿一条真实失败消息检查全链路： 1. 渠道是否收到真实 messageId； 2. 消息和附件是否先持久化； 3. 微信与飞书是否绑定同一稳定 threadId，而不是按标题找； 4. 桌面与后台是否保持单一写手，同一 threadId 是否串行； 5. 固定任务归档时，是否只对精确 threadId 执行 unarchive、同 ID 校验、resume； 6. 旧启动项、旧网关和第二 app-server 是否已持久禁用，并经重启复核； 7. received、persisted、running、completed、delivered、failed 和 retry_scheduled 是否分开记录； 8. 是否存在把引擎错误改写成友好话术后标成 done 的假完成。 先用日志和状态库还原故障停在哪一步，再做最小修复。 最后用真实微信、真实飞书、息屏、重启、归档和附件逐项验收。 机器测试、健康接口和本机回归不得冒充用户验收。 ~~~ ## 来源与修订 官方 Remote 的连接方式、主机在线要求和远程能力，以 OpenAI Remote connections 文档为准。任务续接、归档和恢复，以 OpenAI Codex app-server 文档为准。OpenAI Issue #26159 也记录了归档后继续 resume 被服务器正确拒绝的同类现象。 飞书长连接、pong watchdog、图片和文件转发，以 GolemBot 官方文档和 Releases 为准。飞书业务资源的查询和写入，以飞书官方 `lark-cli` 与 OpenAPI 为准。微信、飞书桥接中的固定任务、可靠 Inbox、单一写手和精确归档自愈，是小龙哥真实使用环境里的本地可靠性补充，不是 OpenAI、微信或飞书提供的原生能力。 本文保留固定地址 `/exp/mobile-codex/`，旧 `/kits/001/` 继续兼容。以后官方版本和小参数变化继续修订本文；只有整条路线被新证据推翻，才另开新篇。