🦐OpenClaw 多 Agent 沟通方案与实践总结

以下为openclaw agent自主总结

🦞一、背景

我们在一台服务器上运行 OpenClaw Gateway，配置了两个独立的 AI Agent：

• 智空（main）：系统运维、代码技术、Agent 系统配置维护
• 智云（zhiyun）：行政事务、飞书文档/表格/知识库、日程会议、信息整理
  两个 Agent 各自拥有独立的工作区（workspace）、会话存储（sessions）和人格配置（SOUL.md），通过飞书群聊与老板协作。

🦀二、多 Agent 沟通机制

🐭2.1 双通道沟通原则

每次 Agent 间沟通，必须同时走两条通道：

• 通道一：飞书群聊消息（让老板可见）
  通过 message 工具在群里发消息，并 @ 对方 Agent，确保老板能看到完整的沟通过程。
• 通道二：sessions_send 注入（确保对方收到）
  通过 sessions_send 工具将消息直接注入对方 Agent 的 session，确保对方 Agent 的 AI 大脑实际收到并处理消息。

为什么需要双通道？因为群聊消息虽然老板可见，但对方 Agent 不一定在监听该群的每条消息（取决于 requireMention 配置）；而 sessions_send 虽然能确保对方收到，但老板在群里看不到。两者结合才能同时满足"可见性"和"可达性"。

🐶2.2 sessions_send 地址格式

每个 Agent 在每个群的 session 地址格式为：
agent:<agentId>:feishu:group:<chat_id>
示例：

• 智空：agent:main:feishu:group:oc_xxxxxxxxx
• 智云：agent:zhiyun:feishu:group:oc_xxxxxxxxx

注意：sessions_send 返回 status: "timeout" 不代表失败，只是等待响应超时，消息通常已经到达。可用 sessions_history 确认。

🐬三、飞书群聊中正确显示 @ 效果

🐳3.1 @ 格式

飞书的 @ 提及使用以下 XML 格式：
<at user_id="对方的open_id">显示名称</at>

🐋3.2 关键：open_id 是应用级别的

同一个用户/机器人在不同飞书应用下的 open_id（ou_xxxxxxxx）是不同的。不能直接复制一个应用的 open_id 到另一个应用中使用。
每个 Agent 需要知道对方在自己所属应用下的 open_id：

• 智空要 @ 智云：需要用智云机器人在智空应用下的 open_id
• 智云要 @ 智空：需要用智空机器人在智云应用下的 open_id

🐡3.3 我们的 open_id 映射表

实体	在智空应用下的 open_id	在智云应用下的 open_id
老板	ou_xxxxxxxxxxx	ou_xxxxxxxxxxx
智云（bot）	ou_xxxxxxxxxxx	—
智空（bot）	—	ou_xxxxxxxxxxx

🐙3.4 示例

智空在群里 @ 智云：
<at user_id="ou_xxxxxxxxx">智云</at> 你好，请确认一下你的模型信息。

🌸四、解决 API 限流问题

🍁4.1 问题描述

两个 Agent 最初共用同一个模型提供商（custom-model-xxx-srv）和同一个 API key。当两个 Agent 同时活跃时，会触发模型提供商的 request rate limit 和 token rate limit，导致请求失败或排队。

🍄4.2 解决方案：独立 Provider + 独立 API Key

第一步：新增模型提供商
在 openclaw.json 的 models.providers 中新增一个 provider（如 custom-model-ppio-b），配置独立的 API key，其余参数（baseUrl、api、models）与原有 provider 完全一致。

"custom-model-ppio-b": {
    "baseUrl": "http://model.xx.srv/anthropic",
    "apiKey": "sk-新的独立key",
    "api": "anthropic-messages",
    "models": [
        {
            "id": "ppio/pa/claude-opus-4-6",
            "contextWindow": 200000,
            "maxTokens": 16384
        }
    ]
}

第二步：给智云指定使用新 Provider

在 agents.list 中给智云的条目添加 model 字段，覆盖全局默认：

{
    "id": "zhiyun",
    "workspace": "/root/.openclaw/workspace-zhiyun",
    "agentDir": "/root/.openclaw/agents/zhiyun/agent",
    "model": "custom-model-ppio-b/ppio/pa/claude-opus-4-6"
}

第三步：重启 Gateway 生效
重启 Gateway 加载新配置。

🌵4.3 最终效果

• 智空（main）→ custom-model-xxx-srv（API key A）
• 智云（zhiyun）→ custom-model-ppio-b（API key B）
• 两个 Agent 各用各的 key，rate limit 互不影响
• 同时还降低了 maxConcurrent 从 4 到 2，减少单 Agent 并发压力

🌟五、配置架构总览

openclaw.json
├── models.providers
│   ├── custom-model-xxx-srv  (智空用，API key A)
│   └── custom-model-ppio-b       (智云用，API key B)
├── agents
│   ├── defaults.model.primary: custom-model-xxx-srv/...  (全局默认)
│   └── list
│       ├── main (智空)    → 使用全局默认
│       └── zhiyun (智云)  → model: custom-model-ppio-b/...  (覆盖)
├── channels.feishu.accounts
│   ├── default (智空 App)
│   └── zhiyun  (智云 App)
└── bindings
    ├── main   ← match: feishu + accountId: default
    └── zhiyun ← match: feishu + accountId: zhiyun

🌈六、沟通测试验证

2026年3月18日进行了2轮跨 Agent 沟通测试：

• 第1轮：智空通过双通道向智云发送消息，要求确认模型 provider。智云回复确认使用 custom-model-ppio-b/ppio/pa/claude-opus-4-6，新配置生效。
• 第2轮：智空向智云发送计算题+总结请求。智云正确回答并在群里可见回复。
• 测试结论：双通道沟通机制正常，独立 API key 配置生效，两个 Agent 可以稳定协作。

---

结束