02-配置 · 00 多 Agent 架构

预计阅读：12 分钟适用版本：公开稳定包 OpenClaw 2026.5.2；作者端已验证 2026.5.7 · 最后审核：2026-05-09 本章回答：从零规划多 agent 拓扑。要分几个？按什么切？先上哪个？

前置阅读：03-多Agent/00-协作拓扑（了解拓扑模式）

为什么不能”按感觉分”

新手最常见的错：

❌ 按"工作阶段"分： 需求收集 / 方案设计 / 执行 / 复盘
❌ 按"工具"分：    写文档 agent / 查资料 agent / 做图 agent
❌ 按"AI 模型"分： Claude agent / GPT agent / MiniMax agent

这些分法很快就变样：一个任务跨多个阶段、多个工具、多个模型。分在一起时 agent 要频繁切换上下文，非常累。

正确的切分维度：业务领域 / 用户群体 / 数据边界。

决策流程（4 步决定拓扑）

步骤 1：列出你要让 agent 做的所有事

不用想 agent，先想事。列 15-30 条具体任务，不是抽象职责。

例：

- 在飞书群里答用户问题
- 每周五整理本周民宿订单
- 月底发招生报告
- 监控 gateway 健康，异常时通知
- 爬竞品小红书数据
- 写小学招生公众号文案
- 帮我规划下周待办
- 记录我对"重复决策"的偏好
- 早上 9 点发 daily-digest 卡片
- 把会议纪要转成任务清单
- ...

步骤 2：按”数据边界”聚类

问：这些任务的数据各自不能混。

“民宿订单 / 房态 / 收益” 是一类（不能和招生混）
“招生物料 / 家长咨询” 是一类（和民宿隔离）
“小红书运营 / 内容素材” 是一类（独立业务线）
“系统健康 / 维护脚本” 是一类（元能力，跟业务无关）
“用户日常对话 / 规划” 是一类（跨业务的协调层）

每一类可能就是一个 agent。

步骤 3：加两个跨业务 agent

不管你业务切几块，下面两个几乎都要：

main（入口 + 协调）—— 唯一的飞书私聊入口，路由到正确业务 agent
planner（规划 + 方法论）—— 独立于业务，专注”拆解任务”这件事

加了 planner 之后，main 不用管”怎么拆”，只管”派给谁”。SOUL 更干净。

步骤 4：考虑要不要加一个”反思者”

第三个备选 agent：reflector。它不参与业务，只做两件事：

周期性整理记忆（把散落的 memory/YYYY-MM-DD.md 上卷到 MEMORY.md）
输出周审卡片（一周工作总结 / 偏差识别）

什么时候加 reflector：

✅ 你愿意每周花 15 分钟看周审卡片
✅ 你有 3+ 业务 agent，需要一个”旁观者”视角
❌ 你刚开始，业务 agent 都没调顺

不急着加。先跑通业务，再加 reflector。

典型三档拓扑

根据你的业务规模，选一档起步。

档 A · 单 agent（起步）

用户 → main（什么都自己干）

适用：刚装完 OpenClaw，还没明确多 agent 需求。 维护成本：最低。 天花板：SOUL 超过 8KB 就开始乱。

档 B · main + planner + 1 业务（推荐大多数）

用户 → main ─┬→ planner（规划）
             └→ 业务agent

适用：有 1 条明确业务线（如”民宿运营”），需要 AI 记长期账。 维护成本：中。踩坑：初期容易把 planner 当成”又一个问答 agent”。planner 只负责拆解 + SOP，不答业务问题。

档 C · main + planner + 3-5 业务 + reflector（作者当前）

用户 → main ─┬→ planner
             ├→ 民宿
             ├→ 招生
             ├→ 运营
             └→ 学习伙伴
        reflector（周期性，不在主链路）

适用：多条业务线，且需要跨业务的记忆沉淀。 维护成本：高。每周至少 2 小时维护（看周审、调 SOUL、跑 weekly-maintenance）。上限：不超过 7 个 agent（参考 shared/AGENTS.md 不成文规则）。

何时拆新 agent（三个信号）

已有 agent 跑一段时间后，要不要拆？看三个信号：

信号 1：某 agent 的 SOUL + TOOLS 超过 15KB

读 SOUL 已经成了”每次 /reset 最费时”的环节。拆出一块独立职责到新 agent。

信号 2：记忆库里两类事实互相污染

现象：在民宿 agent 问”怎么上房”，memory_recall 召回一堆”招生物料模板” —— 说明当前 agent 的语义库混了两类事实。

拆 → 给”招生”独立 agent，让它有自己的记忆空间。

