企业官网建设流程全解析

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_docs

memory: 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会问清楚是内容主题、发布时间还是人员分配，然后它会把任务转给内容运营C，C产出一版排期表之后，再把文档 @ 给相关同事。

协作能否跑通，核心就看交接节点写没写干净。我见过很多团队配置了多个助理，最后变成“各说各话”——助理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 个助理立起来，跑两个星期，再根据团队的真实使用反馈调整角色职责，这比一开始就设计完美架构靠谱得多。