企业官网建设流程全解析

1. 从单 Agent 到多 Agent，卡住的地方到底在哪

OpenClaw 多 Agent 部署这件事，真正让人卡住的往往不是“怎么装”，而是“装完之后怎么让多个 Agent 各干各的、还能互相喊得动”。单 Agent 的时候，一个workspace目录、一个飞书机器人，跑起来就完事；一旦要拆成“调度中枢 + 增长 + 交付 + 财务”这种结构，配置文件立刻从十几行膨胀到上百行，飞书那边还要为每个 Agent 单独建应用、配权限、发版本，任何一环漏了，表现都是“机器人不回消息”。

这篇就聚焦两件事：openclaw.json的配置骨架怎么搭，以及飞书多机器人怎么接进来并验证成功。适合已经跑通单 Agent、准备往多 Agent 协作升级的人。核心检索词先摆出来：OpenClaw 多 Agent 部署、openclaw.json 配置、飞书接入。读完你应该能拿到一份可复制的配置片段，并且知道每个字段为什么这么写。

先说清楚一个心智模型，后面所有配置都围绕它展开：

1 个飞书应用 = 1 个飞书机器人 = 1 个 OpenClaw Account；1 个 Account 通过 binding 绑定到 1 个 Agent；main Agent 是默认路由，没匹配上的消息都走它；main 可以通过 spawn 实时调度其他 Agent。

这个模型一旦立住，openclaw.json里那些agents.list、channels.feishu.accounts、tools.agentToAgent就不再是零散字段，而是这条链路上的三个环节。下面按“前置检查 → 配置骨架 → 飞书接入 → 验证 → 排障”的顺序走一遍。

2. 动手前先把环境和现状摸清楚

在改任何配置之前，先确认当前处于什么状态。很多人一上来就手写 JSON，结果改完发现根本没生效，其实是没搞清楚运行时到底读的是哪个文件。

先跑三条命令看现状：

openclaw agents list openclaw channels status --probe cat ~/.openclaw/openclaw.json

第一条列出当前所有 Agent，第二条探测通道健康度，第三条把主配置打印出来。如果agents list里只有一个 main，说明你还在单 Agent 模式，正好从这篇开始升级。

环境上需要满足：Ubuntu 22.04+ / macOS / Windows 任一；OpenClaw 已安装并完成openclaw onboard；飞书有企业账号，开放平台能创建自建应用；至少一个 LLM API 已配好模型（比如zai/glm-4.7），并且注意 API 频率限制，多 Agent 并发时很容易撞到 429。

这里有个容易被忽略的点：OpenClaw 的配置其实分两层。~/.openclaw/openclaw.json是主配置，管 Agent 列表、通道、绑定；而~/.openclaw/channels/feishu/accounts.json是飞书账号的运行时文件。两个都要改，只改一个会出现“配置看着对，但飞书连不上”的诡异现象。后面第 4 节会专门讲这个坑。

3. openclaw.json 配置骨架：从 defaults 到 agents.list

3.1 单 Agent 的原始形态

单 Agent 模式下，配置里通常只有一段：

"agents": { "defaults": { "workspace": "/home/user/.openclaw/workspace" } }

defaults.workspace是全局默认工作目录，所有 Agent 没单独指定时都用它。问题在于，多 Agent 场景下每个 Agent 需要独立的记忆、技能和产出目录，共享一个 workspace 会互相污染。

3.2 升级为多 Agent 骨架

升级的关键动作是：删掉defaults.workspace，改成agents.list数组，每个 Agent 显式声明自己的workspace。下面是一份可直接复制的骨架：

"agents": { "defaults": { "model": { "primary": "zai/glm-4.7" }, "compaction": { "mode": "safeguard" }, "maxConcurrent": 4, "subagents": { "maxConcurrent": 8 } }, "list": [ { "id": "main", "name": "CEO经营参谋官", "default": true, "workspace": "/home/user/.openclaw/workspace", "subagents": { "allowAgents": ["*"] }, "heartbeat": { "every": "6h", "activeHours": { "start": "09:00", "end": "22:00", "timezone": "Asia/Shanghai" } } }, { "id": "content-growth", "name": "公域内容增长官", "workspace": "/home/user/.openclaw/workspace-content-growth", "subagents": { "allowAgents": ["*"] }, "heartbeat": { "every": "24h", "activeHours": { "start": "09:00", "end": "22:00", "timezone": "Asia/Shanghai" } } } ] }

