https://github.com/RyanWeb31110/lark-cli-codex-app
最近在折腾一个小项目：让飞书/Lark 变成 Codex App 的远程入口。
我想解决的不是简单的“机器人回复消息”，而是一个更完整的闭环：
人在飞书/Lark 里发起任务
-> 本地 gateway 接收消息事件
-> 任务分发给 Codex App / codex exec
-> Codex 在本机读取代码、运行命令、操作浏览器或桌面
-> Codex 通过 lark-cli / skills 操作飞书
-> 结果回写到飞书对话、文档、日历、表格等协作对象
https://i.v2ex.co/wp9YaoVXl.png
简单说，就是：
飞书负责入口和协作，Codex App 负责本地执行，中间这个项目负责把两边接起来。
为什么做这个
我现在越来越觉得，很多 AI agent 的关键问题不是“模型能不能回答”，而是它能不能进入真实工作流。
比如我在外面，只带手机，突然想到一个任务：
如果只是一个聊天 bot ，它通常只能做到“收消息、回消息”。
但 Codex App 本来就在本地，能看到 workspace ，能运行命令，能读写文件，也有 computer use / skills / 多任务这些方向。那飞书/Lark 更适合做的事情，其实是成为 Codex App 的远程控制面和团队协作界面。
所以这个项目想做的是：
飞书/Lark 发起和承接任务
Codex App 在本地真实执行
lark-cli-codex-app 负责事件接入、任务分发和结果回写
为什么选择 Codex App ，而不是使用通用 agent
我也看过 OpenClaw 、Hermes 这类项目。它们更像是从 agent runtime 开始做一套完整系统：长期运行、记忆、工具编排、多入口交互、任务调度都自己承载。
这个路线很强，也很适合做通用个人助理。
但我这个项目的边界不一样。我不太想重新造一个 agent runtime ，而是更想依托 Codex App 已经有、并且未来还会继续增强的能力。
Codex App 更贴近真实工程任务：本地代码上下文、终端、文件、浏览器、computer use 、skills 、多任务、插件生态，这些都天然适合开发者工作流。
所以我希望把精力放在另一个问题上：
飞书/Lark 如何可靠地触发 Codex ？
Codex 如何把结果自然地回写到飞书/Lark ？
需要 GUI 操作时，如何交给本地 Codex App 处理？
这样边界会比较清楚：
目前已经有的东西
项目是基于 yjwong/lark-cli 的 MIT fork 做的扩展，保留了原许可证。
当前主要包含：
和普通 bot 的区别
普通 bot 更像是：
聊天软件 -> bot -> 回复
我想做的是：
飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark
也就是不只是“回复一段话”，而是让 Codex 能在本地真的把事情做完，再把结果带回协作场景。
现在还比较早期
这个项目现在还不是一个非常成熟的产品，更像是一个方向已经明确的开源原型。
我接下来比较想继续打磨这些点：
如果你也在折腾 Codex App 、本地 agent 、飞书/Lark 自动化，欢迎看看这个项目，顺手提 issue 或拍砖。
项目地址：
https://github.com/RyanWeb31110/lark-cli-codex-app
