你有没有遇到过这种局面几个群同时在催一个要稿子一个要数据一个要客服回复模板还有人在问活动文案怎么改。我当时的解法很简单——抽了一个下午把重复劳动全部收编成“可协作的 AI 助理团队”。整体架构只用两样东西开源编排框架 OpenClaw 负责创建角色、调度任务、管理记忆飞书负责给这些 AI 助理一个大家都能发消息、看结果、点按钮的办公入口。5 个团队搭完之后原本需要我手动流转的活儿变成了群里说一句话就自动开跑。这篇不是宣传稿是我自己搭完之后的完整复盘包含选型理由、配置清单、5 个团队各自的角色设计和协作流水线以及我排查过的几个典型问题。适合三类人看一是被重复事务淹没的中小团队负责人二是想给运营、客服、内容、研发几摊事找统一出口的开发者三是刚接触 Agent 编排、想找一个能落地的场景而不是停留在 hello world 的人。基础要求不高但你需要能改配置文件和简单的 JSON。1. 开局思路为什么是 OpenClaw 飞书以及“5 个团队”的设计逻辑1.1 选型拆解OpenClaw 解决什么问题飞书解决什么问题先说结论OpenClaw 管“脑子”飞书管“手脚和门面”。OpenClaw 在我理解里是一个开源的 Agent 编排框架。它负责几件很具体的事定义每个 AI 助理的身份和 Prompt、挂载工具插件、维护会话记忆、按规则把任务分发给对应角色、记录运行日志。你不需要自己写一套消息队列也不需要自己设计 Agent 的状态管理它天生就是干这个的。飞书则解决了“人怎么和 AI 助理打交道”的问题。它提供了群聊、机器人、事件订阅、消息卡片、多维表格、审批流这些开箱即用的能力。我不用再开发一个聊天气泡界面不用处理 WebSocket 连接、消息去重、未读计数这些东西。飞书群就是控制台机器人就是前台卡片就是公告板多维表格就是档案柜。我试过自建一个简单的管理页面后来放弃了。原因很现实聊天式交互是最高效的任务入口而飞书本身就是团队每天都在用的工具把 AI 助理塞进已有的协作习惯里学习成本几乎为零。相比之下让团队去打开一个陌生的网页后台还要惦记着刷新看结果这个流程天然就断了。选用 OpenClaw 而不是闭源商业平台还有一层考虑数据可控。Agent 的 Prompt、知识库内容、工具权限都放在自己的配置里团队的上文语境、业务口径、敏感信息不会流到外部私有平台上。对很多公司来说这一点比功能多少更重要。1.2 五条业务线的团队划分逻辑“5 个团队”不是拍脑袋定的而是按照业务闭环来划分的。我见过很多人一上来就堆二十个 Agent结果互相抢任务、上下文串场、逻辑乱成一团。正确的做法是先找“业务流”再把 Agent 沿业务流排布。我当时梳理了团队里最常被塞过来的需求归纳成五条线内容产线从选题策划到成稿、审校、多平台分发一条龙。客服支持从首次响应到知识库检索、工单记录、后续回访。数据分析从取数、清洗到分析洞察、图表输出。研发辅助从需求澄清到接口设计、代码审查、文档更新。运营增长从热点发现、排期、投放文案到效果复盘。每个团队内部再拆 3 到 4 个角色比如内容产线里有策划、撰稿、编辑、分发四个助理。团队之间不是完全隔离而是通过一个“跨团队协作频道”互相喊话。这个设计的好处是单个团队内部的流转路径很短出错容易定位跨团队协作又保留了灵活性不会变成五个信息孤岛。为什么是 5 个而不是更多因为每一个团队都要有人维护 Prompt、工具、知识库和权限。在资源有限的前提下5 条线已经覆盖了绝大多数小微团队的日常高频需求。等跑顺了再往里面加角色比一开始铺开几十个 Agent 要稳得多。2. 落地前必须做好的基础配置环境准备与权限设计2.1 OpenClaw 侧的基础设置我建议先把 OpenClaw 装在一台 Linux 小机器上配置不用太高4 核 8G 就够起步。安装过程不展开按官方文档走就行不同版本略有差异。装好后我习惯先把目录结构理清分成agents/角色定义、tools/工具插件、flows/协作流程、memory/会话记忆几个目录方便后面维护。每个 Agent 的核心配置文件大概长这样伪配置字段名以你用的版本为准agent: name: content_writer team: content_production model: your-model-name temperature: 0.4 system_prompt: | 你是内容产线团队的撰稿助理。 你的输出必须基于策划助理提供的 Brief 遵循团队风格指南禁止编造事实。 每次写完后用 Markdown 输出稿件正文。 tools: - feishu_doc_reader - feishu_base_writer - web_search max_iterations: 8注意几个关键字段。team用于逻辑分组后续消息路由会按这个字段找对团队。system_prompt决定了这个助理的“人设边界”是后面所有协作行为的地基。max_iterations是防死循环的保险丝一个任务最多让 Agent 迭代多少次超过就停下来问人。另一个容易忽略的点是模型参数。内容生成类的助理我会把temperature调高一点比如 0.7让文案有更多变化数据分析、代码审查类的助理则调到 0.1 到 0.3保证输出稳定可靠。同一个团队里不同角色用不同参数这是很基本但很有效的调优手段。2.2 飞书侧的应用与机器人配置飞书这边的第一件事是在开放平台创建一个企业自建应用。注意是“企业自建应用”不是简单的自定义机器人。前者支持事件订阅和双向交互后者只能往群里推消息做不了真正的“对话式调度”。创建应用后按步骤开通机器人能力然后添加权限。我的最小权限清单供参考权限点用途im:message接收和发送群消息im:message:send_as_bot以机器人身份发消息contact:user.base:readonly读取用户基础信息用于识别发送人docs:doc:read读取飞书文档内容base:record:read/base:record:write读写多维表格记录权限不是越多越好按需申请。我见过有人一口气把所有权限全勾上后面审查看得自己都心虚。事件订阅这里有个省心选项如果不想暴露公网回调地址可以直接开飞书的长连接模式WebSocket 长连。我一开始用的就是长连接本地开发时不用折腾内网穿透部署到服务器后也少一台中转机器。如果你确实需要通过回调地址推送那就把Encrypt Key和Verification Token记好后面配置加签会用到。事件订阅里一定要选对事件类型接收消息im.message.receive_v1。如果你只开了权限但没订阅事件机器人就是个“聋子”群里被 也不会有反应。这个问题我后面在排查清单里会再提。2.3 消息路由与权限隔离配置完基础设施后最重要的一步是设计消息路由规则。我的规则很简单按“团队 指令前缀”路由。在群里 对应机器人同时说清楚要哪个团队干活例如“内容指挥官 写一篇关于产品上新公告的公众号文章”“数据小队 分析上周各渠道转化率”“客服总机 总结今天前 20 个咨询的共性问题”路由规则放在 OpenClaw 的消息入口服务里本质是一组判断逻辑先判断目标 Agent 属于哪个team再判断消息是否包含指定业务关键词最后把消息丢给对应团队的入口 Agent。权限隔离这块我做了两层。第一层是群维度隔离内容团队群只有内容相关机器人数据团队群只有数据相关机器人避免无关 Agent 被误唤醒。第二层是操作维度控制比如数据分析团队的取数工具只绑定了数据库只读账号内容团队的分发工具只能写指定的飞书文档目录谁也不能跨权限干自己不该干的事。这样做不只是为了安全更是为了让 Agent 的上下文保持干净——每个团队只看到自己需要的信息不会互相污染。3. 逐个拆解5 个 AI 助理团队的搭建实录3.1 团队一内容产线团队策划-撰稿-编辑-分发内容产线是我最先搭的团队因为它的协作链条最长、最能体现“多 Agent 接力”的价值。团队里有四个角色。第一个是策划助理负责把一句需求扩写成结构完整的 Brief包括目标读者、核心卖点、大纲、风格要求第二个是撰稿助理基于 Brief 产出正文初稿第三个是编辑助理按风格指南审校检查事实错误、逻辑漏洞、错别字和 SEO 关键词密度第四个是分发助理把定稿改写成不同平台的版本比如公众号长文、小红书笔记、朋友圈短文案。协作流是这样的我在群里喊一句“内容指挥官 下周要发一篇企业服务选型指南”入口 Agent 会把消息转给策划助理。策划助理生成 Brief 后发给撰稿助理撰稿助理成稿编辑助理审校打回或放行最后分发助理按平台生成版本。这一步完成后结果自动写入多维表格的选题库并在群里推一张卡片告知“内容已归档”。做这个团队时最需要注意的是不要让撰稿助理越过策划直接写稿。你可能会觉得多绕一圈很慢但实际上策划 Brief 是质量基线。有一次我把策划助理临时停用让撰稿直接接需求结果写出来的稿子结构松散、经常跑题。恢复 Brief 流程后虽然多了一步但审校通过率明显提升。知识库方面我给编辑助理接了一个飞书文档目录里面存了历史爆款文章和官方风格指南。编辑审校时会主动对照这些文档而不是只靠通用 Prompt。这样团队越用越“懂你”而不是每次从零开始。3.2 团队二客服支持团队接待-检索-工单-回访客服团队看起来简单实际上是最考验“边界感”的团队。我的设定是四个角色并行协作接待助理、检索助理、工单助理、回访助理。用户 客服总机 提问后接待助理先做意图分类是咨询、投诉、还是售后问题。然后检索助理在飞书知识库和向量检索插件里找答案。检索命中后由接待助理组织回复语言检索未命中时接待助理必须明确回复“这个信息我需要人工确认”并转人工处理而不是硬编一个答案。工单助理则同步把所有咨询记录结构化写入工单表包括用户身份、问题归类、解决状态、是否需回访。回访助理是定时触发的每天下午六点它扫描工单表里标记为“已解决但未回访”的记录生成回访消息草稿由人工确认后发送。这个设计让我很省心因为很多售后问题其实第二天就能发现是否有复发迹象回访助理正好接住了这个时间点。我个人在这里踩过的最深的一个坑是客服团队必须开“知识库未命中转人工”的硬规则。有一次我图省事允许检索助理“基于常识尽量回答”结果它对一个特定产品的退改政策给出了完全错误的解释最后导致客户投诉。从那以后所有客服类 Agent 的 Prompt 里都加了同一句话“如果没有检索到明确依据必须回答不知道并转人工。”3.3 团队三数据分析团队取数-清洗-分析-可视化数据分析团队我分了四个角色取数助理、清洗助理、分析助理、可视化助理。取数助理绑定了数据库只读账号只允许执行SELECT查询连接配置里显式声明了read_onlytrue。这样做既方便又安全至少不会让 Agent 在“理解错需求”时把表给改了。清洗助理拿到原始数据后做去重、补全、格式统一并输出一份数据质量说明。分析助理负责找异常、算转化、做对比输出结论和置信度说明。最后一个可视化助理把结果转成图表描述和摘要文字生成飞书卡片推送到群里。整个流水线通过一个简单的工作流触发我先给 OpenClaw 配了一个data_pipeline流程指定任务必须按照“取数 → 清洗 → 分析 → 可视化”的顺序流转不允许跳步。有一次团队想赶时间直接让分析助理“接管原始表”被我拦住了。因为缺失清洗环节会导致数据口径混乱分析结果反而更不可信。这里有个实用技巧给分析助理的 Prompt 里加上一句“如果需要做出业务判断必须标注置信度”。比如“判断下周转化率会回升置信度中等依据是近 7 天趋势和节假日因素”。这样业务人员看结论的时候就不用对着数字猜了。可视化助理我用的是图表描述加表格摘要而不是直接生成图片因为生成图片依赖外部渲染服务会增加不稳定因素。飞书多维表格本身就能展示表格数据够用了。3.4 团队四研发辅助团队需求澄清-接口-代码审查-文档研发辅助团队的搭建思路和前三者不太一样它更像是给研发人员配的“影子同事”。角色包括需求澄清助理、接口设计助理、代码审查助理、文档助理。需求澄清助理的最大作用是“把模糊话说清楚”。研发群里有人丢一句“这个订单查询接口要加个筛选条件”它会自动追问筛选条件的具体字段、返回格式、权限范围、是否分页并生成一份需求确认单。接口设计助理基于确认单产出接口定义和字段说明。代码审查助理则接入了仓库只读权限可以拉取最近的 MR/PR 和变更文件从代码规范、潜在 bug、安全风险几个维度提审查意见。文档助理是这个团队里最被低估的角色。它会在需求确认后自动在飞书文档里生成一份接口说明并把文档链接回填到多维表格。以前团队最讨厌写文档现在文档助理推着大家把规范落实下去甚至不需要人的参与。这个团队我强烈建议不要让代码生成助理直接改代码。AI 生成的代码可以作为建议和 patch 提供给开发人员但合并分支、执行构建这些操作必须留给人。原因不用多说一旦 Agent 误操作把开发分支搞坏恢复的成本远高于它省下来的那点时间。协作边界明确研发辅助才有价值否则只是增加运维负担。3.5 团队五运营增长团队选题-排期-投放-复盘运营增长团队是五个团队里时效性最强的一个所以它的核心是“定时触发 人工选品”的半自动模式。这个团队包含选题发现助理、排期助理、投放文案助理、复盘助理。选题发现助理每天早上九点跑一次热点检索汇总热搜关键词和行业话题生成今日选题清单推送到运营群。排期助理负责把选题清单按渠道和时间排进多维表格标出优先级和负责人。投放文案助理能根据选定的选题快速生成 3 到 5 版不同口吻的投放文案。复盘助理每周日晚上跑一次数据回收对比各渠道的点击、转化、互动输出周报要点。关键设计是“人工选品”这个环节不能省。选题发现助理只负责“提供候选”不负责“决定发什么”。因为热点判断涉及品牌立场和业务目标这是目前 AI 还不太靠得住的地方。我在流程里加了一个状态字段候选选题进入表格后默认是“待人工确认”运营小伙伴点一个按钮确认后排期助理才会继续往下走。这个团队让我体会最深的是半自动比全自动更可靠。纯自动排期很容易出现内容不合时宜的情况比如节假日热点被漏掉、或者把负面事件相关议题排进了品牌推送。保留一个人工确认的“闸门”AI 负责把重复性工作压到最小人把精力放在最终决策上两全其美。3.6 跨团队协作如何让 5 个团队互相“喊话”搭建完五个团队后我发现它们还是“各干各的”于是加了一个跨团队协作机制让它们能互相发现、互相接力。实际实现的是一个“事件广播频道”当某个团队产出一个值得其他团队关注的结果时对应助理会把事件写入一张共享的“协作事件表”。其它团队如果订阅了这类事件就会收到一张带“接手”按钮的消息卡片。举一个真实跑通的例子数据分析团队在周报里发现某渠道转化率突然翻倍立刻把事件推给运营增长团队运营增长团队基于这条线索生成了一份追投文案由人工确认后投放。反过来内容产线团队发现有篇内容在小红书表现异常好就会触发事件让数据分析团队去拆解流量来源看是偶然因素还是可复制的路径。跨团队协作必须注意循环依赖问题A 触发 BB 又触发 A就会变成无限循环。我在 OpenClaw 的配置里给每个 Agent 设了max_iterations和事件去重机制。只有“协作事件表”里没有出现过的新事件才会被广播给其他团队同一事件不会重复触发两次。这样既保留了协作能力又避免了消息风暴。4. 实操中踩过的坑常见问题与排查清单4.1 事件回调不生效机器人“装聋”这是最容易踩的坑。现象是群里的 消息发过去了机器人毫无反应日志里干干净净。排查顺序我建议固定下来先看飞书开放平台的事件订阅列表确认im.message.receive_v1确实被添加了再看权限点im:message有没有给到应用然后核对加签配置OpenClaw 侧的verification_token和encrypt_key必须与开放平台完全一致最后看长连接有没有保活。如果用的是 WebSocket 长连接模式记得在部署环境里配置自动重启否则断线后不会自动恢复。有一次我在本地调试一切正常部署到服务器后怎么都不通。查到最后发现是服务器安全组把长连接需要访问的地址给屏蔽了。这种问题最能体现“先分端排查再怀疑程序逻辑”的重要性。4.2 Agent 上下文串场与消息风暴五个团队跑起来之后最让人头疼的问题是“串场”。内容产线团队的回答里突然冒出数据分析团队的记忆片段或者客服团队用内容团队的风格说话。根因九成是会话隔离没做好。OpenClaw 里每个 Agent 的 session 需要有明确的唯一键我用的格式是app_id 群 ID 会话主题。如果只按群 ID 隔离同一个群里不同主题的会话还是会串如果只按用户 ID 隔离多个用户在同一个群里的对话也会混。必须每个维度都考虑进去。消息风暴则是另一个问题。两个团队互相触发之后群里消息像弹幕一样刷屏。我加了硬性保险任何 Agent 的单任务最大迭代次数设为 8超过就停止并主动询问“任务过于复杂是否拆分为多个子任务”。事件去重机制也要开着同一事件 ID 只允许被处理一次。4.3 把结果沉淀到卡片与多维表格刚开始我把结果全发成纯文本消息后来发现一个问题人很难从聊天记录里回溯“上个星期这个需求是怎么处理的”。后来我养成了一个习惯——所有团队的产出都必须落库到多维表格并在群里推一张结构化的消息卡片。卡片的好处是带有操作按钮。比如客服团队生成的回访消息草稿卡片上有“一键确认发送”和“人工修改”两个按钮提交后按钮事件回调会触发回访助理重新生成消息。交互闭环一下就完整了。多维表格则是长期记忆的载体人后去找历史记录不是去翻聊天记录而是直接筛选表格。这里有个细节卡片的 JSON 模板里不要写死内容要用变量填充。比如{ msg_type: interactive, card: { header: { title: {tag: plain_text, content: 内容归档通知 — {{team_name}}}, template_color: {{status_color}} }, elements: [ {tag: div, text: {tag: lark_md, content: **标题** {{title}}\n**状态** {{status}}}} ] } }这样同一个模板可以在五个团队里复用只是传入的变量不同。维护成本低视觉呈现也统一。4.4 限流与超时处理飞书开放接口有频控限制如果是小团队应用每秒调用次数并不高。初期我把所有 Agent 的中间步骤都做成同步消息推送结果任务一多就触发限流机器人回复变得断断续续。我的解决办法是“异步化”对于耗时较长的任务机器人收到指令后先在群里推一张“任务处理中稍后完成后会推送结果”的卡片然后把任务丢进内存队列/Redis 队列里异步执行执行完再通过 Webhook 主动推送结果。大模型调用几十秒是常态如果同步等待飞书侧的请求早就超时了。先给用户一个“收到”的反馈体验会好很多。重试也要考虑退避策略。对于 429 限流错误指数退避比固定间隔重试更友好对于 5xx 错误可以快速重试两三次再放弃。日志里一定要把错误码和请求标识记录下来后面排查和优化才有依据。5. 只有真正跑起来才会留意到的几个经验写到最后聊几点只有真正跑起来才会明白的东西。第一“可协作”的关键不是 Agent 的数量而是任务状态机。我一开始以为多定义几个 Agent它们自己就会像团队一样配合后来发现那只是各自为战。真正让协作成立的是每个任务都有明确的状态比如待处理 → 进行中 → 已完成 → 待人工确认团队之间的交接就是状态变更加事件通知。把这个状态模型搭好再加多少 Agent 都是顺理成章的事。第二先从一条业务线跑通再铺开五条线。我当时第一个跑通的是内容产线从需求到归档走完整条链路后才复制这套模式到其他四条线。直接一把梭五个团队遇到问题你会很难定位是哪个环节出的错。内容产线最适合当第一个试点因为它流程清晰、容错率高、效果肉眼可见。第三给 AI 助理画清楚“知识边界”比增强能力更重要。客服团队不许编造分析团队要标置信度运营团队不得自动排期——这些限制一开始就要写进 Prompt而不是等出了问题再补救。AI 助理的价值不是替你做所有决定而是帮你把确定的工作流压缩到秒级完成然后在不确定的地方停下来找你确认。最后分享一个小技巧在飞书群里给每个团队的机器人名字加上统一的团队前缀比如“内容产线·写手”“数据团队·取数”“运营增长·选题”。团队成员一看到前缀就知道这个回答来自哪条流水线不用点开资料卡去猜。五个团队、十几个助理靠这一条小规则就把认知负担压下来不少。希望这份复盘能帮那些想用 Agent 编排工具解放重复劳动的团队少走点弯路。先跑起来再慢慢调整角色分工、Prompt 和协作边界——你会发现AI 助理团队这个东西真的是越用越顺手。