企业官网建设流程全解析

1. OpenClaw 多 Agent 在飞书群组协作开发：从踩坑到跑通

OpenClaw 多 Agent 协作开发，简单说就是让一群各有分工的 AI 角色（业务、产品、项目经理、架构、开发、测试）待在同一个飞书群里，你 @ 一下项目经理，它就能按流程把需求拆下去、把任务派给对应 Agent，最后把代码和测试结果交回来。这套玩法最适合两类人：一是想用 AI 把一个小软件从需求到测试全流程跑一遍的独立开发者，二是团队里想先搭个"AI 协作流水线"试水、再决定要不要接真实项目的技术负责人。我这次的目标很明确：6 个 Agent 组成一家叫 Band 的"软件公司"，在飞书群BandCompany里协作开发一个安卓 App。

真正卡住我的不是 Agent 人格怎么写，而是三件事：allowAgents没配导致 Agent 之间互相调不动、Agent 名字带大写导致调用失败、以及飞书群 ID 没加进白名单导致机器人根本不回话。这篇就把allowAgents配置骨架、飞书群接入验证、以及统一模型通道的接法一次讲清楚，你照着改就能跑通调用链路。

2. 先解决模型调用：用 TaoToken 统一 Key 给所有 Agent 供能

多 Agent 协作最容易被忽略的成本是"每个 Agent 一套模型配置"。6 个 Agent 如果各自填不同的 Key、不同的 base_url，后面排查问题会疯掉。我的做法是全部走同一个 API 通道，所有 Agent 共用一套 Key，出问题只看一个地方。

TaoToken 在这里扮演的就是"统一模型入口"的角色：你申请一个 Key，配一个 base_url，6 个 Agent 全部指向它。这样无论是主会话、子 Agent 还是飞书机器人触发的调用，走的都是同一条链路，日志和额度也好统一看。

具体操作分两步。第一步，去控制台创建 API Key：

• 控制台入口：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
• Key 管理页：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite

第二步，把 Key 和 base_url 写进 OpenClaw 的模型配置。base_url 用https://taotoken.net/api，注意这个地址后面不要加 UTM 参数，直接填干净的 API 根路径即可。配置长这样：

{ "models": { "providers": { "taotoken": { "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的Key", "api": "openai-completions", "models": [ { "id": "claude-sonnet-4-5", "name": "Claude Sonnet 4.5" } ] } } } }

这里api字段填openai-completions是因为大多数兼容层都按 OpenAI 的 completions 协议走，OpenClaw 侧不用改代码。配好之后，主会话和所有子 Agent 都会继承这个 provider，你不需要在每个 Agent 的agents.list里重复写 Key。

提示：如果你后面要接 Claude Code 这类编码工具，模型对话和编码计划可以分开看。模型对话入口在 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite ，长期编码/Agent 场景更适合用 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。

3. allowAgents 配置骨架：让 6 个 Agent 能互相调用

这是全文最关键的一段。OpenClaw 里 Agent 之间能不能互相调用，取决于agents.list.subagent.allowAgents。默认情况下子 Agent 调用是受限的，你不显式加白名单，就会出现"调用别的 Agent 失败，然后它自己干起来了"的尴尬场面——我实测就遇到过，业务 Agent 调不动产品 Agent，结果它自己把产品需求也写了，上下文直接污染。

先给一份可复制的骨架。6 个 Agent 全部用小写 id，这是硬性要求，后面第 5 节会讲为什么：

{ "agents": { "list": [ { "id": "bandbusiness", "name": "业务负责人", "subagents": { "allowAgents": [ "bandprojectmgr", "bandproductmgr", "bandsysdesign", "bandcoder", "bandtester" ] } }, { "id": "bandprojectmgr", "name": "项目经理", "subagents": { "allowAgents": [ "bandbusiness", "bandproductmgr", "bandsysdesign", "bandcoder", "bandtester" ] } }, { "id": "bandproductmgr", "name": "产品经理", "subagents": { "allowAgents": [ "bandprojectmgr", "bandsysdesign" ] } }, { "id": "bandsysdesign", "name": "系统设计师", "subagents": { "allowAgents": [ "bandprojectmgr", "bandcoder" ] } }, { "id": "bandcoder", "name": "开发人员", "subagents": { "allowAgents": [ "bandprojectmgr", "bandtester" ] } }, { "id": "bandtester", "name": "测试人员", "subagents": { "allowAgents": [ "bandprojectmgr", "bandcoder" ] } } ] } }

几个设计要点值得说清楚。项目经理bandprojectmgr的allowAgents里放了所有人，因为它是协调中枢，需要能触达每个角色；业务负责人bandbusiness也放了所有人，方便它把需求直接抛给对应环节。而产品、设计、开发、测试这几个执行角色，我只让它们能回调项目经理和上下游直接对接方，避免它们越权去指挥别的 Agent。

注意：allowAgents是"允许调用"的白名单，不是"自动调用"的开关。你还要在提示词或工作流里明确告诉 Agent 什么时候该调谁，否则它可能还是自己硬写。

另外建议给每个 Agent 加一句工作边界约束，比如在bandcoder的系统提示里写"你只负责编码，不产出产品需求文档，遇到需求不明确时调用 bandprojectmgr 协调"。这一句能显著减少"自己干起来"的情况。

