OpenClaw Agent 协作踩坑：3 个 Agent 一起干活，为什么比单打独斗还慢？
去年我在团队里尝试把运维工作流拆成 3 个 Agent 协作，想着自动化能省点时间。
📌 本文关键词：OpenClaw、多Agent协作、Agent踩坑、Agent死锁、OpenClaw协作，这些是运维中高频踩坑的技术点。
结果拆完后发现——3 个 Agent 一起跑，比一个人手动还慢。
我也经历过。今天聊聊真实踩坑经历。
一个真实的协作场景
我的工作流拆成了 3 个 Agent：
code
content_trend_agent → 抓热点、选题
wechat_creator_agent → 写正文、排版
content_pm_agent → 审核、归档
理想状态：A 写完 → B 接手 → C 归档，流水线。
实际运行：
code
A 写完了 → B 等 30 秒才收到消息 → B 开始写 → 写到一半被 C 打断 → C 以为该自己了 → 三个人抢同一个文件 → 崩了
3 个 Agent 一起跑，互相抢资源、互相等、互相覆盖。
问题 1：Agent 之间没有”锁”
单 Agent 工作时，OpenClaw 的 session 天然是串行的——你发一条消息，它处理完再回你。
但多 Agent 协作时，没有锁机制。
踩坑现场
yaml
# 错误的配置：3 个 Agent 共享同一个 session
agents:
– name: content_trend_agent
provider: openai
model: gpt-4o
– name: wechat_creator_agent
provider: openai
model: gpt-4o
– name: content_pm_agent
provider: openai
model: gpt-4o
当 A 和 B 同时收到消息，它们会同时处理。如果都写同一个文件，后写的覆盖先写的。
正确做法：分 session + 明确交接
yaml
# 正确配置：每个 Agent 独立 session，通过消息传递交接
agents:
– name: content_trend_agent
provider: openai
model: gpt-4o
session: session_trend # 独立 session
– name: wechat_creator_agent
provider: openai
model: gpt-4o
session: session_creator # 独立 session
– name: content_pm_agent
provider: openai
model: gpt-4o
session: session_pm # 独立 session
关键原则： 每个 Agent 独立 session，交接通过 sessions_send 发送消息，而不是直接操作同一个文件。
问题 2：Agent 之间的”死锁”
踩坑现场
A 在等 B 完成，B 在等 C 完成，C 在等 A 完成。
code
A: “B 你写完了吗？”
B: “C 你审核完了吗？”
C: “A 你选题定了吗？”
三个人互相等，谁也没干活。
正确做法：明确 DAG 依赖
不要用”互相通知”的方式协作，而是用明确的 DAG（有向无环图）：
code
content_trend_agent → wechat_creator_agent → content_pm_agent
↑ ↑ ↑
选题完成通知 正文完成通知 审核完成通知
实现方式：
javascript
// 在 trend_agent 完成选题后，通知 creator_agent
async function notifyCreator() {
await sessions_send({
sessionKey: ‘session_creator’,
message: ‘新选题已完成: “K8s 日志告警链路搭建”，请开始写正文’
});
}
// 在 creator_agent 完成正文后，通知 pm_agent
async function notifyPM() {
await sessions_send({
sessionKey: ‘session_pm’,
message: ‘正文已写完: “K8s 日志告警链路搭建”，请审核归档’
});
}
关键原则： 协作链路必须是单向 DAG，不能有环。A→B→C 可以，A→B→C→A 不行。
问题 3：Agent 之间的”上下文丢失”
踩坑现场
A 写完选题，把分析结果发给 B。
B 收到消息后，没有 A 的上下文，不知道 A 做了哪些分析，只能从消息里猜。
结果 B 写的正文和 A 的选题方向偏离了 30%。
正确做法：传递完整上下文
javascript
// 错误：只传标题
await sessions_send({
sessionKey: ‘session_creator’,
message: ‘新选题: “K8s 日志告警链路搭建”‘
});
// → B 不知道为什么选这个题，也不知道读者是谁
// 正确：传递完整上下文
await sessions_send({
sessionKey: ‘session_creator’,
message:
选题分析:
– 文章: K8s 日志告警链路搭建
– 理由: 日志采集深度延展，运维高频痛点
– 目标读者: 运维工程师
– 关键词: Loki告警, LogQL, Alertmanager
– 核心卖点: 从采集到告警到通知的完整链路
附件: /drafts/trend_analysis_20260722.json
});
关键原则： 交接消息里必须包含上下文摘要，让下一个 Agent 知道”为什么做这个”和”前面做了什么”。
问题 4：Agent 之间的”文件冲突”
踩坑现场
A 和 B 同时往同一个文件写内容。
code
A: 写入文件 output.yaml
B: 也写入文件 output.yaml
A: 覆盖了 B 的内容
B: 覆盖了 A 的内容
最终文件里内容混合了两部分，结构全乱。
正确做法：文件所有权
yaml
# 每个 Agent 只写自己的文件
agents:
– name: content_trend_agent
write_path: /drafts/trend/ # 只写 trend 目录
– name: wechat_creator_agent
write_path: /drafts/ # 写 drafts 目录
– name: content_pm_agent
read_path: /drafts/ # 只读 drafts 目录
write_path: /drafts/archived/ # 只写 archived 目录
关键原则： 每个 Agent 只能写自己的目录，只能读上一级的输出。不要共享写权限。
问题 5：Agent 之间的”超时”
踩坑现场
A 通知 B 写正文，B 开始写，但 A 不知道 B 要写多久。
结果 A 以为 B 失败了，又重新发了一次通知。B 收到了两条消息，写了两个版本。
正确做法：状态机 + 超时
yaml
# 在 Agent 配置中加入超时和重试
agents:
– name: wechat_creator_agent
timeout: 300s # 5 分钟超时
retry: 2 # 失败重试 2 次
on_timeout: notify # 超时后通知上游
– name: content_pm_agent
timeout: 120s # 2 分钟超时
retry: 1
on_timeout: escalate # 超时后升级通知
状态机示意：
code
IDLE → RECEIVED → PROCESSING → COMPLETED
↓ ↓
TIMEOUT FAILED
↓ ↓
RETRY NOTIFY_UPSTREAM
总结：多 Agent 协作的 5 条铁律
1. 分 Session — 每个 Agent 独立 session，不要共享
2. DAG 单向 — 协作链路必须是单向有向无环图，不能有环
3. 传上下文 — 交接消息包含完整上下文摘要，不要只传标题
4. 分文件 — 每个 Agent 只写自己的目录，不要共享写权限
5. 设超时 — 每个 Agent 配置超时和重试，避免死锁
一句话： 多 Agent 协作不是”把任务拆开就能快”，而是设计好链路、锁、上下文之后，才能真正提速。
——◆——
延伸阅读：
• OpenClaw 多 Agent 配置文档
• 用 sessions_send 实现 Agent 间通信
• 从单 Agent 到多 Agent 的迁移指南
收藏备用，下次排查直接翻这篇。你遇到过 Agent 协作的坑？留言说说你的经历。
——◆——
💡 觉得有用？转发给正在做多 Agent 协作的同事
你们团队在 Agent 协作上踩过什么坑？评论区聊聊👇
夜雨聆风
