03 | AI Agent 架构设计：任务规划与执行循环 ——OpenClaw、Claude Code、Hermes Agent 对比
声明：📝 作者：甜城瑞庄的核桃（ZMJ）
原创学习笔记，欢迎分享，但请保留作者信息及原文链接哦～
前言
| 基本信息 | 内容 |
|---|---|
| 系列 | AI Agent 架构设计（三）：任务规划与执行循环 |
| 核心目标 | 执行循环解决四大痛点——规划能力、错误恢复、执行可见性、状态持久性，三个框架给出不同答案 |
| 适合读者 | 想理解 Agent 执行机制和防失控设计的开发者 |
| 预计阅读 | 20 分钟 |
记忆系统决定 Agent 知道什么，工具系统决定 Agent 能做什么。
执行循环决定 Agent 怎么把"知道的"和"能做的"结合起来，把一个用户指令变成一系列真实的操作。
一个设计糟糕的执行循环，会让 Agent 出现这些症状：
- 盲目执行：接到复杂任务，直接冲进去执行，中途才发现方向错了
- 无限重试：工具调用失败，无休止重试，消耗资源却没有进展
- 过程黑盒：跑了很长时间，用户完全不知道在做什么，感觉像黑盒
- 状态崩溃：任务执行到一半，上下文满了，状态丢失，从头来过
这四个症状对应四个架构问题：规划能力、错误恢复、执行可见性、状态持久性。
三个框架对这四个问题，给出了截然不同的答案。
一、ReAct 循环：所有框架共同的底层
在拆解三个框架之前，先把共同的底层说清楚。
现代 Agent 框架普遍基于ReAct 模式（Reason-Act-Observe）：
┌─────────────────────────────────────────────────────────────┐ │ ReAct 循环：AI Agent 的心脏 │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 1. 接受输入 (Input) │ │ │ │ 接受用户指令、工具清单、上下文 │ │ │ └────────────────────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 2. 推理 (Reason) │ │ │ │ 分析用户指令，规划如何调用工具来完成任务 │ │ │ │ 决定下一步行动是什么 │ │ │ └────────────────────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 3. 行动 (Act) │ │ │ │ 根据推理结果执行具体操作 │ │ │ │ 调用 API、文件操作、查询数据库… │ │ │ └────────────────────────┬─────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 4. 观察 (Observe) │ │ │ │ 接收执行结果反馈 │ │ │ │ 将结果作为下一步推理的输入依据 │ │ │ └────────────────────────┬─────────────────────────────┘ │ │ │ │ │ └──────────────→ 回到步骤 2 │ │ （循环，直到完成） │ └─────────────────────────────────────────────────────────────┘ReAct 循环用来解决四个核心架构问题：
| 架构问题 | ReAct 的作用 |
|---|---|
| 规划能力 | Reason 阶段分析目标，防止盲目执行 |
| 错误恢复 | Observe 阶段接收失败结果，触发下一轮 Reason 重新规划 |
| 执行可见性 | 每个循环步骤可被外部观察，消除黑盒感 |
| 状态持久性 | 循环状态注入上下文，支持长程任务持续运行 |
这个循环听起来简单，但生产级实现的复杂度远超想象。
从 Claude Code 泄露的源码里能看到一个侧面：仅QueryEngine.ts一个文件就有46,000 行，负责处理所有 LLM 调用、流式响应、缓存、重试和编排逻辑。
这不是意外的膨胀——这是 ReAct 循环在生产环境里运行所需要的工程量的真实写照。
生产级工程复杂度：冰山模型 [水面以上：可见的 ReAct 能力] 推理 → 行动 → 观察 → 循环 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [水面以下：看不见的工程支撑] QueryEngine.ts（46,000 行） ├── LLM 调用管理与流式响应处理 ├── Prompt Cache 命中率优化 ├── 多层次重试策略（含熔断器） ├── 上下文 Compaction（3 次重试机制） └── 多 Agent 编排与状态同步 对比： OpenClaw → 无 QueryEngine 等价物，缺少工程级错误处理 Hermes → 迭代预算 + 双重超时监控，从框架层介入三个框架的 ReAct 实现都建立在这个基础上，但在触发方式、规划深度、错误处理、停止条件上做出了不同的架构选择。
二、OpenClaw：双触发模式，被动响应 + 主动唤醒
2.1 核心设计：两种不同的执行入口
OpenClaw 的执行循环有一个很独特的设计——它有两种触发方式，各自走不同的路径：
┌──────────────────────────────────────────────────────
