OpenClaw多Agent通信的那点事:为什么子agent老失联?

[!INFO] 文章概览

• 文章字数：约 2800 字
• 预计阅读时间：约 7 分钟
• 内容摘要：从底层讲清楚 OpenClaw Gateway 的核心职责、Agent 的能力边界、Cron 运行机制和 Agent 间通信方案，帮你在搭建多 Agent 体系时避开最常见的三个坑。

想象一下：你花了两周时间搭了一套 OpenClaw 多 Agent 体系——A Agent 管写作，B Agent 管代码，C Agent 管日常。结果上线第一天就翻车了：发给 A Agent 的消息石沉大海，Cron 任务漏了一半，Agent 之间跟失联了一样各干各的。

这时候你可能开始怀疑：是不是 OpenClaw 不稳？是不是配置写错了？

大概率不是。大多数人的问题出在一个地方：没搞清楚 Gateway 到底是什么，Agent 之间到底怎么通信。

今天从底层讲清楚。

一、Gateway：消息世界的”总机”

先明确一个定位：Gateway 是 OpenClaw 的控制平面（Control Plane），Agent 是业务执行方。 它跟 Agent 的关系，像公司的总机与各个分机部门——消息进来先到总机，总机根据分机号转给对应的部门处理。

Gateway 运行在你的 Mac mini、VPS 或本地机器上，核心职责就四件事：

可以这么理解：Gateway 就像公司的电话总机——所有来电（消息）先到它这里，它根据分机号（Binding 规则）转给对应的部门（Agent）。Agent 处理完，结果经总机原路返回。中间 Gateway 不干业务的活，但少了它，电话就打不通了。

你手机上打开飞书跟 Main Agent 聊天，这条消息的实际链路是：

飞书 → Gateway（收到消息） → 匹配 Binding 路由 → Main Agent（处理） → Gateway → 飞书（回你消息）

中间 Gateway 不抢戏，但少了它，全链路就断了。

二、Agent 分两种，权限不对等

OpenClaw 有两种 Agent，而且它们不是平等的：

实际的能力边界是这样的：

一句话总结：Sub Agent 是被调度者，不是调度者。

这个区分很重要，因为很多人的”Sub Agent 收不到消息”问题，根源就是没理解这条权限边界——Sub Agent 不会自己找活干，必须有人（Main Agent 或 Cron）叫它。

三、最容易搞混的部分：Cron 运行机制

Cron 是定时任务。但关键在这里：Cron 不是 Agent 级别的功能，是 Gateway 级别的功能。

什么意思？只有 Main Agent 能创建和管理 Cron。Sub Agent 的定时任务，要么是 Main Agent 帮它创建的，要么在 openclaw.json 里手动配置。

举个例子——你给 A Agent（管理内容创作）说”帮我每天早上 9 点检查新闻”：

❌ A Agent 会回答你”好的，我来设置”，但它做不到。它没有 cron 权限。

✅ 正确做法是 A Agent 将你的请求传递给 Main Agent，由 Main Agent 执行 openclaw cron add 创建定时任务。执行时 Gateway 会唤醒 A Agent、将任务结果发回给你。

查看当前所有 Cron：

openclaw cron list

你会看到一列定时任务，每条记录包含名称、执行周期、上次执行时间、目标 Agent ID。这个列表是全局的——只有 Main Agent 能看到全部，Sub Agent 只能看到跟自己有关的。

误区澄清：不是”Main Agent 执行所有 Cron 任务”。Cron 任务是 Gateway 调度的，Main Agent 只是有权创建和管理它们。任务执行时 Gateway 会唤醒对应的 Agent 来干活——所以半夜执行的内容巡检 Cron，是 Gateway 唤醒 A Agent，让 A Agent 去跑。

四、Agent 间通信：sessions_send 的真相

多 Agent 体系里，Agent 之间怎么聊天？OpenClaw 内置了 sessions_send 工具：

Main Agent → sessions_send("A Agent", "帮我写一篇 AI 工具介绍") → A Agent

思路没问题，但实操下来坑不少：

