文章目录
- [多 Agent 系统设计参考框架（OpenClaw 实现版）](#多 Agent 系统设计参考框架（OpenClaw 实现版）)
-
多 Agent 系统设计参考框架（OpenClaw 实现版）
〇、基础概念三层
| 概念 |
定义 |
OpenClaw 对应 |
一句话 |
| LLM |
大语言模型本身，只能单次回答 |
可接入的模型（DeepSeek/Claude/GPT 等） |
会说的"脑子" |
| Agent |
带有目标、工具、记忆、能循环行动的 AI 程序 |
OpenClaw 中的 Agent（由 SOUL.md 定义） |
会做事的"员工" |
| Workflow |
定义多个 Agent/Nodes 的执行顺序、条件、失败处理 |
通过路由规则 (bindings) 和消息通道 (sessions_send) 编排 |
管流程的"规章" |
一切多 Agent 架构，本质上是把多个 Agent 按某种 Workflow 组织起来。
一、静态结构：以 OpenClaw 为例的嵌套模型
复制代码
部署环境 (单机 / 集群 / 云)
└─ OpenClaw 实例 (Instance) ------ 一个操作系统进程，拥有独立内存空间
└─ 网关 (Gateway) ------ 绑定一个端口，消息的唯一出入口
└─ Agent ------ 拥有独立 SOUL、记忆、工作目录的 AI 个体
└─ 会话 (Session) ------ 单次对话的上下文容器
| 概念 |
准确定义 |
关键约束 |
| 部署环境 |
Agent 系统运行的物理或虚拟载体 |
单机、多机集群、云主机、容器集群等 |
| 实例 |
一个运行中的 OpenClaw 进程 |
拥有 OS 隔离的独立内存空间；不同实例在进程层互不可达 |
| 网关 |
实例内的消息路由层 |
一个实例一个主网关，绑定一个端口；多实例不可共占同一端口 |
| Agent |
拥有独立 SOUL.md、记忆、工作目录的 AI 单元 |
同一实例内可存在多个；互相知晓；上下文严格隔离 |
| 会话 |
单次对话的上下文容器 |
归属唯一 Agent；结束后记忆可选择保留 |
层级关系：一个网关下可以有 N 个 Agent；每个 Agent 下有 N 个会话。
复制代码
单实例多 Agent 示例：
┌──────────────────────────────────────────┐
│ 网关 (Gateway) │
│ 一个进程，绑定一个端口 │
│ 例：gateway @ 127.0.0.1:18789 │
│ ────────────────────────────────────── │
│ │
│ ├── Agent: alice │
│ │ ├── 工作目录: /workspace/alice/ │
│ │ │ ├── SOUL.md │
│ │ │ ├── USER.md │
│ │ │ ├── TOOLS.md │
│ │ │ └── memory/ │
│ │ ├── 模型: DeepSeek │
│ │ ├── 会话: Session A │ ← 实例化的对话
│ │ └── 会话: Session B (后台 spawn) │
│ │ │
│ ├── Agent: scout │
│ │ ├── 工作目录: /workspace/scout/ │
│ │ ├── 模型: DeepSeek │
│ │ └── 会话: Session C │
│ │ │
│ └── Agent: ... │
└──────────────────────────────────────────┘
二、隔离光谱：L1--L6 部署层级
复制代码
硬隔离 ←------------------------------------------------------------------------------------------------------------------------------------------------------------------------------→ 软协作
L1 L2 L3 L4 L5 L6
物理隔离 虚拟化隔离 容器化隔离 多实例隔离 同网关多Agent 单Agent多角色
| 层级 |
部署方式 |
隔离机制 |
实例数 |
网关数 |
Agent 间感知 |
典型场景 |
| L1 |
多台物理设备各运行 OpenClaw |
物理断网 |
N |
N |
❌ |
红蓝对抗完全分离 |
| L2 |
单设备多 VM 各运行 OpenClaw |
独立 OS/内核/网络栈 |
N |
N |
❌ |
需独立 IP 的安全任务 |
| L3 |
单设备多容器各运行 OpenClaw |
共享内核，命名空间隔离 |
N |
N |
可配 |
轻量快速部署销毁 |
| L4 |
单 OS 多 OpenClaw 实例 |
进程级隔离 |
N |
N(各占端口) |
❌ 互不知晓 |
一机服务多客户互盲 |
| L5 |
单实例多 Agent |
应用层上下文隔离 |
1 |
1 |
✅ 互相知晓 |
团队内部分工协作 |
| L6 |
单实例单 Agent 多角色 |
无架构隔离，纯提示词切换 |
1 |
1 |
N/A |
个人临时角色扮演 |
核心原则：隔离级别越向左，安全性越高，协作成本越高；越向右，协作越顺，但风险越集中。
三、单机三种部署基元
| 方案 |
实例数 |
Agent/实例 |
网关数 |
Agent 感知 |
映射层级 |
本质描述 |
| 方案 1 |
1 |
1 |
1 |
N/A |
L6 |
最简基元：openclaw agents add main |
| 方案 2 |
1 |
N |
1 |
✅ 互相知晓 |
L5 |
内部协作：通过 sessions_send 通信 |
| 方案 3 |
N |
1 |
N(各占端口) |
❌ 默认互不知晓 |
L4 |
完全隔离：多实例各占独立端口 |
方案 3 扩展： 可通过反向代理、Redis 消息队列、通信中继等外部手段使多个实例的 Agent 互相感知和通信------集群通信的起点。
四、通信机制
| 通信距离 |
对应方案 |
OpenClaw 通信机制 |
关键特征 |
| 同屋檐 (同一实例) |
方案 2 / L5 |
sessions_send 内部消息通道 |
极低延迟，不需网络 |
| 同小区 (同机不同实例) |
方案 3 / L4 |
本地 HTTP API / 本地 Redis MQ |
需主动调用或投递 |
| 天南海北 (多机集群) |
L1--L3 + 网络 |
网络 Redis/Kafka MQ / 通信中继 |
异步解耦，需寻址与容错 |
五、拓扑与协作：双维度的正交"排兵布阵"
5.1 六大拓扑结构
| 拓扑 |
结构 |
优点 |
缺点 |
OpenClaw 实现方式 |
| 平行式 |
并列，互不通信 |
绝对隔离 |
无协作 |
方案 3：多实例互盲 |
| 星型式 |
一处中枢，多卫星 |
控制集中，易管理 |
中枢单点故障 |
一个 Planner Agent 通过 sessions_send 调度多个子 Agent |
| 流水线式 |
A→B→C 链式 |
流程清晰，易调试 |
僵化，一步卡全停 |
各 Agent 通过 sessions_send 依次传递产物 |
| 接力式 |
Agent 主动转移任务给更合适的 Agent |
去中心，专业匹配 |
需清晰转移协议 |
Agent 判断任务类型后 sessions_send 给专职 Agent |
| 网状式 |
任意点对点 |
灵活，容错 |
消息风暴，难治理 |
所有 Agent 间开放 sessions_send 权限 |
| 层级式 |
多级星型嵌套 |
可扩展，权责分明 |
深层次延迟，顶层风险 |
队长 Agent 下挂多个小组 Agent，各组再管队员 |
5.2 四大协作对话模式
| 模式 |
机制 |
方向 |
驱动类型 |
| 委派执行 |
主 Agent 派任务，等结果 |
单向 |
动作驱动 (动词) |
| 招标投标 |
发布任务，多 Agent 竞标 |
多对一 |
动作驱动 |
| 协商辩论 |
多观点碰撞，达成共识 |
双向/多向 |
动作+思维驱动 |
| 广播同步 |
一对多发布状态更新 |
一对多 |
动作驱动 |
拓扑与协作正交，可任意组合。 同时必须搭配产物流转（名词驱动）：传递结构化产物（Spec、报告、验收单），而非仅仅定义"谁对谁说话"。
六、认知协作
6.1 三种认知子模式
| 子模式 |
机制 |
通用场景举例 |
| 串联式 |
A→B→C 链式接力，允许驳回 |
初诊→专家会诊→处方审核 |
| 辩论式 |
并行输出→互相挑战 |
投资决策多因子辩论 |
| 金字塔式 |
并行收集→汇总提炼→统一报告 |
多渠道舆情分析→汇总简报 |
6.2 最小可行架构（PER 三元组）
复制代码
Planner (规划者) → Executor (执行者) → Reviewer (验收者)
| 角色 |
职责 |
OpenClaw 实现 |
| Planner |
拆解目标，生成结构化 Spec |
一个 Agent，仅持有 sessions_send、file_share、read_file 权限 |
| Executor |
按 Spec 执行，产出结构化报告 |
一个或多个 Agent，持有执行类工具，接收 Spec JSON |
| Reviewer |
对照 Spec 验收，决定放行/打回 |
一个 Agent，仅持有只读权限，拥有驳回权 |
七、二维架构矩阵
横轴：隔离度（L1--L6） × 纵轴：组织方式（7 种框架 + PER）
任何交点都是一个可落地的方案，标注 ✓/△/✗ 表示适合程度。
|
L1 物理机 |
L2 VM |
L3 容器 |
L4 多实例 |
L5 同网关多 Agent |
L6 单 Agent 多角色 |
| AutoGen 对话协作 |
多机对话，最安全 |
标准实践 |
可行 |
基本等同 L4 |
降级为内部消息 |
违背设计意图 ✗ |
| CrewAI 角色团队 |
重但可用 |
各 VM 一角色 |
轻量团队 |
自然 |
最舒服 ✓ |
偷懒但危险 |
| LangGraph 图状态 |
分布状态管理复杂 |
需网络状态同步 |
K8s 级 |
可本地 RPC |
最简单 ✓ |
上下文已乱 |
| MetaGPT SOP 流水线 |
不适用 |
可用 |
可用 |
适合 |
顺畅 |
容易自说自话 |
| CAMEL 社会仿真 |
真·社会实验 |
好 |
好 |
好 |
限制多 |
看不出效果 |
| 生产 SDK 型 |
数据合规场景 |
标准部署 |
推荐 |
推荐 |
不够安全 |
不安全 ✗ |
| 可视化平台型 |
外部接入 |
可部署 |
常见 |
可部署 |
不可部署 ✗ |
不可部署 ✗ |
| PER 最小可用 |
物理隔离 PER |
标准 PER |
轻量 PER |
快速 PER |
推荐起点 |
最小但不推荐 |
各交点落地快照（OpenClaw 实现版）：
| 组织方式 × 隔离级 |
Planner |
Executor |
Reviewer |
通信通道 |
| PER × L2 |
宿主机队长 Agent |
队员各占独立 VM 中的 Agent |
独立验收 VM |
网络 Redis/Kafka MQ |
| PER × L4 |
独立实例，仅发 Spec |
独立实例，接收本地 HTTP/MQ |
独立验收实例 |
本地 HTTP / Redis MQ |
| PER × L5 |
同网关规划 Agent |
同网关子 Agent |
同网关验收 Agent |
sessions_send |
| CrewAI × L5 |
Crew 内 Supervisor |
Crew 内角色 Agent |
Crew 内 Reviewer |
框架内部消息 |
| LangGraph × L5 |
图入口 Node |
各执行 Node |
条件边 + 校验 Node |
图状态流转 |
| 生产 SDK × L4 |
独立规划实例 |
隔离执行沙箱 |
独立审计实例 |
gRPC / MQ |
设计方法：先用总表选定 (组织方式, 隔离级) 交点，再用快照表确定各角色的部署位置，最后填入对应的通信机制。
八、工程铁律
- 必须设验收 Agent：执行与验收必须分离，防止"自己出题自己判"。
- 任务交接深度限制 ：一项任务转手超过 3 次 即失控，超过 5 次必须重构流程。
- 权限与工具边界：与隔离级别强绑定。L2 队员 Agent 不应有访问宿主机数据库的权限。
- 全链路可观测：日志、链路追踪，所有 Agent 行动需可回溯。
- 拒绝聊天室产物：Agent 间传递必须是结构化数据（JSON Spec、报告 MD、状态码），严禁把聊天记录当 API。
九、部署环境全景
复制代码
部署环境
└─ 单机
├─ 方案 2 = L5：单实例多 Agent
│ 通信：sessions_send（内部消息通道）
└─ 方案 3 = L4：多实例单 Agent
通信：本地 HTTP API / 本地 Redis MQ
打通：反向代理 / 通信中继
└─ 多机集群
└─ = L2/L4 场景 + 网络通信层
通信：远程 HTTP API / 网络 Redis/Kafka MQ / 通信中继
└─ 云环境 (IaaS/PaaS/SaaS)
└─ = 上述方案 × 云原生基础设施