【Openclaw】openclaw多Agent配置方式-Euler的博客

结论

OpenClaw 里的“多 Agent”主要有两种模式，先区分清楚：

路由隔离型多 Agent
不同消息按 bindings 路由到不同 agentId。每个 agent 有独立的 workspace、agentDir、sessions，适合“不同身份/不同渠道/不同人群”。
协作型多 Agent
不是靠 bindings 让两个 agent 同时处理同一条消息，而是让主 agent 再拉起 sub-agent 或 ACP agent 来协作，适合“A 负责开发，B 负责测试”。

所以如果你的目标是：

“开发群走 dev agent，测试群走 qa agent”：用 agents.list + bindings
“同一个需求里先开发再测试”：更适合 subagents 或 ACP，而不是仅靠 bindings

OpenClaw 多 Agent 的基本结构

核心配置块有两个：

agents.list
定义有哪些 agent。每个 agent 至少有 id，通常还会配自己的 workspace。
bindings
定义入站消息如何路由到某个 agentId。

匹配优先级大致是：

peer 精确匹配
parentPeer
Discord 的 guildId + roles
guildId
teamId
accountId
channel 级匹配
默认 agent

关键限制

1. 每个 agent 必须独立

每个 agent 都应该有独立目录：

独立 workspace
独立 agentDir
独立 session 存储

不要让两个 agent 共用同一个 agentDir，否则会出现 auth / session 冲突。项目里也专门有校验来阻止这种配置。

2. `bindings` 是“二选一”路由，不是“多 agent 会签”

普通 bindings 的含义是：

某条入站消息匹配后，只会选中一个 agent
不会自动让 A 和 B 同时协作

如果你想“一个需求同时由开发 agent 和测试 agent 参与”，不能只靠 bindings。

3. A 开发、B 测试，更像 orchestration

更贴近的做法通常有两个：

主 agent 是 coordinator，允许拉起 sub-agent
用 ACP persistent binding，把某个 conversation 固定到专门的 coding agent / testing agent

如果只是想先把多 agent 路由配起来，先用 agents.list + bindings 就够了。

示例配置 1：最基础的多 Agent 路由

下面这个配置表示：

默认 agent 是 dev
某个 Discord guild 里带开发角色的人走 dev
同 guild 其他人走 qa

{
  agents: {
    list: [
      {
        id: "dev",
        default: true,
        workspace: "~/.openclaw/workspace-dev",
        agentDir: "~/.openclaw/agents/dev/agent",
        model: "anthropic/claude-opus-4-6",
      },
      {
        id: "qa",
        workspace: "~/.openclaw/workspace-qa",
        agentDir: "~/.openclaw/agents/qa/agent",
        model: "anthropic/claude-sonnet-4-5",
      },
    ],
  },
  bindings: [
    {
      agentId: "dev",
      match: {
        channel: "discord",
        guildId: "123456789012345678",
        roles: ["111111111111111111"]
      }
    },
    {
      agentId: "qa",
      match: {
        channel: "discord",
        guildId: "123456789012345678"
      }
    }
  ]
}

这个示例体现的是“路由隔离”：

命中开发角色的消息给 dev
其他消息给 qa

不是“同一条消息 dev 和 qa 都执行”。

示例配置 2：按具体群/会话绑定不同 Agent

如果你想一个群专门给开发，一个群专门给测试，可以按 peer 绑定：

{
  agents: {
    list: [
      {
        id: "dev",
        default: true,
        workspace: "~/.openclaw/workspace-dev",
        agentDir: "~/.openclaw/agents/dev/agent"
      },
      {
        id: "qa",
        workspace: "~/.openclaw/workspace-qa",
        agentDir: "~/.openclaw/agents/qa/agent"
      }
    ]
  },
  bindings: [
    {
      agentId: "dev",
      match: {
        channel: "telegram",
        peer: {
          kind: "group",
          id: "-1001111111111"
        }
      }
    },
    {
      agentId: "qa",
      match: {
        channel: "telegram",
        peer: {
          kind: "group",
          id: "-1002222222222"
        }
      }
    }
  ]
}

这适合最常见的“两个群，两套人格，两套上下文”。

示例配置 3：更接近“开发 + 测试协作”的方式

如果你真的是想：

dev 写代码
qa 测试结果
最后主 agent 汇总

推荐把 coordinator 作为主入口，然后允许它调起 subagent。

配置重点不是 bindings，而是：