4. 飞书群组接入：groupPolicy、oc_id 与 @ 触发

Agent 配好了，接下来要让他们在飞书群里能被你指挥。飞书建群和微信不一样，群是独立功能，每个群有一个以oc开头的群 ID。你要做的第一件事是拿到这个oc_id，然后加进白名单。

我的groupPolicy设的是allowlist，意思是只有白名单里的群才允许机器人响应。配置结构如下：

{ "channels": { "feishu": { "enabled": true, "domain": "feishu", "groupPolicy": "allowlist", "accounts": { "main": { "appId": "cli_xxx", "appSecret": "xxx", "botName": "主助手", "groupAllowFrom": [ "oc_你的群ID" ] } }, "dmPolicy": "pairing" } }, "messages": { "ackReactionScope": "group-mentions" } }

这里有两个坑。第一个是groupAllowFrom里要填的是群 ID（oc_开头），不是用户 ID（ou_开头）。我一开始填错了，机器人死活不回话。第二个是ackReactionScope设成group-mentions后，机器人在群里必须被显式 @ 才会回应，这是设计如此，不是 bug。所以你在群里发消息时，格式是@主助手 帮我推进一下项目。

验证接入是否成功，最简单的办法是在群里 @ 一下主助手，看它有没有回执反应。如果没反应，按这个顺序查：群 ID 是否填对、groupPolicy是否和你的预期一致、机器人是否被拉进了这个群、以及ackReactionScope是否要求 @。

在 Gateway 界面里，你能看到所有会话。飞书里单独找机器人对话是一类会话，群里 @ 机器人的对话是另一类，机器人调用其他 Agent 产生的子对话（Subagent）又是单独一类。不活跃的会话在聊天界面会被隐藏，但在会话列表里能找到，而且命名更规整，排查问题时建议直接看会话列表。

5. 常见错误排查：大小写、初始化状态与调用失败

这一节把我踩过的坑集中列一下，你对照着查能省不少时间。

错误一：Agent 名字带大写导致互相调用失败。这是最隐蔽的一个。我最初把 Agent 命名为BandBusiness、BandProductMgr这种驼峰形式，结果 Agent 之间调用一直失败。改成全小写bandbusiness、bandproductmgr之后就正常了。这看起来像隐藏 bug，但既然实测有效，建议你从一开始就全用小写，别给自己找麻烦。改的时候注意，allowAgents里的引用、工作流里的调用规则、提示词里提到的 Agent 名，全都要同步改成小写。我是让 OpenClaw 自己批量改的，你也可以手动过一遍。

错误二：通过主会话初始化后，Agent 还认为自己没被初始化。这个直接跟 main 会话沟通，让它修复就行。OpenClaw 会重新建立 workspace 和基础文件。公共文件夹默认在~/.openclaw/band-company-workspace，你可以去那里确认文件是否生成。

错误三：调用别的 Agent 失败后，它自己干起来了。这是allowAgents没配的典型症状。加上白名单后如果还失败，先检查大小写，再检查工作流里的调用规则是否同步更新。另外强烈建议给每个 Agent 加工作内容限制，不做自己不专业的事。受上下文窗口大小、上下文污染和系统提示词的专业要求影响，每一项工作最好拆给不同 Agent 执行，别让一个 Agent 从头包到尾。

错误四：飞书群里 @ 了机器人但没反应。回到第 4 节，检查groupAllowFrom填的是不是oc_开头的群 ID，以及ackReactionScope是否要求 @。

排查顺序建议固定成：先看模型通道通不通（用模型对话入口单独测一次），再看allowAgents白名单，再看飞书群白名单，最后看提示词里的调用规则。这样能快速定位是模型层、Agent 层还是渠道层的问题。

6. 验证调用链路与后续接入

配置改完，怎么确认整条链路真的通了？我的验证步骤是这样的：先在飞书群BandCompany里 @ 业务负责人bandbusiness，发一条需求，比如"做一个记账 App 的首页"。然后观察 Gateway 会话列表，应该能看到业务 Agent 发起了一个子对话去调用bandproductmgr。如果子对话正常产生，说明allowAgents和模型通道都通了。

接着 @ 项目经理bandprojectmgr问进展，它会按你之前建立的工作流，把需求、产品设计、系统设计、开发、测试串起来。我实测下来，驱动项目经理基本能把需求、设计、开发工作跑完。唯一卡住的是安卓 App 在 Ubuntu 环境下的构建，这个属于环境问题，跟 Agent 协作本身无关，我准备单独研究。

如果你在接入过程中遇到 Key 或通道问题，直接去 API Keys 页面重新生成一个：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite ，里面有 base_url 和协议字段的说明。想先单独验证模型能不能通，用模型对话页面发一条消息最快：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。如果你打算长期跑编码和 Agent 任务，Coding Plan 会更合适：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。

跑通这套之后，我准备再多搞些 Agent，比如六顶思考帽群组、头脑风暴群组、项目方案咨询群组。核心经验就一条：allowAgents白名单 + 全小写命名 + 统一模型通道，这三件事做对，多 Agent 协作就稳了一大半。