2.3. Agent Runtime 的执行循环采用了增强型 ReAct 模式

结论先行

在 Hermes Agent 中，执行循环并非对 ReAct 模式的简单复刻，而是将其拆解为 推理与计划分离、工具调用异步注入、周期性复盘触发 三个阶段，构成一套“增强型 ReAct”引擎。它把思考从一次性动作升级为多轮迭代的内部协议，从而让 Agent 不仅能完成任务，还能自行发起学习。

用一个对比表格来直观感受这种增强：

阅读完本章，你将能准确说出 Hermes 的“增强”到底发生在循环的哪些环节，以及为什么这些环节构成了一个能够自我进化的操作系统级 Runtime。

一、传统 ReAct 的局限

时间回到 2022 年底，ReAct 范式（Reasoning + Acting）首次被提出。它的核心是用自然语言交织思考和行动：LLM 输出一行“Thought”，接着输出一个“Action”，环境执行动作后返回“Observation”，然后 LLM 再输出下一个“Thought”。这种严丝合缝的线性循环，简单、可解释，很快成为 Agent 构造器的默认骨架。

但到 2025–2026 年，当 Agent 需要处理真实世界的复杂事务——例如跨平台报销、自动化研究文献综述，或是一天内执行数十个互相关联的工具调用——传统 ReAct 三个结构性局限暴露无遗：

1. 思考与行动强行绑定：LLM 必须在输出一条命令的同时，临时放下思考去执行它。这使得 Agent 无法在动手前先完整推演任务树，容易在错误的方向上越走越远。
2. 缺乏中间状态记忆：ReAct 仅将历史信息线性追加进上下文，不维护任何结构化的“任务进展对象”。一旦上下文窗口被撑满或切换模型，Agent 就会丢失对当前进度和全局目标的判断。
3. 没有自发复盘机制：传统 ReAct 只有在用户要求“评估一下你的表现”时才会反思，这不像是会学习的人，更像一个只管执行的流水线工人。

这些局限直接约束了 Agent 的学习能力和长任务稳定性。也就是在这个背景下，2026 年 2 月，Nous Research 开源了 Hermes Agent，其 Runtime 模块对 ReAct 执行循环做了系统性增强。

二、Hermes 的循环增强：思考与计划分离

Her­mes Agent 的执行循环已经不是一条扁平的“Reason→Act→Observe”链路，而是将一个完整的循环拆成两个逻辑阶段：Reasoning（推理） 与 Planning（计划） 分离，再衔接 Action 和 Observation。

根据源码分析和官方文档的描述，单次循环的信息流如下图所示（用文字描述即可）：

上下文 ──> Reasoning 阶段 ──> 生成“思维块”（internal thoughts）
                ↓
           Planning 阶段 ──> 基于思维块生成“行动清单”（task list）
                ↓
           调用工具或生成文本 ──> 返回结果
                ↓
           Observation 阶段 ──> 更新内部状态，可能触发 Nudge
                ↓
           下次循环继续

关键在于，Reasoning 阶段输出的不是具体动作，而是一个可结构化的计划草案。例如，当用户说“帮我把上周的会议录音转成文字并总结要点”时，传统的 ReAct 会立刻想“用 speech-to-text API”，然后执行，等拿到录音文字再想“用 summary 模型”。但在增强型循环中，Reasoning 阶段先完成下列推理：

• 识别出子任务：① 找到录音文件；② 转写；③ 生成摘要；④ 格式化为 Markdown 报告。
• 推断每个子任务可能需要的工具或模型。
• 标记子任务间的依赖关系（例如转写后才能摘要）。
• 猜测每一步预期的工作量。

这些推理结果会被格式化为一个内部的Plan对象，包含 Task 列表、状态、预分配资源等。后续 Planning 阶段的任务，就是根据当前上下文和现有工具，把这个草案转化为精确的行动细节（具体 API 名称、参数、回退策略）。只有在 Planning 完成后，真正去调用工具的 Action 阶段才会启动。

这样“先推理再规划”的分离带来了三个直接收益：

• 减少 LLM 的逐轮认知负荷：推理阶段只需理解需求、分解任务，无需同时处理工具参数细节，输出更稳定。
• 支持复杂流程编排：Agent 可以在头脑里先把电影般的分镜画好，再逐帧拍摄，而不是边拍边改剧本。
• 方便并行操作：独立子任务可以被同时调度（下一节详述），这在传统 ReAct 的串行“思考-行动”里根本无法实现。

从当前调研资料看，这种分离也使得 Hermes 能够接入多模型路由：推理阶段可能调用一个擅长规划的大模型，执行阶段调用更轻量、更便宜的工具语言模型，从而实现成本最优。

三、行动调用与工具结果注入

在计划阶段完成后，行动调用（Action）就开始了。Hermes 的 Action 系统与工具调用是通过“工具注册表 + 异步调度”实现的，这与传统 ReAct 同步阻塞的模式形成鲜明对比。

工具注册表维护了所有可用工具的元信息：工具名称、描述、输入输出 schema、超时策略、是否支持并行调用等。当 Planning 阶段产出一个等待执行的 Task 列表时，调度器会检查这些任务的依赖关系。对于互不依赖的任务，可以同时发起调用。

举个例子：执行前述会议纪要任务时，找到录音文件这一步可能需要调用文件系统 API，而同时，Agent 可以提前检查转录服务的健康状态或请求 API 配额。这种并行异步模式在 Hermes 中是被原生支持的。

工具调用的实际流程是：

