用 GolemBot 把 Codex 接到飞书机器人

GolemBot Codex 飞书 Agent CLI
作者: 醉月思 发布日期: 2026-06-09 分类: 技术实践

想在飞书里直接 @ 一个机器人，然后让它帮我问 Codex，还能顺手去飞书文档、需求清单、bug 清单里翻资料。

这个需求一开始很容易被带偏：自己写一个飞书 Bot Gateway，接事件、调模型、维护会话、处理权限、再封装飞书 OpenAPI。

但这事其实不太值得从零写。飞书机器人入口有现成工具，Codex 本身有 CLI，飞书也有官方 CLI。把这几块拼起来，就能得到一个相对省事的版本。

下面这张图先把调用链画清楚，后面的安装和配置基本都是围绕这条链路展开。

flowchart LR A[飞书用户] --> B[飞书机器人] B --> C[GolemBot<br/>Feishu Channel] C --> D[GolemBot<br/>Codex Engine] D --> E[Codex CLI] E --> F[AGENTS.md<br/>项目规则] E --> G[lark-cli<br/>飞书 CLI Skills] G --> H[飞书 Docs] G --> I[Base / Sheets] G --> J[Tasks / Wiki]

这篇文章就按这个思路写一版可操作的教程。

先说结论

我会选这套组合：

  1. GolemBot：负责把飞书机器人消息接进来，并转给 Codex。
  2. Codex CLI：负责真正的 Agent 推理、命令调用和上下文处理。
  3. AGENTS.md：负责告诉 Codex 该怎么查飞书资料、哪些事情不能乱做。
  4. lark-cli：负责读取飞书 Docs、Base、Sheets、Tasks、Wiki。
  5. larksuite/cli Skills：让 Codex 更知道飞书 CLI 该怎么用。

这样做的好处是少写胶水代码。GolemBot 处理 IM 渠道，Codex 处理 Agent，飞书 CLI 处理数据访问。

准备环境

建议先准备一台长期在线的 Linux 机器，或者至少是一台不会随手关机的开发机。

基础依赖：

node -v
npm -v
git --version

如果没有 Node.js，建议直接装 Node 22 或更新版本。GolemBot 文档里的 Docker 示例也是基于 node:22-slim，所以用太老的 Node 没必要给自己找麻烦。

然后新建一个机器人工作目录：

mkdir -p ~/agents/feishu-codex-bot
cd ~/agents/feishu-codex-bot

后面所有配置都放在这个目录里。这个目录就是 Codex 的工作区，AGENTS.md 也会放在这里。

安装 GolemBot

先安装 GolemBot：

npm install -g golembot

初始化一个使用 Codex 的 bot：

golembot init -e codex -n feishu-codex-bot

如果你不确定当前版本的参数有没有变化，可以走交互式向导：

golembot onboard

初始化后，目录里一般会有 golem.yaml 一类的配置文件。先不用急着启动，飞书应用还没配。

安装并登录 Codex CLI

Codex CLI 可以用 npm 安装：

npm install -g @openai/codex

然后登录：

codex

如果你想用 API Key，也可以走环境变量。GolemBot 的文档里提到 Codex engine 可以用 CODEX_API_KEY，也可以用 ChatGPT OAuth。

export CODEX_API_KEY="你的 API Key"

这里有个小建议：先在当前机器上单独跑一次 Codex，确认它能正常工作，再接 GolemBot。

cd ~/agents/feishu-codex-bot
codex "请用一句话说明你能看到当前目录吗"

这一步如果都失败，后面接飞书只会更难排查。

安装飞书 CLI 和 Skills

飞书 CLI 官方仓库推荐的安装方式是：

npx @larksuite/cli@latest install

然后安装 CLI Skill：

npx skills add larksuite/cli -y -g

接着配置飞书 CLI：

lark-cli config init
lark-cli auth login --recommend

如果你想重新生成一套配置，也可以用：

lark-cli config init --new

登录完成后，先跑一个最简单的命令试试：

lark-cli calendar +agenda

如果这个命令能返回数据，说明 lark-cli 本身已经能访问飞书了。

这里要注意一件事：机器人接收消息用的是飞书开放平台应用的 App ID 和 App Secret，lark-cli 读取文档用的是 CLI 自己的授权。它们可以是同一个应用体系，也可以分开管理。生产环境最好专门建一个低权限账号或低权限应用，不要直接拿自己的超级账号长期挂着。

