24d - Agent 间通信
本文是《AI Agent 实战手册》第 24 章第 4 节。 上一节:24c-自定义集成教程 | 下一节:24e-社区插件生态
概述
当一个 OpenClaw Gateway 上运行多个 Agent 时,它们之间如何交换信息、协调任务、达成共识?本节系统讲解 OpenClaw 的四种 Agent 间通信机制——共享内存、消息传递、事件广播和”AI 委员会”圆桌模式——帮助你根据场景选择最合适的协作方案,构建真正高效的多 Agent 团队。
1. 共享内存(MEMORY.md)
工作原理
OpenClaw 的记忆系统基于 Markdown 文件。每个 Agent 拥有独立的工作空间(agentDir),其中包含 MEMORY.md 等文件用于持久化状态。Agent 在每次被触发时读取这些文件,在任务结束时写回更新。
共享内存的核心思路是:让多个 Agent 读写同一组 Markdown 文件,从而实现信息共享。这类似于多线程编程中的”共享内存”模型——不同 Agent 通过读写公共文件来交换数据,而非直接发送消息。
┌─────────────┐ ┌──────────────────┐ ┌─────────────┐
│ Agent A │────▶│ shared/ │◀────│ Agent B │
│ (研究员) │ │ MEMORY.md │ │ (写作者) │
│ │────▶│ FINDINGS.md │◀────│ │
└─────────────┘ │ STATUS.md │ └─────────────┘
└──────────────────┘
▲
┌──────┴──────┐
│ Agent C │
│ (审核员) │
└─────────────┘配置与使用
方式一:符号链接共享目录
最简单的方式是通过文件系统符号链接,让多个 Agent 的特定文件指向同一位置:
# 创建共享目录
mkdir -p /path/to/openclaw/shared-memory
# 在 Agent A 的工作空间中创建符号链接
ln -s /path/to/openclaw/shared-memory/SHARED_MEMORY.md \
/path/to/openclaw/agents/agent-a/SHARED_MEMORY.md
# 在 Agent B 的工作空间中创建同样的符号链接
ln -s /path/to/openclaw/shared-memory/SHARED_MEMORY.md \
/path/to/openclaw/agents/agent-b/SHARED_MEMORY.md方式二:使用 MemOS 插件(推荐)
MemOS 提供了专门的 OpenClaw 插件,将共享内存抽象为统一的记忆层:
# agents.yaml 中配置 MemOS 插件
agents:
research-agent:
plugins:
- name: memos-memory
config:
pool: "team-alpha" # 共享内存池名称
access: read-write
namespace: research # Agent 专属命名空间
writer-agent:
plugins:
- name: memos-memory
config:
pool: "team-alpha" # 同一内存池
access: read-write
namespace: writing方式三:SOUL.md 中声明共享文件
在 Agent 的 SOUL.md 中明确指示它读写共享文件:
<!-- Agent A 的 SOUL.md -->
## 协作规则
- 你是研究团队的一员
- 将研究发现写入 `../shared/FINDINGS.md`
- 在开始新任务前,先读取 `../shared/STATUS.md` 了解团队进度
- 完成任务后更新 `../shared/STATUS.md` 中你的状态共享内存工具推荐
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| MemOS Plugin | 统一共享内存层,支持命名空间和访问控制 | 免费(开源) | 多 Agent 团队协作,推荐方案 |
| Ensue | Agent 共享记忆网络 | 免费(开源) | 需要跨 Agent 知识订阅和权限管理 |
| mem0 | 个性化 AI 记忆层 | 免费(开源)/ 云版 $49/月起 | 需要语义搜索和自动记忆提取 |
| supermemory | 开源记忆管理 | 免费(开源) | 轻量级记忆共享 |
| 符号链接 | 文件系统级共享 | 免费 | 最简单的共享方案,适合 2-3 个 Agent |
优缺点
优点:
- 实现简单,无需额外基础设施
- 人类可读——直接打开 Markdown 文件即可审查 Agent 共享的内容
- 持久化天然支持——文件系统即数据库
- 使用 MemOS 可降低约 60-70% 的 token 消耗(避免重复加载上下文)
缺点:
- 无实时通知——Agent B 不知道 Agent A 何时更新了文件,需要轮询或定时读取
- 并发写入风险——两个 Agent 同时写同一文件可能导致数据丢失
- 缺乏结构化协议——文件格式依赖约定,没有 schema 验证
- 扩展性有限——Agent 数量增多时,文件冲突概率上升
2. 消息传递(sessions_spawn / sessions_send)
Agent 间直接通信
OpenClaw 的 Gateway 是所有通信的中枢。Agent 之间不直接对话,而是通过 Gateway 的消息队列间接通信。当 Agent A 需要通知 Agent B 时,它向 Gateway 发送一条内部消息,Gateway 将其放入 Agent B 的任务队列,就像处理普通用户消息一样。
┌──────────┐ 内部消息 ┌──────────┐ 路由到队列 ┌──────────┐
│ Agent A │───────────────▶│ Gateway │───────────────▶│ Agent B │
│ (研究员) │ │ (路由器) │ │ (写作者) │
└──────────┘ └──────────┘ └──────────┘
│
│ 路由到队列
▼
┌──────────┐
│ Agent C │
│ (审核员) │
└──────────┘这种设计的关键洞察是:Agent 间的消息和用户消息走同一条路径。Gateway 不区分消息来源,统一排队、按序处理。这保证了系统的简洁性和可预测性。
父子 Agent 模式
sessions_spawn 允许一个 Agent(父)创建子 Agent 会话来处理独立任务。子 Agent 拥有完全隔离的执行环境:
┌─────────────────────────────────────────────────┐
│ 父 Agent(编排者) │
│ │
│ "请分别研究这三个竞品" │
│ │ │ │ │
│ spawn ▼ spawn ▼ spawn ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 子Agent1 │ │ 子Agent2 │ │ 子Agent3 │ │
│ │ 竞品A研究 │ │ 竞品B研究 │ │ 竞品C研究 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ ▼ │
│ 结果汇总到父 Agent │
└─────────────────────────────────────────────────┘每个子 Agent 获得唯一的会话标识符,格式为 agent:{agentId}:subagent:{uuid}。关键特性:
- 上下文隔离:子 Agent 有独立的上下文窗口和对话历史,不会看到父 Agent 的对话内容
- 并行执行:多个子 Agent 可同时运行,将串行任务变为并行
- 结果回传:子 Agent 完成后自动将结果发送回父 Agent 的会话
- 无嵌套限制:子 Agent 不能再创建自己的子 Agent(防止递归失控)
使用 /subagents 管理子 Agent
# 查看所有运行中的子 Agent
/subagents list
# 查看特定子 Agent 的详细信息
/subagents info <subagent-id>
# 向运行中的子 Agent 发送补充指令
/subagents send <subagent-id> "请重点关注定价策略"
# 查看子 Agent 的完整对话日志
/subagents log <subagent-id>
# 终止不再需要的子 Agent
/subagents stop <subagent-id>权限委派
Agent 间消息传递涉及重要的安全边界:
# agents.yaml - 权限隔离配置
agents:
orchestrator:
model: claude-sonnet-4-20250514 # 高能力模型用于编排
tools:
- sessions_spawn
- sessions_send
auth_profiles:
- github-admin
- slack-admin
research-worker:
model: claude-haiku # 低成本模型用于执行
tools:
- web_search
- file_read
auth_profiles:
- github-readonly # 只读权限
# 注意:worker 没有 sessions_spawn 权限,不能创建子 Agent权限设计原则:
- 最小权限:Worker Agent 只获得完成任务所需的最少权限
- 凭证隔离:每个 Agent 的 API 密钥和 OAuth token 严格隔离
- 单向委派:编排者可以创建 Worker,但 Worker 不能反向创建编排者
- 模型分层:编排者使用高能力模型(如 Opus/Sonnet),Worker 使用低成本模型(如 Haiku)
3. 事件广播
事件总线机制
OpenClaw 的 Gateway 本质上是一个事件驱动系统。它接受五种输入源:
- 用户消息(来自 Telegram/Slack/WhatsApp 等)
- 心跳事件(定时器,默认每 30 分钟触发一次)
- Cron 任务(定时调度,如每天早上 9 点)
- 内部 Hook(系统状态变化事件)
- Webhook(外部系统回调)
加上第六种:Agent 间消息。
所有这些输入都进入同一个事件队列,由 Gateway 统一路由和调度。这意味着事件广播可以利用现有的 Hook 和 Webhook 机制实现。
┌─────────────────────────────────────────────────────────┐
│ Gateway 事件总线 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ 用户消息 │ │ 心跳/Cron │ │ Webhook │ │ Hook │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └───┬────┘ │
│ │ │ │ │ │
│ └─────────────┼─────────────┼─────────────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 事件队列 │ │
│ └──────┬───────┘ │
│ │ │
│ ┌──────────┼──────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐┌──────────┐┌──────────┐ │
│ │ Agent A ││ Agent B ││ Agent C │ │
│ └──────────┘└──────────┘└──────────┘ │
└─────────────────────────────────────────────────────────┘订阅与发布
使用 Hook 实现事件订阅
Agent 可以通过 Hook 机制订阅特定的系统事件。当事件发生时,Gateway 自动触发对应 Agent 的处理逻辑:
# Agent A 的 hooks 配置 - 发布事件
hooks:
on_task_complete:
trigger: "agent_action_end"
action: |
将任务结果写入 ../shared/EVENTS.md,格式:
## [时间戳] research-complete
- agent: research-agent
- topic: {{topic}}
- status: done
- output: ../shared/findings/{{topic}}.md
# Agent B 的 hooks 配置 - 订阅事件
hooks:
on_startup:
trigger: "gateway_start"
action: "读取 ../shared/EVENTS.md,检查是否有未处理的 research-complete 事件"
on_heartbeat:
trigger: "heartbeat"
action: "检查 ../shared/EVENTS.md 是否有新的 research-complete 事件,如有则开始写作任务"使用 Webhook 实现跨系统事件
// 外部系统通过 Webhook 触发 Agent
// POST /webhook/agent-b
{
"event": "research_complete",
"source": "agent-a",
"payload": {
"topic": "竞品分析",
"findings_path": "/shared/findings/competitor-analysis.md"
}
}跨 Agent 事件流
一个典型的跨 Agent 事件流示例——产品调研到文档生成:
时间线 ──────────────────────────────────────────────────▶
[Cron 触发] [Hook 触发] [Hook 触发]
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 调研Agent │─────▶│ 写作Agent │─────────▶│ 审核Agent │
│ │ 写入 │ │ 写入 │ │
│ 每日9am │ 共享 │ 检测到新 │ 共享 │ 检测到新 │
│ 执行调研 │ 内存 │ 调研结果 │ 内存 │ 草稿完成 │
└──────────┘ └──────────┘ └──────────┘
│ │ │
▼ ▼ ▼
FINDINGS.md DRAFT.md REVIEW.md4. “AI 委员会”圆桌模式
设计理念
“AI 委员会”(AI Committee)或”圆桌模式”(Roundtable Pattern)是一种高级多 Agent 协作模式,灵感来自人类的委员会决策机制。多个具有不同专业背景和视角的 Agent 围绕同一议题展开结构化讨论,通过多轮辩论和投票达成共识。
这种模式的核心价值在于:单个 AI 的判断可能有偏差,但多个不同视角的 AI 交叉验证可以显著提高决策质量。学术研究(如 ReConcile 框架)已证明,多 Agent 圆桌讨论在复杂推理任务上的表现优于单 Agent。
┌──────────────┐
│ 主持人Agent │
│ (Moderator) │
└──────┬───────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 安全专家 │ │ 架构师 │ │ 产品经理 │
│ Agent │ │ Agent │ │ Agent │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└────────────┼────────────┘
▼
┌──────────────┐
│ 共识决策输出 │
└──────────────┘配置方法
在 OpenClaw 中实现圆桌模式,需要配置一个编排者 Agent 和多个专家 Agent:
步骤 1:定义专家 Agent
# agents.yaml
agents:
moderator:
model: claude-sonnet-4-20250514
soul: |
你是圆桌讨论的主持人。你的职责是:
1. 将议题分发给所有专家
2. 收集每位专家的独立意见
3. 识别分歧点并引导深入讨论
4. 在 3 轮讨论后发起投票
5. 综合所有意见形成最终决策
tools:
- sessions_spawn
- sessions_send
- file_write
security-expert:
model: claude-sonnet-4-20250514
soul: |
你是一位资深安全工程师。在圆桌讨论中,你从安全角度评估方案:
- 攻击面分析
- 数据泄露风险
- 合规性要求
- 安全最佳实践
始终优先考虑安全性,即使这意味着增加复杂度。
architect:
model: claude-sonnet-4-20250514
soul: |
你是一位系统架构师。在圆桌讨论中,你从架构角度评估方案:
- 可扩展性
- 性能影响
- 技术债务
- 维护成本
追求简洁优雅的设计,避免过度工程。
product-manager:
model: claude-sonnet-4-20250514
soul: |
你是一位产品经理。在圆桌讨论中,你从产品角度评估方案:
- 用户体验影响
- 上线时间
- 商业价值
- 竞品对比
始终以用户价值为导向。步骤 2:编写圆桌讨论 Skill
<!-- skills/roundtable-discussion.md -->
# 圆桌讨论 Skill
## 触发条件
当用户说"发起圆桌讨论"或"让团队讨论一下"时激活。
## 执行流程
### 第一轮:独立分析
1. 将议题同时发送给所有专家 Agent(使用 sessions_spawn 并行)
2. 每位专家独立分析,输出结构化意见:
- 立场(支持/反对/有条件支持)
- 关键论点(3-5 条)
- 风险评估(高/中/低)
- 建议行动
### 第二轮:交叉审查
3. 收集所有专家意见后,将汇总发送给每位专家
4. 每位专家针对其他人的意见提出质疑或补充
### 第三轮:共识形成
5. 收集第二轮反馈,识别共识点和分歧点
6. 对分歧点发起加权投票
7. 生成最终决策报告
## 输出格式
将讨论结果写入 `ROUNDTABLE_RESULT.md`,包含:
- 议题摘要
- 各专家立场汇总
- 共识点
- 分歧点及投票结果
- 最终建议
- 风险提示决策聚合策略
圆桌模式的核心挑战是如何从多个 Agent 的意见中提取最终决策。以下是四种常用策略:
策略 1:多数投票(Majority Voting)
专家A: 方案1 ✓ 专家B: 方案2 ✓ 专家C: 方案1 ✓
│
▼
最终决策: 方案1(2:1)最简单的策略。每个 Agent 投一票,多数胜出。适合二选一的决策场景。
策略 2:置信度加权投票(Confidence-Weighted Voting)
# 伪代码:置信度加权投票
votes = {
"security_expert": {"choice": "方案A", "confidence": 0.9},
"architect": {"choice": "方案B", "confidence": 0.6},
"product_manager": {"choice": "方案A", "confidence": 0.8},
}
# 加权计算
scores = {}
for agent, vote in votes.items():
choice = vote["choice"]
scores[choice] = scores.get(choice, 0) + vote["confidence"]
# 结果: 方案A = 1.7, 方案B = 0.6 → 选择方案A策略 3:否决权机制(Veto Power)
特定领域的专家对其领域内的决策拥有否决权:
- 安全专家可以否决任何存在严重安全风险的方案
- 架构师可以否决违反核心架构原则的方案
- 产品经理可以否决严重损害用户体验的方案
策略 4:辩论收敛(Debate Convergence)
多轮辩论直到所有 Agent 达成一致或分歧缩小到可接受范围:
第1轮: A=方案1, B=方案2, C=方案2 (分歧度: 高)
第2轮: A=方案2(修改版), B=方案2, C=方案2(修改版) (分歧度: 低)
第3轮: 所有人同意方案2(修改版) (达成共识)5. 通信模式对比与选择
工具推荐表(含价格列)
| 工具/框架 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| OpenClaw Gateway | 内置 Agent 间消息路由和事件队列 | 免费(开源) | 所有 OpenClaw 多 Agent 场景 |
| MemOS Plugin | 共享内存层,降低 token 消耗 | 免费(开源) | 需要共享知识库的团队 |
| Ensue | Agent 共享记忆网络,支持订阅 | 免费(开源) | 需要实时记忆同步 |
| LangGraph | 状态图驱动的多 Agent 编排 | 免费(开源)/ LangSmith $39/月起 | 复杂工作流编排,需要精确状态控制 |
| CrewAI | 角色制多 Agent 协作框架 | 免费(开源)/ Enterprise 定制 | 角色明确的团队协作 |
| AutoGen | 多 Agent 对话框架 | 免费(开源) | 需要 Agent 间自由对话的场景 |
| Hookdeck | Webhook 事件网关 | 免费(5,000 事件/月)/ $49/月起 | 需要可靠 Webhook 投递和重试 |
| QuorumAI | 多模型审议平台 | 免费试用 / 按量计费 | 需要多模型交叉验证的决策场景 |
模式对比表
| 维度 | 共享内存 | 消息传递 | 事件广播 | 圆桌模式 |
|---|---|---|---|---|
| 通信方式 | 读写共享文件 | Gateway 路由消息 | Hook/Webhook 触发 | 多轮结构化对话 |
| 耦合度 | 低(文件约定) | 中(需知道目标 Agent) | 低(发布-订阅) | 高(需要编排者) |
| 实时性 | 低(轮询) | 高(即时投递) | 中(事件驱动) | 中(多轮等待) |
| 复杂度 | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 适合 Agent 数 | 2-5 | 2-10 | 5-20 | 3-7 |
| Token 消耗 | 低 | 中 | 中 | 高(多轮对话) |
| 典型场景 | 知识共享、状态同步 | 任务委派、结果回传 | 工作流触发、通知 | 复杂决策、方案评审 |
| 持久化 | 天然支持 | 需额外配置 | 需额外配置 | 需写入结果文件 |
选择决策树
你需要 Agent 间通信吗?
│
├─ 只需要共享数据/知识 ──────────▶ 共享内存(MEMORY.md)
│
├─ 需要任务委派和结果回传
│ │
│ ├─ 任务可并行 ──────────────▶ sessions_spawn(父子模式)
│ │
│ └─ 任务需顺序执行 ──────────▶ sessions_send(直接消息)
│
├─ 需要松耦合的工作流触发
│ │
│ ├─ 仅限 OpenClaw 内部 ──────▶ Hook 事件
│ │
│ └─ 涉及外部系统 ────────────▶ Webhook 事件
│
└─ 需要多视角决策/评审 ──────────▶ 圆桌模式
│
├─ 简单投票 ────────────────▶ 多数投票策略
├─ 领域专家权重不同 ─────────▶ 置信度加权投票
└─ 安全/合规一票否决 ────────▶ 否决权机制实战案例:构建多 Agent 协作的产品开发团队
以下是一个完整的多 Agent 产品开发团队配置,综合运用四种通信模式:
团队架构
┌─────────────────────────────────────────────────────────────┐
│ 产品开发 Agent 团队 │
│ │
│ ┌──────────┐ 消息传递 ┌──────────┐ │
│ │ PM Agent │──────────────▶│ 开发Agent │ │
│ │ (产品经理) │ │ (全栈开发) │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ 共享内存 │ spawn │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ shared/ │ │ 测试Agent │ │
│ │ PRD.md │◀─────────────│ (QA工程师) │ │
│ │ SPEC.md │ └──────────┘ │
│ │ STATUS.md│ │
│ └──────────┘ 事件广播 │
│ ▲ ┌──────────┐ │
│ └──────────│ 审核Agent │ ◀── 圆桌模式(代码审查) │
│ │ (Tech Lead)│ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────────┘完整配置
# agents.yaml - 产品开发团队
agents:
pm-agent:
model: claude-sonnet-4-20250514
agentDir: ./agents/pm
soul: |
你是产品经理。职责:
1. 将用户需求转化为 PRD,写入 ../shared/PRD.md
2. 更新 ../shared/STATUS.md 中的项目进度
3. 需求确认后通知开发 Agent 开始工作
tools:
- sessions_send
- file_read
- file_write
hooks:
morning_standup:
trigger: "cron"
schedule: "0 9 * * 1-5" # 工作日早上 9 点
action: "读取 STATUS.md,生成每日站会摘要"
dev-agent:
model: claude-sonnet-4-20250514
agentDir: ./agents/dev
soul: |
你是全栈开发者。职责:
1. 读取 ../shared/PRD.md 了解需求
2. 编写代码并提交
3. 完成后 spawn 测试 Agent 进行验证
4. 代码审查通过后更新 ../shared/STATUS.md
tools:
- sessions_spawn
- file_read
- file_write
- shell_exec
auth_profiles:
- github-push
test-agent:
model: claude-haiku
agentDir: ./agents/test
soul: |
你是 QA 工程师。职责:
1. 接收开发 Agent 的测试请求
2. 运行测试套件
3. 将测试结果写入 ../shared/TEST_RESULTS.md
4. 如有失败,通知开发 Agent
tools:
- file_read
- shell_exec
review-agent:
model: claude-sonnet-4-20250514
agentDir: ./agents/review
soul: |
你是 Tech Lead。职责:
1. 监控 ../shared/STATUS.md 中的"待审查"状态
2. 发起圆桌讨论进行代码审查(安全、性能、可维护性)
3. 审查通过后更新状态为"已完成"
tools:
- sessions_spawn
- sessions_send
- file_read
- file_write
hooks:
check_reviews:
trigger: "heartbeat"
action: "检查 STATUS.md 是否有待审查的任务"工作流程
1. 用户向 PM Agent 描述需求
│
2. PM Agent 编写 PRD → 写入 shared/PRD.md
│ 更新 shared/STATUS.md = "需求已确认"
│
3. PM Agent 通过 sessions_send 通知 Dev Agent
│
4. Dev Agent 读取 PRD.md → 编写代码 → 提交
│
5. Dev Agent 通过 sessions_spawn 创建 Test Agent
│ (并行:Dev Agent 继续下一个任务)
│
6. Test Agent 运行测试 → 结果写入 shared/TEST_RESULTS.md
│ 更新 STATUS.md = "待审查"
│
7. Review Agent 心跳检测到"待审查" → 发起圆桌讨论
│ - 安全视角审查
│ - 性能视角审查
│ - 可维护性视角审查
│
8. 圆桌讨论结果写入 shared/REVIEW.md
│ 更新 STATUS.md = "已完成" 或 "需修改"
│
9. 如需修改 → 通知 Dev Agent → 回到步骤 4避坑指南
❌ 常见错误
-
过早引入多 Agent 架构
- 问题:很多开发者一开始就设计 14 个 Agent 的”梦之队”,结果配置复杂度爆炸,调试困难
- 正确做法:从单 Agent 开始,只在遇到明确的隔离需求时才添加新 Agent。每次只加一个,验证稳定后再加下一个
-
忽略并发写入冲突
- 问题:多个 Agent 同时写入同一个共享 Markdown 文件,导致内容丢失或格式损坏
- 正确做法:为每个 Agent 分配独立的写入区域(如不同的文件或文件中的不同 section),或使用 MemOS 等工具管理并发访问
-
子 Agent 上下文缺失
- 问题:spawn 子 Agent 时没有提供足够的上下文,子 Agent 像”新入职员工”一样一无所知
- 正确做法:在 spawn 指令中明确提供所有必要的背景信息、目标和约束条件,就像给新同事写详细的任务简报
-
圆桌讨论 Token 失控
- 问题:圆桌模式中多个 Agent 多轮对话,Token 消耗呈指数增长
- 正确做法:限制讨论轮数(通常 2-3 轮足够),使用结构化输出格式减少冗余,对 Worker Agent 使用低成本模型
-
缺乏通信审计
- 问题:Agent 间消息没有日志,出问题时无法追溯是哪个 Agent 发了什么消息
- 正确做法:所有 Agent 间通信都写入共享的
COMMUNICATION_LOG.md,包含时间戳、发送者、接收者和消息摘要
✅ 最佳实践
- 从单 Agent 开始,按需扩展:大多数场景下,一个配置良好的单 Agent 就够了。只在需要安全隔离、专业分工或资源管理时才引入多 Agent
- 明确定义通信协议:在 SOUL.md 中明确规定 Agent 间通信的格式、频率和内容,避免”自由发挥”导致的混乱
- 模型分层降低成本:编排者用高能力模型(Sonnet/Opus),Worker 用低成本模型(Haiku),可节省 50-70% 的 Token 费用
- 使用 /subagents 命令监控:定期检查子 Agent 状态,及时终止不需要的 Worker,避免资源浪费
- 共享内存 + 消息传递组合使用:用共享内存传递大量数据(文档、代码),用消息传递发送轻量级通知和指令
- 圆桌模式限定场景:只在高风险决策(架构选型、安全评审、上线审批)时使用圆桌模式,日常任务用简单的消息传递即可
相关资源与延伸阅读
- OpenClaw 官方文档 - Multi-Agent Configuration ——官方多 Agent 配置指南,包含完整的 API 参考
- MemOS OpenClaw Plugin ——共享内存插件,可降低 60-70% Token 消耗
- OpenClaw Sub-agents and Parallel Task Execution Guide ——子 Agent 并行执行的实战指南(2026 年 2 月)
- OpenClaw Multi-Agent Orchestration Advanced Guide ——高级多 Agent 编排模式详解(2026 年 2 月)
- ReConcile: Round-Table Conference Improves Reasoning via Consensus ——多 Agent 圆桌讨论提升推理质量的学术论文
- Building a Multi-Agent Debate System with LangGraph ——使用 LangGraph 构建辩论系统的教程
- Collaborative Memory: Multi-User Memory Sharing in LLM Agents ——多 Agent 协作记忆的学术研究(2025 年)
- AI Agent Coordination: 8 Patterns That Actually Work ——2026 年 Agent 协调模式实战总结
- Ensue - Shared Memory Network for Agents ——OpenClaw 共享内存 Skill,支持权限管理和订阅
- Hookdeck - Reliable Webhooks for AI Agents ——为 OpenClaw 提供可靠 Webhook 投递的事件网关
参考来源
- OpenClaw Multi-Agent Orchestration Advanced Guide (2026 年 2 月)
- OpenClaw Sub-agents and Parallel Task Execution Guide (2026 年 2 月)
- MemOS OpenClaw Plugin to cut agent memory costs by 70% (2026 年 2 月)
- How OpenClaw Works: The Real “Magic” (2026 年 2 月)
- OpenClaw: Architecture of a Local Agent (2026 年 2 月)
- The Architecture of Clawdbot (2026 年 2 月)
- Deep Dive: How OpenClaw’s Memory System Works (2026 年 1 月)
- ReConcile: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs (2023 年 9 月)
- Building a Multi-Agent Debate System with LangGraph (2025 年 10 月)
- AI Agent Coordination: 8 Patterns That Actually Work (2026 年 1 月)
📖 返回 总览与导航 | 上一节:24c-自定义集成教程 | 下一节:24e-社区插件生态