【开源】在飞书 lark-cli 基础上 Vibe 了一个 Codex App 版本
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
lark-cli-codex-app：用飞书/Lark 远程控制 Codex App 的本地闭环工作流
项目地址：
GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,...
A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages.
这是一个围绕 Codex App 和飞书/Lark 做的本地控制项目。简单说，它想解决的是：
人在飞书里发消息、派任务；本地 Codex App 收到后在电脑上执行；Codex 可以读取本地仓库、运行命令、操作浏览器/桌面，也可以通过飞书/Lark API 回写消息、文档、日历、表格、多维表格等协作对象。
也就是说，飞书/Lark 既是远程入口，也是协作结果的回写界面；
依托 Codex App 的原生能力；
Codex App 则负责真正的本地执行、代码理解、工具调用和 computer use。
image1672×941 299 KB
这个项目想做什么
我自己理解的核心链路是：
人在飞书/Lark 发起任务
-> 本地 gateway 接收飞书消息事件
-> 任务分发给 Codex App / codex exec
-> Codex 在本机执行代码、终端、浏览器或桌面任务
-> Codex 通过 lark-cli / skills 操作飞书
-> 结果回写到飞书对话、文档、日历、表格等地方
它不是重新造一个 agent，而是依托 Codex App 原生的本地执行能力、代码理解能力、工具调用能力、computer use 能力，以及未来插件生态的潜力，把飞书/Lark 接成一个更适合团队协作的远程控制面。
为什么做这个
我之前试过一些聊天工具控制本地 agent 的方案，很多都停留在“发一条消息，agent 回复一段结果”的单向链路。
但我更想要的是闭环：
-
我可以在飞书群里让 Codex 排查一个 bug
-
Codex 在本地 workspace 里读代码、跑测试、改文件
-
需要 GUI 时，可以交给 Codex App / computer use 操作电脑
-
需要协作时，可以把结果回写到飞书群、文档、任务、表格或多维表格
-
出门在外时，也能用手机飞书给家里/办公室电脑上的 Codex 派任务
这个场景对我来说挺自然：飞书负责入口和协作，Codex 负责本地执行和智能操作，中间通过一个本地 gateway 串起来。
为什么选择 Codex App，而不是使用 OpenClaw / Hermes 这类通用 agent？
OpenClaw、Hermes 这类项目更像是从 agent runtime 开始构建一套完整的通用助理系统：长期运行、记忆、任务调度、工具编排和多入口交互都由项目自身承载。这条路线很强，也很适合做通用个人助理。
OpenClaw 的稳定性让我崩溃，每次都要单独挂一个 CC、CX 去救OpenClaw。
这个项目没有选择重新造一个 agent runtime，而是选择站在 Codex App 上做飞书/Lark 控制层，原因很简单：我更看重 Codex App 已经具备、并且还会持续增强的原生能力。
Codex App 本身更贴近真实工程任务：它理解本地代码上下文，可以使用终端、文件、浏览器、computer use、skills、多任务和未来插件生态。对我来说，飞书/Lark 不应该替代 Codex App，而应该成为 Codex App 的远程入口和团队协作界面。
所以这个项目的定位不是“再做一个 OpenClaw / Hermes”，而是：
飞书/Lark 负责发起任务、团队协作和结果承接
Codex App 负责本地执行、代码理解、工具调用和 computer use
lark-cli-codex-app 负责把两边连成闭环
这样做的好处是边界更清楚：agent 能力交给 Codex App 演进，飞书/Lark 集成交给这个项目打磨。未来 Codex App 的 skills、computer use、多 agent、自动化和本地执行能力越强，这个项目能承接的飞书协作场景也会越多。
当前已经有的能力
目前项目里主要包括：
-
飞书/Lark CLI：日历、消息、文档、通讯录、表格、多维表格、邮件、妙记等操作
-
Codex 插件元数据：可以作为 Codex plugin 项目使用
-
skills 目录：把常见飞书操作封装成 Codex 可调用的技能
-
gateway 模式：通过飞书/Lark WebSocket 长连接接收消息事件，不需要公网 callback
-
agent bridge：把飞书消息分发给本地
codex exec -
desktop task queue：把 GUI / computer use 类任务放进本地桌面任务队列
-
README 里配了两张流程图，方便理解整体链路
和普通 bot 的区别
普通 bot 更像是：
聊天软件 -> bot -> 回复
这个项目想做的是：
飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark
重点不只是“回复消息”，而是让 Codex 成为一个能在本地真实干活、并能把结果带回协作场景里的执行层。
开源情况
项目是基于 MIT 协议的 yjwong/lark-cli fork 做的扩展，保留了原许可证，并在此基础上增加 Codex App / gateway / desktop queue / skills 相关能力。
当前项目完整开源，没有保留未开源部分。README 中也已链接并认可 LINUX DO 社区：
GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,...
A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages.
欢迎佬友们拍砖，尤其是这几个方向：
-
飞书控制 Codex App 这个闭环是否还有更自然的交互方式
-
gateway / desktop queue 的设计是否合理
-
作为 Codex 插件项目还缺哪些关键能力
-
有哪些具体的工作场景可以落地
-
README 和使用门槛哪里还可以继续降低
--【壹】--：
我就是我想要的 在手机上和电脑上的codex进行对话，解决我不用一直坐在电脑前的工具啊
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
lark-cli-codex-app：用飞书/Lark 远程控制 Codex App 的本地闭环工作流
项目地址：
GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,...
A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages.
这是一个围绕 Codex App 和飞书/Lark 做的本地控制项目。简单说，它想解决的是：
人在飞书里发消息、派任务；本地 Codex App 收到后在电脑上执行；Codex 可以读取本地仓库、运行命令、操作浏览器/桌面，也可以通过飞书/Lark API 回写消息、文档、日历、表格、多维表格等协作对象。
也就是说，飞书/Lark 既是远程入口，也是协作结果的回写界面；
依托 Codex App 的原生能力；
Codex App 则负责真正的本地执行、代码理解、工具调用和 computer use。
image1672×941 299 KB
这个项目想做什么
我自己理解的核心链路是：
人在飞书/Lark 发起任务
-> 本地 gateway 接收飞书消息事件
-> 任务分发给 Codex App / codex exec
-> Codex 在本机执行代码、终端、浏览器或桌面任务
-> Codex 通过 lark-cli / skills 操作飞书
-> 结果回写到飞书对话、文档、日历、表格等地方
它不是重新造一个 agent，而是依托 Codex App 原生的本地执行能力、代码理解能力、工具调用能力、computer use 能力，以及未来插件生态的潜力，把飞书/Lark 接成一个更适合团队协作的远程控制面。
为什么做这个
我之前试过一些聊天工具控制本地 agent 的方案，很多都停留在“发一条消息，agent 回复一段结果”的单向链路。
但我更想要的是闭环：
-
我可以在飞书群里让 Codex 排查一个 bug
-
Codex 在本地 workspace 里读代码、跑测试、改文件
-
需要 GUI 时，可以交给 Codex App / computer use 操作电脑
-
需要协作时，可以把结果回写到飞书群、文档、任务、表格或多维表格
-
出门在外时，也能用手机飞书给家里/办公室电脑上的 Codex 派任务
这个场景对我来说挺自然：飞书负责入口和协作，Codex 负责本地执行和智能操作，中间通过一个本地 gateway 串起来。
为什么选择 Codex App，而不是使用 OpenClaw / Hermes 这类通用 agent？
OpenClaw、Hermes 这类项目更像是从 agent runtime 开始构建一套完整的通用助理系统：长期运行、记忆、任务调度、工具编排和多入口交互都由项目自身承载。这条路线很强，也很适合做通用个人助理。
OpenClaw 的稳定性让我崩溃，每次都要单独挂一个 CC、CX 去救OpenClaw。
这个项目没有选择重新造一个 agent runtime，而是选择站在 Codex App 上做飞书/Lark 控制层，原因很简单：我更看重 Codex App 已经具备、并且还会持续增强的原生能力。
Codex App 本身更贴近真实工程任务：它理解本地代码上下文，可以使用终端、文件、浏览器、computer use、skills、多任务和未来插件生态。对我来说，飞书/Lark 不应该替代 Codex App，而应该成为 Codex App 的远程入口和团队协作界面。
所以这个项目的定位不是“再做一个 OpenClaw / Hermes”，而是：
飞书/Lark 负责发起任务、团队协作和结果承接
Codex App 负责本地执行、代码理解、工具调用和 computer use
lark-cli-codex-app 负责把两边连成闭环
这样做的好处是边界更清楚：agent 能力交给 Codex App 演进，飞书/Lark 集成交给这个项目打磨。未来 Codex App 的 skills、computer use、多 agent、自动化和本地执行能力越强，这个项目能承接的飞书协作场景也会越多。
当前已经有的能力
目前项目里主要包括：
-
飞书/Lark CLI：日历、消息、文档、通讯录、表格、多维表格、邮件、妙记等操作
-
Codex 插件元数据：可以作为 Codex plugin 项目使用
-
skills 目录：把常见飞书操作封装成 Codex 可调用的技能
-
gateway 模式：通过飞书/Lark WebSocket 长连接接收消息事件，不需要公网 callback
-
agent bridge：把飞书消息分发给本地
codex exec -
desktop task queue：把 GUI / computer use 类任务放进本地桌面任务队列
-
README 里配了两张流程图，方便理解整体链路
和普通 bot 的区别
普通 bot 更像是：
聊天软件 -> bot -> 回复
这个项目想做的是：
飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark
重点不只是“回复消息”，而是让 Codex 成为一个能在本地真实干活、并能把结果带回协作场景里的执行层。
开源情况
项目是基于 MIT 协议的 yjwong/lark-cli fork 做的扩展，保留了原许可证，并在此基础上增加 Codex App / gateway / desktop queue / skills 相关能力。
当前项目完整开源，没有保留未开源部分。README 中也已链接并认可 LINUX DO 社区：
GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,...
A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages.
欢迎佬友们拍砖，尤其是这几个方向：
-
飞书控制 Codex App 这个闭环是否还有更自然的交互方式
-
gateway / desktop queue 的设计是否合理
-
作为 Codex 插件项目还缺哪些关键能力
-
有哪些具体的工作场景可以落地
-
README 和使用门槛哪里还可以继续降低
--【壹】--：
我就是我想要的 在手机上和电脑上的codex进行对话，解决我不用一直坐在电脑前的工具啊