创建飞书机器人应用

进入飞书开放平台：

https://open.feishu.cn/

创建一个企业自建应用，然后按下面几项配置。

飞书开放平台这里不复杂，但步骤容易漏。可以按这个顺序走：

flowchart TD A[创建企业自建应用] --> B[开启机器人能力] B --> C[复制 App ID / App Secret] C --> D[开启 WebSocket 事件订阅] D --> E[订阅 im.message.receive_v1] E --> F[添加消息和通讯录权限] F --> G[按需添加 Docs / Base / Sheets / Tasks 权限] G --> H[发布应用版本并等待管理员审批]

机器人能力

在应用能力里开启机器人。

凭证

找到应用凭证，记录：

App ID
App Secret

后面会放到 .env 里。

事件订阅

GolemBot 的飞书适配器使用 WebSocket 长连接模式。这个模式有个好处：不需要公网 IP，也不用自己暴露 HTTP 回调地址。

在事件订阅里：

  1. 开启 WebSocket 长连接模式；
  2. 订阅 im.message.receive_v1；
  3. 如果需要已读回执，再订阅 im.message.message_read_v1。

权限

GolemBot 飞书文档里列出的基本权限如下：

im:message
im:message:readonly
im:message.group_at_msg:readonly
contact:user.base:readonly
contact:contact.base:readonly

如果你希望群聊里能把回复里的 @name 转成飞书原生 mention，再加：

im:chat:readonly

飞书 CLI 读取文档、Base、Sheets、Tasks 时，还需要给对应的数据权限。常见会用到：

Docs / Docx 读取权限
Drive 文件读取或搜索权限
Base / Bitable 读取权限
Sheets 读取权限
Tasks 读取权限
Wiki 读取权限

实际名字以飞书开放平台后台显示为准。飞书这块权限经常分得比较细，不要看到一个“读取文档”就以为 Base 也能读。

发布版本

权限改完后，要发布应用版本，并让管理员审批。

这个步骤很容易漏。后台看起来已经配好了，但应用版本没发布，机器人还是拿不到新权限。

配置 GolemBot

在机器人目录下建一个 .env：

cd ~/agents/feishu-codex-bot
touch .env

写入：

FEISHU_APP_ID=cli_xxxxxxxxxxxxxxxx
FEISHU_APP_SECRET=xxxxxxxxxxxxxxxxxxxxxxxx
GOLEM_TOKEN=换成一个随机长字符串

然后调整 golem.yaml。一个最小配置大概长这样：

name: feishu-codex-bot
engine: codex

channels:
  feishu:
    appId: ${FEISHU_APP_ID}
    appSecret: ${FEISHU_APP_SECRET}
    # 如果是 Lark 国际版租户，可以改成 lark
    # domain: lark

codex:
  sandbox: workspace-write
  approval: on-request
  search: true

gateway:
  port: 3000
  token: ${GOLEM_TOKEN}

这里我建议先用：

sandbox: workspace-write
approval: on-request

原因很简单：Codex 后面会调用 lark-cli，而 lark-cli 能访问飞书里的真实资料。先把权限收住，跑通以后再决定要不要放宽。

如果 GolemBot 后续版本的字段名有变化，优先以当前 golembot onboard 生成的配置为准。不要为了照抄文章，把新版配置改回旧写法。

写 AGENTS.md

在工作目录根部创建 AGENTS.md：

cd ~/agents/feishu-codex-bot
touch AGENTS.md

写入下面这段：

你是飞书里的 Codex 助手，主要帮助用户读取和分析飞书里的项目资料。

## 工作方式

- 当用户询问需求、bug、PRD、会议纪要、任务或知识库内容时，优先调用 `lark-cli`。
- 所有查询命令优先使用 JSON 输出，例如 `--format json`。
- 默认只读，不要创建、修改、删除、发送飞书内容，除非用户明确要求。
- 如果用户只给了模糊描述，先搜索或确认范围，不要假装已经知道文档在哪里。

## 数据约定

- 需求清单优先从 Base / Bitable 读取。
- bug 清单优先从 Base / Bitable 或 Sheets 读取。
- PRD、方案、会议纪要优先从 Docs / Wiki / Drive 读取。
- 任务状态优先从 Tasks 或项目约定的 Base 表读取。

## 安全边界

