不用再导出 PDF:我把飞书文档直接接进了 Codex

以前想让 AI 看一篇飞书文档，我最熟悉的流程是：打开文档、导出 PDF 、上传给 AI 、再开始提问。

偶尔用一次问题不大。但如果文档经常更新，或者还要处理多维表格，这套流程很快就会变成体力活：刚导出的文件可能已经不是最新版， AI 的结论也很难直接回到原来的协作空间。

所以这次我换了一条路：用飞书官方 OpenAPI MCP ，把飞书的权限体系直接接进 Codex 。

配置完成后，我实际验证了两件事：

但先说结论：这不是装一个插件就结束。真正决定能不能用的，是飞书应用、用户权限、 OAuth 回调和版本发布必须全部配对。

一、先判断这套方案适不适合你

如果你只是偶尔让 AI 看一份不会再变的文件，导出 PDF 其实更省事。

官方 MCP 更适合下面几种情况：

需要提前知道的是，飞书官方 MCP 目前仍是 Beta ，接口和能力可能变化。它解决的是“让 AI 在现有权限内调用飞书 API”，不是绕过飞书权限。

二、创建飞书企业自建应用

进入飞书开放平台的“开发者后台”，创建一个企业自建应用。

创建完成后，在“凭证与基础信息”里可以看到 App ID 和 App Secret。它们相当于这个应用的账号和密码，后面登录 MCP 时会用到。

这里有两个安全提醒：

我这次没有给应用堆一大批权限，只围绕文档和多维表格来配。

三、只申请真正需要的三项权限

在“权限管理”中切换到用户身份权限，然后申请：

这次账号里，这三项权限显示可以免审开通。但这不代表所有企业都一样：如果组织设置了更严格的应用审批，仍然需要飞书管理员审核。

我没有顺手开消息、通讯录、日历等权限。原因很简单：权限越多，配置越复杂，泄露后的影响面也越大。先把文档和表格跑通，再按真实需求追加。

还有一个实际踩坑：直接拿文档链接读取已经够用；如果想让 Codex 在整个飞书空间里按关键词搜索文档，可能还要额外申请搜索相关权限。我的选择是先不给，避免为了“可能会用”扩大授权范围。

四、配置 OAuth 回调地址

如果要让 MCP 以当前登录用户的身份访问飞书资源，需要完成一次 OAuth 授权。

进入“安全设置”，添加重定向 URL ：

http://localhost:3000/callback 

很多人看到这个地址，会以为要先部署一个 3000 端口的 Web 服务。

其实不用。

执行官方 MCP 的 login 命令时，它会在本机临时启动一个回调监听。你在浏览器完成飞书授权后，飞书把授权结果跳回这个地址，命令拿到结果后就可以结束。

所以它更像一次登录过程中的“临时接收点”，不是需要长期运行的业务服务。

如果 3000 端口已经被占用，也可以改端口，但命令参数和飞书后台的回调地址必须保持一致。

五、发布应用版本

权限和安全设置配好后，还需要进入“版本管理与发布”创建版本并发布。

我这次发布的是 1.0.0。后台提示本次发布免审，因此确认后直接生效。

这一步很容易漏掉：后台里看到了权限，不代表 MCP 已经能立即调用。应用版本没有发布，新增能力可能仍然不会生效。

六、用官方命令完成用户授权

本机需要有 Node.js 和 npm 。因为使用 npx，不必先全局安装包。

在终端执行：

npx-y@larksuiteoapi/lark-mcplogin\-acli_xxxx\-s'<your_app_secret>'

把示例值替换成自己的 App ID 和 App Secret。命令会打开浏览器，登录飞书并确认授权。

这里使用的是用户访问令牌。它能看到什么，取决于两个条件的交集：

也就是说，用户原本看不到的文档，不会因为接入 MCP 就突然可见。

七、把飞书 MCP 加到 Codex

Codex 支持通过 MCP 接入外部工具。可以使用 CLI 添加，也可以直接修改 ~/.codex/config.toml。

核心配置如下：

[mcp_servers.lark-official]command="npx"args=["-y","@larksuiteoapi/lark-mcp","mcp","-a","cli_xxxx","-s","<your_app_secret>","--oauth","--token-mode","user_access_token"]

--oauth 表示复用前面保存的用户授权；--token-mode user_access_token 则明确要求用用户身份调用，避免访问个人文档时错误回退到应用身份。

官方 MCP 默认会暴露较多 API 。实际使用时，我更建议通过 -t 只启用文档和多维表格相关工具。工具越少， Codex 越容易选对，加载进上下文的描述也更少。

配置完成后重启 Codex ，让 MCP 服务重新加载。

八、实际验证：文档和多维表格都能读取

第一项验证，我把一篇飞书知识库文档链接直接交给 Codex 。

它成功识别了知识库节点，拿到真实文档 ID ，并读取了标题和纯文本正文。这个细节很重要：知识库 URL 里的 token 并不一定就是文档 ID ，需要先解析节点关系。

第二项验证，我提供了一个多维表格链接，并明确说“不要编辑，只看看能不能访问”。

Codex 成功读取了字段结构和 16 条记录，全程没有执行写操作。

至于写入：当前配置已经申请了文档写入和多维表格编辑权限， MCP 也暴露了块更新、记录创建与更新接口。但这次我没有为了演示去改生产数据，所以本文只把“读取成功”算作实际验证，不把写入能力包装成已经实测。

九、目前最明显的三个限制

1. 图片不能直接读取

纯文本正文能拿到，但文档中的图片位置只会出现 image1.png 之类的占位符。官方 FAQ 也说明，当前版本暂不支持文件和图片上传下载。

所以，依赖截图、流程图、扫描件的文档，暂时还不能完全替代 PDF 或人工补图。

2. “给链接读取”和“全局搜索”不是一回事

已有链接时，读取路径比较顺畅；想按关键词搜索整个云空间，通常需要额外权限。是否值得开，要看你的真实工作流。

3. 这是 Beta 工具

命令参数、工具名称和支持范围都可能变化。正式接入团队工作流前，最好固定版本、保留测试文档，并先用只读操作验证。

十、我更推荐的落地顺序

如果你也准备接入，不要一开始就追求“让 AI 操作整个飞书”。

更稳的顺序是：

MCP 真正有价值的地方，不是让 AI 获得无限权限，而是把原来散落在下载、上传、复制和粘贴中的步骤，变成一条可控、可审计的调用链。

现在我再让 Codex 看飞书里的文字资料，至少不需要每次先导出 PDF 了。

但该保守的地方仍然要保守：最小权限、先读后写、敏感凭证不进 Git 、生产数据不拿来做第一次实验。

这比“配置成功”更重要。

参考资料

参考链接

[1] 飞书/Lark OpenAPI MCP 中文说明: https://github.com/larksuite/lark-openapi-mcp/blob/main/README_ZH.md

[2] lark-mcp 命令行参考: https://github.com/larksuite/lark-openapi-mcp/blob/main/docs/reference/cli/cli.md

[3] lark-mcp 常见问题: https://github.com/larksuite/lark-openapi-mcp/blob/main/docs/troubleshooting/faq.md

[4] OpenAI ： Codex 中配置 MCP: https://developers.openai.com/learn/docs-mcp