前阵子我一直在琢磨一件事怎么把一堆 AI 助理真正变成“同事”而不是各聊各的聊天机器人。后来我用开源的多代理框架 OpenClaw 接上飞书搭了一支 5 人 AI 助理团队每个助理各管一摊事还能在群聊里互相配合。这套组合落地之后群里 一下就能查资料、写文档、统计数据、排日程、回客诉彻底从“玩具”变成了“生产力”。这篇文章就是完整的搭建过程从角色设计、环境部署、飞书应用配置到协作机制和踩坑记录全部一次讲清楚。先说清楚这套东西是什么OpenClaw 负责把多个带职责定义的 AI 代理管起来飞书则充当这些代理的工作台和沟通渠道。代理可以收到群消息、被 唤醒、调用工具、读写飞书文档和多维表格最后把结果直接发回群里。适合谁参考如果你手上正好有飞书团队或者你正在选型 AI 助理的落地方式又或者你只是想看看多代理系统怎么和 IM 工具真正打通这篇文章都值得读完。1. 项目概述与整体设计1.1 为什么是 OpenClaw 飞书先聊选型。市面上能做 AI 助理的框架不少但 OpenClaw 有个很讨喜的设计它把“代理管理”“技能调用”“渠道接入”拆得很清楚。我可以在一个配置文件里定义多个代理给每个代理分配不同的系统提示词和工具集然后让它们共享同一个飞书入口。飞书这边的优势也很明显机器人 API 成熟、事件订阅完善、多维表格能当共享数据库用而且国内团队用飞书办公的密度本身就高。集成之后助理不是孤立存在的而是直接嵌进团队原有的聊天流和工作流。有人会问为什么不用自建 Web 界面或者命令行我的判断标准很简单如果 AI 助理不能被团队里的人顺手用起来那它就只活在 demo 里。飞书群聊是团队本来就天天在用的地方助理以机器人身份出现在群里用户不需要学习任何新工具只需要会 。这才是能长时间跑下去的关键。1.2 五助理的角色规划与分工所谓“5 个可协作的 AI 助理团队”第一件事不是写代码而是做岗位设计。我一开始犯过错误把一堆功能塞进一个代理里结果一个请求触发十几个工具上下文乱得没法看。后来按职责拆成五个独立代理反而简单稳定。助理名核心职责主要工具典型触发场景情报助理搜索、抓取网页、整理摘要网页搜索、网页抓取、文档读取“情报助理 帮我查一下最近三个月的行业动态”文档助理写文档、改写、做会议纪要飞书文档读写、AI 生成“文档助理 把这份资料整理成周报”数据助理查表、统计数据、生成图表多维表格读写、数据分析“数据助理 按部门汇总一下本周销售数据”协调助理管理日程、派发任务、设置提醒日历查询、多维表格任务板、定时任务“协调助理 周三下午提醒我跟进客户”客服助理回复群内常见问题、沉淀 FAQ知识库检索、群消息读取、标准回复“客服助理 有人问退款政策帮忙回一下”这五个角色不是拍脑袋定的它们对应的是团队里最高频的协作需求信息获取、内容生产、数据处理、任务协调、对外响应。拆开之后每个代理的系统提示词可以写得很聚焦工具列表也短出错概率大幅降低。1.3 协作机制的总体思路团队协作的核心是把“任务”显式化。我的方案是用一张飞书多维表格当公共任务板字段包括任务内容、负责人、状态、截止时间、结果链接。任何代理接到用户请求后先把任务写进表格再根据负责人字段决定是自己处理还是转交给其他代理。处理完更新状态和结果链接整个过程在群里可见。这样做的好处是第一代理之间的交接有据可查不会出现“我以为你干了、你以为我干了”的情况第二飞书多维表格天然支持多人多端查看人类同事也能随时插手第三表格本身就是记忆代理重启后还能接着干。后面第 4 章我会详细展开这个协作机制的具体配置。2. 环境准备与 OpenClaw 部署2.1 部署前的依赖规划OpenClaw 本质上是跑在服务器上的服务所以你需要一台能持续运行的机器。个人测试用一台 4 核 8G 的云主机就很舒服内存再低也凑合但多代理同时推理时会明显变慢。操作系统我用的 Ubuntu 22.04Node.js 版本不低于 18另外要装好 Git 和 Docker。这里我建议优先用 Docker 方式部署省去一堆依赖问题如果后续要改源码再回到本地进程方式。飞书这边的准备工作相对简单你需要一个飞书企业管理员账号或者至少能创建自建应用的权限。个人测试可以用飞书个人版里的“团队”空间但真正要让机器人出现在群里最好是在一个真实的企业或团队环境下操作。整个接入过程不涉及付费飞书开放平台的基础机器人能力是免费的多维表格 API 也在免费额度范围内。2.2 安装与首次启动我按 Docker 方式走一遍流程。先把 OpenClaw 官方镜像拉下来再把配置文件目录挂载到宿主机docker pull openclaw/openclaw:latest mkdir -p /opt/openclaw/config cd /opt/openclaw docker run -d \ --name openclaw \ -p 9000:9000 \ -v /opt/openclaw/config:/app/config \ openclaw/openclaw:latest启动后OpenClaw 会生成一份默认配置文件openclaw.yaml。第一次跑别急着配飞书先确认服务进程活着docker logs -f openclaw看到类似“listening on 0.0.0.0:9000”的输出就说明框架起来了。这时可以用浏览器打开管理面板看看里面能看到代理列表和消息日志后面排查问题全靠它。2.3 配置文件的最小骨架OpenClaw 的配置核心是 YAML 文件。我习惯先把最小骨架搭起来再逐步往上加内容。下面是一个只包含一个占位代理的配置先验证链路通不通server: port: 9000 webhook_path: /feishu/webhook channels: feishu: enabled: true app_id: cli_xxxxxxxx app_secret: xxxxxxxx encrypt_key: verification_token: xxxxxxxx agents: - name: assistant_test display_name: 测试助理 system_prompt: 你是一个乐于助人的助理。 enabled_skills: [] channel: feishuchannels.feishu这一段先留空等第 3 章从飞书开放平台拿到 App ID 和 App Secret 再填。代理先不要挂技能确保消息能收到、能回复再逐步加能力。这个“先通路、再丰富”的顺序帮我省掉了大量排查时间。3. 飞书应用接入与机器人配置3.1 在飞书开放平台创建自建应用登录飞书开放平台后台进入“开发者后台”创建一个“企业自建应用”。创建时只需要填应用名称和描述头像随意。创建完成后你会看到两个关键凭证App ID 和 App Secret。前者是应用的唯一标识后者相当于密码千万不要提交到 Git 仓库里。我习惯把这两个值直接放到服务器的环境变量里避免写死在配置文件中。接着给应用添加“机器人”能力。在应用功能列表里找到“机器人”开启后这个应用就能以机器人的身份出现在飞书群聊中。注意光开机器人还不够你还得在“权限管理”里给机器人申请发消息、读消息的权限否则它只能站在群里当摆设。3.2 配置事件订阅与回调地址这是整个接入过程中最容易翻车的一步。飞书需要知道“消息来了往哪送”所以你必须在开放平台后台配置一个事件订阅地址。事件类型里勾选im.message.receive_v1接收用户发给机器人的消息然后填入回调地址。回调地址格式是https://你的服务器域名或IP/feishu/webhook注意必须是 HTTPS 或者飞书后台能访问到的公网地址。本地调试时很多同学卡在这一步因为没有公网地址。我的建议是直接把 OpenClaw 部署在带公网 IP 的服务器上省去内网穿透的额外复杂性。填完回调地址后飞书会发送一个 URL 验证请求。OpenClaw 收到后会自动响应验证。如果你启用了 Encrypt Key飞书会用 AES 加密回调内容OpenClaw 侧必须填入相同的 Encrypt Key 才能解密。为降低初期调试难度我建议先把 Encrypt Key 留空等消息收发通了再开启加密。3.3 权限申请与版本发布飞书开放平台的一个特点是即使你在代码里调用了某个 API如果应用没有申请对应权限调用依然会被拒绝。我整理了一份最小权限清单覆盖本项目五个助理的主要操作读取用户信息contact:user.base:readonly发送消息im:message接收消息事件im:message.receive_v1读写云文档docs:document读写多维表格bitable:app、bitable:record读写日历calendar:calendar申请完权限后必须“创建版本”并提交发布由企业管理员审核通过后权限才会真正生效。这一步经常被忽略我见过有人配置完全正确但忘记发布版本机器人始终没有完整权限报错信息还很隐晦。3.4 OpenClaw 侧连接配置与连通性测试回到服务器的openclaw.yaml把之前留空的飞书配置填上channels: feishu: enabled: true app_id: cli_xxxxxxxx app_secret: xxxx encrypt_key: verification_token: xxxx保存后重启 OpenClaw 容器docker restart openclaw。然后在飞书群里搜索你应用的名字把机器人拉进群发一条测试助理 你好。如果一切正常机器人会回复一句欢迎语。如果没反应优先查看 OpenClaw 日志里面会直接显示飞书回调是否成功。这一步打通了后面的五助理就是纯配置工作了。4. 五助理团队的配置与协作机制4.1 情报助理的配置实例我把情报助理定义成团队的“眼睛”。它的系统提示词我写得比较克制只强调三件事搜索前先拆解用户意图、优先采用可靠来源、输出带来源链接。工具方面只挂网页搜索和网页抓取避免它跑去读写表格造成权限混乱。- name: intelligence_bot display_name: 情报助理 system_prompt: | 你是团队的情报助理。接到查询请求时先判断用户真正想了解什么再用搜索工具获取信息。 输出必须包含信息来源链接。如果没有找到相关信息直接说明不要编造。 enabled_skills: [web_search, web_fetch] channel: feishu mention_trigger: truemention_trigger: true表示只有被 时才会响应防止它在群里抢答。实测下来这个配置让情报助理在多人群里非常有“边界感”不会打扰正常聊天。4.2 文档助理与知识库写作文档助理的价值是产出结构化内容。它挂了飞书文档读写技能和 AI 生成能力能把一段零散的聊天记录变成一份可分享的文档。我给它加的约束是生成文档前先列大纲确认内容结构后再落笔这样生成的文档基本不需要人工返工。- name: doc_bot display_name: 文档助理 system_prompt: | 你是团队的文档助理。接到写作任务时先输出大纲让用户确认再生成完整内容。 最终产出一篇飞书文档并把文档链接发回群聊。文档语气保持专业、简洁。 enabled_skills: [feishu_doc_create, feishu_doc_read, ai_generate] channel: feishu实际使用场景很直观群聊里有人说“把今天讨论的几个方案整理一下”文档助理把讨论要点抓取出来自动生成一篇带标题层级和结论的飞书文档再扔一个链接回群里整个流程一分钟内结束。4.3 数据助理与多维表格联动数据助理的定位是“表格操作员”。它不负责写作文案只负责查询、统计、更新多维表格。比如销售团队在群里问“华东区这周的签单额是多少”数据助理会直接查飞书多维表格里的销售明细汇总后给出数字。为了实现这个能力我给它挂了多维表格的读写技能并在提示词里写清楚表格的字段名和结构。- name: data_bot display_name: 数据助理 system_prompt: | 你是团队的数据助理。你可以读取和写入飞书多维表格。 回答数据问题时先说明数据来源表名和统计口径再给出结果。 enabled_skills: [bitable_query, bitable_update] channel: feishu parameters: default_table: 销售明细表这里有个经验不要指望数据助理自己“猜”字段含义最好把常用表结构直接写进系统提示词或者在启动时让它先读取表头做一次自检。我在第一次接入时就踩过坑它把“订单金额”和“回款金额”搞混了报出来的数字偏差很大后来把字段说明写清楚才解决。4.4 协调助理与任务流转协调助理是五个代理里最像“项目经理”的一个。它负责维护任务多维表格本身并不执行具体业务而是把任务分派给其他四个助理。我给它开了日历查询、多维表格读写和定时通知技能这样它可以定期检查任务状态并在截止时间前提醒负责人。协作触发逻辑是这样的当协调助理收到一个任务请求它先判断应该交给谁然后在任务板上新建一条记录负责人字段指向对应的助理状态设为“待处理”。其他助理通过监听任务板的变化或者被协调助理直接发消息通知来领取任务。为了让这套机制稳定我在任务表里加了“领取时间”“完成时间”字段方便追踪每个任务的耗时。4.5 客服助理与 FAQ 沉淀客服助理处理的是团队对外或对内的高频重复提问。它挂了一个简单的知识库检索技能知识来源是飞书文档里的 FAQ。当群里有新同事问“报销流程是怎样的”客服助理检索到相关文档提炼关键步骤并回复。回复末尾会附上文档链接方便提问者自己查看完整内容。- name: support_bot display_name: 客服助理 system_prompt: | 你是团队的客服助理。回答问题时优先检索知识库若知识库内容不充分明确告知用户并建议人工介入。 每次回答后如果发现知识库缺少相关问题记录下来供人工补充。 enabled_skills: [kb_search, feishu_doc_read] channel: feishu客服助理跑起来后一个明显变化是群里“有人问但没人答”的情况少了很多。它不追求回答所有问题核心价值是把已知答案的重复问答自动化让真人只专注于处理未知问题。4.6 团队协作的工作流设计五个代理各自独立能干活但要真正形成“团队”必须有一套共同的工作流。我的方案落地为三步所有任务入口统一走飞书群聊通过 指定某个助理或直接发到协调助理由它分派。所有任务状态统一写在“任务协调表”里表格字段固定为任务ID、任务内容、负责人、状态、创建人、截止时间、结果链接。每个助理处理完任务后必须回填状态和结果链接并在群里同步一条简短消息。这个设计把“记忆和协作”外置到了飞书多维表格里不依赖某个代理的上下文窗口。代理哪怕重启、换模型只要任务表还在就能无缝接续。实际操作中我还给每个助理在任务表里建了不同的视图比如“情报助理视图”只显示负责人是情报助理的记录避免代理每次查询都要过滤全表。5. 常见问题与排查技巧实录5.1 事件订阅验证失败这是接入飞书时最高频的问题症状是后台保存回调地址时报错“URL 验证失败”。一般就三个原因回调地址公网不可达、OpenClaw 没在监听正确端口、Encrypt Key 不一致。先 curl 一下回调地址确认能访问且返回 JSON。如果地址通但验证还是失败把 Encrypt Key 临时清空再试。绝大多数情况都能在这三步里解决。5.2 机器人收不到消息配置全部正确但机器人毫无反应优先检查事件订阅类型。很多人只添加了机器人能力忘了订阅im.message.receive_v1。另外飞书的权限和事件是两个独立体系事件订阅本身也要在“事件订阅”页面确认状态为“已订阅”。最后看一眼 OpenClaw 日志如果显示“received event”但没有后续处理动作多半是代理的channel字段写错或者代理被禁用。5.3 权限不足与错误码调用飞书 API 时常见的错误码对应关系我整理了一份速查现象常见原因解决办法返回 99991672应用没有对应权限后台添加权限并重新发布版本返回 9499 或 permission deniedtoken 类型不匹配确认用的是 tenant_access_token 还是 user_access_token发消息成功但群内不可见机器人未被拉入群在群设置里添加机器人多维表格写入失败未开通 bitable 权限申请bitable:record权限并发布一开始我习惯把错误码背下来后来发现没必要只要在 OpenClaw 日志里看到“api error”关键字再配合权限管理页面逐个核对问题基本都能定位。5.4 并发协作冲突五个助理共享一张任务表并发写入时会出现互相覆盖。最常见的情况是协调助理刚把任务状态改成“处理中”数据助理拿到旧数据又把它改回“待处理”。我的解决办法是引入“更新时间”字段每次更新前先检查当前记录的时间戳另一个方案是让每个代理只更新自己负责的字段比如数据助理只更新“工作结果”协调助理只更新“状态”。后者更简单实测够用。5.5 上下文遗忘问题代理跑久了之后经常出现“忘了自己刚才在干什么”的尴尬。这不是模型的问题而是系统提示词太长、对话上下文被截断。我的策略是在系统提示词里写“每次处理任务前先读取任务表中最新的记录”让代理从外部任务板恢复上下文而不是依赖群聊记录。这套做法让长时任务也能保持稳定值得推荐给所有做多代理应用的人。我个人在实际操作中的体会是搭建这套五助理团队最难的不是技术接入而是角色边界的设计。一个代理能干的活太多了真正让它稳定高效的反而是你为它划下的那条线只做一类事、只用几个工具、只回应该回应的人。当你把五个边界清晰的助理放进同一个飞书群协作自然就发生了。如果你正好也在折腾类似的事不妨从“先打通一个助理再逐步加人”开始这套路线我已经替你验证过了值得一试。