- 不要导出大批量敏感数据。
- 不要读取与当前问题无关的私人文档。
- 不要把 App Secret、Token、Cookie、访问凭证发送到飞书聊天里。
- 遇到写操作、删除操作、批量导出操作，先向用户确认。

## 回答风格

- 先给结论，再给依据。
- 引用飞书资料时说明来源，例如文档标题、表名、记录 ID 或链接。
- 如果 lark-cli 报权限不足，直接说明缺少什么权限，不要猜内容。

这份 AGENTS.md 是整个方案里很关键的一层。

GolemBot 解决“飞书消息怎么进来”，Codex 解决“怎么思考和调用工具”，但 Codex 具体该怎么用飞书 CLI，最好写清楚。否则它可能会到处试命令，或者在权限不足时瞎补内容。

启动机器人

回到工作目录：

cd ~/agents/feishu-codex-bot

启动网关：

golembot gateway --verbose

如果配置没问题，日志里应该能看到飞书通道启动成功。GolemBot 文档说飞书适配器会通过 @larksuiteoapi/node-sdk 的 WebSocket 长连接接入，收到消息时日志里会有 [feishu] 前缀。

然后去飞书里测试：

@你的机器人 你好，回复一句话

再测试 Codex 是否真的能调用飞书 CLI：

@你的机器人 用 lark-cli 查一下我今天的日程，只返回标题和时间

再进一步测试文档：

@你的机器人 读取这个飞书文档，帮我总结成 5 条要点：https://xxx.feishu.cn/docx/xxxxx

如果你用 Base 管需求和 bug，可以这样问：

@你的机器人 读取需求清单，列出所有状态为“开发中”的 P0 需求

或者更明确一点：

@你的机器人 从这个 Base 里读取 bug 表，筛选严重级别为 P0 且状态不是已关闭的记录：app_token=xxx table_id=xxx

我更建议一开始把 app_token、table_id 直接给出来。等流程跑顺以后，再让 Codex 自己搜索和定位。

推荐的资料组织方式

如果飞书里资料放得很散，Agent 再聪明也会翻得很累。

比较稳的方式是给它一个“项目资料入口”：

flowchart TD A[项目 Wiki 首页] --> B[PRD 文档] A --> C[需求 Base] A --> D[bug Base] A --> E[会议纪要目录] A --> F[发布计划] C --> G[关联需求 ID] D --> G B --> G

这张图想表达的重点很简单：不要让 Codex 每次从整个飞书空间开始猜，给它一个稳定入口，再让需求、bug、PRD 之间尽量有同一个关联 ID。

然后在 AGENTS.md 里补一段项目约定：

## 项目资料入口

- 项目 Wiki 首页：https://xxx.feishu.cn/wiki/xxxxx
- 需求清单 Base：https://xxx.feishu.cn/base/xxxxx
- bug 清单 Base：https://xxx.feishu.cn/base/yyyyy

如果用户没有指定资料位置，先从项目 Wiki 首页开始查。

这比让 Agent 在整个飞书空间里乱搜靠谱很多。

常见问题

机器人在飞书里不回复

先看 GolemBot 日志：

golembot gateway --verbose

如果日志里完全没有收到消息，优先检查：

  1. 飞书事件订阅有没有开 WebSocket；
  2. 有没有订阅 im.message.receive_v1；
  3. 应用版本有没有发布并审批；
  4. 群聊里是不是没有 @ 机器人；
  5. 权限里有没有 im:message:readonly 和 im:message.group_at_msg:readonly。

能收到消息，但机器人不能回复

检查：

im:message

没有这个权限，机器人能听见，但发不出话。

私聊里用户都是 ou_xxx

通常是通讯录权限不够。

检查：

contact:user.base:readonly
contact:contact.base:readonly

GolemBot 文档里也提到，没有这些权限时机器人仍然能工作，但看到的可能是用户 ID，而不是显示名。

Codex 找不到 lark-cli

在机器人运行的同一个 shell 里检查：

which lark-cli
lark-cli --help

如果你是用 systemd、pm2、Docker 跑 GolemBot，要确认运行环境里的 PATH 能找到 lark-cli。

lark-cli 权限不足

重新登录：

lark-cli auth login --recommend

如果是某一类资源读不了，例如 Base 能读、Docs 不能读，那就回飞书开放平台检查对应权限。飞书权限不是一个总开关，文档、云空间、多维表格、任务经常要分开授权。

