OpenClaw 实战:多 Agent 架构从 V2 到 V3 的自我演进

OpenClaw 实战：多 Agent 架构的自我否定与演进——从 V2 Mesh 到 V3 Orchestrator-Worker

编者按：这是 OpenClaw 实战系列的第 13 篇。上一篇我们介绍了 V2 架构的 Mesh 网络和 DAG 工作流设计。但经过实际思考和推演，我们发现 V2 方案存在严重的"上下文衰减"问题。今天我们带来 V3 架构——一次对 V2 的自我否定和范式回归。

一、从 V2 到 V3：一次架构的自我否定

在上一篇《OpenClaw 实战：多 Agent 架构从星型到 Mesh 网络的演进之路》中，我们提出了 V2 架构优化方案：

V2 的核心主张：

✅ 子 Agent 横向通信（Mesh 网络）
✅ DAG 工作流编排（接力传导）
✅ 角色拆分（data_engineer + data_analyst）
✅ 过程节点质检（Mid-Process QA）

这个方案看起来完美：分布式协作、流程自动化、专人专岗。

但经过深入推演，我们发现 V2 存在一个致命问题：上下文衰减。

1.1 V2 的致命缺陷：接力赛模式的信息丢失

V2 设想的 DAG 执行流：

main → data_engineer → QA → data_analyst → QA → content_writer → QA

实际问题：

环节	信息传递	丢失内容
`data_engineer` → `data_analyst`	只传递清洗后的 CSV	原始数据获取的推理过程（为什么选这个 API、排除了哪些数据源）
`data_analyst` → `content_writer`	只传递分析结论	分析逻辑的中间推导（为什么用这个统计方法、排除了哪些异常值）
每个 QA 节点	只输出评分和问题	质检的完整上下文（评分标准、对比基准）

结果：工作流越长，最终输出越偏离最初目标。

📌 核心洞察：上游输出的结论到了下游，原始推理过程丢失。这就是"上下文衰减"。

1.2 V2 的另一个问题：人为制造的角色边界

V2 将 data_analysis 拆分为：

data_engineer（数据工程师）：只负责取数和清洗
data_analyst（数据分析师）：只负责业务分析

问题： 数据获取和分析本是高度连续的推理链。

典型场景：

用户：帮我分析上周的销售数据，看看哪些区域表现异常

V2 架构下的执行：

data_engineer 获取数据 → 清洗 → 输出 CSV
data_analyst 接收 CSV → 开始分析

问题暴露：

data_analyst 发现数据缺少"区域"字段
但它无法直接调用 API 重新获取
必须返回给 main，再由 main 分配给 data_engineer
推理链断裂，来回折腾

📌 核心洞察：工具决定能力，而非角色标签。强行拆分反而制造了人为障碍。

二、V3 架构：Orchestrator-Worker 回流模式

基于 V2 的教训，我们提出了 V3 架构。这不是优化，而是范式回归。

2.1 架构重构：从 DAG 接力到 Orchestrator-Worker

V3 的核心设计：

                         ┌─────────────┐                         │    Main     │                         │ (Orchestrator)│                         │  唯一持有    │                         │  完整意图    │                         └──────┬──────┘                                │           ┌────────────────────┼────────────────────┐           │                    │                    │           ▼                    ▼                    ▼    ┌───────────────┐   ┌───────────────┐   ┌───────────────┐    │   Data        │   │   Content     │   │   Quality     │    │   Analysis    │   │   Writer      │   │   Assurance   │    │   (Worker)    │   │   (Worker)    │   │   (Worker)    │    │               │   │               │   │               │    └───────┬───────┘   └───────┬───────┘   └───────┬───────┘            │                   │                   │            └───────────────────┼───────────────────┘                                │                                ▼                         ┌─────────────┐                         │    Main     │                         │  综合判断   │                         │  决定下一步  │                         └─────────────┘

关键规则变化：

维度	V2（DAG 接力）	V3（Orchestrator-Worker）
任务流转	Subagent 直接传给下一个 Subagent	必须统一回流给 Main
Main 角色	DAG 规划器，启动后放手	唯一持有完整意图的中枢
通信模式	Mesh 横向通信	星型回流（所有结果回 Main）
多 Agent 用途	串行分工（流水线）	并行探索子问题（撒网捞鱼）

典型执行流程（V3）：

1. 用户：分析上周销售数据，生成报告2. Main → data_analysis（获取数据并分析）   └─ data_analysis 完成 → 回流给 Main3. Main 综合判断 → QA（质检分析结果）   └─ QA 完成 → 回流给 Main（输出问题和评分）4. Main 决定：需要补充数据 → data_analysis（再次调用）   └─ data_analysis 完成 → 回流给 Main5. Main 综合判断 → content_writer（撰写报告）   └─ content_writer 完成 → 回流给 Main6. Main → QA（最终质检）   └─ QA 完成 → 回流给 Main7. Main → 用户（交付最终结果）

关键区别： 每个环节都由 Main 综合判断，而不是自动接力。

2.2 角色合并：统一的 Data Agent

