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 的执行循环有一个很独特的设计——它有两种触发方式，各自走不同的路径：┌──────────────────────────────────────────────────────