OpenClaw 实战指南

Appearance

8.3 Agent间通信 ​

想象一下这个场景：

你是项目经理，接到一个任务：“写一篇 AI 趋势分析”。

你不会自己干所有事。你会：

  • 让研究员去收集资料
  • 让写手根据资料写文章
  • 让编辑审核发布

这就是团队协作——每个人各司其职，但需要通信。

多 Agent 不是各自为战，而是需要协作。一个 Agent 接到任务，可能要派给其他 Agent 执行。这一节，我们用20分钟，学会Agent间通信的两种方式。

通信方式概览 ​

OpenClaw 提供了两种 Agent 间通信方式：

方式作用使用场景
sessions_send往另一个 Agent 的会话发消息让其他 Agent 干活，结果返回给自己
sessions_spawn在当前 Agent 下开子任务重活、需要干净上下文、后台执行

第一步：开启通信权限 ​

Agent 之间默认不能互相通信。你需要在配置里显式开启：

json5
{
  tools: {
    agentToAgent: {
      enabled: true,
      allow: ["main", "research", "writer", "coder"]
    }
  }
}

⚠️ 重要：只有 allow 列表里的 Agent 才能互相通信。

第二步：写团队通讯录 ​

开启权限还不够——每个 Agent 得知道有哪些“同事”可以联系。

在 AGENTS.md 里写明团队通讯录：

markdown
# AGENTS.md - 团队通讯录

你是主 Agent，负责接收指令并分发任务。

## 团队成员

- research（研究员）：负责资料收集和分析
  - 专长：搜索、数据整理
  - 调用方式：sessions_send to research

- writer（写手）：负责内容创作
  - 专长：写文章、改文案
  - 调用方式：sessions_send to writer

- coder（工程师）：负责代码实现
  - 专长：写脚本、修 bug
  - 调用方式：sessions_send to coder

就像入职第一天，公司得给你通讯录——不然你都不知道该 @ 谁。

两种方式的区别 ​

sessions_send：跨Agent发消息 ​

特点：

  • 消息进入对方已有的上下文
  • 回复只返回给调用方，不会在飞书群里显示
  • 如果目标 Agent 没有会话，会静默创建 webchat session（对方收不到）

流程示意：

飞书群里：

你 @主Agent：帮我写一篇AI趋势分析

主Agent内部：
sessions_send → research Agent
research Agent完成研究，返回结果给主Agent

主Agent再调用：
sessions_send → writer Agent（带上研究结果）
writer Agent完成写作，返回给主Agent

主Agent汇总，在群里回复你

sessions_spawn：开子任务 ​

特点：

  • 全新上下文，不影响主会话
  • 非阻塞，立即返回 runId
  • 完成后自动向请求者聊天渠道发完成消息
  • 子 Agent 不能生成子 Agent（防止嵌套扇出）

流程示意：

飞书群里：
你 @主Agent：帮我研究一下本周AI趋势

主Agent spawn子任务：
"研究本周AI趋势，输出到 intel/DAILY-INTEL.md"

子Agent后台运行，完成后在群里通告结果
主Agent继续处理其他事情

试一试：配置Agent间通信 ​

步骤1：开启权限 ​

编辑 ~/.openclaw/openclaw.json：

json5
{
  tools: {
    agentToAgent: {
      enabled: true,
      allow: ["main", "research", "writer"]
    }
  }
}

步骤2：写团队通讯录 ​

在 main Agent 的 AGENTS.md 里添加：

markdown
## 团队成员

- research（研究员）：负责资料收集和分析
  - 专长：搜索、数据整理
  - 调用方式：sessions_send to research

- writer（写手）：负责内容创作
  - 专长：写文章、改文案
  - 调用方式：sessions_send to writer

步骤3：测试通信 ​

在聊天里对 main Agent 说：

帮我研究一下 OpenClaw 的多Agent功能，
然后写一篇简短的介绍。

观察它是否会自动调用 research 和 writer。

对话示例 ​

场景：主 Agent 接到“写一篇 AI 趋势分析”的任务

你：@主Agent 帮我写一篇AI趋势分析

主Agent：（收到任务，分析需要先研究）
主Agent：（调用 sessions_send → research）

research Agent：（研究完成，返回结果）
“本周AI领域的主要趋势是...”

主Agent：（收到研究结果，调用 sessions_send → writer）
主Agent：（传递研究结果给 writer）

writer Agent：（写作完成，返回文章）
“AI趋势分析报告...”

主Agent：好的，文章已经准备好了。以下是内容：
[完整文章]

会话传递：让Agent看到完整上下文 ​

Agent 之间传递的不仅是消息，还有会话上下文。

sessions.visibility 配置 ​

json5
{
  tools: {
    sessions: {
      visibility: "all"  // 让所有Agent共享频道内的全量上下文
    }
  }
}

如果不开启 all，当你 @writer 干活时，它只知道你 @ 了它，却看不见前面 research 出的方案。

开启后，每个 Agent 都能感知到频道里发生的一切，就像大家坐在一张圆桌前开会。

注意：这个配置只影响 Agent 能否“看到”频道里的消息，不影响文件系统的隔离。

实战技巧 ​

技巧1：明线+暗线 ​

飞书有 Bot-to-Bot Loop Prevention 机制，Agent A @Agent B，Agent B 的后台收不到推送。

解决方案：

  • 暗线：用 sessions_send 走底层进行数据交换
  • 明线：在群里用文本汇报进度

技巧2：文件中转站 ​

长内容不要直接 send，会撑爆对方的上下文。把内容写到共享文件里，send 只传文件路径：

workspace/
├── intel/
│   └── DAILY-INTEL.md      # 研究员写，其他人读
├── drafts/
│   └── article-v1.md       # 写手写，编辑读
└── output/
    └── final.md            # 最终输出

技巧3：子Agent成本优化 ​

每个子 Agent 都有自己的上下文和 token 使用量。对于繁重或重复的任务：

  • 子 Agent 用便宜的模型（如 Gemini 3 Flash）
  • 主 Agent 用高质量的模型（如 Claude Opus）

在 spawn 时覆盖模型：

json5
{
  agents: {
    defaults: {
      subagents: {
        model: "google/gemini-3-flash"
      }
    }
  }
}

故障排查 ​

Agent之间无法通信 ​

检查项操作
agentToAgent.enabled确认为 true
allow 列表确保相关 Agent 在列表中
AGENTS.md 通讯录确保写明了团队成员

send的回复收不到 ​

检查项操作
回复位置send 的回复只返回给调用方，不会在群里显示
目标Agent会话如果目标 Agent 没有会话，会静默创建 webchat session

子Agent“忘事” ​

检查项操作
MEMORY.md子 Agent 看不到 MEMORY.md，需要的历史上下文要手动粘进 task
白名单文件子 Agent 只能看到 5 个白名单文件

长内容撑爆上下文 ​

检查项操作
内容长度长内容写到共享文件，send 只传文件路径
对方上下文让对方自己去读文件，不要在 send 里粘贴长内容

这一节，你做了什么 ​

学了什么核心理解
通信方式sessions_send 跨Agent发消息，sessions_spawn 开子任务
权限配置需要开启 agentToAgent，设置 allow 白名单
团队通讯录在 AGENTS.md 里写明成员和调用方式
会话共享sessions.visibility: "all" 实现上下文穿透
实战技巧明线+暗线、文件中转站、成本优化

下一节 ​

Agent 之间能通信了。但如果有多个 Agent，消息来了该给谁？

基于 MIT 许可发布

Copyright © 2025 Gleam2Torch