几个字段值得单独说。default: true标记默认路由 Agent，有且只有一个；subagents.allowAgents控制这个 Agent 能调度谁，["*"]表示不限制；heartbeat.every是自主运行节拍，main 设 6 小时、执行型 Agent 设 24 小时比较合理；activeHours限定活跃时段，避免半夜乱跑。

3.3 打开跨 Agent 调用权限

光有 list 还不够，Agent 之间要能互相调用，得显式开权限：

"tools": { "agentToAgent": { "enabled": true, "allow": ["main", "content-growth", "wechat-conversion"] } }

allow数组里列出允许参与互调的 Agent id。建议用脚本生成，避免手写漏项：

node -e " const fs = require('fs'); const p = process.env.HOME + '/.openclaw/openclaw.json'; const config = JSON.parse(fs.readFileSync(p, 'utf8')); config.tools = config.tools || {}; config.tools.agentToAgent = { enabled: true, allow: config.agents.list.map(a => a.id) }; fs.writeFileSync(p, JSON.stringify(config, null, 2)); console.log('agentToAgent allow =', config.tools.agentToAgent.allow.join(',')); "

跑完打印出所有 Agent id，说明权限已同步。

3.4 每个 Agent 的 workspace 要放什么

配置指向的 workspace 目录不是空的，每个 Agent 至少需要 5 个核心文件：

批量创建目录可以这样写：

OC=~/.openclaw SRC=/path/to/source ROLES="content-growth wechat-conversion delivery-upgrade" for role in $ROLES; do WS="$OC/workspace-$role" mkdir -p "$WS"/{memory,skills,work/{inbox,drafts,archives,output/{reports,content,data,plans},runtime/{state,scripts,cache}}} cp "$SRC/workspace-$role"/{SOUL.md,IDENTITY.md,TOOLS.md,HEARTBEAT.md,MEMORY.md} "$WS/" echo "workspace-$role 创建完成" done

main Agent 的 SOUL.md 里必须显式写清调度方式，否则它会默认走异步 inbox 模式（写文件等领取），而不是实时 spawn。这一点我在实际部署里踩过，表现是“让它调增长官，结果半天没动静”，后来才发现是 SOUL.md 没写调度规则。

注意：如果 SOUL.md 不显式写明“直接 spawn”，Agent 会默认使用异步 inbox 模式，而非实时调用。

4. 飞书多机器人接入：应用、权限、绑定三步走

4.1 为每个 Agent 创建飞书应用

在飞书开放平台，对每个新 Agent 执行一遍：创建企业自建应用，取名与角色一致；凭证与基础信息里复制 App ID 和 App Secret 并妥善保管；权限管理里添加权限；事件与回调订阅方式选「长连接」，不需要公网服务器；事件与回调里添加im.message.receive_v1，这是最容易漏的一步；应用功能里开启机器人；版本管理与发布里创建版本并发布，不发布不生效。

必需权限清单：

im:message im:message:send_as_bot im:message.group_at_msg:readonly im:message.p2p_msg:readonly contact:contact.base:readonly

三个最常见的漏配：忘了加im.message.receive_v1事件，机器人收不到消息；加了权限和事件却忘了发布新版本，不会生效；缺少contact:contact.base:readonly，日志会报 99991672 错误。

4.2 注册与绑定脚本

拿到 appId/appSecret 后，两个配置文件都要更新，然后绑定路由、重启：

AGENT_ID="content-growth" APP_ID="cli_xxxxxx" APP_SECRET="xxxxxx" # 1. 更新 openclaw.json node -e " const fs = require('fs'); const p = process.env.HOME + '/.openclaw/openclaw.json'; const config = JSON.parse(fs.readFileSync(p, 'utf8')); config.channels.feishu.accounts['$AGENT_ID'] = { appId: '$APP_ID', appSecret: '$APP_SECRET' }; fs.writeFileSync(p, JSON.stringify(config, null, 2)); console.log('openclaw.json updated'); " # 2. 更新运行时 accounts.json（关键） node -e " const fs = require('fs'); const p = process.env.HOME + '/.openclaw/channels/feishu/accounts.json'; const acc = JSON.parse(fs.readFileSync(p, 'utf8')); acc.accounts['$AGENT_ID'] = { appId: '$APP_ID', appSecret: '$APP_SECRET' }; fs.writeFileSync(p, JSON.stringify(acc, null, 2)); console.log('accounts.json updated'); " # 3. 绑定路由 openclaw agents bind --agent $AGENT_ID --bind feishu:$AGENT_ID # 4. 重启 openclaw gateway restart