主 agent 作为默认入口
subagents.allowAgents 允许它调起 dev、qa
dev、qa 各自有独立 workspace

示意配置如下：

{
  agents: {
    defaults: {
      subagents: {
        maxSpawnDepth: 1,
        maxChildrenPerAgent: 5,
        maxConcurrent: 8,
        runTimeoutSeconds: 900
      }
    },
    list: [
      {
        id: "coordinator",
        default: true,
        workspace: "~/.openclaw/workspace-coordinator",
        agentDir: "~/.openclaw/agents/coordinator/agent",
        subagents: {
          allowAgents: ["dev", "qa"],
          model: "anthropic/claude-sonnet-4-5"
        }
      },
      {
        id: "dev",
        workspace: "~/.openclaw/workspace-dev",
        agentDir: "~/.openclaw/agents/dev/agent",
        model: "anthropic/claude-opus-4-6"
      },
      {
        id: "qa",
        workspace: "~/.openclaw/workspace-qa",
        agentDir: "~/.openclaw/agents/qa/agent",
        model: "anthropic/claude-sonnet-4-5"
      }
    ]
  }
}

这个配置本身只完成“允许 coordinator 调起 dev / qa”。

真正运行时，还需要主 agent 在任务里使用 sessions_spawn 或 /subagents spawn 去拉起对应 agent。

也就是说：

bindings 解决“谁来接消息”
subagents 解决“接到消息后，如何分工”

如果只是想要“开发 Agent + 测试 Agent”我建议这样配

最稳妥的落地方式是：

先建 3 个 agent：coordinator、dev、qa
用户统一和 coordinator 对话
coordinator 在需要时拉起 dev 做实现
再拉起 qa 做验证
最后由 coordinator 汇总给用户

这样比单纯用 bindings 更符合“多 agent 协作”的目标。

最小可执行建议

如果你现在只想先跑通，建议按这个顺序：

先配置 agents.list
确保 dev / qa 各自有独立 workspace 和 agentDir
再配置 bindings
让不同入口可以路由到不同 agent
最后再加 subagents
让 coordinator 能调 dev 和 qa

一句话总结

OpenClaw 的多 Agent 配置本质是：

agents.list 定义多个隔离 agent
bindings 决定消息路由给哪个 agent
若要“A 开发、B 测试”的协作链路，通常还要配 subagents，而不是只靠 bindings

补充问题 1：默认进来时，怎么决定用哪个 agent

默认入站时，OpenClaw 不是先看“任务内容像开发还是测试”，而是先看“这条消息命中了哪条路由规则”。

决策顺序可以理解为：

先匹配 bindings
如果没有命中，就走默认 agent
默认 agent 优先取 agents.list[].default = true
如果没配默认 agent，就取 agents.list 里的第一个
如果连 agents.list 都没有，就回到内置的 main

也就是说，默认选 agent 主要依据是入口，不是语义

常见匹配维度有：

channel
accountId
peer.kind
peer.id
guildId
teamId
roles

所以：

如果你想“开发群 -> dev，测试群 -> qa”，用 bindings
如果你想“同一个入口里，系统自己判断这是开发任务还是测试任务”，更适合统一先进入 coordinator，再由它决定是否调起 dev / qa

补充问题 2：一个主 agent 是否可以发起其他所有 agent

可以，但不是默认就能发起所有 agent，而是要显式授权。

OpenClaw 里主 agent 通常通过 subagents / sessions_spawn 去拉起别的 agent。是否允许，关键看：

agents.list[].subagents.allowAgents

规则可以理解为：

默认只允许操作当前 agent 自己
如果配置了 allowAgents
主 agent 才能发起其他 agent
如果写的是具体列表
只能发起列表中的 agent
如果写 ["*"]
表示允许发起任意 agent

示例：

{
  agents: {
    list: [
      {
        id: "coordinator",
        default: true,
        workspace: "~/.openclaw/workspace-coordinator",
        agentDir: "~/.openclaw/agents/coordinator/agent",
        subagents: {
          allowAgents: ["dev", "qa", "ops"]
        }
      },
      {
        id: "dev",
        workspace: "~/.openclaw/workspace-dev",
        agentDir: "~/.openclaw/agents/dev/agent"
      },
      {
        id: "qa",
        workspace: "~/.openclaw/workspace-qa",
        agentDir: "~/.openclaw/agents/qa/agent"
      },
      {
        id: "ops",
        workspace: "~/.openclaw/workspace-ops",
        agentDir: "~/.openclaw/agents/ops/agent"
      }
    ]
  }
}

