OpenClaw 进阶:从单兵作战到多智能体协作,打造生产级 AI 团队

前文我们完整剖析了 OpenClaw 的消息传递机制，以飞书插件为例，看到了单智能体如何接收消息、调用模型、返回回复。但在真实业务中，一个智能体往往不够——你需要多个智能体分工协作，需要用户分级服务，需要定时任务自动完成复杂工作流。本文将带你从“单兵作战”走向“团队协作”，深入 OpenClaw 的多智能体高阶能力，并结合生产级案例，展示如何构建一套可扩展的 AI 工作流。

一、为什么需要多个智能体？

在单智能体模式下，OpenClaw 默认会创建一个名为 main 的智能体，所有消息都由它处理。这对于个人使用绰绰有余，但在企业环境中，往往面临以下挑战：

• 职责混杂：产品咨询、技术支持、内部运维混在一起，提示词臃肿。

• 数据隔离：不同用户的对话历史可能泄露隐私。

• 权限控制：无法为不同角色（如管理员、普通用户）分配不同的工具权限。

• 资源浪费：所有请求都用同一个高性能模型，成本高。

多智能体架构通过职责分离和数据隔离，让每个智能体专注自己的领域，独立配置、独立记忆、独立权限，从而构建出灵活、安全、可扩展的 AI 团队。

二、核心概念：账号、机器人、用户与智能体

在配置多智能体之前，我们必须理清 OpenClaw 中几个容易混淆的核心概念：

2.1 账号（Account）与机器人（Bot）

一个飞书账号（Account）对应一个在飞书开放平台创建的自建应用（机器人）。在配置文件中，你可以为不同业务场景定义独立的飞书账号：

{  "channels": {    "feishu": {      "enabled": true,      "accounts": {        "dev_bot": {          "appId": "cli_dev_xxx",          "appSecret": "secret_dev",          "botName": "研发机器人"        },        "pm_bot": {          "appId": "cli_pm_yyy",          "appSecret": "secret_pm",          "botName": "产品机器人"        },        "ops_bot": {          "appId": "cli_ops_zzz",          "appSecret": "secret_ops",          "botName": "运维机器人"        }      }    }  }}

• enabled 用于整体开关飞书渠道。

• accounts 的键（如 dev_bot、pm_bot）是自定义的 accountId，用于在路由中标识该账号。

• 每个账号拥有独立的 appId、appSecret，可以独立启用/禁用（通过该账号下的 enabled 字段，默认为 true）。

• 多个账号可以共享同一个智能体，也可以绑定不同的智能体（通过路由规则）。

• 用户添加哪个机器人，就对应使用哪个账号。

2.2 用户（Sender）与会话（Session）

当用户向机器人发送消息时，OpenClaw 需要为这个对话分配一个 sessionKey，用于存储上下文。默认情况下：

• 所有私聊（DM）共享一个主会话（agent:main:main），意味着不同用户的私聊会互相看到对方的对话历史，存在隐私泄露风险。

• 每个群聊/频道拥有独立会话（agent:main:feishu:group:oc_xxx），群组之间隔离。

这由 session.dmScope 配置控制。在生产环境中，强烈建议将 dmScope 改为 "per-channel-peer"，让每个用户获得独立会话：

{  "session": {    "dmScope": "per-channel-peer"  }}

此时，私聊的 sessionKey 会包含用户 ID，例如 agent:main:feishu:dm:user_001 和 agent:main:feishu:dm:user_002 完全隔离。

2.3 路由绑定：将账号、用户映射到智能体

通过 bindings 配置，我们可以将不同的账号或用户指向不同的智能体。bindings 数组中的每个条目包含一个 agentId 和一个 match 对象，match 中可以组合多个条件（如 channel、accountId、peer 等），所有条件必须同时满足才算匹配。匹配按数组顺序进行，第一个匹配的生效。

 {  "bindings": [    {      "agentId": "dev_agent",      "match": { "channel": "feishu", "accountId": "dev_bot" }    },    {      "agentId": "pm_agent",      "match": { "channel": "feishu", "accountId": "pm_bot" }    },    {      "agentId": "vip-agent",      "match": {        "channel": "feishu",        "accountId": "dev_bot",        "peer": { "kind": "direct", "id": "vip_user_001" }      }    }  ]}

