1. 为什么需要“一群”AI助理而不是一个先聊个现象。很多人第一次接触 AI 助理的时候习惯把它当成一个“万能机器人”问什么答什么今天让它查资料明天让它写周报后天又让它管日程。一开始确实新鲜用上一段时间就会发现单机版的助理有几个很难受的瓶颈。第一一个上下文里塞了太多职责角色混乱。同一个助理既要做代码审查又要做活动策划还要回复用户投诉它的系统提示词会越来越长最后变成一个什么都懂一点、什么都不精的“万金油”。第二多人协同时无法分权。比如团队里有运营、技术、销售所有人都拉同一个助理进群助理不知道该听谁的也不知道哪些信息该对谁说。第三状态管理基本为0。我让它跟进项目 A 的进度转头又让它处理项目 B它经常把两件事搅在一起甚至忘掉之前的约定。我身边不少朋友最后的选择是把 AI 助理从“一个机器人”拆成“一群机器人”每个机器人只干一类活彼此之间还能互相交接。这个思路并不新鲜就像公司里没人指望一个员工身兼 CEO、设计师、财务三个职位一样AI 助理也应该有分工。问题只是怎么把这一群机器人高效地组织起来让它们共用一个聊天入口用户不需要装五个 App也不需要记住五个网址。这次我用的方案是 OpenClaw 飞书。OpenClaw 作为助理框架负责把各个“助理实例”跑起来飞书负责当统一入口和消息总线。最后搭出来的效果是团队一个群聊里躺着5个 AI 助理用户 谁就找谁干活助理之间也能在一个共享频道里互相传递任务摘要。这篇文章把整套搭建过程、角色设计、消息路由和踩过的坑都写清楚想直接照着做的朋友可以少走不少弯路。2. 搭建前的整体架构OpenClaw 和飞书各自扮演什么角色动手之前先花几分钟把架构讲明白。很多人一上来就急着配环境结果配完发现根本不知道数据从哪儿流到哪儿出了问题也不知道去哪个环节排查。2.1 OpenClaw 不是“一个机器人”而是一个机器人运行环境OpenClaw 这类框架的核心能力是让每个 AI 助理成为一个可独立配置的实例。每个实例有自己的名字、人设、使用哪个模型、挂在哪个 IM 平台、能调用哪些工具以及自己的长期记忆存储。你可以把它理解成“一个能同时养很多条电子宠物鱼的鱼缸”每条鱼吃什么、游到哪个角落全部独立配置但共用同一套水质管理系统。这个设计解决了我前面说的“职责混乱”问题。运营助理的提示词里不需要写任何代码规范技术助理的提示词里也不需要管内容排期。各实例的上下文互相隔离模型也不需要在多个角色之间反复横跳回答质量明显比单一大助理稳定得多。我这次搭的5个助理实例分别是助理A项目统筹、助理B技术开发、助理C内容运营、助理D数据分析、助理E会议记录。取名没有特别复杂就是按职责来因为后面在飞书群里 的时候名字越直观越好认。2.2 飞书当消息中枢的逻辑飞书在这套架构里不是“锦上添花”而是唯一的用户交互层。用户不直接接触 OpenClaw 的 API也不关心后端跑的是什么进程他们只需要知道“在飞书群里 助理A 就能汇报进度 助理C 就能安排推文”就够了。选飞书而不是其他 IM主要出于三个考虑事件订阅机制够灵活机器人能接收到消息、回复消息、也能主动往群里推送群聊和话题线程的原生支持很完善适合多个助理共用一个“大群 独立话题”的协作场景国内团队用它的比例高不需要额外培养用户习惯。为了便于理解整套消息流可以简化为用户在飞书群里发消息 → 飞书事件订阅推送回调给 OpenClaw 的网关 → 网关根据 的对象选择对应助理实例 → 助理处理后把回复内容通过 API 发回飞书群。后面所有配置都是围绕这条链路展开的。2.3 环境准备清单一台能长期在线的服务器或者本机开发调试阶段用自己的电脑也行跑通后建议换到常驻机器因为飞书回调要求你的网关能公网可达OpenClaw 运行环境Python 3.10及以上牵扯到本地记忆存储的话建议配好数据库一个飞书开发者账号企业自建应用权限即可各助理实例背后的大模型 API Key可以都用同一个也可以按角色分配不同模型这套清单看起来简单但有一个容易忽略的细节回调地址必须是公网可访问的 HTTPS 地址。如果你在本地调试飞书根本推不过来事件因为它的服务器访问不到你的 localhost。我用内网穿透工具直接把本机的 8080 端口映射出去拿到一个临时 HTTPS 域名才开始正常收到消息后面正式部署时换成了服务器上的域名。3. 飞书自建应用从零到能收发消息的完整步骤飞书这边的配置是整个链路里最容易出诡异问题的一环很多报错信息你不去搜根本不知道它想表达什么。我从头到尾走了一遍把关键步骤和坑都列出来。3.1 创建自建应用与权限配置登录飞书开放平台创建一个“企业自建应用”。创建时只填应用名称和描述就行我起的应用名就叫“AI 助理团队”描述里简单写了各助理的职责范围。创建完进入“权限管理”页面这个环节是最容易漏的。我不止一次遇到“消息发不出去”“收不到回调”的问题最后发现是没有启用对应权限。需要开通的权限项包括im:message获取与发送单聊/群聊消息im:message.group_at接收群聊中 机器人的消息im:chat读取群信息contact:user.base读取用户基本信息用来区分是谁发的消息这里有一个经验之谈不要在权限列表里凭感觉勾选飞书的权限分得非常细“读消息”和“读取群聊中的消息”是两个完全不同的权限漏一个都不行。配完之后最好手动触发一次事件看看到底是“没收到”还是“收到了但被过滤了”。3.2 事件订阅验证 URL 与回调配置这一步很多人卡了很久。飞书要求你在事件订阅配置里填一个“请求地址”它会在保存时向这个地址发送一个 challenge 验证请求你的服务端必须正确响应才能通过验证。OpenClaw 如果带了飞书适配层通常会把这个验证逻辑封装好。你需要做的就是在配置里填好回调地址https://你的域名/webhook/feishu这种路径然后保存。如果保存时报“URL 验证失败”大概率不是代码问题而是你那个地址在公网上根本访问不到先用 curl 在服务器上确认一下能通再回头排查别的。事件类型方面我订阅了这几个im.message.receive_v1收到消息im.message.message_read_v1消息已读用于后续做已读回执group.member.added有人把机器人拉进群自动发欢迎语3.3 发消息时的身份与租户凭证问题配置好凭证之后OpenClaw 要用tenant_access_token去调用发消息接口而不能用user_access_token。区别在于user_access_token代表某个真实用户的身份有时候会被权限策略限制tenant_access_token代表应用本身适合机器人主动推送消息。封装好的框架一般会自动获取和缓存 token但如果你自己写脚本调试记得 token 有有效期别图省事硬编码。我实际调试时还遇到一个很隐蔽的问题应用发布后权限不会自动生效。飞书的权限改动需要“创建版本并发布”发布之后才真正生效。我在权限管理里加了字段看文档说“已开通”但回调里始终拿不到用户详情最后发现是压根没发布新版本旧版本的权限还是原来那套。这个环节排完之后的效果是你在飞书群里 机器人它会在几秒钟内回复一条“收到”。这个时候说明链路已经打通接下来要做的就是让它具备干活的能力。4. 5个助理的角色矩阵提示词分工与协作边界链路打通之后就进入真正有意思的部分给这5个助理写“岗位说明书”。这一步决定了团队好不好用。我当时的想法是每个角色必须有明确的职责边界、触发条件和交接格式否则就会出现“助理A 抢了助理B 的活”这种场景。4.1 角色设计背后的思考扮演项目统筹的助理A主要接收项目相关消息里程碑、风险、任务指派扮演技术开发的助理B接收代码和部署相关请求它需要访问一些内部文档扮演内容运营的助理C负责排期、选题、文案扮演数据分析的助理D处理指标查询和报表解读扮演会议记录的助理E专门整理会议纪要并且在会议结束后把待办事项发给对应负责人。为什么是这5个而不是3个或者10个因为团队协作的常见场景就这几类角色太少会出现“什么都往技术助理里塞”的情况角色太多则会因为消息路由不清晰出现“不知道 谁”的局面。5个在我这个场景里刚好平衡。有一点需要强调角色之间边界不清AI 再聪明也白搭。比如你同时给助理A和助理C配置了“生成项目周报”的能力那用户 谁都能生成周报分工具的意义就没了。我在提示词里会给每个角色加上“拒绝清单”遇到不属于自己职责范围的事项不要硬答直接说明应该找哪位同事。4.2 提示词模板一个可以直接改用的例子以内容运营助理C的提示词为例我写的是你是内容运营助理C隶属于 AI 助理团队。 你的专属职责内容选题建议、推文大纲、标题优化、排期表更新。 你只能处理与内容运营相关的事务以下情况请直接拒绝并引导对方去找对应同事 - 对方让你改代码、查服务器日志 → 引导其 技术开发 - 对方让你生成数据报表 → 引导其 数据分析 - 对方让你安排会议 → 引导其 会议记录 与同事交接时使用统一的交接格式 【交接给X】【任务编号】【上下文摘要】【请求事项】 例如【交接给数据分析D】【任务编号T-2025-011】【用户需要上周文章阅读量趋势】【请生成按渠道拆分的阅读量同比表】这个“交接格式”非常重要。因为单个助理的上下文是隔离的如果想实现“运营助理收集需求数据助理出报表”这条链路就必须有一个显性的交接协议。格式越固定后续做状态解析越方便。4.3 各助理的模型与工具配置在这个例子里助理A和助理B的上下文较长推理逻辑要求高所以分配给上下文窗口更大的模型助理C和会议记录E 的日常任务相对轻量用更快的模型即可数据分析D 需要处理表格给它加了文件读取工具。OpenClaw 里每个实例的配置类似这样以示意配置为例agents: 项目统筹: model: fast-context-large memory: true system_prompt_file: prompts/coordinator.md tools: - todo_list - group_notify 技术开发: model: deep-reasoning memory: true system_prompt_file: prompts/developer.md tools: - shell - repo_docsmemory: true这行建议所有助理都打开它让每个助理能记住用户在群里聊过的历史避免每次对话都像第一次见面一样。数据可以存在 SQLite 里量不大成本几乎可以忽略。5. 协作链路的关键消息路由与交接协议飞书这边有一个天然优势——它允许在一个群里多个机器人共存。这意味着5个助理可以都拉进同一个群用户不需要切换聊天窗口。但这同时带来一个挑战**一条消息发进来怎么知道该让哪个助理处理**我在实际搭的时候试过几种方案最后保留了三层规则。5.1 第一层 指定路由最直接的方式是让用户主动 。飞书的消息回调里会带上 mention 信息说明这条消息 了谁。OpenClaw 的飞书适配层通常会解析这个字段如果消息里明确 了“数据分析D”就直接把消息交给助理D处理。这个方案的优点是简单可靠缺点是需要用户记忆每个助理叫什么。所以我在每个助理的欢迎语里都会写一句自我介绍比如助理A进群时自动发“我是项目统筹A负责里程碑、风险、任务协调。需要协作请 我我会把任务分配给对应同事。”5.2 第二层关键词与群话题兜底用户不总是记得 谁尤其刚上手的时候。我用关键词做了一层兜底路由消息包含“报表”“环比”“指标”等词自动转给数据分析D包含“排期”“标题”“选题”等词自动转给内容运营C。关键词表的准确率没必要追求百分之百因为还有第三层兜底。群话题也是一个好用的功能不同类型的任务在不同话题里讨论我在话题标题里带上对应助理的名字比如“【技术开发】服务部署问题”然后让 OpenClaw 监听并匹配话题名。这样即使没 对只要在正确的话题里发也能送到合适的助理手上。5.3 第三层人工兜底与历史任务查询三层规则之外我在 OpenClaw 里加了一个“未知意图处理”的逻辑。如果消息没有触发任何路由规则OpenClaw 默认交给助理A项目统筹处理助理A会追问用户需求做一次粗分诊再决定是自己处理还是转给其他助理。这才是真正的协作不是5个助理各干各的而是有一个“总调度”负责兜底和分发。你可以在飞书群里体验到一个很自然的流程先在群里说一句“帮我安排下周的推文排期”助理A会问清楚是内容主题、发布时间还是人员分配然后它会把任务转给内容运营CC产出一版排期表之后再把文档 给相关同事。协作能否跑通核心就看交接节点写没写干净。我见过很多团队配置了多个助理最后变成“各说各话”——助理A让用户去找助理C但助理C完全不知道之前聊了什么。这是最掉链子的场景可一旦你把【交接给X】【上下文摘要】这些字段规范化助理之间传递信息的能力会明显提升。6. 协同之外的另一个重点统一知识库与权限隔离多助理跑起来之后比“谁能干活”更让人头疼的问题是“谁可以知道什么”。有些信息适合让所有助理看到比如产品使用文档有些则必须隔离比如机密配置信息。如果用一套知识库喂给所有助理等于把权限问题全部抹平了这在团队协作里是很危险的。6.1 知识库按角色分区存放我用的方案是给每个助理指定独立的文档目录。项目统筹A 的文档目录里放的是团队目标、里程碑计划技术开发B 的目录里放的是接口文档、部署手册内容运营C 只能访问运营素材库数据分析D 能访问指标定义文档会议记录E 则对接会议模板和日历权限。OpenClaw 的配置里可以给每个实例指定不同的知识库路径内容索引也是分开构建的。这样技术开发B 被问到“排期怎么定的”它不会因为检索到运营文档而乱答因为它根本没有那个索引。6.2 通过群成员可见性控制范围飞书这边也做了第二层隔离不是所有人都在同一个群里。我搭了一个“核心协作大群”里面5个助理都在另外按项目性质建了小群只拉入相关的两三个助理。比如某个项目群只放进项目统筹A和技术开发B这样这个群里的对话天然不会被内容运营C看到信息流更干净也避免助理在无关话题里插嘴。飞书支持应用在某个群内使用前提是机器人被拉进了那个群。这就带来一个很自然的现象哪个助理在哪个群由群管理员决定而不是由 OpenClaw 决定。权限管理因此在两个系统里各做一半飞书管“谁能跟这个助理对话”OpenClaw管“助理能读哪些知识库”。这套组合目前我用下来比较踏实机密信息不会因为“另一个助理问了”而泄露。6.3 敏感操作的审批机制还有一个值得记录的点不是所有操作助理都能自行落地。我在 OpenClaw 里给部分工具加了“需人工审批”的标记比如发送对外消息、执行数据库写操作、删除文件。用户 技术开发B“在测试环境跑一条删表 SQL”B 不会直接执行而是生成一条待办事项发给指定审核人员等审核通过后由人工抽验后才放行。有人可能觉得这违背了“自动化”的初衷但团队落地 AI 助理最怕的就是失控。先有护栏再谈效率。等运行一段时间,大家信任度上来了再逐步放开某些低风险工具的自动执行权限这个节奏比较稳妥。7. 实际运行中的典型故障与排查链路这节写排错。多助理跑在真实环境里和 Demo 完全不一样很多问题不是你写代码能预判出来的必须在日志里一行一行看。我把遇到过的三类比较典型的故障整理出来原因、排查链路和修复方案都说清楚。7.1 事件回调超时导致消息处理失败症状用户 助理之后飞书群里没有任何反应后台日志里也看不到消息过来。原因飞书的事件订阅对回调响应有时间限制。如果你的 OpenClaw 网关在处理消息前先去做了一些耗时操作比如初始化模型、加载知识库索引、拉取远程文档超过了允许的时间窗口飞书会判定回调失败并反复重试最终事件被丢弃。排查链路先看 OpenClaw 的访问日志里有没有收到飞书的 POST 请求如果收到了看返回的状态码和响应体如果没收到多半是回调地址公网不通或者事件订阅配置不对。我当时的问题就是模型冷启动耗时太长处理请求前先加载了一个几百 MB 的本地索引导致网关没办法快速返回 200。解决方案把全局初始化和消息处理分开网关先回 200再用后台异步任务处理消息逻辑。这套改完之后哪怕模型生成回复需要 20 秒飞书也不会因为超时重试了因为回调接口本身永远是秒回的。7.2 多个助理在同一个群里“抢答”症状有人发消息没有 任何助理结果技术开发B和内容运营C同时回复了一个是技术建议一个是文案脑暴整个群乱成一锅粥。原因关键词路由配置了不只一个助理命中同一句话。比如消息里同时有“部署”和“发布计划”B 和 C 都会命中自己的关键词表而 OpenClaw 默认允许并发处理就出现了两个助理同时回复。排查链路翻日志看两条回复各自的触发规则是什么发现自己配的关键词存在交叉再检查路由优先级配置之前没有设明确优先级。解决方案一是给关键词表按优先级排序命中高优先级后直接短路不再向低优先级路由分发二是开启“单条消息至多一个助理响应”的模式。这个模式引进来之后“抢答”问题基本绝迹。7.3 长短时记忆串台症状内容运营C 在给“项目X”写推广文案时忽然提到了之前技术开发B 查到的服务器配置参数看起来非常突兀。原因两个助理原本是隔离的但我在配置记忆系统时图省事让它们共用了同一个向量数据库集合。查询语义相似的文本时C 检索到了 B 的记录然后当成自己的知识用了。排查链路去向量数据库里看 C 的检索记录发现返回的文档里有 B 的索引条目随后检查知识库配置确认共享集合的问题。解决方案为每个助理创建独立的记忆集合或者加标签字段检索时强制加上agent_id过滤条件。改完之后再做一次交叉提问测试确保上下文完全隔离。这类坑总结下来就一句话多助理真正难的不是让每个助理变聪明而是不让它们互相污染。一旦状态、知识库、记忆开始混用协作团队会退化成一个精神分裂的大模型效果比单助理还差。8. 可扩展的方向与最后的实战感受这套“5 个助理团队”的架子搭完之后我身边不少同事已经直接照搬进自己的内部项目里。除了跑通那 5 个基础角色我还有几个后续优化思路写出来供参考。第一个思路是加“助理间会议机制”。现在助理之间的协作主要靠交接格式但有些任务不是单线交接能解决的比如运营策划需要技术评估可行性。下一步我想在 OpenClaw 里设计一个简单的“调度频道”项目统筹A 把任务描述发到一个内部频道技术开发B和内容运营C 分别异步回复意见A 汇总后给出结论。相当于把真实团队的异步讨论机制复制到助理之间而不是只靠格式化的交接字段。第二个思路是给每个助理增加“对外动作”的粒度控制。现在助理能触达的外部系统还比较有限比如数据分析D 能读 CSV 文件但还不能直接查询数据库技术开发B 能读部署文档但没有实际操作服务器的权限。下一步会逐步接入只读数据库查询和测试环境的基础运维操作权限低风险动作走自动化高风险动作仍保留人工审批。第三个思路是想办法降低路由配置的维护成本。现在关键词表是手工维护的过一段时间角色职责变化关键词也要跟着改。长期来看可以考虑在每个助理处理完消息后自动记录一个“任务类型标签”用历史数据反向优化路由规则让系统学出来的路由比手写关键词表更接近真实使用习惯。最后聊几句实际使用的体会。整套系统从配通到稳定运行中间经历了几轮明显的调整最大的变化是心态不用追求“一个模型干所有事”把任务拆给多个角色即使每个角色的模型不是最强的整体效果也好过一个大而全的模型。另外就是“路由规则要尽量让用户感知不到”。用户不需要了解关键词表、优先级、知识库索引这些底层设施他们只管在群里 一个名字事情办完这就是一个合格助理团队的标准。如果你已经有一个正在用的 OpenClaw 实例加一个飞书群里的助理成员只需要几分钟如果是零基础从申请飞书自建应用到第一句消息跑通我实测一个下午足够。照着文中的角色矩阵和交接格式先把 5 个助理立起来跑两个星期再根据团队的真实使用反馈调整角色职责这比一开始就设计完美架构靠谱得多。