重要：openclaw.json和~/.openclaw/channels/feishu/accounts.json两个文件都必须更新。只改一个会导致飞书连接不上。

绑定这一步不要手写 bindings JSON，格式很容易错，始终用openclaw agents bind命令。

5. 验证请求：从直接对话到多 Agent 协作

配置改完，用三个测试逐层验证。

测试一，直接对话。在飞书里 @ 某个机器人或私聊：“你是谁？”验证点是回复包含 SOUL.md 里定义的角色名称和职责。如果没回复，先看第 6 节排障。

测试二，单 Agent 调度。私聊 main：“直接调用增长负责人，出 3 个围绕核心用户痛点的内容选题。”验证点是 main 通过 spawn 调用 content-growth，返回完整结果。如果 main 只是自己答了，说明tools.agentToAgent没生效或 SOUL.md 没写调度规则。

测试三，多 Agent 协作。私聊 main：“请立即调用以下 Agent：1. 增长负责人出 3 条引流选题；2. 客户成功官设计新客户欢迎话术。汇总结果给我。”验证点是 main 并行 spawn，汇总后一次性回复。这一步可能触发 API 限流，注意观察日志。

验证绑定和通道状态：

openclaw agents list --bindings openclaw channels status --probe

第一条确认路由规则，第二条确认连接状态。两条都正常，说明飞书接入成功。

6. 本篇常见错排查

日志是排查的第一入口：

openclaw logs --follow

对照下面这张速查表定位问题：

清 session 重启用这几条：

# 清单个 Agent find ~/.openclaw/agents/<agent-id>/sessions/ -type f -delete # 清全部 find ~/.openclaw/agents/*/sessions/ -type f -delete # 重启 openclaw gateway restart

日常运维记住这几个命令和路径：

添加新 Agent 的完整清单：设计 5 个 workspace 文件 → 创建 workspace 目录结构 → 添加到openclaw.json的agents.list→ 更新tools.agentToAgent.allow→ 飞书开放平台创建应用（权限 + 事件 + 发布）→ 更新openclaw.json的channels.feishu.accounts→ 更新channels/feishu/accounts.json→ 执行openclaw agents bind→ 执行openclaw gateway restart→ 执行openclaw channels status --probe验证 → 飞书群测试对话。

7. 模型接入与长期编码的配套选择

多 Agent 跑起来之后，模型调用量会明显上升，尤其是 main 频繁 spawn 其他 Agent 时。这时候如果模型接入不稳定，整个协作链路都会抖。我自己的做法是把模型接入统一走一个兼容层，避免每个 Agent 各自配一套 key 和 endpoint。

TaoToken 在这里的角色就是提供统一的模型接入入口，支持对话、编码等多种调用方式。你可以先到 TaoToken 模型对话 验证模型是否可用，确认没问题后再把 key 配到 OpenClaw 的模型配置里。

具体操作路径：先到 API Keys 管理页 创建 key，然后参考 接入文档 把 endpoint 和 key 填进agents.defaults.model。如果只是排障和接入验证，走 API Keys + 接入文档这条线就够了。

如果你的多 Agent 场景偏长期编码、Agent 持续运行，比如让某个 Agent 专门负责代码生成和重构，那更适合用 Coding Plan，它在长会话和编码任务上的配额更友好。控制台入口在 Console，可以统一看调用情况。

配置模型时有个细节：agents.defaults.model.primary填的是模型标识，比如zai/glm-4.7，如果你的接入层用的是自定义 endpoint，需要在 OpenClaw 的 provider 配置里对应改掉 base URL。改完记得openclaw gateway restart，然后跑一次测试一确认模型响应正常。

最后留一个实操建议：多 Agent 部署最容易出问题的不是配置本身，而是“改了一个文件忘了另一个”。每次动完openclaw.json，顺手确认accounts.json是否同步，再跑一遍openclaw channels status --probe。这个习惯能省掉大半的排障时间。