Codex 不按 AGENTS.md 来

先确认 AGENTS.md 放在 GolemBot 的工作目录根部。

也可以在飞书里直接问：

@机器人 请说明你当前读到的项目规则，不要执行其他操作

如果它完全不知道规则，大概率是工作目录不对，或者 GolemBot 调 Codex 时没有以这个目录作为 workspace。

回复太慢

读取飞书文档、Base 记录、再让 Codex 汇总，本来就不是毫秒级任务。

可以先做三件事：

  1. 让用户给出明确链接、app_token、table_id；
  2. 在 AGENTS.md 里要求先小范围查询；
  3. Base 表设计上保留状态、优先级、负责人这些可筛选字段。

Agent 最怕资料入口不清楚。资料多一点还可以筛，入口乱了就只能跟着乱翻。

安全建议

这个方案虽然省开发，但权限一点都不能省心。

我会按下面几个原则配置：

  1. 先只读，写操作后面再说；
  2. 不用个人超级账号长期登录 lark-cli；
  3. .env 不提交 Git；
  4. AGENTS.md 明确禁止批量导出和删除；
  5. 生产环境用 systemd 或容器守护进程，并单独限制运行目录；
  6. 给飞书应用单独建权限清单，知道它到底能读什么。

.gitignore 里至少要有：

.env
.codex/
.lark-cli/
node_modules/

如果你把机器人跑在服务器上，还要注意服务器本身的登录权限。Agent 能调用命令行，命令行能读飞书，这条链路打通以后，它就不是一个普通聊天机器人了。

小结

这套方案的关键不是“飞书接入大模型”，那种 ChatGPT Bot 已经很多了。

关键在于：后面接的是 Codex 这种能调用命令行的 Agent，飞书资料访问又交给了官方 lark-cli 和 Skills。这样一来，机器人就有机会围绕项目资料干活，而不是停在普通问答机器人那一层。

当然，它也没有神奇到不需要整理资料。需求清单、bug 清单、PRD、会议纪要如果本来就散成一团，Agent 也只能陪你一起迷路。

所以我觉得最舒服的落点是：先用 GolemBot 把入口接起来，再用 AGENTS.md 把边界写清楚，最后把飞书里的项目资料整理成几个稳定入口。工具只是把路打通，路上有没有路牌，还是得自己立一下。

参考

版权声明: 本文首发于 指尖魔法屋-用 GolemBot 把 Codex 接到飞书机器人（https://blog.thinkmoon.cn/post/995_%E7%94%A8golembot%E6%8A%8Acodex%E6%8E%A5%E5%88%B0%E9%A3%9E%E4%B9%A6%E6%9C%BA%E5%99%A8%E4%BA%BA/） 转载或引用必须申明原指尖魔法屋来源及源地址！

相关阅读

根据标签、分类和主题为你挑选的相近文章

使用智谱api将长语音转文本
智谱AI API虽性能优异但仅支持30秒以内音频文件。本文详细介绍如何基于pyannote.audio的语音活动检测技术实现智能音频分块，通过批量API调用构建完整的长语音转文本系统，包含完整的环境配置、代码实现和部署方案。
📁 技术实践
📅 2025-12-16
一些在Jetson设备的开发经验
NVIDIA Jetson系列设备作为边缘AI计算的重要平台，在计算机视觉和深度学习应用中发挥着关键作用。本文将详细介绍Jetson设备的刷机、SDK安装、YOLO模型部署以及TensorRT优化等开发经验，帮助开发者快速上手并实现高性能的AI应用部署。
📁 技术实践
📅 2025-10-27
使用CloudFlare反向代理七牛云存储实现SSL自由
本文详细介绍了如何利用CloudFlare Workers免费实现七牛云存储的自定义域名HTTPS访问。通过编写反向代理脚本，不仅解决了混合内容加载问题，还利用CloudFlare的全球CDN加速了资源访问，实现了零成本的SSL加密方案，适合个人开发者或小型项目使用。
📁 技术实践
📅 2025-03-19
Harness Engineering 的介绍与编程实践
这篇文章从 AI 编程的真实工程场景出发，梳理 Harness Engineering 如何通过上下文、工具、沙盒、验证和人工闸门，让 Agent 从“会写代码”走向“能稳定交付”。
📁 技术实践
📅 2026-04-23