最近我换了一种干活的姿势，换过去就回不来的那种：我不再在人和一堆 AI 窗口之间当搬运工，而是让飞书当一个我和几个 agent 一起用的共同工作台。agent 就是能自己干活、会读文件跑命令的 AI 程序，后面还会提到好几个。
先说说以前的日子，你们就知道我为什么这么折腾。
我手上有一堆 AI：Codex、Qoder CN、Claude Code，还有 Hermes。以前它们各开各的窗口，我的日常就是在这几个窗口之间搬东西——把 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 和 Hermes：Codex 是 OpenAI 的官方订阅；Qoder CN 也是官方订阅，写代码我特别依赖它；Claude Code 我这边给它接的是 DeepSeek 的官方 API；Hermes 则用 Kimi 的官方 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 代写一份初稿，自己改改就行。
最后，做成机器人拉进群
这条我强烈建议：agent 做成机器人，拉进群聊，群里 @ 一下就开始干活。相比在独立窗口里等结果，这种"在群里说句话就能派活"的体验顺得多，也更像在跟同事说话。
踩过的坑，和一些个人建议
最后说几个坑，都是我踩过的。
协作是串行的，想并行得拆任务
在群聊、小队里那种对话式协作，agent 基本是一条链上串行接力，一个干完，下一个接上。截至 2026 年 8 月，按我实际用下来的体感就是这样。想要并行，得把活拆成几个独立任务同时派出去，最后再汇总。不抱怨，只是协作方式得自己设计。
接入基本都走 CLI
目前官方提供的接入方式都是 CLI 形态（截至 2026 年 8 月），没有那种"打开界面、把 agent 图标拖进去"的傻瓜路径。好在 CLI 不吓人，装一次，之后都是复用。
官方支持的 agent 范围有限
飞书官方公开的接入列表，截至 2026 年 8 月，主要是 Claude Code、Cursor、Trae、Codex、OpenCode 这类，Kimi Code 不在里面。注意，这是"官方接入、纳管"的层面；当然了，技术上，凡是能跑 shell 的 agent，理论上都可以自己手动接上 lark-cli。列表里没有，不等于完全不能用，别被官方列表框住。
多用知识库，多沉淀
最后一条建议：调研、复盘、工作方法，如果只躺在聊天记录里，下个月就找不到了。写进云文档和知识库，它们才变成下一次可复用的上下文。这东西还滚雪球——沉淀得越多，AI 帮你的时候就越准。
入口在飞书，执行在最合适的工具里
说到底就一句话：入口在飞书，执行在最合适的工具里。
不要为了形式上的统一，牺牲执行时真正需要的上下文。飞书负责协作的那张"面"——让对的人在对的时间看到对的信息；Qoder、Codex 负责执行的那个"点"——钻进代码、环境、终端里，把事真正做完。
我想要的从来不是让飞书替代所有工具，而是让每个工具回到自己最擅长的位置。这样，人和 AI 才都不用被"一个平台解决一切"的想象绑住。