• accountId 必须与 channels.feishu.accounts 中定义的键一致。

• peer.kind 可以是 direct（私聊）或 group（群聊），id 为平台用户/群组 ID。

• 更具体的规则应放在前面（如包含 peer.id），通用规则放在后面。

2.4 动态创建：为每个用户自动生成独立智能体

当主 Agent 开启 dynamicAgentCreation 后，每个用户首次对话时会自动复制主 Agent 的工作区，生成专属的智能体实例。这个新智能体仍然可以使用 bindings 进行路由，但更常见的是直接由主 Agent 内部调用 Skill 处理。动态创建的核心价值在于为用户保留独立记忆和配置，实现“千人千面”。

三、多智能体协作：从新闻采编看分工

假设我们有一个新闻采编业务，需要每天早中晚自动完成以下工作：

1. 采集：从多个新闻源抓取最新内容，分类、打标签。

2. 编辑：根据主题组稿，润色文字，提炼摘要。

3. 发布：针对不同平台（小红书、微信公众号、头条）调整文风，包装后发布。

我们可以创建三个持久 Agent：collector、editor、publisher。每个 Agent 拥有独立的工作区和专属 Skill。

3.1 创建持久 Agent

openclaw agents add collector --workspace ~/.openclaw/workspace-collectoropenclaw agents add editor   --workspace ~/.openclaw/workspace-editoropenclaw agents add publisher --workspace ~/.openclaw/workspace-publisher

3.2 为每个 Agent 配置 Skill

采集 Agent 的 SKILL.md（~/.openclaw/workspace-collector/skills/collect/SKILL.md）：

---name: collectdescription: 从 RSS 源抓取新闻，分类打标签。---# 新闻采集 Skill1. 调用 `http_request` 工具，读取配置的 RSS 源列表。2. 解析每个源的条目，提取标题、链接、发布时间。3. 使用内置分类器（或调用模型）为每条新闻打上标签（如“AI”“开源”“商业”）。4. 返回 JSON 格式的结果。

编辑 Agent 的 SKILL.md（~/.openclaw/workspace-editor/skills/edit/SKILL.md）：

markdown---name: editdescription: 将采集的新闻组稿成一篇完整的文章。---#新闻编辑 Skill1.接收采集 Agent 返回的新闻列表。2.根据用户预设的主题（如“本周 AI 热点”）筛选相关新闻。3.撰写导语，将新闻按重要性排序，每篇附上简要评论。4.输出 Markdown 格式的完整文章。

发布 Agent 的 SKILL.md（~/.openclaw/workspace-publisher/skills/publish/SKILL.md）：

markdown---name: publishdescription: 将文章适配不同平台并发布。---# 新闻发布 Skill1. 接收编辑 Agent 输出的文章。2. 根据目标平台（小红书、公众号、头条）调用对应的格式转换函数（可使用自然语言描述要求）。3. 调用对应平台的发布工具（如飞书机器人、微信 API）发送文章。4. 返回发布结果。

3.3 协作规范：写在 AGENTS.md 中

在主控 Agent 的 AGENTS.md 中，定义团队通讯录和委派规则，让智能体知道“什么时候”以及“如何”与其他队友协作：

markdown# 团队协作规范## 队友- **collector**（采集助手）：负责新闻抓取、分类、打标签。- **editor**（编辑助手）：负责组稿、润色、写摘要。- **publisher**（发布助手）：负责平台适配、发布内容。## 委派规则当用户请求涉及以下内容时，必须委派给对应队友：- 抓取新闻、获取 RSS → collector- 整理文章、润色 → editor- 发布到特定平台 → publisher## 委派操作使用 `sessions_send` 工具，格式为 `agent:<agentId>:main`，建议设置 `timeoutSeconds` 根据任务时长调整。

3.4 具体流程：写在 Skill 中

将顺序调用子 Agent 的详细步骤封装在 news-pipeline Skill 中，使主控 Agent 只需一句话就能执行整个流程：

markdown---name: news-pipelinedescription: 执行新闻采编发布全流程（采集 → 编辑 → 发布）---# 新闻采编发布 Skill## 执行步骤1. 调用 collector：`sessions_send` 等待 30 分钟，抓取新闻。2. 调用 editor：`sessions_send` 等待 10 分钟，润色成文。3. 调用 publisher：`sessions_send` 等待 1 分钟，发布到飞书。

