多 Agent 协作流程

流程一：标准任务流

每个任务从人类到交付的完整路径：

人类 (Telegram) → COO 接收
    ↓
COO 写任务简报（目标 / 上下文 / 完成标准 / 优先级）
    ↓
COO 分发到 Agent 的 Discord 频道
    ↓
Agent 执行 → 完成后 @提及 COO
    ↓
COO 收到结果 → 分发给 QA（质量检查）
    ↓
QA 审查 → 通过 / 不通过
    ↓
通过 → COO 向人类汇报
不通过 → 反馈给原 Agent → 修复 → QA 重审 → 循环直到通过

关键约束：

COO 永远不碰执行（首席运营官原则）
没有 QA 通过永远不说”完成”
每步都记录到 memory/YYYY-MM-DD.md

流程二：质量关卡

质量检查不是可选的。它是硬编码在系统里的约束。

QA 的审查清单

代码类交付：

代码逻辑是否正确
是否有安全漏洞（硬编码 API key、未验证输入）
构建是否通过
部署是否成功（HTTP 200，不是 404）
核心功能是否可用（不只是首页能打开 — 这是 2 月 8 日教训的直接产物）

内容类交付：

事实是否准确
语法/拼写
格式是否符合目标平台
敏感信息检查（不泄露 API key、个人信息）

质量检查失败后的流程

QA 不通过 → COO 提取失败原因
    ↓
COO 生成修复简报（包含 QA 的具体反馈）
    ↓
分发回原 Agent
    ↓
Agent 修复 → 重新提交
    ↓
QA 二次审查
    ↓
如果再次不通过 → 升级给人类

硬规则： 同一任务 QA 连续不通过两次 → 升级给人类，不继续循环。无限质量检查循环和无限 API 重试一样有害。

流程三：任务队列

所有任务记录在 memory/task-queue.md。格式：

- [ ] 任务描述 | 执行者: xxx | 优先级: P0 | 添加时间: 时间戳
- [x] 已完成任务 | 完成时间: 时间戳 | 质量检查状态: 通过
- [~] 进行中任务 | 分发时间: 时间戳
- [-] 已取消/回收 | 原因: 原因

任务优先级

级别	含义	行为
P0	人类明确要求	需要人类审批后执行
P1	重要	通知人类后执行
P2	自动化	直接执行
P3	低风险	直接执行，用便宜模型

任务队列规则

人类给的指令 → 全部变成待处理任务，零例外
队列里有待处理任务 → 立即分发下一个
Agent 完成 → 检查队列 → 分发下一个
永远不写 “等 Z 决定” 除非真的需要人类输入（比如需要密码、需要付款）
拿不准的 → 默认执行

这条规则的起源： 2026 年 2 月 11 日，子 Agent 凌晨 7:14 完成任务。剩余任务被写进”待办事项”列表，没有继续执行。COO 空转了 4 小时。人类醒来发现什么都没动。

流程四：心跳监控

COO 每 15 分钟执行一次自检（cron 触发）：

自检清单

读取今天的每日日志 — 了解上下文
读取任务队列 — 有没有待处理任务
自问三个问题：
- 有没有接近的截止时间？
- 有没有停滞的项目需要推一下？
- 有没有人类交代的事还没做？
如果有需要行动的事 → 做
如果没有 → HEARTBEAT_OK

Agent 失联处理流程

当 Agent 超过 30 分钟没有完成确认：

检测到超时
    ↓
第一步：检查 Agent 日志
    ├── 有错误日志 → 判断错误类型
    │   ├── API 错误 (429/403/500) → 切换模型或等待
    │   ├── 工具调用超时 → 可能是 SSH/网络问题
    │   └── 上下文溢出 → 需要新会话
    └── 日志正常 → Agent 可能在正常工作但比预期慢
        ↓
第二步：Telegram 通知人类
    内容包括：谁、什么任务、已经过了多久、日志摘要
        ↓
第三步：人类决定
    ├── 重试 → 新会话，重新分发任务
    ├── 换 Agent → 分发给其他有能力的 Agent
    ├── 换模型 → 同一 Agent，切换到更合适的模型
    └── 手动处理 → 人类自己来

已知缺陷： 如果 Agent 一直在输出但方向完全错误，超时不会触发。这需要结果验证（待办：计划实现基于输出内容的自动审查）。

流程五：跨网关协作

MacBook Air（COO + QA）和 Mac Mini（Coder + Research + Marketing）在不同网关上。sessions_send 只在同网关内有效。

当前方案

COO → Coder/Research/Marketing： 通过 Discord 消息发送
Coder/Research/Marketing → COO： 通过 Discord @提及
COO → QA： 通过 sessions_send（同网关，直接通信）

跨网关分发模板

~/.openclaw/bin/openclaw message send \
  --channel discord \
  --target "⚡・coder" \
  --message "[任务简报] — COO (首席运营官)"

跨网关踩坑总结

问题	原因	解法
`sessions_send` 不工作	只在同网关内有效	改用 Discord 消息
@提及不触发通知	纯文本 @name，不是 `<@BOT_ID>`	用正确的 Discord ID 格式
消息被静默丢弃	接收端 `users` 列表没包含 bot ID	加上所有 bot ID + `ignoreBots: false`
改了配置不生效	会话缓存旧配置	改配置后必须 `openclaw gateway restart`

详细过程： 见架构篇 — @提及三次翻车

流程六：记忆管理与优化

记忆架构

