夜雨聆风(基于 OpenClaw、Claude Code、Hermes Agent 的架构横评)
一、 第一性原理：执行循环究竟在解决什么架构级灾难？
我们先问一个最根本的物理学问题：为什么语言模型需要一个“循环（Loop）”？
大语言模型（LLM）的本质，是一个无状态（Stateless）、无时间概念（Atemporal）的概率坍缩引擎。
在它的宇宙里，没有“过去”和“未来”，只有当前 Context Window 里排列的 Token。它不会“主动”去思考，它也不会感到“时间”的流逝。
如果说记忆系统是它的“海马体”，工具系统是它干涉物理世界的“触手”，那么执行循环（Execution Loop），就是这个缸中之脑的“中枢神经反射弧”与“生物钟（Pacemaker）”。
在架构的最底层，执行循环在解决一个极其致命的系统矛盾：“非确定性意图”与“线性物理时间”之间的阻抗匹配。
如果没有一个强健的执行循环引擎，Agent 必然会表现出四种架构级并发症：
- 时序迷失
：不知道什么任务该先做、什么该后做（缺乏规划）。 - 死锁与无限递归
：遇到错误时产生幻觉，陷入无限的“重试-失败”死循环。 - 黑盒化失控
：执行过程对系统外围不可见，变成脱缰的野马。 - 状态雪崩
：上下文爆满导致任务进度彻底丢失。
理解了这一点，我们就能看懂，所有 Agent 框架底层的 ReAct (Reason-Act-Observe) 循环，绝对不是写个 while(true) 那么简单。它是用确定性的代码逻辑，去框定和规训不可控的机器意识流。
二、 架构流派剖析与核心原理解构
所有的现代 Agent 框架，其底层都建立在一个共享的基础之上：ReAct 循环（Reason-Act-Observe）。
通用 ReAct 底层工作流：
- 接收
输入 → 2. 推理（分析状态，决定下一步） → → 3. 行动（调用工具） → → 4. 观察（获取工具结果） → → 5. 注入上下文并继续推理（直到触发停止条件）。 →
看起来很简单？但当它跑在生产环境时，就演变成了三种截然不同的架构流派。
流派一：异步状态机与时间空间互换（OpenClaw & Hermes）
设计哲学：模型是死物，必须用外部调度器为其挂载“心跳与闹钟”。
【核心机制原理解构 1：OpenClaw 的被动响应与主动心跳】
OpenClaw 设计了双入口触发机制。针对 LLM “不会主动做事”的物理缺陷，它通过定时读取本地 Markdown 文件来实现任务唤醒。
- 配置机制：
默认每 30 分钟系统下发一次心跳，触发 Agent 读取 HEARTBEAT.md：
# HEARTBEAT.md 文件结构## 每日任务- 每天早上 7:00：读取昨天工作日志，发送当日摘要## 监控任务- 每 30 分钟：检查服务器状态，如有异常立即通知
如果有任务则执行；如果没有，返回 HEARTBEAT_OK，网关层面直接静默丢弃，实现轻量级轮询。
【核心机制原理解构 2：Hermes 调度器的内部事件循环】
Hermes 走得更深，将调度器作为架构的一等公民深度集成。
- 执行链路流：
每次系统维护周期，都会触发严格的 scheduler.tick()流水线：
1. scheduler.tick() 触发2. 获取全局调度器锁 (Scheduler Lock) -> 【架构点：防止并发执行引发数据脏写】3. 筛选到期且状态为 scheduled 的任务4. 遍历到期任务：a. 创建一个【完全干净无历史】的全新 AIAgent 会话b. 根据配置，动态加载附加的 Skills (热记忆与方法论)c. 执行 Task Promptd. 结果路由输出，更新 run_count 计算下次时间5. 释放调度器锁
- 状态与能力解耦：
Hermes 允许通过 JSON 绑定特定的 Skill（经验），让同一个 Cron 任务随时间进化：
// Hermes 调度绑定 Skills 示例{"name": "Morning AI briefing","schedule": "0 8 * * *","skills": ["ai-funding-daily-report", "news-aggregator"]}
Q1：Agent 执行一个需要 3 分钟才能返回的外部 API 怎么办？
- 架构代价与取舍：
绝不能让模型挂起等待。OpenClaw 的标准做法是用时间换空间：一旦探测到长时等待 → → →
流派二：确定性防线与物理级隔离（Claude Code）
设计哲学：先规划再执行，对昂贵的连环故障零容忍。
【核心机制原理解构 3：自愈循环与 3次熔断防线】
Claude Code 的 QueryEngine.ts 高达 46,000 行，里面装满了针对非确定性引擎的工程护栏。
- 自愈链路：
工具执行失败 → → → → Compaction（压缩历史）继续执行。 - 熔断器机制：
这是一个由真实故障（单会话重试 3272 次，浪费 25 万次 API 调用）倒逼出来的硬代码规则：
MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3# 逻辑：只要连续自动压缩失败达到 3 次，立刻停止重试机制，向上抛出给用户。
【核心机制原理解构 4：子 Agent 的三相隔离模型】
当需要派生子任务时，资源隔离与上下文共享是一对天敌。Claude Code 显式提供了三种进程/存储隔离机制：
- Fork（分叉）：
子 Agent 作为父 Agent 上下文的字节级绝对拷贝。 - 架构原理
：因为共享 100% 相同的历史，所以完美命中底层大模型的 Prompt Cache。启动 5 个并行任务的算力成本等同于 1 个。 - Teammate（同伴）：
拥有独立上下文，运行在独立终端（tmux/iTerm2），仅通过“文件级邮箱”进行通信。（防止上下文交叉污染） - Worktree（工作树）：
子 Agent 强制在独立的 Git Worktree 里工作。（防止文件系统并发写冲突）
流派三：硬约束与系统熔断（Hermes）
设计哲学：必须给概率引擎装上物理刻度的“油箱”。
【核心机制原理解构 5：迭代预算与活跃度超时】
没有底线的 while(true) 是灾难。Hermes 拒绝依靠模型自身的“聪明度”来判断停止时机，而是将防御编码进循环核心。
- 防无限循环基准（Iteration Budget）：
设定明确的调用次数生命周期。
0次 63次(70%) 81次(90%) 90次|---------------------------|--------------------------|-------------------------|开始执行 注入第一次警告 注入第二次警告 强制终止(Hard Stop)
- 活跃度超时（Liveness Timeout）设计：
针对长时任务，摒弃传统的“墙时钟”超时（即执行开始后 10 分钟无脑干掉），转而监测**“最后一次工具调用完成时间”**。只有静默超过阈值才判定为卡死。
Q2：Claude Code 的熔断与 Hermes 的硬停止有何本质区别？
- 架构代价与取舍：
Claude Code 是条件性硬停止（只有连续犯同样错误 3 次才叫停），赋予了 Agent 较高的自动重试容错率，代价是可能引入复杂的异常分支；而 Hermes 是绝对物理硬停止（无论任务多接近成功，到了 90 次油箱见底，必须死机）。前者追求自动化闭环，后者追求极致的可预测性与资源绝对安全。
三、 降维打击：从业务逻辑向“控制面”的大迁徙
看懂了这些执行循环的底层设计，我们再来回答那个终极问题：未来的系统拓扑长什么样？高级架构师的真正价值在哪里？
如果你仔细观察这三个框架，你会发现一个惊人的事实：
它们花费了数万行代码，没有一行是在写具体的业务逻辑（比如怎么发邮件、怎么查库），全都是在写“控制流（Control Flow）”——重试、熔断、并行克隆、超时截断、上下文压缩。
这标志着软件工程史上的一次伟大迁徙：从数据面（Data Plane）向控制面（Control Plane）的全面跃迁。
- 系统的重构：非确定性微服务网格（Cognitive Service Mesh）
过去，Kubernetes 和 Airflow 是我们调度确定性容器和任务的框架。
未来，像 Claude CodeQueryEngine这样的执行循环，就是 AI 时代的 K8s。Agent 不再是简单的代码脚本，而是被装在 Fork/Worktree 隔离舱里、受 Iteration Budget 监控的“认知微服务”。 - 被替代的与被重塑的：
那些每天在写“读取 A 系统数据，判断状态，调用 B 系统 API”这种死板工作流的传统业务流（CRUD/RPA）开发人员，将被彻底替代。 因为 Agent 的 ReAct 循环会自动生成这种一次性的“胶水流”。 - 架构师的终极命运：制定“物理法则”
当大模型接管了具体的业务调度后，未来的顶级架构师，工作将变得像一个“宇宙的造物主”。
你不再关心任务是怎么被执行的，你只关心： 这个 Agent 的 Prompt Cache 命中率（算力成本） 如何优化？ 它的 爆炸半径（文件级还是信箱级隔离） 是否安全？ 当它陷入逻辑死锁时，你的 迭代预算（Iteration Budget）和活跃度监控 能否在系统崩溃前 1 毫秒将其绞杀？
执行循环的设计证明了：人类也许无法完全理解大模型的思维过程，但我们依然可以通过设计严密的物理法则（架构），牢牢掌控这台轰鸣的概率引擎。