阳阳的技术博客：Hermes多Agent、OpenClaw实践、DevOps与AI辅助Web开发实践

文章大纲

[背景引入] 从一个真实的架构切换故事开始 - 代码梦工厂早期采用多 Agent 架构，后来切换回单 Agent 的经历
[架构对比] Hermes vs OpenClaw：两种不同的 Agent 协作模式 - 从工具层面分析两种架构的设计哲学
[核心问题] 多 Agent 的诱惑与陷阱：上下文断裂 - 为什么多 Agent 反而带来更多问题
[实战经验] 代码梦工厂的取舍标准 - 什么场景该用多 Agent，什么场景该用单 Agent
[设计原则] 单 Agent 串行的工作流设计最佳实践 - 如何在单 Agent 模式下保持高效
[总结] 架构选择的本质是上下文管理的权衡 - 回到根本问题做决策

引言

在代码梦工厂的 AI 工作流实践中，我们经历了一次有意思的架构演进：最初为了"专业化分工"引入了多 Agent 模式，运行一段时间后发现问题比想象中多，最终又切换回了单 Agent + 人工确认的模式。

这个过程让我重新思考了一个根本问题：什么时候该用多 Agent并行，什么时候该用单 Agent串行？

本文结合代码梦工厂的实际经历，从 Hermes 和 OpenClaw 两种架构的对比切入，聊聊我们对 AI 团队工作流设计的一些反思。

Hermes vs OpenClaw：两种架构的设计哲学

在讨论工作流设计之前，需要先理解两种主流 Agent 架构的差异，因为架构决定了工作流的上限。

Hermes：主管中转模式

Hermes 采用的是主管中转（Orchestrator）模式。核心是 delegate_task 工具：

python

# 来源：hermes-agent/agent/tools/delegate_tool.py（已验证）
MAX_CONCURRENT_CHILDREN = 3   # 最多 3 个并行子 Agent
MAX_DEPTH = 2                  # 委托深度限制

父 Agent 负责任务分解和结果汇总，子 Agent 是"临时工"——任务来了执行，执行完就结束，不保留会话状态。

OpenClaw：多 Agent 平等协作模式

OpenClaw 的多 Agent 架构更接近"平等协作"模式：

python

# OpenClaw 多 Agent 协作示意（来源：migrate-from-openclaw.md，已验证）
# 每个 agent 有独立会话和上下文
"agents": {
    "main": { "workspace": "~/.openclaw/agents/main" },
    "secondary": { "workspace": "~/.openclaw/agents/secondary" }
}

多个 Agent 各自维护独立的上下文，通过共享文件或人工协调来传递信息。

两种模式的核心差异

维度	Hermes 主管模式	OpenClaw 多 Agent 模式
任务分配	父 Agent 统一分解派发	Agent 间平等协作
上下文	子 Agent 无状态	Agent 独立维护上下文
协调成本	低（统一入口）	高（需要同步机制）
适用场景	独立子任务并行	需要长期专业分工

多 Agent 的诱惑与陷阱

最初的吸引力

多 Agent 看起来很美：

text

┌─────────────────────────────────────────────┐
│              多 Agent 协作图                  │
├─────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐      │
│  │ Agent A │  │ Agent B │  │ Agent C │      │
│  │  写代码  │  │  审查   │  │  测试   │      │
│  └────┬────┘  └────┬────┘  └────┬────┘      │
│       │            │            │            │
│       └────────────┼────────────┘            │
│                    ▼                         │
│              人工最终确认                      │
└─────────────────────────────────────────────┘

分工明确，各司其职。Agent A 专注写代码，Agent B 专注审查，Agent C 专注测试。听起来像一个人类敏捷团队。

现实中的三大陷阱

陷阱一：上下文断裂

每个 Agent 都在自己的独立 session 里运行。当 Agent A 写完代码，Agent B 开始审查时，Agent B 可能不记得之前的上下文里 Agent A 做了哪些假设。

结果：

Agent A："我按需求文档实现了 XXX"
Agent B："需求文档在哪里？"
人工介入："我来给你们同步一下"

陷阱二：信息传递成本

多 Agent 之间需要某种机制来共享信息。常见的方案：

共享文件：写入一个所有人都能读的中间文件
人工中转：人来协调信息传递
共享记忆层：所有 Agent 读写同一个记忆存储

