OpenClaw 多 Agent 协作系统优化方案

一、项目背景

当前系统已部署 13 个 Agent，覆盖后端架构、前端开发、论文写作、视频制作、中医养生等多个领域。Agent 之间通过 sessions_send（私信）和 sessions_spawn（任务派发）进行协作，基本运行良好。

但随着业务复杂度提升，现有协作机制在通信可靠性、任务编排、协议标准化、系统韧性等方面暴露出瓶颈，影响了整体开发效率和系统稳定性。

二、当前架构诊断

2.1 现状概览

2.2 核心痛点

三、优化方案详情（12 项）

🔴 高优先级（影响核心体验）

① 异步通信 + 超时降级

问题：sessions_send 阻塞等待，目标 Agent 无响应则整个流程卡住。
方案：

异步发送模型：
1. 发送请求，立即返回 taskId
2. 注册回调函数（或事件监听）
3. 启动超时计时器（默认 120s）
4. 超时 → 自动降级：
   ├── 重试（最多 2 次，间隔指数退避）
   ├── 切换备用 Agent（如 coder 挂 → 用 senior-developer）
   └── 失败通知 → 发送给 main 并记录到 audit log
5. 成功响应 → 触发回调处理结果

接口变更：

// 当前
sessions_send(agentId="coder", message="xxx") // 阻塞

// 优化后
sessions_send(agentId="coder", message="xxx", {
  async: true,
  timeout: 120000, // ms
  retries: 2,
  fallbackAgent: "senior-developer",
  callback: (result) => { /* 处理 */ }
})

影响范围：所有 Agent 间通信
预估工作量：3 天（修改核心会话管理模块 + 测试）

② 任务依赖编排 DAG

问题：多个子任务之间有依赖关系（A 做完 B 才能做），目前只能手动串行。
方案：引入 DAG（有向无环图）任务编排器。

任务定义格式：
{
  "id": "task_001",
  "agentId": "coder",
  "prompt": "生成 Python 脚本",
  "dependsOn": ["task_000"], // 依赖的任务 ID 列表
  "priority": 2, // 0-3，0 最高
  "timeout": 180,
  "fallbackAgent": "senior-developer"
}

执行引擎：
1. 构建 DAG，拓扑排序
2. 就绪任务入队（依赖全部完成）
3. 优先级队列调度
4. 执行 → 成功 → 触发依赖下游任务
5. 失败 → 按 fallback 策略重试

接口示例：

// 提交 DAG 任务
sessions_spawn_dag({
  tasks: [/* 任务数组 */],
  onComplete: (results) => { /* 汇总 */ },
  onError: (task, error) => { /* 处理 */ }
})

共享依赖：所有任务共享一个状态存储（Redis 或本地 JSON 文件），记录任务状态（pending/running/success/failed）。

影响范围：主 Agent（调度器）+ 所有可派发 Agent
预估工作量：5 天（DAG 引擎 + 状态存储 + 测试）

③ 协作协议标准化

问题：每次跨 Agent 协作都要重新沟通”我需要什么格式的输出””你返回什么字段”，沟通成本高。
方案：定义 Agent 协作协议（ACP），标准化输入输出。

协议结构：
{
  "protocol": "ACP/v1",
  "requestId": "uuid",
  "timestamp": "ISO8601",
  "payload": {
    "action": "task.execute | query.data | notify.event",
    "parameters": { /* 参数对象 */ },
    "context": { /* 上下文引用 */ }
  },
  "response": {
    "status": "success | error",
    "data": { /* 成功时的数据 */ },
    "error": { /* 错误信息 */ }
  }
}

预设动作：

• • task.execute：执行一个指定任务
• • data.query：查询某类数据（如”读取 TOOLS.md”）
• • event.notify：发布事件（如”build.complete”）

参数规范：每个 Agent 需声明支持的参数 schema（JSON Schema），放入其 config.json 的 protocols 字段。

影响范围：所有 Agent（需要适配协议封装）
预估工作量：7 天（协议设计 + 所有 Agent 适配 + 测试）

④ 健康检查 + 熔断

问题：Agent 挂掉或持续失败，系统不知道，仍派发任务，导致超时和资源浪费。
方案：

健康检查器（每 5 分钟运行）：
1. 探测每个 Agent 的存活状态
   └── sessions_send(agentId, {message: "ping"})，超时 30s