是否建议直接配 `["*"]`

可以，但一般不建议一开始就这样配。

更稳妥的是白名单方式：

["dev", "qa"]
["dev", "qa", "ops"]

原因是：

权限边界更清晰
更不容易误调不该调起的 agent
更方便后续审计和排错

额外注意

“可以发起其他 agent”不等于“会自动协作”。

它只表示主 agent 有权限调起其他 agent。至于：

什么时候调
调哪个
先调开发还是先调测试

仍然要靠主 agent 的提示词、工作流设计或者显式指令来控制。

补充问题 3：每个 agent 是否需要绑定不同 skills

不是必须，但通常建议按职责拆分。

可以把 skill 分成两类理解：

共享 skill
多个 agent 都能用
agent 专属 skill
只给某个 agent 用

什么时候可以共用

如果几个 agent 职责差不多，可以共用一批基础 skills。

比如：

通用文档检索
通用代码阅读
通用命令执行

什么时候应该拆开

如果 agent 的职责明显不同，最好拆开。

例如：

coordinator
只保留编排、总结、任务拆分相关 skills
dev
侧重代码实现、修改、重构、运行开发命令
qa
侧重测试执行、回归验证、日志分析、验收检查

这样做的好处是：

降低无关技能干扰
减少 prompt 污染
让 agent 行为边界更清楚
方便定位问题出在哪个 agent

一个简化的职责建议

coordinator
负责收需求、拆任务、决定调用谁、汇总结果
dev
负责实现、修改代码、生成 patch、执行开发相关命令
qa
负责跑测试、验证输出、检查回归、整理测试结论

更新后的总体建议

如果你的目标是做一个“开发 + 测试”的多 agent 系统，建议按下面的方式理解和落地：

默认入口统一进 coordinator
bindings 主要解决“入口消息归谁”
subagents.allowAgents 解决“主 agent 可以调谁”
skills 按职责做差异化配置
dev 和 qa 各自使用独立 workspace / agentDir / session

这样整个结构会更清晰：

网关层靠 bindings 做静态路由
任务层靠 coordinator 做动态编排
能力层靠不同 skills 做边界划分

目录CONTENT

【Openclaw】openclaw多Agent配置方式

结论

OpenClaw 多 Agent 的基本结构

关键限制

1. 每个 agent 必须独立

2. `bindings` 是“二选一”路由，不是“多 agent 会签”

3. A 开发、B 测试，更像 orchestration

推荐理解方式

方案 A：按入口路由到不同 agent

方案 B：主 agent 调度子 agent

示例配置 1：最基础的多 Agent 路由

示例配置 2：按具体群/会话绑定不同 Agent

示例配置 3：更接近“开发 + 测试协作”的方式

如果只是想要“开发 Agent + 测试 Agent”我建议这样配

最小可执行建议

一句话总结

补充问题 1：默认进来时，怎么决定用哪个 agent

也就是说，默认选 agent 主要依据是入口，不是语义

推荐策略

补充问题 2：一个主 agent 是否可以发起其他所有 agent

是否建议直接配 `["*"]`

额外注意

补充问题 3：每个 agent 是否需要绑定不同 skills

什么时候可以共用

什么时候应该拆开

推荐做法

一个简化的职责建议

更新后的总体建议

【Openclaw】openclaw多Agent配置方式

结论

OpenClaw 多 Agent 的基本结构

关键限制

1. 每个 agent 必须独立

2. bindings 是“二选一”路由，不是“多 agent 会签”

3. A 开发、B 测试，更像 orchestration

推荐理解方式

方案 A：按入口路由到不同 agent

方案 B：主 agent 调度子 agent

示例配置 1：最基础的多 Agent 路由

示例配置 2：按具体群/会话绑定不同 Agent

示例配置 3：更接近“开发 + 测试协作”的方式

如果只是想要“开发 Agent + 测试 Agent”我建议这样配

最小可执行建议

一句话总结

补充问题 1：默认进来时，怎么决定用哪个 agent

也就是说，默认选 agent 主要依据是入口，不是语义

推荐策略

补充问题 2：一个主 agent 是否可以发起其他所有 agent

是否建议直接配 ["*"]

额外注意

补充问题 3：每个 agent 是否需要绑定不同 skills

什么时候可以共用

什么时候应该拆开

推荐做法

一个简化的职责建议

更新后的总体建议

2. `bindings` 是“二选一”路由，不是“多 agent 会签”

是否建议直接配 `["*"]`