1. 调度器根据 Plan 中的 Action 描述，构建对应的 API 请求或本地函数调用，异步提交。
2. 每个工具调用的返回结果（成功/失败、产出数据）进入一个统一的结果队列。
3. 在执行循环的 Observation 阶段到来时，这些结果被批量注入回当前上下文。

注意“批量注入”这个词：传统 ReAct 是工具调用立即返回就立刻拼接到 prompt 里，导致上下文在短时间内膨胀且碎片化。而 Hermes 可以选择收集多个工具结果后，一次性整理成一段简洁的摘要，再注入到对话或内部状态中。这样做既降低了 token 消耗，也避免 LLM 被散乱的结果搞乱注意力。

工具调用结果的注入还包含归因信息：每段结果都会附上是由哪个 Task 产出的、是否异常、建议的后续步骤。这相当于人类在执行一个步骤后，不是粗暴地把打印日志扔给大脑，而是先让自己的“观察助手”整理成一份简报。

从调研素材的社区分析可看到，这种工具调用机制使得 Hermes 在处理需要大量工具组合的任务时（比如一次性操作十几个不同 API），平均耗时比传统 Serp‑Agent 降低了 42%（该数字来自某篇社区评测，采样任务为电子商务自动下单场景）。当然，这并非绝对权威数据，但足够说明异步注入的工程价值。

四、观察阶段的状态更新与 Nudge 触发

行动结果被整理注入后，进入 Observation（观察）阶段。在这一步，传统 ReAct 只是把结果作为下一次思考的跳板，但 Hermes 做了两件额外的事：更新内部状态对象和计算复盘触发条件。

4.1 内部状态对象

Her­mes 维持着一个称为AgentState的结构化对象，包含：

• 当前任务的完成百分比（通过一个进展评估器估算）
• 每个子任务的状态：待执行、运行中、已完成、失败
• 已使用的工具及其成功率
• 错误堆栈和重试次数
• 学习模块触发的标记

Observation 阶段会将本轮工具的结果更新到AgentState中，并基于此决定下一步走向。例如，如果一个子任务连续三次失败，内部状态就会降低主线任务的信心值，进而触发 Planning 阶段生成一个替代策略或回退方案。这使得 Agent 具备类似“根据挫折调整预期”的能力，而不是懵头懵脑地无限重试。

4.2 周期性 Nudge 与自动复盘

外部调研文章明确提到 Hermes 的一个核心创新是“周期性 Nudge（提示机制）”。具体来说，Runtime 内置一个计数器，每执行完一定轮次（默认可能为 5 或 10 轮，可配置），会自动产生一个内部信号：“该复盘了”。这个信号并非用户发出的，而是 Agent 自己给自己触发一个反思子流程。

当 Nudge 触发时，循环不再直接进入下一轮 Reasoning，而是先插入一个反思子循环：Agent 会将最近的行动历史、内部状态变化和结果摘要，交由一个专门的复盘模型（或就是当前 LLM 但以总结模式运行）进行简短分析，提炼出几条经验教训，并决定是否要将某些知识持久化为“技能”或“记忆”。这个过程全自动，用户甚至可能察觉不到。

这背后是一个重要认知转变：学习不再是使用者需要主动发出的“请总结一下”请求，而是变成了 Agent 的本能。这个机制解释了为什么 Hermes 在官方文档中强调“自己越用越聪明”——因为它在不停地把做过的任务总结成可复用的经验。

4.3 综合：一个完整循环的刻度

把以上所有阶段串联起来，就是一次增强型 ReAct 循环的完整执行：

1. 上下文输入：任务、历史、工具元信息、上一次的 Observation 摘要。
2. Reasoning（推理）：生成高层计划草案（结构化 Plan）。
3. Planning（规划）：将草案转化为精确的 Action 列表，处理依赖，确定执行顺序。
4. Action（行动）：异步或并行调用工具，收集结果，批量整理成报告。
5. Observation（观察）：将报告注入上下文，更新AgentState，并检查是否需要触发 Nudge 复盘。
6. 如果是最后一轮（任务完成或达到最大步数），生成最终回答；否则回到步骤 1 开启下一轮循环，其中 AgentState 会作为内部信号影响下一轮的推理。

正是这五个环节的协同，让 Hermes 的增强型 ReAct 摆脱了“单线思维”，成为支撑自进化体的运转内核。

五、结论与选择

我们再用一个对比表格总结增强型 ReAct 给 Agent 带来的改变：

基于上述分析，如果你正在设计自己的 Agent 运行时，作者给出的推荐策略是：

• 不要满足于一个无限 while 循环里反复 prompt + execute。 先做任务分解和计划存储，即使你暂时不用异步执行。
• 为 Agent 建立内部状态对象，并设置“触发复盘”的简单机制（例如每完成 10 个步骤就自动总结一次），会显著提升长期任务的稳定性和感觉上的“聪明度”。
• 考虑将工具调用结果统一收集、批量整理后再填入 prompt，这能缓解上下文膨胀问题，还能减少 LLM 被无关信息干扰。

当然，任何增强都是有代价的。增加的结构化计划、状态更新、复盘触发都需要额外的计算和 token 开销，适合复杂、长周期的任务。如果你的任务只是一次简单的问答，那么原版 ReAct 可能更轻量。关键是根据场景在复杂度和收益间取得平衡。

在下一章《Prompt Builder 实现了一套轻量级 RAG 管理系统》中，我们将走进上下文本身的构建过程。 你刚刚看到的“推理、规划、工具结果”都必须经由 Prompt Builder 才被拼装成 LLM 可以理解的最终 prompt，而它内部使用了一套最小化的 RAG 机制来压缩历史、复用摘要，避免上下文膨胀。我们接着看。