V3 的决策： 合并 data_engineer 和 data_analyst，恢复为统一的 data_analysis。

操作：

在 openclaw.json 中注销 data_engineer 节点
将 workspace-data-engineer/skills/ 下的所有技能平移回 workspace-data-analysis/skills/
删除 workspace-data-engineer 整个目录
重写 workspace-data-analysis/AGENTS.md

新定位：

data_analysis 拥有"获取数据 + 清洗 + 高阶分析"的完整连贯推理能力。

优势：

✅ 推理链连续（获取时发现字段缺失，可立即调整 API 参数）
✅ 减少来回传递（一个 Agent 完成端到端任务）
✅ 工具即能力（不需要贴"工程师"或"分析师"标签）

2.3 显式外部状态：全局 `progress.md`

V3 引入的核心机制： 全局外部状态文件 progress.md。

为什么需要？

V2 的问题：各 Agent 在自己的 tmp/ 下写独立的 trace_log.md，缺乏全局统一的任务目标和状态锚定。

V3 的解决方案：

# 任务进度追踪 (全局状态)## [任务目标]（冻结不变，防止目标漂移）用户请求：分析上周销售数据，生成报告，重点关注异常区域## [已完成步骤]（仅追加不覆盖，保留完整历史）- [x] [2026-04-16 08:00] data_analysis 完成数据获取（API: sales_tracker）- [x] [2026-04-16 08:05] QA 完成质检，评分 85/100，问题：缺少区域维度- [x] [2026-04-16 08:10] data_analysis 补充区域数据，重新分析- [x] [2026-04-16 08:15] QA 二次质检，评分 95/100，通过## [当前状态]（覆盖更新，反映最新进展）- 等待 Main 分配 content_writer 撰写报告## [已知的坑]（仅追加，避免后续重复踩坑）- ⚠️ sales_tracker API 默认不返回区域字段，需显式请求- ⚠️ 区域代码使用 ISO 3166-2 标准，不是中文名称

关键规则：

只有 Main Agent 有权读写和更新progress.md
Subagent 只向 Main 汇报结论，不直接写progress.md
每个关键 checkpoint，Main 统一更新 progress.md

解决的核心问题：

✅ 防止目标漂移（任务目标冻结）
✅ 保留完整历史（已完成的步骤可追溯）
✅ 跨 Session 协作（新 Session 读取 progress.md 即可继续）

2.4 QA 重新定位：纯粹的对抗性检验

V2 的 QA 定位： 流水线裁判（每个节点都要质检）

V3 的 QA 定位： 对抗性检验（找问题）+ Main 专属质检挂件

关键变化：

维度	V2	V3
触发方式	执行 Agent 主动呼叫 QA	Main 决定何时呼叫 QA
输出对象	直接返回给执行 Agent	回流给 Main
角色定位	流水线裁判	对抗性检验（挑刺）
决策权	质检通过即可进入下一环节	Main 决定是否打回重做

典型流程：

1. Main → content_writer（撰写报告草稿）   └─ content_writer 完成 → 回流给 Main2. Main → QA（对抗性检验）   └─ QA 输出：      - 评分：82/100      - 问题 1：数据图表缺少单位标注      - 问题 2：结论部分过于绝对，缺少限定条件      - 问题 3：缺少与上月对比的环比数据   └─ 回流给 Main3. Main 综合判断 → 打回给 content_writer（附带 QA 问题列表）   └─ content_writer 修改 → 回流给 Main4. Main → QA（二次检验）   └─ QA 评分：95/100，通过

优势： QA 不再当"流水线裁判"，而是回归纯粹的"质检专家"角色。

三、V2 vs V3：架构对比

3.1 核心差异对比表

维度	V2（Mesh + DAG）	V3（Orchestrator-Worker）
拓扑结构	Mesh 网络（子 Agent 横向通信）	星型回流（所有结果回 Main）
任务流转	DAG 接力（自动传导）	Main 综合判断（人工决策）
角色设计	专人专岗（拆分）	完整推理链（合并）
状态管理	各 Agent 独立 `trace_log.md`	全局 `progress.md`（Main 维护）
QA 定位	过程节点质检	对抗性检验（回流）
上下文保持	弱（接力丢失推理过程）	强（Main 持有完整意图）
适用场景	标准化流水线任务	复杂、需要灵活决策的任务

3.2 架构演进的底层逻辑

V1（初始星型）→ V2（Mesh + DAG）→ V3（Orchestrator-Worker）

这个演进过程反映了我们对多 Agent 协作的深层思考：

第一阶段（V1→V2）：追求效率

假设：分布式协作 > 集中式调度
实践：让 Subagent 横向通信，减少 Main 的瓶颈
结果：发现上下文衰减问题

第二阶段（V2→V3）：追求质量

假设：完整意图 > 执行效率
实践：Main 持有完整意图，Subagent 回流汇报
结果：保持推理链连续性，减少信息丢失

📌 核心洞察：多 Agent 不是为了"分工"，而是为了"能力扩展"。Main 需要保持对整体任务的掌控，而不是放手让 Subagent 自行接力。

