多 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)
└─ = 上述方案 × 云原生基础设施
扫一扫
964
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
