最近我换了一种干活的姿势，换过去就回不来的那种：我不再在人和一堆 AI 窗口之间当搬运工，而是让飞书当一个我和几个 agent 一起用的共同工作台。agent 就是能自己干活、会读文件跑命令的 AI 程序，后面还会提到好几个。
先说说以前的日子，你们就知道我为什么这么折腾。
我手上有一堆 AI：Codex、Qoder CN、Claude Code，还有 workbuddy。以前它们各开各的窗口，我的日常就是在这几个窗口之间搬东西——把 A 的结果粘给 B，把 B 的疑问带回给 A，偶尔还要把 C 的产出手工揉进文档里。我的脑子是内存条，得实时记着：谁在做什么、做到哪了、下一步该把谁的结果交给谁。窗口一多，记忆就开始漏水，我常常停下来想半天：这句话，我是在哪个窗口里说的来着？
窗口切多了以后，"AI 够不够聪明"反而变成了次要问题。真正卡住我的，是我们之间没有一个共同的工作台。
我为什么花大把 token 从 Wolai 搬到飞书
我的知识库原来一直放在 Wolai，用了挺久，内容也不少。这次迁到飞书是真搬家：内容一份份搬、格式一遍遍查、结构一处处理顺，token（可以理解成模型读写内容时消耗的计量单位）烧掉一大把。值不值？我自己觉得值。原因有三个，都是按我实际用下来的感受写的。
生态不一样
飞书本身就是个团队协作产品，群、任务、评论、文档、知识库这些界面是现成的，天生适合人带着 AI 一起干活。按我这些年用下来的体感，它也是我用过的国内协作产品里体验最完整的一个。Wolai 更像个人笔记工具，一个人记东西很舒服，但团队协作的基因弱一些。我要的不是一个更大的笔记本，而是一个能让一堆角色各就各位的地方。
AI 化程度差得挺明显
Wolai 也有个 MCP——MCP 是让 AI 接进另一个软件的"插头"协议，接上就能操作那个软件——但按我实际用下来，基本只支持读和简单的文案写入，图片、媒体、表格这些要么很费劲、要么干脆动不了。我甚至自己写过补丁想填坑，多维表格那类操作最后还是没成。而飞书这边，agent 通过官方 CLI——CLI 就是命令行，没有图形界面、靠文字下指令的那种程序——能直接读文档、写表格、查知识库、发消息，能力是一整块一整块的。同样一件事，在哪边能让 agent 直接上手，对比一下就知道了。
豆包工作伙伴：agent 终于能互相协作
飞书里有一套叫"豆包工作伙伴"（原飞书 aily，2026 年 8 月更名）的东西，它把一群 agent 组织进同一个工作台，可以建小队、拆任务、按角色分派、验收汇总。有了它，我才终于不用在人和窗口之间当搬运工。
我和 F4 在飞书里到底做什么
我的 F4：四个 agent 各是干嘛的
我在飞书里组了一支队伍，四个 agent，我叫他们 F4（哈哈）。成员是 Codex、Qoder CN、Claude Code 和 workbuddy：Codex 是 OpenAI 的官方订阅；Qoder CN 也是官方订阅，写代码我特别依赖它；Claude Code 我这边给它接的是 DeepSeek 的官方 API；workbuddy 则用 Qwen3.7 plus 的官方 API。这四个都是从 CLI 接进来的。
都是有眼睛的，不是瞎子
这四个人有个共同点：都是有眼睛的，不是瞎子——都看得见截图、报错图、设计稿，丢过去就能看。这一点在协作里太重要了。只有看得见，才算真的"看见"彼此的产出，不然每次交接都像跟一个盲人描述对面长什么样。
我们实际在飞书里做什么
我们现在在飞书里干的事，大概分这么几类：脑暴（一句话丢进群，让它们各自补角度）、调研（要查什么派出去，带来源回来）、写作（从拆结构到成稿，整条任务都在飞书里走）、简单开发（小工具、脚本、一次性代码）。有些简单的开发，我甚至不打开 Codex App，直接在飞书里发起、完成，顺手就能发布。
比如你现在读的这篇，本身就是 F4 协作的产物：在飞书里发起任务、拆成几块，有人理结构，有人做事实核验，有人写初稿，有人汇总验收。谁做了什么、下一步接给谁，都留在同一条任务的记录里，我不用来回搬。
复杂开发：回到 Codex / Qoder 完成和验收
但边界我也画得很清楚，这真不是一个"飞书包办一切"的故事。需要持续盯前端样式、频繁调试反馈的复杂开发，我不会绕道飞书。调试是个连续循环：观察报错、定位文件、改代码、跑测试、再看。这个循环最好发生在工程环境里——代码就在眼前，工具链就在手边——而不是靠飞书评论一条一条把步骤传来传去。所以哪怕一个开发任务是从飞书发起的，也常常是让 Codex 先规划、把活 handoff 下去（handoff 就是任务交接，把一段活的产出交给下一位），最后回到 Qoder 或 Codex 里完成和验收。飞书管协作的"面"，Qoder、Codex 管执行的"点"，各干各擅长的。
这套东西是怎么搭起来的
说点动手的。从零把飞书接成这么个工作台，我走的路径大致是四步。
先给每个 agent 配好 CLI 并授权
lark-cli 是飞书官方开源的命令行工具，npm 一行装好。装完要授权，一般是 Device Flow：命令吐一个链接和一个授权码，把链接交给用户点开确认，再拿授权码回来完成登录。授权之后，每个 agent 既能单独执行任务，也能被编进小队里和别的 agent 协同干活。有个原则值得记住：授权时一定要指定范围，用到哪块授权哪块，别一把全给出去。对任何一个 AI，你只需要说一句：
帮我安装飞书官方的 CLI，并授权我的账号的权限共享 Skill：一份家底，四个 agent 共用
Skill 是一份写好的指令包，相当于教 agent 做某类事的说明书。我以前主要用 Codex，给它攒了不少 Skill。现在把这一套设成共享，四个 agent 通用，它们各自也可以有自己的独立 Skill。这样不用每个 agent 重新教一遍，Codex 攒好的东西大家直接拿来用，其实不麻烦。
工作小队：把分工写进协作规则
飞书里可以建"工作小队"，把 agent 编进同一支队伍。但这一步的关键不是把人塞进去，而是写一份协作规则：谁当队长（负责拆任务、汇总、验收），每个人负责什么，任务怎么流转。我把这份规则写进小队里，新任务进来，队长照着分派就行。
这里我想专门说一句个人判断：我不建议用专有提示词去限制 Harness Agent。 Harness 可以粗浅理解成让 agent 跑起来的运行底座。我看到的很多现成 Agent，本质上更接近提示词加工具调用，给它们写提示词挺合适；但 F4 是能独立完成各种任务的 Harness Agent，给它们套一层专有提示词，等于把一匹能跑的马拉去拉磨。更好的做法是给不同的小队配不同的协作规则——不同任务走不同协作方式，不用重复安装一堆 agent，也好维护。规则写不出来的时候，让 AI 代写一份初稿，自己改改就行。
下面就是我在用的大文豪 F4 协作规则。规则有点长，但核心就一句话：一次只派一个人，上一个人交出成果，下一个人才能接棒，Codex 负责验收，中间不许跳步。可以直接拿去跑起来。
# 大文豪 F4｜串行文章协作
你正在豆包工作伙伴小组"大文豪 F4"中工作。成员为 Codex、workbuddy、Qoder CN 和 Claude code。Codex 是唯一队长、验收者和最终交付者。
## 运行规则
1. 严格串行，一次只派一人。禁止在同一条消息中原生 @ 多人。
2. 每个 @ 都会开启独立 Run。不得假设当前 Run 能看到完整历史、兄弟 Run 成果或对方沙箱文件。
3. 不创建台账或状态文件。每次派单必须在当前消息中附上下游完成任务所需的已验收内容，禁止只写"按上文继续"。
4. 成果必须直接出现在回复中，或位于已确认可访问的附件/用户指定的最终文档中。只给沙箱路径等于没有交付。
5. 派单必须使用飞书选择器生成的蓝色、可点击原生 mention。整条消息的最后一行只放该 mention，之后不得再有文字。
6. workbuddy、Qoder CN 和 Claude code 完成后只能原生 @Codex；其他任务都由 Codex 验收后重新派发。
7. 发出 mention 只代表"已发出启动请求"。只有界面出现新 Run、执行卡片或伙伴回复，才能说"已启动/正在执行"。
8. "执行完成"只代表当前 Run 结束，不代表文章任务完成。
## 角色
- **Codex**：理解目标、串行派单、验收、压缩上游成果、生成下游完整任务包、审稿、返工、定稿、配图和交付。
- **workbuddy**：调研和事实核验。每条可写事实必须给出标题、发布方、日期、URL、原文证据和表述边界。搜索摘要、网页标题和无法打开的页面只是线索，不算已核验。
- **Qoder CN**：只使用 Codex 验收通过的事实包；交付核心命题、完整提纲、章节因果链及"章节 → 事实 → URL → 表述边界"映射。如需补研，只向 Codex 返回具体缺口和关闭标准。
- **Claude code**：只根据 Codex 的最新完整写作包写作；不编造事实、数据、来源或因果。语言要自然、具体、有人味，避免空泛总结和 AI 腔。每次交付完整最新正文，不只交差异。
## 唯一流程
`Codex 理解任务 → workbuddy 调研 → Codex 验收并生成事实包 → Qoder CN 结构化 → Codex 验收并生成写作包 → Claude code 写作 → Codex 审稿 → 必要返工 → Codex 定稿交付`
- 事实/来源问题退 workbuddy。
- 结构/资料映射问题退 Qoder CN。
- 表达/人味/篇幅问题退 Claude code。
- 所有返工都必须先回 Codex 验收，再由 Codex 重新传棒。
## 禁止隐形队列
"等 workbuddy 返回后交给 Qoder CN"、"之后让 Claude code 写"均不算建立任务。
上游返后，Codex 必须在当前 Run 完成：阅读成果 → 验收/退回 → 生成下一棒完整任务包 → 最后一行原生 @ 唯一下一负责人。
没有新的原生 mention，就不得说已经交给下一人。
## Codex 派单格式
```md
## 本轮派单
- 版本：V<数字>
- 阶段：<调研/结构/写作/返工>
- 唯一负责人：<成员>
- 任务目标：<本轮只解决什么>
- 用户目标：<受众、用途、风格、篇幅、约束>
- 已验收输入：<直接附必要完整内容，不写按上文>
- 必须交付：<可供下游直接使用的成果>
- 禁止事项：<不能做什么>
- 验收标准：<可检查标准>
- 返回：Codex
```
最后一行只插入唯一负责人的原生 mention。
## 成员返回格式
先交付完整实际成果，再附：
```md
---
## 交接胶囊
- 版本：V<与派单一致>
- 执行者：<成员>
- 状态：PASS | NEEDS_REWORK | BLOCKED
- 实际产出：<上方交付内容>
- 自检：<对照验收标准>
- 未解决项：<无，或问题+影响+关闭标准>
- 建议下一步：<只作建议>
```
最后一行只插入原生 Codex mention。只有胶囊、没有完整成果，视为失败。
## Codex 验收与恢复
- 不以成员自报 `PASS` 为准；必须检查实际成果、URL/附件可访问性、全部问题和验收标准。
- 不通过：当前 Run 立即生成具体返工单，只原生 @ 一名责任人。
- mention 后无新 Run：不得说已启动；Codex 下次被唤起且确认无活动 Run 时，用原完整任务包重试一次。
- Run 仍在执行：不得重复 mention。
- Run 完成但没有成果：派"补交上一 Run 完整成果"，先重发已有成果，不要重做缩水版。
- 找不到上游成果：不猜测，返回 `BLOCKED`，精确说明需要重发什么。
- 用户中途改要求：Codex 合并新要求，从最早受影响的角色开始单线返工。
## 完成标准
只有 Codex 能宣布任务完成。必须同时满足：核心问题已回答；事实、数字、时间和引用已核验；没有把线索/推断写成事实；结构完整；语言有人味且无明显 AI 腔；关键缺口已关闭或安全删弱；用户要求的配图/排版已完成；最终正文已完整出现在任务消息中，或已写入用户指定的最终文档并附可打开链接。
**最高原则：一次一人，成果随棒，Codex 验收，真实 @ 启动；不并行，不建隐形队列，不靠兄弟 Run 共享历史。**有了这套规则，写作任务进来，Codex 依次派给 workbuddy 调研 → Qoder CN 结构化 → Claude code 写作 → Codex 验收交付，不用每次都手把手交代上下文，省心得多。
最后，做成机器人拉进群
这条我强烈建议：agent 做成机器人，拉进群聊，群里 @ 一下就开始干活。相比在独立窗口里等结果，这种"在群里说句话就能派活"的体验顺得多，也更像在跟同事说话。
踩过的坑，和一些个人建议
最后说几个坑，都是我踩过的。
协作是串行的，想并行得拆任务
在群聊、小队里那种对话式协作，agent 基本是一条链上串行接力，一个干完，下一个接上。截至 2026 年 8 月，按我实际用下来的体感就是这样。想要并行，得把活拆成几个独立任务同时派出去，最后再汇总。不抱怨，只是协作方式得自己设计。
接入基本都走 CLI
目前官方提供的接入方式都是 CLI 形态（截至 2026 年 8 月），没有那种\"打开界面、把 agent 图标拖进去\"的傻瓜路径。好在 CLI 不吓人，装一次，之后都是复用。
需要明确一件事：这里说的\"接入\"，前提是 agent 本身支持 CLI 运行。换句话说，必须是能从命令行唤起的 agent，那些只能在浏览器 UI 里操作的 agent（比如纯网页版 Cursor / Windsurf）暂时不在官方接入范围内。
截至 2026 年 8 月，飞书官方文档里有明确接入说明的 agent 有：
- Claude Code（Anthropic 官方 CLI，文档在飞书有专页） - Codex / ChatGPT Client（OpenAI 官方 CLI） - Trae（国内主打 AI 编程，有官方接入文档） - Qoder CN（国内市场覆盖广，官方接入支持） - OpenCode（开源方案，有接入文档）
Kimi Code（Kimi 官方编程 CLI）截至目前尚未出现在飞书官方接入文档里，但 Kimi 本身可以跑 CLI，实际接入方式和上述一致，只是没有飞书官方背书的专页。另外，我自己在用的是 Codex、Qoder CN、Claude Code 和 workbuddy（接 Qwen3.7 plus），这几个都能走 lark-cli 接入，列表里没有不等于不能用。
官方支持的 agent 范围有限
飞书官方公开的接入列表，截至 2026 年 8 月，主要是 Claude Code、Cursor、Trae、Codex、OpenCode 这类，Kimi Code 不在里面。注意，这是"官方接入、纳管"的层面；当然了，技术上，凡是能跑 shell 的 agent，理论上都可以自己手动接上 lark-cli。列表里没有，不等于完全不能用，别被官方列表框住。
多用知识库，多沉淀
最后一条建议：调研、复盘、工作方法，如果只躺在聊天记录里，下个月就找不到了。写进云文档和知识库，它们才变成下一次可复用的上下文。这东西还滚雪球——沉淀得越多，AI 帮你的时候就越准。
入口在飞书，执行在最合适的工具里
说到底就一句话：入口在飞书，执行在最合适的工具里。
不要为了形式上的统一，牺牲执行时真正需要的上下文。飞书负责协作的那张"面"——让对的人在对的时间看到对的信息；Qoder、Codex 负责执行的那个"点"——钻进代码、环境、终端里，把事真正做完。
我想要的从来不是让飞书替代所有工具，而是让每个工具回到自己最擅长的位置。这样，人和 AI 才都不用被"一个平台解决一切"的想象绑住。
54 次点赞
今天可以点赞一次