企业官网建设流程全解析

1. openclaw 多 agent 飞书群管理到底解决什么问题

openclaw 多 agent 飞书群管理，本质上是把「一个机器人干所有事」拆成「多个机器人各管一摊」，再让飞书群里的消息按角色自动路由到对应 agent。你可以把它理解成一个微型团队：main 负责接待和初筛，manager 负责拆任务和调度，writer 负责产出内容，每个角色背后挂着不同的模型和工具权限。适合谁？适合已经在用 openclaw 接飞书、但发现单 agent 回复又慢又乱、权限还收不住的团队。

我试过的场景是这样的：一个飞书群里同时拉了三个机器人，用户 @ 谁，谁才回；不 @ 的时候，群消息按 allowlist 策略决定进不进。听起来简单，但真正卡人的地方在于——机器人加进群了，@ 了没反应。这不是飞书的问题，是 openclaw 的visibleReplies默认值在群聊里把普通文本回复静默抑制了，只有显式调用 message 工具发的内容才会显示。这个坑我在配置时踩了整整一个下午。

所以这篇不聊虚的，直接给你可复制的openclaw.json片段：从群组 ID 获取、agent 工具权限、群聊准入策略、bindings 路由，到visibleReplies修正，一条链路走通。同时把模型调用统一收口到 TaoToken 的 API 通道，一个 Key 管多个 agent 的模型请求，省得每个 agent 配一套密钥。下面按「先建群 → 再配 agent → 再联调 → 再排障」的顺序来。

2. TaoToken 统一 Key 接入：一个通道管住多 agent 模型请求

多 agent 最烦的是什么？每个 agent 挂不同模型，DeepSeek 一个 Key、GLM 一个 Key、SenseNova 又一个 Key，密钥散落在配置文件里，轮换的时候要改好几处。TaoToken 的思路是把这些模型请求统一走一个 API 通道，Base URL 指向https://taotoken.net/api，Key 用同一个，模型 ID 在 agent 配置里区分就行。

具体怎么接？openclaw 的模型配置在agents.defaults.models里，每个模型用alias起个别名，agent 的model字段引用这个别名。你要做的是把模型的 provider 指向 TaoToken 的兼容端点。假设你已经拿到了 Key，先确认通道能通：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek/deepseek-v4-flash", "messages": [{"role": "user", "content": "ping"}] }'

返回里能看到choices数组就说明通道没问题。这一步很关键，因为后面 agent 报错reading choices基本都是这里没通。Key 的获取在控制台的 API Keys 页面，模型对话页面可以先手动试几个模型 ID，确认哪些能用再写进配置。

注意：TaoToken 是 API 通道，不是编辑器替代品，也不做任何网络层的事情。你本地能正常访问taotoken.net就能用，配置里只填 Base URL 和 Key。

接入完成后，agents.defaults.models里三个模型都指向同一个通道，只是 model ID 不同：

"models": { "deepseek/deepseek-v4-flash": { "alias": "DeepSeek" }, "zai/glm-4.5-air": { "alias": "GLM" }, "sensenova/sensenova-6.7-flash-lite": { "alias": "SenseNova" } }

这样 manager 用 DeepSeek 做调度、writer 用 GLM 做写作、main 用 SenseNova 做轻量接待，三个 agent 共享一个 Key，轮换时只改一处。如果你后面要跑长期编码或 Agent 任务，可以考虑 Coding Plan，额度更稳；只是验证模型通不通，用模型对话页面就够了。

3. 可复制配置：openclaw.json 多 agent 飞书群完整片段

这一节是全文的核心，直接给可复制的 JSON。路径按 openclaw 默认的/root/.openclaw/openclaw.json，你如果改过位置，对应替换。配置分四块：agents、channels.feishu、bindings、messages。

先看 agents 部分。关键改动是给每个群聊 agent 加tools.profile，main 用minimal（接待不需要重权限），manager 和 writer 用full（要执行任务和写作）：

