看到一系列好的文章，这里分享一下：
https://mp.weixin.qq.com/s/nb8TstDnh0CfW0KNyREt9g
执行循环是 Agent 的心脏
记忆系统决定 Agent 知道什么，工具系统决定 Agent 能做什么。
执行循环决定 Agent 怎么把"知道的"和"能做的"结合起来，把一个用户指令变成一系列真实的操作。
一个设计糟糕的执行循环，会让 Agent 出现这些症状：
-
接到复杂任务，直接冲进去执行，中途才发现方向错了
-
工具调用失败，要么无限重试，要么直接停住
-
跑了很长时间，用户完全不知道在做什么，感觉像黑盒
-
任务执行到一半，上下文满了，状态丢失，从头来过
这四个症状对应四个架构问题：规划能力、错误恢复、执行可见性、状态持久性。
三个框架对这四个问题，给出了截然不同的答案。
ReAct 循环：所有框架共同的底层
在拆解三个框架之前，先把共同的底层说清楚。
现代 Agent 框架普遍基于 ReAct 模式（Reason-Act-Observe）：
接收输入 ↓推理（Reason）：分析当前状态，决定下一步 ↓行动（Act）：调用工具执行操作 ↓观察（Observe）：获取工具执行结果 ↓将结果注入上下文，继续推理 ↓（循环，直到任务完成或触发停止条件）这个循环听起来简单，但生产级实现的复杂度，从 Claude Code 泄露的源码里能看到一个侧面：仅 QueryEngine.ts 一个文件就有 46,000 行，负责处理所有 LLM 调用、流式响应、缓存、重试和编排逻辑。
这不是意外的膨胀，这是 ReAct 循环在生产环境里运行所需要的工程量的真实写照。
三个框架的 ReAct 实现都建立在这个基础上，但在触发方式、规划深度、错误处理、停止条件上做出了不同的架构选择。
OpenClaw：双触发模式，被动响应 + 主动唤醒
核心设计：两种不同的执行入口
OpenClaw 的执行循环有一个很独特的设计------它有两种触发方式，各自走不同的路径：
被动响应：用户发来消息，Gateway 接收，启动 Agent 会话，在 ReAct 循环里处理，返回结果，会话结束。
主动心跳（Heartbeat） ：系统每隔固定时间（默认 30 分钟）自动触发，Agent 读取 HEARTBEAT.md 里的任务清单，决定是否需要采取行动。
心跳机制解决了一个根本问题：语言模型是被动的，不会主动做事。 Heartbeat 是 OpenClaw 给语言模型安装的闹钟------定时叫醒它，扫描待办，主动执行。
HEARTBEAT.md 的结构：
## 每日任务- 每天早上 7:00：读取昨天工作日志，发送当日摘要- 每天下午 6:00：检查待办事项，标记已完成项## 监控任务- 每 30 分钟：检查服务器状态，如有异常立即通知当心跳触发，Agent 读取这份文件，判断哪些任务时间到了，执行。如果没有需要处理的事情，回复 HEARTBEAT_OK 信号，Gateway 静默丢弃，不打扰用户。
Cron Job：精确时间点触发
心跳是"每隔一段时间扫描"，Cron Job 是"在精确时间点执行"。
Cron Job 还解决了心跳做不到的"等待"问题------Agent 触发了一个需要 3 分钟才能完成的外部操作，不能傻等。正确做法是设一个 3 分钟后的 Cron Job，当前会话结束，到时间由新会话去检查结果。
执行操作 → 发现需要等待 ↓创建 Cron Job（3 分钟后执行） ↓当前会话结束 ↓（3 分钟后）Cron Job 触发新会话 ↓检查结果，继续后续步骤这是用时间换空间的架构思路：用定时任务替代阻塞等待，每个会话都保持轻量。
错误恢复：依赖模型判断，风险集中
OpenClaw 的错误处理相对简单：工具执行失败，错误信息注入上下文，模型自己决定------重试、换方法还是向用户报告。
这个设计有一个已知的生产问题：模型在遇到错误时，有时会"默默绕路"------用相近的任务替代失败的任务，然后自信地汇报"完成"，但原始任务实际上没有执行。
没有内置的重试次数限制，没有强制的错误上报机制，错误恢复质量完全依赖模型的判断能力。
Claude Code：先规划再执行，自愈查询循环
核心设计：显式规划 + 工程级错误处理
Claude Code 的执行循环和 OpenClaw 最大的不同，在于显式的规划阶段。
Claude Code 有专门的 Plan 模式：在执行任何操作之前，先让 Agent 输出完整的执行计划，等用户确认，再按计划逐步执行。
这个设计回答了一个经典问题：复杂任务应该先规划还是直接执行？
先规划的好处是：在真正执行前，人有机会发现计划里的问题，纠正方向，避免产生副作用之后才发现错误------修改了文件、发出了请求，回滚成本很高。
从泄露的源码还发现了更高级的规划系统------代号 ULTRAPLAN：把复杂规划任务卸载到远端 Cloud Container Runtime，运行 Opus 4.6，规划窗口最长 30 分钟，本地每 3 秒轮询一次结果，浏览器 UI 支持审批和驳回。
这说明 Anthropic 认为规划是值得单独投入算力的子系统，而不是和执行混在一起的。
自愈查询循环
Claude Code 最有工程价值的设计，是 QueryEngine 里的自愈机制：
工具调用失败 → 分析错误类型，决定重试或换方案
模型输出格式不对 → 提示模型修正，重新生成
上下文接近上限 → 触发 Compaction，压缩历史，继续执行
有一个来自源码注释的内部数据：在 2026 年 2 月，工程师用 BigQuery 发现 1,279 个会话出现 50 次以上连续 Compaction 失败，单个会话最多重试 3,272 次，每天浪费约 25 万次 API 调用。
修复方案简单直接：
MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3连续失败超过 3 次，停止重试，上报用户。 这个熔断器是从真实生产数据里推导出来的，不是纸上设计。
三种子 Agent 执行模型
从泄露源码里发现了 Claude Code 内部的三种子 Agent 模式，由源码中多处引用所证实：
Fork（分叉）：子 Agent 继承父 Agent 的完整上下文作为字节级拷贝，命中 Prompt Cache------因为上下文完全相同，并行启动 5 个子 Agent 的 Cache 成本几乎等于启动 1 个。适合需要父上下文的探索性子任务，并行几乎免费。
Teammate（同伴）：子 Agent 和父 Agent 通过文件级邮箱通信，各自有独立上下文，可以运行在独立的终端面板（tmux/iTerm2）。适合相互独立的并行子任务。
Worktree（工作树）：子 Agent 在独立的 Git Worktree 里工作，有完全隔离的文件系统视图，防止并行修改冲突。适合需要文件系统隔离的任务。
这三种模式回答了一个重要的架构问题：子任务需要多少上下文共享？ 不同场景需要不同程度的隔离，一刀切会在某些场景下既浪费资源又引入风险。
执行可见性：实时流式输出
Claude Code 的每一步工具调用、每一次文件修改，都实时显示给用户。
这不只是用户体验问题，是执行循环架构的一部分：用户的观察和干预，是执行循环的一个输入。 用户看到中间状态，可以随时叫停，修正方向。
Hermes Agent：调度器作为一等公民，迭代预算防失控
核心设计：调度深度集成到执行架构
Hermes Agent 的执行循环有一个和另外两个框架都不同的特征：调度器不是附加功能，而是架构的一等公民。
OpenClaw 里，Heartbeat 是 Gateway 旁边的附加机制。Claude Code 里，调度没有原生支持。Hermes 里，Cron 调度器和 Gateway 深度集成------调度器的 tick 是 Gateway 主事件循环的一部分，每次维护周期都调用 scheduler.tick()。
Cron 任务执行流程：
scheduler.tick() 被调用 ↓获取调度器锁（防止并发执行同一批任务） ↓筛选到期且状态为 scheduled 的任务 ↓对每个到期任务： 创建全新 AIAgent 会话（无历史上下文） 按顺序加载附加的 Skills 执行任务 prompt 结果路由到配置目标 更新 run_count，计算下次执行时间 ↓释放调度器锁每个 Cron Job 都在全新的会话里执行------和 OpenClaw 的设计一致，保持干净的执行状态。但知识不丢失，因为热记忆层（MEMORY.md + USER.md）和 Skills 每次都会加载。
Cron 任务 + Skills：调度任务随时间进化
Hermes Agent 调度器有一个独特设计：Cron Job 可以附加 Skills。
{
"name":"Morning AI briefing",
"prompt":"Summarize today's top AI news",
"schedule":"0 8 * * *",
"skills":["ai-funding-daily-report","news-aggregator"]
}这意味着调度任务不只是"定时执行一个 prompt"，而是"定时用特定经验和方法执行一个任务"。随着 Agent 积累 Skills，同样的调度任务，执行质量会随时间提升。
执行循环和学习循环在这里融合------每次执行既完成任务，也可能沉淀为 Skill，下次执行质量更好。
迭代预算：防止无限循环的硬约束
Hermes Agent 有一个 OpenClaw 和 Claude Code 都没有的机制------
迭代预算（Iteration Budget）：
0 次 63 次（70%） 81 次（90%） 90 次|__________________|____________________|___________________|开始执行 第一次警告 第二次警告 强制停止默认上限 90 次工具调用，70% 和 90% 处各有一次警告，达到上限强制停止。
这个设计的架构价值：把无限循环的防护编码进执行循环本身，而不是依赖外部监控。
没有这个机制，Agent 可能在边界条件下进入无限循环------每次都认为"再试一次就能成功"，实际上在消耗资源却没有进展。迭代预算是明确的"执行完成度"概念，让 Agent 感知自己还有多少"油"，可以据此调整剩余策略。
超时：墙时钟 vs 活跃度
Hermes Agent 的超时机制（默认 10 分钟）有一个已知的设计局限：当前实现是固定墙时钟超时------从任务开始计时，10 分钟后强制终止。
这会误杀合法的长时任务（比如等待慢 API 响应的数据分析任务）。
社区讨论的更合理方案是活跃度超时：不从任务开始计时，而是监测最后一次工具调用完成的时间，只有"静默"超过阈值时才触发。这能区分"正在工作"和"卡死在某个调用"两种状态。
这个取舍揭示了一个执行循环的通用原则：超时策略的目标是检测真正的失败，而不是限制正常的长时间任务。
执行循环设计的核心取舍
取舍一：先规划还是直接执行
Claude Code 的 Plan 模式选择先规划。好处是减少方向错误的浪费；代价是每次复杂任务多一个确认回合，不适合完全自动化的场景。OpenClaw 和 Hermes 选择直接执行，依赖模型自己在执行中调整，流程更自然但中途修正成本更高。
取舍二：软停止还是硬停止
Hermes 的迭代预算是明确的硬停止------达到上限就停，不管有没有完成。Claude Code 的熔断器是条件性硬停止------只在连续失败超过阈值时触发。OpenClaw 更接近软停止------依赖模型判断任务何时完成。
硬停止给系统更强的可预测性，软停止给 Agent 更多自主性。没有绝对对错，取决于你的场景更需要哪个。
取舍三：子任务用多少隔离
Claude Code 的三种子 Agent 模式（Fork/Teammate/Worktree）把这个问题显式地暴露为一个设计决策------不同任务选不同的隔离级别。OpenClaw 和 Hermes 的子任务默认全隔离，更简单但少了灵活性。
Fork 模型里有一个值得注意的工程洞察：因为共享父上下文命中 Prompt Cache，并行启动多个子 Agent 的成本几乎等于启动一个------这是 Claude Code 能做到"并行几乎免费"的架构原因。