无论哪种方案，都引入了额外的工程复杂度和协调成本。

陷阱三：错误放大

当一个 Agent 的理解有偏差，这个偏差会传递到下一个环节。如果不加以检查，可能到最后测试阶段才发现最初的需求理解就错了。

代码梦工厂的取舍标准

经过一段时间的实践，我们总结出一个简单的决策框架：

什么时候用多 Agent 并行？

适合场景：

子任务之间相互独立，不需要共享太多上下文
每个子任务的输入输出可以清晰定义
有成熟的信息传递机制（如共享文件、记忆层）

典型案例：批量博客写作

python

# 代码梦工厂实际使用场景（已验证）
# 多个独立的博客文章可以并行创作
result = delegate_task(
    tasks=[
        {"goal": "撰写文章 A", "context": "文章A的详细信息..."},
        {"goal": "撰写文章 B", "context": "文章B的详细信息..."},
        {"goal": "撰写文章 C", "context": "文章C的详细信息..."}
    ]
)

三篇文章之间没有依赖，可以完全并行处理。

什么时候用单 Agent 串行？

适合场景：

任务之间有依赖关系，需要共享上下文
任务的中间结果难以结构化
团队规模中小型，协调成本高于并行收益

代码梦工厂的教训

早期我们试图用多 Agent 处理一个完整的博客写作任务：

text

Agent 写稿 → Agent 验证 → Agent 发布

结果是：验证 Agent 发现问题，需要返回给写稿 Agent 修改；修改后需要重新验证；来回几次后，上下文已经混乱，人工介入协调的成本远超单 Agent 串行的效率。

最终我们改成了：

text

单 Agent 完成全流程 → 人工最终确认

效率反而更高。

单 Agent 串行的工作流设计最佳实践

单 Agent 不意味着低效。关键在于如何设计工作流来保持上下文连贯：

1. 明确任务边界

不要在一个任务里塞太多东西。使用清晰的步骤标记：

text

## 任务分解示例

Step 1: 调研主题背景
Step 2: 列出文章大纲
Step 3: 撰写正文
Step 4: 自检修改
Step 5: 最终确认

每个 Step 完成后，主动确认上下文是否正确。

2. 利用上下文管理工具

Hermes 提供了 memory 工具来管理持久上下文：

python

# 来源：hermes-agent/hermes_state.py（已验证）
# SessionDB 使用 FTS5 全文搜索，记忆可跨 session 持久化
session.search(query="项目背景和历史决策")

对于需要长期记忆的信息，写入共享的记忆文件：

markdown

# 记忆文件示例
## 项目架构决策
- 2026-04-10: 切换到单 Agent 模式
- 原因：多 Agent 上下文传递成本过高

## 待办事项
- [ ] 优化上下文压缩策略

3. 人工确认节点

单 Agent 的弱点是"一条道走到黑"。在关键节点设置人工确认：

text

任务开始 → Agent 执行 → 关键节点人工确认 → Agent 继续 → 任务完成

这样既保留了 Agent 的效率，又有人工的把关来避免偏差累积。

架构选择的本质

回到最初的问题：单 Agent vs 多 Agent，其实是在问：

上下文的维护成本和传递成本，哪个更高？

架构	上下文维护成本	上下文传递成本
单 Agent	低（所有上下文在一起）	无（不需要传递）
多 Agent	各 Agent 独立维护	高（需要同步机制）

当任务复杂度低、上下文依赖简单时，单 Agent 几乎总是最优解。

当任务复杂度高、子任务高度独立且有成熟的协调机制时，多 Agent 才能发挥价值。

不要因为"多 Agent 听起来更厉害"就上多 Agent。也不要因为"单 Agent 好像能力不够"就急着拆分。

先回答：你的场景里，上下文管理的瓶颈在哪里？

结语

代码梦工厂的 AI 工作流设计经历告诉我一个简单的道理：

最好的架构是团队能驾驭的架构，而不是理论上最"先进"的架构。

从多 Agent 切回单 Agent 不是倒退，而是一次务实的选择。如果你也在考虑 Agent 架构的选型，希望我们的经验教训能给你一些参考。

AI 创作声明：本文由 OpenClaw 和 Hermes Agent 协作生成，内容经审核后发布。