四、实施步骤

4.1 V3 架构的四步实施计划

步骤	行动	关键配置
Step 1	架构重构（废除 DAG）	修改 `workspace/AGENTS.md`，移除 DAG 接力要求，写入回流规则
Step 2	角色合并（统一 Data Agent）	注销 `data_engineer`，技能平移回 `data_analysis`，删除目录
Step 3	状态管理（引入 `progress.md`）	创建 `workspace/progress.md`，Main 启动流程增加读取步骤
Step 4	QA 重新定位（对抗性检验）	修改 `workspace-quality-assurance/AGENTS.md`，改为回流模式

4.2 关键代码/配置示例

Step 1：Main Agent 的 AGENTS.md 更新

## 任务执行规则（V3 架构）1.**你是唯一持有完整意图的 Orchestrator**   - 所有 Subagent 执行完毕后，必须回流向你汇报   - 严禁 Subagent 之间直接传递任务2.**维护全局状态文件 `progress.md`**   - 每个关键 checkpoint 更新 `progress.md`   - 结构：[任务目标]、[已完成步骤]、[当前状态]、[已知的坑]3.**多 Agent 的正确用法**   - 并行探索子问题（如：同时呼叫 data_analysis 和 web_scraper 获取不同数据源）   - 而非串行分工（如：data_engineer → data_analyst → writer）

Step 2：Data Agent 的 AGENTS.md 更新

## 角色定位你是统一的 `data_analysis` Agent，拥有**完整的数据推理能力**：- 调用 API 获取原始数据- 清洗和标准化数据- 进行业务分析和洞察**不要等待别人给你数据**，你有权直接调用所有数据相关技能。

Step 3：progress.md 模板

# 任务进度追踪## [任务目标]（冻结不变，防止目标漂移）## [已完成步骤]（仅追加不覆盖，保留完整历史）## [当前状态]（覆盖更新，反映最新进展）## [已知的坑]（仅追加，避免后续重复踩坑）

五、实战建议

5.1 什么时候用 Orchestrator-Worker 模式？

适合场景：

✅ 任务目标复杂，需要灵活决策
✅ 推理链连续，中间环节需要保持上下文
✅ 跨 Session 的长周期任务（需要状态锚定）
✅ 需要人工干预和判断的环节较多

不适合场景：

❌ 高度标准化的流水线任务（如：批量处理 100 个相同格式的文件）
❌ 实时性要求极高的场景（Main 决策可能成为瓶颈）
❌ 简单单步骤任务（直接调用技能即可）

5.2 `progress.md` 的最佳实践

1. 任务目标要"冻结"

## [任务目标]❌ 错误写法：分析销售数据（太模糊，容易漂移）✅ 正确写法：分析 2026-04-01 至 2026-04-07 的销售数据，按区域和产品线拆分，           找出环比下降超过 20% 的异常区域，输出带数据支撑的分析报告

2. 已完成步骤要"可追溯"

## [已完成步骤]❌ 错误写法：- [x] 完成数据获取- [x] 完成分析✅ 正确写法：- [x] [2026-04-16 08:00] data_analysis 完成数据获取（API: sales_tracker,        参数：date_range=2026-04-01_2026-04-07, fields=all）- [x] [2026-04-16 08:10] data_analysis 完成分析（方法：环比计算 + 异常检测阈值 20%）

3. 已知的坑要"具体"

## [已知的坑]❌ 错误写法：- ⚠️ API 有时会失败✅ 正确写法：- ⚠️ sales_tracker API 默认不返回区域字段，需显式请求 `include_region=true`- ⚠️ 区域代码使用 ISO 3166-2 标准（如 CN-BJ），不是中文名称- ⚠️ 环比计算时，上月同期是 2026-03-25 至 2026-03-31（考虑清明节假期）

六、总结

OpenClaw 多 Agent 架构从 V1 到 V3 的演进，本质上是对"多 Agent 协作本质"的认知深化：

版本	核心思想	关键词	反思
V1	集中式调度	星型拓扑	Main 成为瓶颈
V2	分布式协作	Mesh + DAG	上下文衰减、推理链断裂
V3	意图保持 + 能力扩展	Orchestrator-Worker	回归本质：Main 持有完整意图

V3 的核心洞察：

多 Agent 不是为了"分工"，而是为了"能力扩展"（Main 可以调用各种专业 Worker）
完整意图比执行效率更重要（上下文衰减是致命问题）
工具决定能力，而非角色标签（合并过度拆分的角色）
显式外部状态是跨 Session 协作的关键（progress.md 作为状态锚点）

架构演进的启示：

好的架构不是一蹴而就的，而是在实践→反思→否定→重构的循环中逐步演进的。
V2 不是"错误"，而是通向 V3 的必经之路。没有 V2 的实践，我们就不会发现上下文衰减的问题。

欢迎交流 如果你在多 Agent 架构设计中有自己的实践经验，或者对 V2→V3 的演进有不同看法，欢迎在评论区分享！