OpenClaw 架构设计实战:Multi-Agent 与 Sub-Agent 怎么选?

用 OpenClaw 搭系统时，经常纠结一个问题：是配多个独立 Agent 长期运行，还是用一个主 Agent 临时拉 Sub-Agent 干活？这两种模式差别很大，选错了后期改起来很痛苦。今天聊聊我的实践经验。

先搞懂本质区别

很多人以为 Multi-Agent 和主+Sub-Agent 只是叫法不同，都是"多个 Agent 一起干活"。其实完全是两回事。

维度	Multi-Agent	主 Agent + Sub-Agent
存在方式	长期独立运行	临时拉起，用完即走
核心能力	各管一摊，边界清晰	任务拆分，并行执行
适用场景	多角色长期分工	复杂任务临时拆解
配置成本	高（每个都要配）	低（按需 spawn）
隔离程度	完全隔离	会话内共享

一句话：Multi-Agent 是"养了几个专职员工"，主+Sub-Agent 是"临时外包几个临时工"。

Multi-Agent：什么时候该用？

典型场景

你有多个长期稳定、职责明确的角色：

写作 Agent：专门处理内容创作
运维 Agent：专门处理系统监控
研究 Agent：专门做资料搜集分析

每个角色有独立的：

workspace（工作目录）
认证配置（不同平台的 API key）
会话存储（不互相污染）
人设和规则（SOUL.md、AGENTS.md）

路由机制

Multi-Agent 的核心价值在于入口级分流：

用户消息 → Gateway → Router → 不同 Agent                ↓        飞书消息 → 工作 Agent        Telegram → 个人 Agent          Discord  → 运营 Agent        某个群   → 特定 Agent

关键：消息还没进 Agent，就已经被路由到对应的地方。不是先进一个总控再分发。

我的踩坑经验

坑 1：一开始拆太细

刚开始我配了七八个 Agent：writer、ops、research、coding、design... 结果自己都记不住该找谁，维护成本爆炸。

建议：

先 2-3 个核心角色
跑一段时间看是否真的需要拆分
再逐步增加

坑 2：误以为 workspace 是强隔离

OpenClaw 的 workspace 只是默认工作目录，不是沙箱。不同 Agent 之间如果配置不当，文件、认证还是可能互相影响。

建议：

需要真正隔离时，看 sandbox 配置
敏感操作加权限控制

主 Agent + Sub-Agent：什么时候该用？

典型场景

你有一个统一的入口（比如一个主 Telegram 账号），但偶尔遇到复杂任务需要拆解：

用户：帮我写一篇技术文章主 Agent 判断：这个任务可以拆  ↓  ├─ Sub-Agent A：去搜资料（并行）  ├─ Sub-Agent B：整理大纲（并行）  └─ Sub-Agent C：等 A 做完后做事实核查（串行）  ↓主 Agent 汇总结果 → 生成最终文章

为什么不用一个 Agent 全包？

试过让一个 Agent 全做，问题很明显：

上下文爆炸：查资料、搭结构、改措辞全混在一起，前面搜到的垃圾信息污染后面的判断
目标漂移：写着写着忘了最初要干什么
没法局部重跑：某个环节出问题，只能全部重来
速度慢：所有事串行做

拆成 Sub-Agent 后，每个只干一件事，清爽多了。

实操方式

OpenClaw TUI 里直接用斜杠命令：

/subagents spawn --task "搜集 Transformer 优化相关资料"/subagents spawn --task "整理文章大纲结构"/subagents list          # 看哪些 Sub-Agent 在跑/subagents steer <id>    # 给某个 Sub-Agent 发指令/subagents kill <id>     # 结束某个 Sub-Agent

注意：Sub-Agent 是 OpenClaw 内部的机制，不是 ACP 外部 harness。如果要接 Codex、Claude Code 这些外部工具，那是另一回事。

混合架构：我的推荐方案

用了一段时间后，我发现纯 Multi-Agent 或纯主+Sub 都不够灵活，现在用的是混合模式：

