opencraw架构（3）- Agent Loop循环

目录

• Agent Loop循环-react模式
  • • 1. 核心循环：边想边做（Interleaved Reasoning & Execution）
    • 2. 如何进行深度规划？（Thinking 机制）
    • 3. 如何完成“多 Agent”调用？（Sub-agents 工具）
    • 总结对比
• 1. 核心循环（边想边做）是什么
  • 2. Sub-agents（多 Agent 调用）是什么
  • 3. 区别对照
  • 4. 一句话

为什么是ReAct 而不是Plan & Execute？

项目	ReAct（OpenClaw 用的）	Plan & Execute
执行流程	一步一步走，边做边决定下一步	先产出完整计划，再逐步执行
弹性	高（可根据工具输出即时调整）	低（计划定了就照做）
Token 消耗	较高（每步都要完整 context）	较低（计划阶段只思考一次）
适合场景	探索性任务、不确定步骤数	明确流程、可预测步骤

Agent Loop循环-react模式

在传统 Agent 架构（如早期的 AutoGPT、LangChain 的 Plan-and-Execute）中，通常有一个死板的“状态机”：先强制让大模型写出一个 [Step 1, Step 2, Step 3] 的清单，然后框架按照这个清单逐个执行，每次停下来让模型评估。

OpenClaw 没有采用这种硬编码的“规划-执行”状态机。
相反，OpenClaw 处理复杂多工具、多 Agent 调用的核心理念是：原生工具调用循环（Iterative Tool Calling） + 显式思考（Thinking） + 动态召唤（Sub-agents）。

具体是如何完成的？分为以下三个层面：

1. 核心循环：边想边做（Interleaved Reasoning & Execution）

OpenClaw 不会强迫模型在一开始把所有步骤定死（因为现实情况往往在第一步就因为报错而偏离了计划）。
它的底层是一个连续的对话循环（Loop）：

1. 收到 Query： LLM 收到用户需求和所有可用工具（本地工具 + Node 远程命令）。
2. 思考与调用： LLM 输出自己的推理过程，并同时发起一个或多个 Tool Call。
3. 框架执行： OpenClaw 执行这些工具（比如向树莓派发 node.invoke），拿到结果。
4. 状态回传： OpenClaw 把成功或报错的结果附加到对话历史中，再次触发 LLM。
5. 动态调整： LLM 看到报错，自动决定是“换个参数重试”、“换个工具尝试”，还是“发消息问用户”。
6. 结束： 直到 LLM 认为任务完成，输出最终回复，循环停止。

这个过程是非常丝滑的，不需要“先列计划清单”，计划是存在于 LLM 当下那一轮的上下文中。

2. 如何进行深度规划？（Thinking 机制）

如果遇到非常复杂的任务，LLM 确实需要先盘算一下。OpenClaw 是怎么做的？
通过「显式思考级别（Thinking Level）」。

• 你可以在消息里加一个指令，比如 /think:high 帮我排查一下服务器宕机原因。
• OpenClaw 会在系统提示词中强制开启深度思考模式。模型会在真正调用工具之前，在自己内部的 <thinking> 标签里写下：“要排查宕机，我首先需要去 Node A 看系统日志，然后去 Node B 看网关状态，如果发现...我再去...”。
• 规划发生在大模型原生的思考过程中，而不是框架层面的强制状态机。这保留了极大的灵活性。

3. 如何完成“多 Agent”调用？（Sub-agents 工具）

这是 OpenClaw 设计中最强大的地方。
假设用户给了一个巨复杂的任务：“分析一下上个月的财报数据，帮我写个 Python 脚本画个饼图，然后传到树莓派上展示。”

如果让主 Agent 一把梭，不仅容易出错，而且大量的“试错报错、写代码调试”的记录会把主聊天窗口（Session）弄得非常脏。

OpenClaw 的解决方式是让主 Agent 当“包工头”：

1. 主 Agent 看了任务，调用了内置的 subagents 工具。
2. 它发起调用：subagents(action: "spawn", prompt: "你去写个画饼图的 Python 脚本，直到跑通为止，把代码给我")。
3. 此时，OpenClaw 在后台拉起了一个全新的、纯净的子 Agent（这也是 Agent-as-Resource 的体现，瞬间分配一个新资源）。
4. 这个子 Agent 在后台疯狂地循环：写代码 -> 调用本地 bash 运行 -> 报错 -> 修改代码 -> 运行通过。
5. 子 Agent 运行结束后，把最终那段完美的 Python 代码返回给主 Agent 的工具结果里。
6. 主 Agent 拿到代码后，再调用 node.invoke 把代码发给树莓派（Node）去执行。
7. 最后，主 Agent 在当前的聊天框里对用户说：“搞定了，图已经显示在树莓派上了。”

