开源 Skill 让 Grok Bot 派活给 Codex 并等回调
作者开源 bot-codex-delegate，用 Codex app-server 常驻会话替代轮询，让 Grok Bot 只在派发、干预和验收时介入。
最近看到很多人用 Grok @bot 做管理，再调用 Codex 等 CLI 来写代码，遇到了各种问题的讨论。 我很早之前也遇到了同样的问题，并且一直有个相对完美的 Skill 来解决。索性整理了一下，开源出来： https://github.com/realTaki/bot-codex-delegate 我的思路和定时轮询不太一样：与其让 Bot 定期检查 Codex 干完了没，不如让 Codex 干完之后主动叫醒 Bot。 这个 Skill 的核心是把 Codex 变成一个类似 Cursor Cloud Agent 的常驻工作进程。 Codex CLI 其实有 app-server 模式，常驻一直开着你的 Codex ，就像你网页桌面端那样，随时可以接进去多个对话/任务，插话、打断、整理。比无头模式更方便。 所以具体来说，是在 Grok Bot 的云电脑上启动一个 codex app-server，通过ws通信，让 Bot 可以直接派发任务，而不需要一轮轮对话盯着 Codex。 有几个关键点： 不需要轮询。 Bot 派发任务后，后台 Shell 等待 Codex 的 turn/completed 事件。Codex 完成后，工具调用返回并唤醒 Bot，继续后续验收。不需要额外的 Routine，也不需要 Bot 一直消耗 Token 陪跑。 复用 Codex Session。 按项目和任务类型管理会话，后续任务直接恢复已有 Session，而不是每次重新扫描整个代码库、重新建立上下文。会话太长时再压缩，任务结束后归档。 支持中途干预。 Codex 执行期间，Bot 可以通过 turn/steer 补充新要求，也可以通过 turn/interrupt 打断任务，不需要直接杀掉整个 Session。 常驻服务。 用 tmux + watchdog 管理 Codex app-server，自动检查服务健康状态。长任务可以配合我之前开源的 bot-keepalive，避免 Grok Bot 的云电脑休眠导致任务冻结。 这里面我觉得最重要的其实是架构上的区别。 Bot 应该是任务的调度者，而不是一个每隔几分钟就跑过去问程序员「写完了吗」的监工。 Codex 自己维护执行状态和项目上下文，Bot 只在需要决策、干预、验收的时候介入。 这样不仅减少 Bot 侧的 Token 消耗，也能减少 Codex 重复加载上下文的开销。 有点类似 Cursor Project 管理 Cloud Agent 的体验，只不过现在可以直接在 Grok Bot 的云电脑里实现。 安装也很简单，把仓库里的 SKILL.md 链接丢给 Grok Bot，让它自行安装就行。 希望能帮到同样拿 Grok Bot + Codex 写代码的朋友。