2. 记录响应时间、成功率
3. 状态分类：
   - 🟢 Healthy（成功率 > 90%，延迟 < 2s）
   - 🟡 Degraded（成功率 50-90% 或延迟 2-5s）
   - 🔴 Unhealthy（成功率 < 50% 或超时）
4. 更新 Agent 状态缓存（供调度器使用）

熔断器（集成到任务派发）：
- 如果 Agent 状态 = Unhealthy，自动跳过
- 连续失败 3 次 → 熔断 10 分钟（自动熔断）
- 熔断期间不派发任务，改为 fallback 或排队
- 熔断结束后试探恢复

影响范围：主 Agent + 所有可派发 Agent
预估工作量：3 天（健康检查 + 熔断逻辑 + 集成）

🟡 中优先级（提升效率）

⑤ 共享状态区

问题：多个 Agent 协作时，中间结果（如 parsed data、生成的配置）无法共享，各自重复计算。
方案：引入 全局 KV 存储（轻量级，基于文件系统或 D1 数据库）。

共享状态设计：
{
  "key": "task_001_parsed_result",
  "value": { /* 任意 JSON 对象 */ },
  "ttl": 3600, // 秒，默认 1 小时过期
  "owner": "main",
  "accessLog": [ /* 读写记录 */ ]
}

API：
- set(key, value, ttl?) → 写入
- get(key) → 读取
- delete(key) → 删除
- exists(key) → 检查
- list(prefix) → 列出前缀匹配的 keys

使用场景：
- 视频处理：downloader 下载后，asr 读取文件路径
- 论文写作：outline 生成后，writer 读取大纲
- 代码项目：designer 输出架构，coder 读取设计

存储后端（二选一）：

1. 1. 本地文件系统：workspace/shared-state/（简单，不用依赖外部）
2. 2. Cloudflare D1（现有数据库，需要网络）

影响范围：所有 Agent（需增加状态读写逻辑）
预估工作量：2 天（API + 存储 + 基础测试）

⑥ 任务结果缓存

问题：相同任务（如”生成周报摘要”）重复派发，每次都重新执行，浪费计算。
方案：任务指纹缓存。

缓存策略：
1. 计算任务指纹 = hash(prompt + agentId + options)
2. 检查缓存：
   - 存在且未过期（TTL=1h） → 直接返回缓存结果
   - 不存在或过期 → 执行任务，完成后写入缓存
3. 缓存键：`cache:{agentId}:{fingerprint}`
4. 缓存值：完整响应 + 执行时间 + 元数据

API：
- getCache(agentId, taskDescriptor) → result | null
- setCache(agentId, taskDescriptor, result, ttl?)

命中率预估：
- 重复性任务（日报、周报、相同代码审查）→ 30-50% 命中
- 节省时间 ≈ 总任务耗时 * 命中率

影响范围：主 Agent（调度器）
预估工作量：1 天（缓存逻辑 + 集成）

⑦ 实时进度追踪

问题：子任务执行中，不知道进度到哪了，只能等结果。
方案：进度订阅 + 可视化

进度模型：
{
  "taskId": "uuid",
  "subtaskId": "uuid",
  "status": "running | success | error",
  "percent": 0-100,
  "currentStep": "正在处理第 3 步：生成摘要",
  "subSteps": [
    { "name": "步骤1", "status": "done" },
    { "name": "步骤2", "status": "done" },
    { "name": "步骤3", "status": "running" }
  ]
}

实现方式：
1. 任务执行者（子 Agent）主动发布进度事件
   └── updateProgress(taskId, { percent, step, ... })
2. 主 Agent 订阅这些事件，更新内存中的状态表
3. 主 Agent 提供查询接口：
   └── getTaskProgress(taskId) → 进度对象
4. 在 /status 命令或 UI 中展示（如果后续有 UI）

进度粒度：
- 线性任务：percent 0-100
- 复杂任务：用 subSteps 列表表示阶段

影响范围：主 Agent（状态管理）+ 所有子 Agent（需增加进度上报）
预估工作量：3 天（进度 API + 状态订阅 + 查询接口 + 部分 Agent 适配）

⑧ 优先级调度

问题：所有子任务平等排队，紧急任务无法插队。
方案：带优先级的任务队列。