memory/
├── MEMORY.md          # 长期决策规则（手动维护，<200 行）
├── task-queue.md      # 当前任务队列
├── improvements-log.md # 改进记录（每次失败后更新）
├── 2026-01-25.md      # 每日日志
├── 2026-01-26.md
├── ...
└── 2026-03-09.md

三层记忆策略

层级	文件	内容	加载方式
一层：硬规则	SOUL.md	角色定义、行为约束、硬性规则	每次会话启动自动加载
二层：工作记忆	memory/YYYY-MM-DD.md	当天的任务记录、决策、进展	每次心跳自动读取
三层：长期规则	MEMORY.md	跨天的决策、教训、配置规则	每次会话启动自动加载

上下文管理实操

# 检查当前上下文使用率
# （在 Agent 会话内通过 cron 定期执行）

# SOUL.md 中的规则：
# ⛔ 硬规则：当上下文使用率 > 60% 时：
# 1. 保存当前状态到 memory/YYYY-MM-DD.md
# 2. 执行 /compact
# 3. 继续工作
# ⛔ 硬规则：永远不让上下文 > 70%

记忆文件模板

MEMORY.md 模板：

# MEMORY — 长期决策规则

## 模型规则
- ⛔ 不通过 OpenClaw OAuth 调用 Anthropic
- 前端任务用 Kimi 2.5，后端用 Codex
- 2 次 API 失败后停止，不无限重试

## 通信规则
- Discord @提及必须用 <@BOT_ID> 格式
- 改 SOUL.md 后必须重启网关
- 跨网关用 Discord，同网关用 sessions_send

## 质量检查规则
- ⛔ 没有 QA 通过永远不说"完成了"
- QA 连续不通过 2 次 → 升级给人类

## 已知问题
- Tailscale macOS 睡眠后可能断连
- OpenClaw 会话不会自动刷新 SOUL.md
- Agent 静默失败时超时是唯一可靠的检测手段

## 成本规则
- P3 任务用 MiniMax（便宜 1/3）
- 每周查一次 API 账单

每日日志模板：

# 2026-03-09 每日日志

## 完成的任务
- [x] 任务描述 | agent: Coder | 质量检查: 通过 | 耗时: 25min

## 进行中
- [~] 任务描述 | agent: Research | 已分发: 14:30

## 问题与改进
- 问题：Coder 部署时 SSH 超时
- 原因：Mac Mini 睡眠了
- 改进：加了 caffeinate -d 到启动脚本

## 统计
- 任务完成: 5/6
- 质量检查通过率: 4/5 (80%)
- API 调用: ~120 次

压缩策略

什么时候触发压缩：

上下文使用率到 60% → 自动触发
任务完成后 → 归档结果到每日日志，然后压缩
会话运行超过 2 小时 → 主动压缩

压缩不是 OpenClaw 内置功能 — 它是通过 /compact 命令或在 SOUL.md 中设置自动触发规则来实现的。具体来说：

/compact 命令让模型总结当前对话，丢弃早期细节
你也可以在 cron 里定期执行类似操作
关键信息应该在压缩之前保存到记忆文件

流程七：子 Agent 效率原则

厚任务，薄 Agent

给子 Agent 一次性提供所有信息，不来回追问。目标：每个子 Agent 的会话里只有 3-5 次工具调用。

反模式：

COO: "帮我查一下竞品"
Agent: "查哪个竞品？"
COO: "CrewAI"
Agent: "查哪些方面？"
COO: "功能、定价、用户量"
// 三轮对话浪费了，Agent 才开始干活

正确模式：

COO: "研究 CrewAI。需要：功能列表、定价模型、GitHub stars、融资历史、
技术栈。参考这个文件 [路径]。输出格式：markdown 表格。30 分钟内完成。"
// 一轮搞定

任务简报模板

## 任务
[一句话描述任务目标]

## 上下文
- 相关文件路径: [具体路径]
- 背景信息: [Agent 需要知道的上下文]
- 参考资料: [链接或文件]

## 完成标准
- [ ] 具体的完成标准 1
- [ ] 具体的完成标准 2
- [ ] 具体的完成标准 3

## 约束
- 优先级：P[0-3]
- 截止时间：[时间]
- 模型：[推荐使用的模型]

脚本优先原则

如果任务涉及 API 调用，先写脚本再运行。不要让 Agent 一个一个手动调用 API。

反模式： Agent 用 20 个工具调用分别查询 20 个 API 端点

正确模式： Agent 写一个 Python 脚本，一次性查询所有端点，输出整理好的结果

重试纪律

基础设施失败（API 超时、429） → 最多重试 2 次
2 次后 → 停 30 分钟或换方案
永远不无限重试

这条规则的成本： 有一次子 Agent 花了 30 分钟重试一个已经耗尽配额的 API。30 分钟 = 0 产出。

延伸阅读： 关于 Agent 效率优化，可以参考 Anthropic 的 Agent 设计最佳实践和 OpenAI 的 Agent 构建指南。

版本兼容性说明

本手册中的所有配置和命令基于 OpenClaw 2026.3.2 测试。

如果你使用的版本不同：

你的版本	注意事项
2026.2.x	大部分配置兼容，但 `openclaw message send` 的参数可能略有不同
2026.3.x	本手册完全适用
2026.4.x+	建议查看 OpenClaw 更新日志确认是否有破坏性变更

下一篇：AI Agent 的非共识思考 — 关于组织、产品、记忆力的看法。