多 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

设计方法：先用总表选定 (组织方式, 隔离级) 交点，再用快照表确定各角色的部署位置，最后填入对应的通信机制。

---

八、工程铁律

1. 必须设验收 Agent：执行与验收必须分离，防止"自己出题自己判"。
2. 任务交接深度限制：一项任务转手超过 3 次 即失控，超过 5 次必须重构流程。
3. 权限与工具边界：与隔离级别强绑定。L2 队员 Agent 不应有访问宿主机数据库的权限。
4. 全链路可观测：日志、链路追踪，所有 Agent 行动需可回溯。
5. 拒绝聊天室产物：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)
       └─ = 上述方案 × 云原生基础设施