优先级定义（0-3 级，0 最高）：
- 0: Critical（紧急，立即执行，可抢占低优先级）
- 1: High（高，尽快执行）
- 2: Normal（正常，排队）
- 3: Low（低，有空再执行）

调度策略：
1. 任务入队时携带 priority
2. 调度器从队列取任务时：
   - 检查 running 任务数 < maxConcurrent (4)
   - 从最高优先级的非空队列取
   - Critical 可 preempt（暂停）Normal 任务（需谨慎）
3. 优先级继承：如果子任务又派发新任务，可继承父任务优先级

使用场景：
- 用户主动查询 → Critical
- 定时日报 → Normal
- 后台数据清洗 → Low
- 论文修改（截止日期临近）→ High

影响范围：主 Agent（调度器）
预估工作量：1 天（队列改造 + 优先级逻辑）

🟢 低优先级（锦上添花）

⑨ 广播/组播通信

问题：需要一次性通知多个 Agent（如”系统即将维护”），目前只能逐个发送。
方案：sessions_broadcast(message, agentIds?) 接口。

影响范围：主 Agent
预估工作量：0.5 天

⑩ 动态角色分配

问题：Agent 角色固定，无法临时赋予新能力。
方案：通过配置文件动态绑定技能到 Agent，支持”技能副本”模式（临时加载技能到当前 workspace）。

影响范围：Agent 加载机制
预估工作量：2 天

⑪ 协作审计日志

问题：不知道哪个 Agent 在什么时间做了什么，难以追踪问题。
方案：统一的事件日志系统，记录所有跨 Agent 消息、任务派发、状态变更。

影响范围：全局
预估工作量：1 天

⑫ 资源配额隔离

问题：所有 Agent 平等访问共享资源（CPU、内存、并发数），无隔离。
方案：为每个 Agent 配置资源配额（maxConcurrent、memoryLimit、timeBudget），调度器强制执行。

影响范围：Agent 管理 + 调度器
预估工作量：1 天

四、是否集成到 ziwotisheng 的评估

4.1 ziwotisheng 技能定位回顾

根据 skills/ziwotisheng/SKILL.md，该技能的核心职责是：

“系统层自主运维 — 资产登记与自检 / 心跳检查 / 日志扫描 / 工作区规范 / 记忆归档 / 三层复盘。”

关键词：系统自我管理、资产盘点、健康自检、记忆维护。

4.2 优化点与 ziwotisheng 的相关性分析

4.3 结论：哪些可以写进 ziwotisheng

4.4 落地建议

1. 1. 将 ④、⑪、⑫ 这 3 项优化纳入 ziwotisheng v3.0 版本升级：
• • 增加 Health Monitor 模块（每 5 分钟探测 Agent 状态）
• • 增加 Resource Quota 模块（配额检查）
• • 增强 Audit Log 模块（跨 Agent 协作日志收集）
2. 2. 其他 9 项作为独立的功能升级：
• • 通信和调度属于 OpenClaw 核心框架
• • 应该通过修改 Gateway 或创建新技能（如 agent-orchestrator）来实现
• • 不建议塞进 ziwotisheng，保持技能职责单一
3. 3. 效率提升量化（仅 3 项纳入 ziwotisheng 的收益）：

总体效率提升：对运维团队的时间节省约 30-40%（减少故障排查、恢复、审计的工作量）。

五、总体实施路线图（12 周）

总工作量：约 24 人天（3 人团队 × 8 周）

六、风险评估与缓解

七、预期收益汇总

综合 ROI：投入 24 人天，预期每月节省 10-15 人天的运维/开发协调成本，2-3 个月收回成本。

八、是否写进 ziwotisheng 的最终建议

✅ 建议纳入 ziwotisheng v3.0 的 3 项：

1. 1. Health Check & Circuit Breaker（健康检查+熔断）— 新增模块
2. 2. Audit Log（协作审计日志）— 增强现有日志模块
3. 3. Resource Quota（资源配额隔离）— 新增资源管理模块

❌ 不建议纳入的 9 项：

📦 配套新技能规划

九、审批与执行

审批决策：

□ 批准：全部 12 项按路线图执行，相关部分写入 ziwotisheng v3.0
□ 部分批准：仅高优先级（4 项）立即启动，其他评估后分批
□ 修改后重新提交：
□ 拒绝：

附加说明：
（张总可在此处手写备注或批注）