• 超时：sessions_send 等待目标 Agent 执行完再返回，如果任务复杂（比如 A Agent 要搜 10 个网页、生成 2000 字），很容易超时，返回一个”执行失败”——但 A Agent 明明已经在干活了。
• 送达不确定：超时后主调方不知道消息到底送达了没有。
• 单向：被调 Agent 处理完后，没法主动通知主调 Agent”我好了”。

更稳的方案：共享文件夹轮询

不少 OpenClaw 用户在实践一种更可靠的方式：

Main Agent → 写任务文件到 ~/.openclaw/shared/tasks/ → Sub Agent 通过 Cron 定时扫描 → 读取并处理

优势很明显：

1. 不依赖实时网络通信：写文件总比等消息超时靠谱
2. 有记录可追溯：所有任务都有文件日志，排查问题一目了然
3. Agent 可以主动拉任务：配合定时 Cron，Sub Agent 每隔一段时间扫描一次共享文件夹，有新任务就处理

跟你用飞书协同文档管理团队任务一样——每个人定期查看自己的任务列表，完成了标记状态，而不是靠 @人吵架。

五、三个实战中的典型坑

这些坑在搭建过程中常见的社区反馈：

🕳️ 坑 1：以为发了消息 = 对方收到了

sessions_send 超时后，消息可能根本没送达目标 Agent。正确做法：用共享文件夹 + 状态标记。发任务时写一个 JSON 文件，目标 Agent 处理完后回写一个 {status: "done"}。

🕳️ 坑 2：以为 Agent 会自动扫描任务

Agent 不是人，它不会闲着没事”找活干”。OpenClaw Agent 只在三种情况下被唤醒：

• 收到飞书/微信等通道消息
• Cron 定时任务触发
• 其他 Agent 通过 sessions_send 调用

如果你没给 Agent 配定时 Cron，它就是”被动上班”——你叫它才动。

🕳️ 坑 3：调度者自己成了瓶颈

Main Agent 负责所有调度和协调，但如果所有任务都经过它中转，Main Agent 的 session 很快就会被撑爆。

正确做法：Main Agent 只做轻量调度——判断任务类型、分发给对应 Agent、标记任务状态。具体的”重活”（写作、搜索、代码）交给 Sub Agent，不经过 Main 中转。

六、给你的多 Agent 搭建建议

如果你也想搭一套自己的多 Agent 体系，推荐从最小可用架构开始：

Gateway（跑在 1 台机器上）├── Main Agent（调度中心，不干重活）├── A Agent（内容创作，独立飞书 bot）└── B Agent（健康/巡检，定时检查系统状态）

四个原则记住就行：

1. Main 是调度中心，不是干活主力。 它的工作是”指派”，不是”包办”
2. Sub Agent 专注垂直领域，各守边界。 写文章的不看代码，写代码的不管健康
3. 通信用文件，不依赖 sessions_send。 共享文件夹是最稳定的 Agent 间通信方式
4. 状态可验证，不靠假设。 定期检查 Agent workspace 文件更新时间，而不是”我觉得它在运行”

写在最后

OpenClaw 的多 Agent 架构很强——独立的 workspace、独立的记忆、独立的人格定义，真正做到”在一个 Gateway 上跑一支团队”。但三个关键点最容易出错：

• Cron 只有 Main Agent 能管理，Sub Agent 只是”被叫起来干活”
• sessions_send 有超时和送达不确定性，共享文件是更靠谱的选择
• 状态验证大于状态假设——Agent 不会主动报平安，需要你主动查

搞清楚这些，你的多 Agent 体系才能真正自动化运转，而不是每天人工 debug。

参考资料

1. OpenClaw 官方文档 – Multi-agent Routing: https://docs.openclaw.ai/concepts/multi-agent
2. OpenClaw Multi-Agent Guide (Heyuan110): https://www.heyuan110.com/posts/ai/2026-02-23-openclaw-multi-agent-guide/
3. OpenClaw Architecture, Explained (ppaolo Substack): https://ppaolo.substack.com/p/openclaw-system-architecture-overview
4. OpenClaw GitHub Repository: https://github.com/openclaw/openclaw