总结对比

环节	传统“清单式” Agent 架构	OpenClaw 架构
生成计划	框架层强制分为 Planner 和 Executor 两个实体。	模型原生推理，通过 /think 触发内部规划，边做边调。
应对失败	按照步骤节点，失败后进入评估状态决定是否回退。	融入统一的 Tool Calling Loop，模型看到错误自动决定重试还是问用户。
多任务隔离	往往都在一个巨大的上下文中堆砌日志。	遇到脏活累活，主 Agent 动态调用 subagents 召唤子 Agent 隔离执行。
多节点调度	需要配置复杂的路由脚本。	统一通过 node.invoke 工具，由主 Agent 决定代码是在本地跑还是远端跑。

所以，OpenClaw 完成复杂任务不靠“写死清单”，靠的是 “原生的工具循环纠错” + “主从 Agent 动态召唤” + “统一的资源路由（Gateway/Node）”。这种方式容错率更高，也更符合大模型自身的发展趋势的发展趋势。

1. 核心循环（边想边做）是什么

• 范围：一个 Agent、一条 Session、一次完整对话。
• 过程：
  用户发话 → LLM 想/输出 → 发起若干 Tool Call（如 read_file、node.invoke、exec）→ 框架执行这些工具、把结果塞回对话 → 再调 LLM → 如此反复，直到 LLM 给出最终回复。
• 特点：
  • 工具是普通函数/能力（读文件、调 Node、跑命令），在当前这次 Agent 运行里执行，结果都写进同一条对话历史。
  • 没有“再开一个 Agent”，只是同一个 Agent 多轮“想 → 调工具 → 再看结果”。

所以：核心循环 = 单个 Agent 的“边想边做”循环，多步是“多轮工具调用”，不是多个 Agent。

---

2. Sub-agents（多 Agent 调用）是什么

• 范围：主 Agent 在循环里调用了其中一个工具，这个工具叫 subagents，作用是再起一个完整的 Agent 运行。
• 过程：
  主 Agent 在某一步发起 subagents(action: spawn, prompt: "去写个脚本并跑通...") → 系统新起一条 Agent 运行（新的 LLM 循环、新的临时上下文）→ 子 Agent 自己“边想边做”（也可以调各种工具）→ 子 Agent 跑完后把最终结果作为这一次 tool call 的返回值还给主 Agent → 主 Agent 继续自己的循环（可能再调别的工具或直接回复用户）。
• 特点：
  • 子 Agent 有独立的对话/上下文，不会把中间的试错、长输出塞进主会话。
  • 对主 Agent 来说，“调 subagents”和“调 read_file”一样，都是一次 tool call，只是这个 tool 内部是“跑完一整条 Agent”。

所以：Sub-agents = 在“边想边做”的某一步里，通过一个特殊工具再启动一条完整的 Agent 运行，实现多 Agent 协作。

---

3. 区别对照

维度	核心循环（边想边做）	Sub-agents（多 Agent 调用）
发生层面	一次 Agent 运行的主流程	这次运行里某一步调用的一个工具
参与方	只有当前这个 Agent + 一堆普通工具	当前 Agent + 另一个完整 Agent（子 Agent）
工具是什么	读文件、调 Node、执行命令等普通工具	子 Agent 整段运行，结果当作一个工具的返回值
上下文	所有结果都进同一条 Session 历史	子 Agent 用自己的临时上下文，主 Session 只看到最终结果
典型用途	所有对话的默认方式：一步步推理、查资料、调设备	把复杂/脏活（写代码、长链推理）丢给子 Agent，保持主会话干净

---

4. 一句话

• 核心循环：一个 Agent 在一条会话里，反复“想 → 调工具（普通工具）→ 看结果 → 再想或回复”。
• Sub-agents：在这个循环的某一步，调一个特殊工具，这个工具会再跑一整条 Agent，跑完把结果当这一次调用的返回值；本质是“多 Agent”，但对主 Agent 来说只是“多调了一个工具”。

所以：核心循环是“单 Agent + 多工具”的步进方式；Sub-agents 是在这种步进里，用“再起一个 Agent”当一种工具，完成多 Agent 调用。