"agents": { "defaults": { "workspace": "/root/.openclaw/workspace", "models": { "deepseek/deepseek-v4-flash": { "alias": "DeepSeek" }, "zai/glm-4.5-air": { "alias": "GLM" }, "sensenova/sensenova-6.7-flash-lite": { "alias": "SenseNova" } }, "model": { "primary": "deepseek/deepseek-v4-flash" } }, "list": [ { "id": "main", "model": "sensenova/sensenova-6.7-flash-lite", "tools": { "profile": "minimal" } }, { "id": "manager", "name": "manager", "workspace": "/root/.openclaw/workspace/manager", "agentDir": "/root/.openclaw/agents/manager/agent", "model": "deepseek/deepseek-v4-flash", "tools": { "profile": "full" } }, { "id": "writer", "name": "writer", "workspace": "/root/.openclaw/workspace/writer", "agentDir": "/root/.openclaw/agents/writer/agent", "model": "zai/glm-4.5-air", "tools": { "profile": "full" } } ] }

再看 channels.feishu。这里三层控制群聊准入：groupPolicy设allowlist只允许指定群，groupAllowFrom填目标群 ID，groups里针对具体群覆盖requireMention。注意requireMention全局默认 true，但可以在groups里对某个群设 false，实现「这个群不用 @ 也回」：

"channels": { "feishu": { "enabled": true, "defaultAccount": "main", "accounts": { "main": { "appId": "cli_aa83f01aa5f9dcbd", "appSecret": "你的main密钥", "name": "Primary bot" }, "manager": { "appId": "cli_aa80568dbb78dcc4", "appSecret": "你的manager密钥", "name": "Manager bot" }, "writer": { "appId": "cli_aa81ae19deb9dcc6", "appSecret": "你的writer密钥", "name": "Writer bot" } }, "domain": "feishu", "dmPolicy": "allowlist", "allowFrom": [ "ou_75dce55c2f809dfc09f52c8bc526c294", "ou_89a264d33137392b4e7e74f63be35f23", "ou_01dac560d8cb4ef22dd17083ff49b741" ], "groupPolicy": "allowlist", "groupAllowFrom": ["oc_533b58bb625e4ee7bb3fa81efbc5737e"], "requireMention": true, "groups": { "oc_533b58bb625e4ee7bb3fa81efbc5737e": { "requireMention": false } } } }

bindings 是防消息串线的关键。三个 agent 分别绑三个飞书账号，群消息按 accountId 路由。注意 main 的 match 里不要带peer字段，带了就只收私聊，群聊命中不了：

"bindings": [ { "agentId": "main", "match": { "channel": "feishu", "accountId": "main" } }, { "agentId": "manager", "match": { "channel": "feishu", "accountId": "manager" } }, { "agentId": "writer", "match": { "channel": "feishu", "accountId": "writer" } } ]

最后是 messages，这是群聊 @ 不回复的根因修复。默认visibleReplies是message_tool，群聊里普通文本回复被静默抑制，改成automatic后跟私聊一样自动可见：

"messages": { "groupChat": { "visibleReplies": "automatic" } }

改完重启 gateway 生效。这四块配完，多 agent 飞书群管理的骨架就搭好了。

4. 联调验证：飞书群 @ 触发与消息路由实测

配置写完不代表能跑，得一步步验证。先确认群组 ID 拿对了。飞书群 ID 是oc_开头的那串，获取方式：在群里点右上角三个点 → 设置 → 群信息里能看到，或者用飞书开放平台的 API 查。填错 ID 的表现是消息完全不进，日志里连路由记录都没有。

第一步，验证单 agent 私聊。给 main 机器人发私聊消息，看有没有回复。私聊不受visibleReplies影响，如果私聊都不回，说明模型通道或 agent 配置有问题，先查curl那步通不通。

第二步，验证群聊 @。在群里 @main 机器人，发一句「你好」。预期是 main 用 SenseNova 回复。如果没反应，先看 gateway 日志里有没有stopReason: stop且没有 message 工具调用——这就是visibleReplies没改的典型症状。