这种设计让主控 Agent 的 AGENTS.md 保持简洁（只描述团队结构和委派原则），而具体的流程逻辑放在可复用的 Skill 中，便于维护和升级。

四、用户分级服务：免费 vs VIP 的最佳实践

在多用户场景下，我们常常需要根据用户等级提供不同能力。以下三种方案的对比：

结论：主 Agent 动态创建 + Skill 是生产环境的最优解。具体实现：

4.1 开启主 Agent 动态创建

在 ~/.openclaw/openclaw.json 中配置：

json{  "agents":{    "list":[     {      "id":"main",      "workspace":"~/.openclaw/workspace",      "dynamicAgentCreation":true     }    ]  }}

每个用户首次对话时，系统会自动复制 ~/.openclaw/workspace 到 ~/.openclaw/workspace-users/<userId>，并为其维护独立的记忆和配置。

4.2 定义两个 Skill：vip-skill 和 free-skill

在 ~/.openclaw/workspace/skills/ 下创建两个 Skill 目录，分别描述 VIP 和免费用户的能力。

4.3 在主 Agent 的 AGENTS.md 中编写等级判断逻辑

markdown# 你是主 Agent，负责处理所有用户消息## 用户等级判断每次收到消息时：1. 读取当前用户工作区根目录下的 `user_profile.json` 文件。2. 如果文件不存在，则创建新用户，默认等级为 `free`。3. 检查 `level` 字段：  - 如果是`vip`，调用 `vip-skill`。  - 如果是 `free`，调用 `free-skill`。## 动态升级当收到支付回调时，系统会调用 `update_user_level` 工具（自定义 Skill），将用户工作区中的`level` 改为 `vip`。

4.4 升级后记忆保留

由于升级只修改 user_profile.json，而 MEMORY.md 等文件原封不动，用户的历史对话、偏好设置完全保留，实现无缝体验。

4.5 试用期与降级

可在 user_profile.json 中添加 trial_expires 字段，主 Agent 每次判断时检查是否过期。订阅到期后，通过支付回调将 level 改为 free，用户下次对话自动降级。

五、长任务处理：Cron 定时任务与 Agent 间通信

回到新闻采编案例，我们需要每天早中晚自动执行整个流程。如何让多个 Agent 协同工作？OpenClaw 提供了两种核心机制：sessions_send（同步等待） 和 异步回调。

5.1 sessions_send 的同步等待机制

当主 Agent 调用 sessions_send 并设置 timeoutSeconds > 0 时，它会挂起当前会话，等待目标 Agent 回复。挂起期间不占用 CPU，其他会话可并行处理。超时后返回 status: "timeout"，但目标 Agent 仍会继续运行，稍后可通过 sessions_history 查询结果。

语法示例：

