飞书当遥控器：OpenClaw多代理AI团队搭建实战指南

最近我在折腾一个很有意思的项目——用飞书当遥控器管着一群 OpenClaw 智能体干活。说白了就是把几个不同“岗位”的 AI 代理塞进一个飞书群里让它们自己开会、自己协作、自己汇报我只需要在群里发号施令。这个思路玩起来之后最大的感受是AI 应用落地真正的门槛早就不在“能不能跑通模型”而是“怎么让别人、让团队、让自己方便地用起来”。飞书恰好是个现成的交互界面身边同事都在用机器人发消息大家天然会看OpenClaw 则能把大模型接上各种工具让代理真的去动手干活。把这两者一拼就得到了一个成本很低、见效很快的多代理管理系统。这篇文章我就把整套搭建过程、角色分工、飞书配置、常见坑位全部摊开来讲内容偏向实战适合正在研究多代理协作、想用即时通讯软件管 AI 团队的开发者或者说哪怕你只想知道“怎么把一个 AI 代理接入飞书”这篇也能当个参考手册用。1. 项目整体思路用聊天窗口做 AI 团队的控制台1.1 为什么选 OpenClaw 做代理底座先聊 OpenClaw。它本身是一个开源项目核心思路是把大模型的能力接到各种执行载体上本地电脑桌面、浏览器、GitHub 账号、媒体平台发布入口等等。跑起来之后它不是说“我给你一段建议”而是直接动手去操作系统去打开网页、去点按钮、去填表单、去提交内容。本质上它是一个把“语言能力”翻译成“操作行为”的中间层。和市面上其他几类方案对比选 OpenClaw 的理由很直接Dify、Coze 这类平台擅长编排“工作流”但它们更像流水线节点固定灵活性和自主性偏弱。自己直接用 API 写脚本接飞书可控性最强但开发量不小而且每个需求都要从零写一套逻辑维护成本高。OpenClaw 更像“一机多能”它把电脑操作能力、网页检索能力、文件处理能力整合到一起代理可以像人一样去用各种软件、看各种网页而不是只能调用预设好的 API。它跑起来后就是一个常驻进程可以一次拉起多个实例每个实例有自己的身份配置天然支持多代理。这些代理共享同一个底层能力但各自绑定不同的记忆空间和工具权限就像招了几个能力相近、但分工不同的员工。1.2 为什么选飞书当管理界面飞书在这套系统里扮演的角色是“调度台”。我不需要做一个 Web 前端不需要自己写审批流不需要搞复杂的 Dashboard飞书自带三样东西直接够用群聊机器人每个 OpenClaw 实例可以对接一个飞书机器人机器人把代理的发言转发到群里我在群里 某个机器人就等于给对应代理下达指令。消息卡片与按钮代理可以把待确认的任务、执行结果的预览以卡片形式推送到群里我在卡片上点“确认”或者“驳回”就能完成人工审核。多维表格相当于一个可以给代理读写权限的简易数据库。让代理把任务状态、执行记录、产出链接直接写进多维表格天然形成一张团队看板。这三样东西让飞书从一个“聊天软件”变成了“系统控制台”。信息流即指令流审批流即卡片点击存储即多维表格。不需要额外开发任何界面省掉了大量无用功。1.3 这套系统解决了什么问题平时做 AI 项目最烦的事情是什么是让 AI 结果“被人看到”。模型调用再灵活如果反馈渠道是命令行、是后台日志那只有开发者自己看得见团队里的其他人根本用不起来。而通过飞书管代理解决的是这四件事降低了使用门槛。只要会发消息就会指挥 AI 团队干活。增加了协作透明度。谁在执行什么任务、进展如何群里一目了然。加上了人工审核闸门。涉及关键操作时代理会先把方案发到群里等人确认避免代理乱来。沉淀了团队记忆。飞书群聊记录、多维表格本身就是长期记忆库。2. OpenClaw 安装与环境准备2.1 安装前的资源规划OpenClaw 可以本地直接跑也可以用 Docker 跑。我先说结论本地裸跑适合快速试玩和调试Docker 适合长期稳定运行。如果你手头只有一台普通的家用电脑或云服务器用 Docker 方案更省心开机自启、日志隔离、环境干净。需要准备的东西有这么几样一台能联网、有图形环境或虚拟显示能力的机器。Windows、macOS、Linux 都行。Docker 环境如果用容器方案。Linux 服务器上装 Docker 再配 docker-compose比较顺滑。一个大模型 API 的访问密钥。OpenClaw 兼容 OpenAI 格式的接口云厂商的也好开源的本地模型服务也好只要能兼容就行。一个飞书企业自建应用的权限。注意这里是“企业自建应用”不是飞书个人版因为机器人 API 需要企业管理员权限来创建和发布。2.2 一键安装命令OpenClaw 官方提供了一键安装脚本快速上手时直接用curl -fsSL https://openclaw.example.com/install.sh | bash装完以后验证一下版本openclaw --versionDocker 方式的启动脚本大致长这样我先给一个能跑的版本mkdir openclaw-demo cd openclaw-demo cat docker-compose.yml EOF services: openclaw: image: openclaw/openclaw:latest container_name: openclaw-team restart: always ports: - 127.0.0.1:8080:8080 volumes: - ./profiles:/app/profiles - ./logs:/app/logs environment: - TZAsia/Shanghai EOF docker compose up -d这里我特意把 8080 端口绑到 127.0.0.1而不是 0.0.0.0。理由很实在OpenClaw 自带一个控制面板方便查看每个代理的实时动作但这个面板不应该暴露到公网不然等于把电脑控制权挂到外网上风险极大。自己本机访问、内网访问就够了。2.3 配置第一个代理实例OpenClaw 的配置文件是profiles/目录下的一个 profile 文档每个代理实例都对应一个独立配置。最简配置里至少要包含这几项name: alpha llm: provider: openai model: gpt-4o api_key: 你的密钥 base_url: https://api.xxx.com/v1 chrome: headless: false user_data_dir: ./browser-data/alpha extensions: - feishu我解释一下这几项为什么重要。name实例标识多个代理靠它区分身份。llm大模型接入信息。模型名、密钥、接口地址是老三样不多说。chromeOpenClaw 会启动一个真实浏览器窗口代理像真人一样去观察页面、点击按钮。headless设成 false 时你能在机器上看到它在“操作电脑”这对排查问题非常直观。extensions功能扩展模块。接飞书靠的就是这个扩展后面专门说。配置完以后启动代理openclaw run --profile alpha看到控制台输出“Agent alpha is running”之类的日志说明代理已经在线。3. 设计多代理团队给每个角色配一个专属配置3.1 AI 团队的角色分工设计单一代理接飞书只是第一步真正好玩的是多代理协作。我在自己的环境里跑了 4 个代理角色是这样的角色实例名主要职责典型操作作业员worker处理重复性文秘工作整理文档、批量改格式、定时转发消息网络调查专员researcher检索信息、汇总资料打开搜索引擎、翻阅网页、摘录要点项目经理manager分配任务、汇总进度读取多维表格、核对状态、发出提醒代码工程师coder写脚本、改代码、跑测试操作终端、编辑文件、执行命令这样设计的理由是把“执行”和“决策”拆开。作业员和网络调查专员负责干活项目经理负责派活和盯进度代码工程师负责需要“硬核操作”的活。每个代理只专注一类事Prompt 可以做得更精准工具挂载也更聚焦出错的概率小很多。3.2 用消息前缀做“虚拟团队群”飞书这边我建了一个群把 4 个机器人全部拉进群。这样发出的每条消息所有代理都能看到但我用“某机器人”方式来指定由谁响应。举个例子“作业员 把上周的会议纪要整理成表格发出来”——作业员代理响应。“网络调查专员 调研一下市面上主流的开源日历项目列出前五名”——网络调查专员代理响应。“项目经理 汇总一下今天所有任务进度”——项目经理代理响应。这种方式很轻量不需要做复杂的路由算法飞书自带的 机制就把人机路由解决了。有个细节在飞书后台机器人接受消息事件的权限要打开“接收群消息”否则 它是没有反应的。3.3 代理间协作的“弱连接”设计多代理协作最容易翻车的地方是强行让代理之间互相调用。Anthropic 团队自己的经验也提到代理协同的关键是“用文档交接而不是用对话交接”。我参考这个思路让代理之间不直接聊天而是通过多维表格和共享文件夹传递产物项目经理把任务拆解后写到多维表格的“任务清单”视图。作业员看到自己的任务条目把产出文件传到共享文件夹并在表格里更新状态。网络调查专员把调研结论写成文档放共享空间然后把链接贴到群里。这样即使某个代理中途挂了、换了模型、或者干脆换人接管任务上下文都还在表格和文档里不至于断档。这段设计虽然不起眼但它是整个系统能稳定跑起来的关键。4. 飞书机器人接入从新建应用到消息收发4.1 创建飞书自建应用先登录飞书开放平台在“开发者后台”里创建一个企业自建应用。名字随意比如“AI 团队助理”。创建完以后要干三件事在“应用能力”里添加“机器人”能力这是让代理能收发消息的前提。在“权限管理”里开通需要的权限。常用权限包括im:message读取与发送单聊/群聊消息im:message.group_at_msg读取群组中 机器人的消息im:chat读取群信息drive:drive读写云空间文件可选发布应用版本。注意自建应用只有发布上线后机器人和权限才真正生效。4.2 生成机器人凭证在应用的“凭证与基础信息”页面能看到 App ID 和 App Secret。这两个值要写到 OpenClaw 的飞书扩展配置里。另外飞书要求机器人事件订阅走 HTTPS 回调或者用长连接模式。OpenClaw 的飞书扩展封装了长连接方案不需要公网回调地址这对没有公网 IP 的本地环境非常友好。配置如下extensions: - type: feishu app_id: cli_xxxxxxxxxxx app_secret: 你的应用密钥 bot_name: 作业员 mode: websocketmode设成websocket相当于飞书主动把消息推给本地长连接省掉了配置回调服务器、HTTPS 证书的麻烦。这算是一个很省心的设计。4.3 把机器人拉进群飞书应用发布上线后在群设置里搜索应用名称添加进群即可。然后直接发一条消息测试作业员 在吗如果 OpenClaw 日志里出现收到消息的记录说明链路通了。如果没反应优先检查三处应用是否已发布、机器人是否已入群、权限里是否勾了“读取群消息中 机器人”的权限。5. 跑通第一个真实任务从建群到产出报告5.1 配置模拟项目 X 的自动化工位为了演示完整流程我在本地搭了一个模拟项目环境目录结构大致是~/demo-project/ ├── docs/ # 项目文档 ├── scripts/ # 脚本目录 ├── reports/ # 产出报告 └── README.md然后我在飞书里建了第二个群专门用来跑“模拟项目 X”。群里只有两个机器人项目经理、代码工程师。我的目标是让代码工程师根据 README 文件把项目里所有文档的标题提取出来生成一份索引报告并统计字数。5.2 群内派活建好群后我发了一条消息项目经理 让代码工程师检查一下 demo-project 项目把 docs 目录下所有文档的标题做成索引统计每篇字数输出一份报告到 reports 目录。项目经理收到这条消息后会自动把任务拆成两步通知代码工程师代理执行任务。在多维表格里登记一条任务记录状态是“进行中”。这个“拆任务”的过程靠的是 Prompt 里预设的协同规则。我在项目经理的配置文件里写了类似这样的约束system_prompt: | 你是项目经理。用户下达需求后先拆解为具体子任务 明确每个子任务的执行人并写入多维表格(任务清单工作表)。 然后在群里 对应的执行代理说明目标与交付物。代码工程师代理收到 通知后会通过终端进入~/demo-project用ls和head命令查看文档目录遍历所有.md或.txt文件提取标题统计字数最后把结果写进reports/index.md。5.3 查看最终产出任务跑完代码工程师代理会在群里汇报模拟项目 X 的文档索引报告已生成。共扫描 5 篇文档总字数 12800 字。文件路径reports/index.md。我再打开多维表格看到那条任务记录的状态已经自动变为“已完成”更新人一栏写的正是代码工程师代理的名称。这整个过程里我实际只动了两次手建群、发需求。剩下的全由代理协作完成。6. 飞书管理 AI 团队的进阶玩法6.1 用多维表格做任务状态看板飞书多维表格在这里不只是记录工具它同时是代理之间交换信息的“共享内存”。我给“任务管理”建了几个字段任务名负责人状态待处理 / 进行中 / 已完成 / 已阻塞产出链接优先级最后更新人OpenClaw 的飞书扩展支持代理直接读写多维表格项目经理代理在派活时自动新增记录执行代理完成后回写状态。这样就得到了一块“活”的看板不需要任何人手工维护。我在实际跑的时候发现字段命名和选项命名最好全用英文或拼音避免代理在处理时因为中文编码或多字同义产生理解偏差。比如状态直接用todo、doing、done、blocked比“进行中”“已完成”这类词更稳。6.2 在飞书群里做“人审确认”AI 代理一旦有写操作权限风险就会上来。比如代码工程师改文件、网络调查专员发布文章这类动作不适合完全放开。我的做法是在代理的系统提示词里加上这么一条规则——每当你要执行不可逆或高风险操作删除文件、覆盖内容、提交推送、对外发布先将操作预览发送到群内并附带一个确认按钮。用户点击确认后你才能继续执行。飞书机器人支持发送交互卡片卡片里带按钮{ msg_type: interactive, card: { elements: [ { tag: button, text: {content: 确认执行, tag: lark_md}, value: {action: confirm, task_id: T001} } ] } }OpenClaw 的飞书扩展会把按钮回调转成代理可感知的事件代理收到确认信号后继续干活。这套机制非常关键它把 AI 从“无人监管的自动执行者”变成了“等待指令的辅助者”安全性和可控性都上了一个台阶。我在测试时试过让代码工程师代理删除一个旧目录它果然先把目录结构和删除命令列出来等我点了“确认”才动手。这种交互方式很踏实也适合推广给对 AI 操作有顾虑的团队使用。6.3 定时任务与主动汇报飞书机器人还能配置定时触发。我在一个测试群里设了每天早上 9 点让项目经理代理发一条进度汇总哪些任务今天到期、哪些任务状态异常、哪些任务需要人工介入。实现方式不复杂在 OpenClaw 配置里加一个 cron 触发器它到点自动构造一条消息塞给对应代理代理处理后通过飞书机器人发到群里。相当于团队里多了一个“每天主动汇报”的 AI 助理而且不需要任何额外开发。7. 踩坑实录与排查技巧7.1 飞书长文本消息被截断第一个遇到的问题代理生成的报告太长通过飞书消息发出去时被截断了后面一截直接消失。飞书单条消息有长度限制超长内容会被截断但这个限制具体到卡片、文本、富文本会不一样。解决办法有两个在代理的 Prompt 里加上“生成摘要完整内容保存为文档发送链接”从源头控制消息长度。用飞书云文档扩展能力让代理把长报告自动写成云文档再把文档链接发到群里。我最后选了第二种方案。打开“云文档”权限后代理可以直接用 API 创建文档并写入内容返回链接我再在群里转发这个链接。效果比贴出一大段文本好得多阅读体验也更好。7.2 代理“看起来没反应”如果 代理之后它没有任何回复先别急着怪代码。按这个顺序排查查看 OpenClaw 进程日志确认是否收到了飞书事件。如果日志连事件都没收到去飞书开放平台的事件订阅列表看是否有人推送记录。没有的话大概率是机器人没启用“接收消息”事件。如果事件收到了但代理没有回复看日志里有没有异常栈信息常见原因是 LLM API 请求失败或者超时。如果 LLM 有响应但飞书没显示检查机器人权限是否包含“发送消息”。这套排查顺序基本能覆盖 90% 的“没反应”问题。7.3 多个代理同时操作电脑导致资源争抢多代理实例同时跑在一个宿主机上每个代理都可能启动浏览器、执行终端命令资源竞争在所难免。我跑 4 个代理时机器直接出现内存吃满、浏览器卡死的情况。后来做了两件事给每个代理单独挂载 Chrome 用户目录避免浏览器配置互相覆盖。在 docker-compose 里给每个代理容器设 CPU 和内存上限。services: worker: image: openclaw/openclaw:latest deploy: resources: limits: memory: 2048M cpus: 1.5这样即使某个代理执行了重负载任务也不会拖垮整个宿主机。7.4 敏感操作与密钥管理OpenClaw 的配置文件里直接写了 LLM API 密钥、飞书应用密钥。如果整个 profiles 目录被同步到代码仓库或分享给他人等于把系统权限拱手送人。我的建议是profiles 目录加入本地.gitignore永远不进仓库。密钥用环境变量注入不在 YAML 里写明文。飞书应用的权限遵循最小化原则不需要的权限一律不开。这类问题看似琐碎但一旦出事就是大坑我在早期调试时曾经把测试用的配置文件临时发给别人参考虽然只是测试密钥但也花了额外的时间去轮换。现在一律用环境变量干净很多。7.5 模型选择对代理执行质量的影响不同大模型对“行动指令”的理解能力差异很大。偏对话优化的模型在调用工具写文件、读取浏览器状态的时候经常出现“理解不了当前页面状态”的情况而更擅长智能体任务Agentic的模型则相对稳很多。我个人的建议是如果预算允许主力代理用能力较强的商业模型辅助角色可以用开源模型跑本地推理。这个搭配既控成本又保证核心链路质量。不要把所有代理都塞同一个高成本模型也没必要为了省钱全用弱模型要看每个角色的任务边界。8. 扩展可能性总结整套系统验证下来飞书 OpenClaw 组合让我重新理解了“AI 团队管理”这件事。它最大的价值不在于单点自动化而在于把一群代理放进了人类已经熟悉的协作工具里用群聊、表格、卡片这些日常组件去驱动它们。顺着这套框架还可以继续向外扩展接更多飞书原生应用能力比如音视频会议纪要自动生成、日程表自动排期。把代理接入更多的外部工具扩展比如社交平台发布、代码托管平台协作。在飞书审批流里做更复杂的人工审核比如多人投票确认才允许代理执行高权限操作。我个人的体会是AI 多代理系统现在的定位不是替代人而是把人人不想干的重复活、盯不住的琐碎活、理不清的杂事接过去。飞书这种 IM 工具恰恰是它跟人类协作者之间的“翻译层”。最后再分享一个经验。如果你也准备搭一套类似系统不要一上来就堆四五个代理。先跑通一个代理、接好飞书、把消息收发和任务执行理顺再慢慢加角色。系统复杂度和故障排查难度是指数上升的少即是多。这次分享到这儿也就差不多了。希望这篇文章能给你一些可以直接上手的思路少走我在配置和排错阶段踩过的那些弯路。