信号 3：两类任务有不同的失败模式

如：业务咨询失败了用户能自己改述；但浏览器自动化失败了需要截图分析、重启 CDP、重新登录。这两种失败的处理流程完全不一样，放一起会互相掩盖。

拆 → 浏览器自动化独立（参考作者的 shangfang）。

何时不要拆（反信号）

❌ 因为”想试试多 agent” 而拆 —— 拆了就要维护 5 份 SOUL
❌ 为了让某个 agent “显得专业” —— 用户不关心你几个 agent，只关心回答
❌ 为了”绕开某个 bug” —— 拆了不代表 bug 消失，只是换个地方出

一个反例：作者早期想把”日常对话”和”命令执行”拆成两个 agent。结果发现用户经常是”聊着聊着要执行命令”，切换 agent 反而断了上下文。后来合回一个 main 反而更顺。

拓扑规划自查表

做决定前先回答：

[ ] 我列出了 15+ 条具体任务（不是抽象职责）
[ ] 我按"数据边界"聚类，而不是按"工作阶段"
[ ] 我确定了 main 以外的每个 agent 的**唯一核心职责**
[ ] 每个 agent 的职责一句话能说清（超过两句就拆）
[ ] 我算过维护成本（每 agent 每周至少 30 分钟 review）
[ ] 我预留了 1 个名额给 reflector（哪怕现在不加）
[ ] 我在 openclaw.json 的 `subagents.allowAgents` 里规划好了白名单

七项全答”yes”再开配。不是的话先回到步骤 1 重来。

先上哪个（落地顺序）

不要一次上 5 个 agent。按这个顺序：

① main（跑通飞书、SOUL、IDENTITY）       ← 01-入门/02 已覆盖
② main + planner（验证派发链路）          ← 验证 03-多Agent/00 的拓扑
③ 上第 1 个业务 agent（最成熟的那条业务）
④ 稳定 2 周后上第 2 个业务 agent
⑤ 3+ 业务后再考虑 reflector

每加一个 agent，必过 01-入门/03-验证的 8 维验证。

常见拓扑误区

误区 1：“planner 就是 main 的副驾驶，可以直接给用户回”

错。planner 不面向用户，只面向 main。 planner 的输出是拆解清单 / SOP，由 main 加工后再给用户。原因：planner 的语气和 main 不一样（更理性、更结构化），直接给用户会割裂。

误区 2：“业务 agent 之间可以互相调用”

看 shared/AGENTS.md：sub-agent 不主动路由给同级 sub-agent。原因：避免循环调用、责任不清。做法：业务 A 需要业务 B 协助 → 回报 main → main 判断要不要派 B。

误区 3：“agent 越多越智能”

反。agent 越多，每次路由决策越慢，每次派发前确认流程越长，用户耐心越短。实际：3-5 个 agent 是大多数场景的甜点。超过 7 个难维护。

误区 4：“每个 agent 都要有飞书 bot”

不。reflector / planner 可以没有独立 bot，只通过 sessions_send / sessions_spawn 被 main 调起。好处：省飞书应用、省 Verification Token、省维护。

从拓扑规划到 openclaw.json

规划定了之后，在 ~/.openclaw/openclaw.json 的 agents.list[] 配置：

{
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "subagents": { "allowAgents": ["planner", "minsu", "reflector"] },
        "...": "..."
      },
      {
        "id": "planner",
        "subagents": { "allowAgents": ["main"] },
        "...": "..."
      },
      {
        "id": "minsu",
        "subagents": { "allowAgents": ["main", "shangfang"] },
        "...": "..."
      }
    ]
  }
}

关键字段（完整字段见 03-多Agent/00-协作拓扑第 7 节）：

id：唯一标识
default：飞书私聊默认指向哪个 agent
subagents.allowAgents：允许派发到的白名单
groupChat.mentionPatterns：群聊 @ 匹配规则（没飞书 bot 可不配）
tools.alsoAllow：额外允许的工具

下一步

01-记忆系统 —— 配好多 agent 后，给每个 agent 装记忆
02-Skills选择 —— 哪些 skill 必装、哪些可选
03-飞书深度配置 —— openclaw-lark vs 官方插件迁移史
03-多Agent/01-委派机制 —— 派发陷阱深度

本章准确性保证 拓扑档位 A/B/C 基于作者 20+ 天从单 agent → 5 agent 的真实演进。三个”拆 agent 信号”和四个”误区”都有对应的踩坑日期可查（作者 memory/2026-03-XX 日记）。

导航：← 验证 · 📖 目录 · → 记忆系统