const result = await sessions_send({  sessionKey: "agent:collector:main",  message: "请抓取最新新闻",  timeoutSeconds: 1800  // 最多等待 30 分钟});// result 包含子 Agent 的回复

5.2 Cron 任务独立会话的特性

Cron 任务由 Gateway 调度器管理，每次执行会在独立会话（如 cron:news-job）中运行。该会话的阻塞不会影响其他用户，因此我们可以放心使用同步等待，让流程清晰易维护。

创建 Cron 任务：

openclaw cron add \  --name "新闻采编发布" \  --schedule "0 8,12,18 * * *" \  --agent "main" \  --prompt "执行新闻采编发布任务"

5.3 集中式同步流程（推荐）

在主 Agent 中定义一个 news-pipeline Skill，顺序调用三个子 Agent：

# 新闻采编发布 Skill## 执行步骤1. **采集新闻**     调用 `sessions_send` 向 collector 发送消息，等待返回：   - sessionKey: `agent:collector:main`   - message: `"抓取最新 10 条新闻，分类打标签"`   - timeoutSeconds: 18002. **编辑润色**     将采集结果作为消息，调用 editor：   - sessionKey: `agent:editor:main`   - message: `"请将以下新闻组稿成一篇完整文章：\n{采集结果}"`   - timeoutSeconds: 6003. **发布到飞书**     将编辑结果作为消息，调用 publisher：   - sessionKey: `agent:publisher:main`   - message: `"请将以下文章发布到飞书群：\n{编辑结果}"`   - timeoutSeconds: 60## 异常处理- 任何步骤超时或返回错误，立即终止流程并记录日志。

这样，整个流程逻辑集中在一个文件中，易于调试和维护。

5.4 异步回调模式（适用于实时对话中的长任务）

如果用户是在实时对话中触发了长任务（如“帮我分析这份 500 页的财报”），我们不想阻塞该用户的会话。此时可以采用异步回调：主 Agent 使用 sessions_send 设置 timeoutSeconds: 0 发起任务后立即返回，子 Agent 完成后通过 sessions_send 将结果发回主 Agent 的会话，主 Agent 被唤醒后继续处理。

子 Agent Skill 中的回调示例：

# 采集 Agent Skill## 执行步骤1. 抓取新闻...2. 完成后，使用 `sessions_send` 将结果发回主 Agent：   - sessionKey: `agent:main:main`（主 Agent 默认会话）   - message: `{"status":"success","data":...}`   - timeoutSeconds: 0

主 Agent 收到消息后会启动新轮次，可以继续调用后续 Agent，形成完整的异步工作流。

六、生产级案例：新闻采编发布全流程

结合上述所有高阶能力，我们构建一套完整的生产级新闻采编系统：

1. 创建持久 Agent：collector、editor、publisher，每个配置独立 Skill。

2. 定义协作规范：在主控 Agent 的 AGENTS.md 中写明团队通讯录和委派原则。

3. 封装工作流 Skill：将顺序调用子 Agent 的逻辑写入 news-pipeline Skill。

4. 配置飞书账号：使用一个机器人（如 news_bot）接收所有用户消息，通过 bindings 路由到主控 Agent。

5. 配置用户分级：主 Agent 开启动态创建，通过 user_profile.json 区分免费/VIP，调用不同 Skill。

6. 创建 Cron 任务：每天 8:00、12:00、18:00 自动执行，调用主 Agent 的 news-pipeline Skill。

完整配置示例（~/.openclaw/openclaw.json）：

{  "session": {    "dmScope": "per-channel-peer"  },  "channels": {    "feishu": {      "enabled": true,      "accounts": {        "news_bot": {          "appId": "cli_news_xxx",          "appSecret": "secret_news",          "botName": "新闻机器人"        }      }    }  },  "bindings": [    {      "agentId": "main",      "match": { "channel": "feishu", "accountId": "news_bot" }    }  ],  "agents": {    "list": [      {        "id": "main",        "workspace": "~/.openclaw/workspace",        "dynamicAgentCreation": true      }    ]  }}

效果：

• 每天早中晚，系统自动完成新闻采编发，无需人工干预。

• 免费用户和 VIP 用户共用同一个机器人，体验一致，升级实时生效，记忆保留。

• 所有 Agent 独立迭代，采集逻辑升级不影响编辑和发布。

• 主控 Agent 的职责清晰（只负责委派），流程细节封装在 Skill 中，易于维护。

七、总结：从单兵作战到团队协作

通过本文，我们完整地走过了 OpenClaw 多智能体架构的各个关键环节：

• 账号体系：一个机器人对应一个账号，多个机器人可共用或独立绑定智能体。

• 会话隔离：私聊默认共享主会话，存在隐私风险；生产环境应配置 dmScope: "per-channel-peer"。

• 路由绑定：通过 bindings 将账号、用户映射到不同智能体，实现精细化分工。

• 动态创建：为每个用户自动生成独立工作区，实现千人千面与记忆隔离。

• 协作规范：在 AGENTS.md 中定义团队结构和委派原则，让智能体知道“什么时候”协作。

• 流程封装：将具体执行步骤写在 Skill 中，实现“如何做”的可复用模块。

• Agent 间通信：sessions_send 提供同步/异步两种模式，满足长任务与实时对话的不同需求。

• 定时任务：Cron 独立会话配合同步等待，让复杂工作流简单可靠。

这些高阶能力让 OpenClaw 不仅是一个个人助手，更是一个可以支撑企业级业务的 AI 团队平台。你可以像组建一个公司一样，为每个业务线分配专属的智能体，让它们各司其职，协同工作。