第一层：长期 Agent（Multi-Agent）

配 2-3 个核心角色：

main    → 默认入口，简单任务直接处理writer  → 内容创作类任务ops     → 系统运维类任务

第二层：Sub-Agent（任务拆解）

在 writer 或 ops 内部，遇到重活时 spawn：

writer 内部：

主 Agent 接收需求  ↓  ├─ Sub 1：查资料（搜 10 篇相关文章）  ├─ Sub 2：整结构（输出大纲）  └─ Sub 3：校对（检查事实错误）  ↓主 Agent 汇总 → 输出成品

ops 内部：

主 Agent 接收告警  ↓  ├─ Sub 1：查日志  ├─ Sub 2：做配置对比  └─ Sub 3：生成修复建议  ↓主 Agent 汇总 → 输出处理方案

为什么这样设计？

入口统一：用户永远只跟 main/writer/ops 对话，不感知后面的复杂性
灵活拆解：需要并行时用 Sub-Agent，不需要时主 Agent 直接处理
渐进演进：某个 Sub-Agent 的任务模式稳定后，可以升级成独立长期 Agent

选型决策树

开始  ↓有多个长期稳定的角色？  ├─ 是 → 需要不同入口直接路由？  │         ├─ 是 → Multi-Agent  │         └─ 否 → 主 Agent + Sub-Agent  │  └─ 否 → 主要是复杂任务拆解？            ├─ 是 → 主 Agent + Sub-Agent            └─ 否 → 先一个主 Agent 就够了

快速判断

你的情况	推荐方案
有 writer/ops/research 等长期角色，各管一摊	Multi-Agent
只有一个主入口，偶尔需要拆任务并行处理	主 + Sub-Agent
两者都有	混合架构
刚起步，还没想清楚	先一个主 Agent，跑着看

配置建议

如果走 Multi-Agent

# 1. 创建 Agentopenclaw agents add writeropenclaw agents add ops# 2. 配置路由（关键！）openclaw agents bind --agent writer --bind telegram:writer_botopenclaw agents bind --agent ops --bind discord:ops_bot# 3. 每个 Agent 配齐自己的 identity# writer/workspace/SOUL.md → "你是一个技术写作专家..."# ops/workspace/SOUL.md → "你是一个运维工程师..."# 4. 重启生效openclaw gateway restart

如果走主 + Sub-Agent

# 1. 先确保主 Agent 配好# main/workspace/SOUL.md 里明确说明会 spawn sub-agent# 2. TUI 里直接用/subagents spawn --task "具体任务描述"# 3. 监控和管理/subagents list/subagents steer <id> "补充指令"/subagents kill <id>

常见误区

误区 1：Sub-Agent 可以替代 Multi-Agent

错误：把所有长期角色都做成 Sub-Agent。

问题：Sub-Agent 不是入口级角色，没法直接绑定渠道，也不适合长期驻场。

误区 2：Multi-Agent 越多越好

错误：一开始配七八个 Agent。

问题：维护成本爆炸，自己都记不住该找谁。

误区 3：两种模式必须二选一

错误：要么纯 Multi-Agent，要么纯主+Sub。

实际：混合架构往往最实用，长期角色用 Multi-Agent，复杂任务用 Sub-Agent。

总结

模式	核心定位	最佳实践
Multi-Agent	长期角色分工	2-3 个核心角色，入口级路由
主+Sub-Agent	任务拆解执行	按需 spawn，用完即走
混合架构	两者结合	长期层 + 执行层分层设计

我的建议：

刚起步：一个主 Agent 够用
有多个长期角色：上 Multi-Agent
任务复杂需要拆解：用 Sub-Agent
两者都有：混合架构，分层设计

架构设计没有银弹，关键是先跑起来，再逐步演进。

养虾经验分享，欢迎交流~

关注我，获取更多大模型训练/部署、AI Infra的硬核技术干货，带你从原理到实战，玩转大模型！