第三步，验证路由不串线。@manager 发「帮我拆个任务」，@writer 发「写一段文案」，看回复的模型和角色对不对。manager 应该走 DeepSeek，writer 走 GLM。如果 @manager 结果 writer 回了，说明 bindings 的 accountId 对错了，检查三个账号的 appId 有没有填混。

第四步，验证准入策略。用一个不在groupAllowFrom里的群发消息，预期是静默丢弃。再在目标群里不 @ 直接发消息，因为groups里设了requireMention: false，预期是自动回复。

实测下来，最容易出问题的是第三步和第四步的交叉：群 ID 填对了但 bindings 的 accountId 写错，表现是消息进了但回错人。建议每改一次配置就重启 gateway，然后按「私聊 → @ 单 agent → @ 多 agent → 不 @」的顺序过一遍。

5. 常见报错排查：401、local proxy failed、reading choices、OAuth

配置过程中会撞到几类典型报错，逐个说清楚。

401 Unauthorized：TaoToken 的 Key 没填对或过期。检查Authorization: Bearer后面的 Key 有没有多余空格，控制台 API Keys 页面重新生成一个对比。如果 curl 能通但 agent 报 401，说明 agent 配置里的 provider 没指向 TaoToken 的 Base URL，检查模型配置的端点。

local proxy failed：这个报错通常出现在 openclaw 尝试走本地代理但代理没起来。openclaw 本身不需要本地代理，如果你配置里残留了 proxy 相关字段，删掉。Base URL 直接填https://taotoken.net/api即可，不要加额外的代理层。

reading choices 报错：模型返回体里没有choices字段，说明请求没到真正的模型端点，或者模型 ID 写错了。先用 curl 确认deepseek/deepseek-v4-flash这个 ID 在 TaoToken 通道里可用，再检查 agent 的model字段有没有拼错。这个错和 401 的区别是：401 是没权限，reading choices 是通了但返回格式不对。

OAuth 相关报错：飞书账号的 appId/appSecret 配错，或者应用没开机器人能力。去飞书开放平台确认三个应用都开启了机器人，且权限里勾了「接收群聊消息」。appSecret 填错的表现是账号初始化失败，日志里会有 OAuth 字样。

群聊 @ 不回复但私聊正常：99% 是visibleReplies没改成automatic。改完记得重启 gateway，不重启不生效。

消息串线：bindings 的 accountId 和 channels.accounts 的 key 对不上。三个账号的 key 分别是 main、manager、writer，bindings 里必须一一对应。

排障时建议开 gateway 的 debug 日志，每条消息的路由决策都会打出来，比猜快得多。接入文档里有各字段的完整说明，遇到不确定的字段先去文档对一遍。

6. 多 agent 协作的下一步：从群管理到任务编排

群管理跑通之后，多 agent 的价值才刚开始。你可以让 manager 收到任务后，通过 message 工具把子任务派给 writer，writer 写完再回群。这需要 agent 之间有调用关系，openclaw 的 tools.profile 设成 full 的 agent 才有这个能力。

模型层面，TaoToken 的统一 Key 让你可以按角色分配模型：接待用轻量的 SenseNova 省成本，调度用 DeepSeek 保准确，写作用 GLM 保文风。要调整某个角色的模型，只改 agent 的model字段，不用动 Key。

如果你打算长期跑这套多 agent 流程，Coding Plan 的额度比按次调用更划算，适合 manager 这种高频调度的角色。只是验证配置通不通，模型对话页面手动发几条就够了。

最后给个实用技巧：把openclaw.json用 git 管起来，每次改配置前 commit 一次。多 agent 配置字段多，改错一个字段排查半天，有版本记录能快速回滚。群 ID、appId 这些敏感信息用环境变量注入，别硬编码在文件里。配置改完统一openclaw gateway restart，养成习惯。