系列说明：本系列共计约 20 篇，全面介绍 OpenClaw 开源 AI 智能体框架。本文为系列第 008 篇，聚焦于 OpenClaw Agent 智能体循环机制深度解析。建议先阅读 第 007 篇：流量枢纽——OpenClaw Gateway 网关深度解析。

---

摘要

“龙虾循环”（Lobster Loop）是 OpenClaw 智能体的核心驱动引擎，它脱胎于学术界的 ReAct 框架，在工程实践中演化为 Think（思考）→ Act（执行）→ Observe（观察）→ Reflect（反思）的四段式闭环。本文从理论基础出发，深入剖析 OpenClaw 智能体循环的每个阶段，讲解工具调用（Function Calling）的完整生命周期、上下文窗口压缩机制、循环终止策略，并横向对比 LangChain、AutoGen、CrewAI 的 Agent Loop 实现差异，配以完整代码示例，帮助读者彻底理解"AI 如何真正地做事"。

---

一、从一个问题开始：AI 如何"做事"？

当我们向 ChatGPT 提问"今天北京天气怎么样"，它会回答，但这个回答来自训练数据——它实际上并不知道今天是几号，更无法查询实时天气。这是传统 LLM 的本质局限：只能基于训练知识生成文本，无法主动采取行动获取信息或改变世界。

OpenClaw 代表的 AI Agent 系统，解决的正是这个问题。它让 AI 从"回答问题"变成"解决问题"——不仅能思考，还能调用工具查询天气、读写文件、执行代码、控制浏览器。这种能力背后的核心机制，就是本文的主角：Agent Loop（智能体循环）。

---

二、理论基础：ReAct 框架

2.1 ReAct 的诞生

2022 年，普林斯顿大学与谷歌研究院联合发表了论文《ReAct: Synergizing Reasoning and Acting in Language Models》（arXiv:2210.03629，发表于 ICLR 2023）。这篇论文提出了一个简单但深刻的想法：

让 LLM 交替生成"推理轨迹（Reasoning Trace）“和"环境行动（Action）”，而不是分别单独进行。

在此之前，AI 研究界有两条相对独立的路线：一条是 Chain-of-Thought（思维链），让模型生成中间推理步骤；另一条是 Action Planning，让模型规划并执行动作。ReAct 的贡献在于将两者有机融合，形成如下循环：

用户问题
    ↓
Thought（推理）：我需要查询今天北京的实时天气数据
    ↓
Action（行动）：search["北京天气"]
    ↓
Observation（观察）：搜索结果返回 "北京今天晴，气温 18-26°C，东北风3级"
    ↓
Thought（推理）：信息已获取，可以给出最终答案
    ↓
Final Answer：今天北京天气晴朗，气温在18到26摄氏度之间…

2.2 ReAct 的实验成果

论文在多个基准任务上验证了 ReAct 的有效性：

在 HotpotQA（多跳问答）和 FEVER（事实验证）任务中，ReAct 显著减少了幻觉现象，因为模型被迫通过工具检索真实信息，而非从记忆中"编造"答案。在 ALFWorld（文字游戏环境）中，绝对成功率提升了 34%；在 WebShop（模拟在线购物）中提升了 10%。

更重要的是，ReAct 的推理轨迹具备可解释性——我们能够清楚地看到 AI 在每一步"想了什么"、“做了什么”，这是调试和监督 AI Agent 的重要基础。

2.3 从学术到工程

从强化学习（RL）的视角来看，Agent Loop 对应了经典的 POMDP（部分可观测马尔可夫决策过程）框架：

RL 概念	Agent Loop 中的对应
State（状态）	当前上下文窗口（对话历史 + 工具结果）
Action（动作）	LLM 输出的工具调用指令
Observation（观测）	工具执行结果
Reward（奖励）	任务完成度（通过 RLHF 隐式编码在模型中）
Policy（策略）	经过 RLHF 训练的 LLM 本身

这个理论框架使得 Agent Loop 不仅是一种工程实践，更有坚实的理论根基。

---

三、Lobster Loop：OpenClaw 的工程实现

OpenClaw 将其智能体循环命名为 “Lobster Loop（龙虾循环）”——这个命名带有浓厚的项目风格，与框架名称中的"Claw"（爪子）形成呼应。驱动这个循环的核心组件称为 Pi Agent（Pi Embedded Runner），位于 src/agents/ 目录下。

3.1 四阶段闭环结构

Lobster Loop 在 ReAct 的 Think-Act-Observe 三段式基础上，增加了第四阶段 Reflect（反思），形成更完整的认知闭环：

┌─────────────────────────────────────────────────┐
│              Lobster Loop 龙虾循环               │
│                                                  │
│   ┌──────────┐           ┌──────────────┐       │
│   │  Think   │ ─────────▶│     Act      │       │
│   │  思考     │           │    执行      │       │
│   └──────────┘           └──────────────┘       │
│         ▲                        │               │
│         │                        ▼               │
│   ┌──────────┐           ┌──────────────┐       │
│   │ Reflect  │◀──────────│   Observe    │       │
│   │  反思     │           │     观察     │       │
│   └──────────┘           └──────────────┘       │
│         │                                        │
│         └── 任务已完成？──▶ 生成最终回复 ────────▶│
└─────────────────────────────────────────────────┘

每一次完整的循环称为一个"轮次（Turn）"，一个复杂任务可能经历数十个轮次才能完成。

---

四、四个阶段的深度剖析

4.1 Think（思考）阶段——LLM 推理

Think 阶段是调用 LLM 进行推理决策的核心步骤，对应源码 src/agents/system-prompt.ts 和 src/agents/model-selection.ts。

输入组成（动态组装的上下文）：

Think 阶段送入 LLM 的 prompt 并非静态文本，而是每轮动态组装的复合上下文，由以下几部分拼接：

1. 系统提示词（System Prompt）：从以下文件动态读取并组合——

   • AGENTS.md：Agent 的角色定义、行为指令、工作边界
   • SOUL.md：Agent 的性格设定（语气、风格、个性化表达）
   • TOOLS.md：当前可用工具的描述说明
   • MEMORY.md：长期记忆摘要（仅限私密会话）

2. 工具列表（Skills Schema）：通过 toClientToolDefinitions() 将所有已加载的 Skills 转换为 LLM 可识别的工具定义 JSON Schema，相当于告诉 LLM “你现在有哪些武器可以使用”。

3. 会话历史（Messages History）：由 SessionManager 加载的当前会话完整对话历史（含之前所有轮次的工具调用和结果）。

4. 当前用户输入：本轮用户发送的新消息。

输出：

LLM 的输出有两种形式，这是判断循环是否继续的关键分叉点：

• 包含 tool_calls：LLM 认为需要调用一个或多个工具才能继续，循环继续。
• 纯文本（不含 tool_calls）：LLM 认为任务已完成或已有足够信息，输出最终回复，循环结束。

4.2 Act（执行）阶段——工具调用

Act 阶段负责解析 LLM 输出的 tool_calls，依次执行每个工具调用，对应核心源码 src/agents/attempt.ts。

执行流程（伪代码示意）：

for (const toolCall of response.tool_calls) {
  // 第一步：权限策略过滤（Policy Pipeline）
  // 按优先级依次检查：Profile Policy → Provider Policy
  // → Global Policy → Agent Policy → Group Policy
  await applyToolPolicyPipeline(toolCall);

  // 第二步：记录执行开始（推送 WebSocket 状态事件）
  await handleToolExecutionStart(toolCall);

  // 第三步：在沙箱中执行工具
  const result = await executeTool(toolCall);

  // 第四步：将结果追加到会话历史（供 Observe 阶段使用）
  await sessionManager.appendToolResult(
    toolCall.id,
    toolCall.name,
    result
  );

  // 第五步：执行后钩子（用于日志、监控、成本追踪）
  await handleToolExecutionEnd(toolCall, result);
}

沙箱安全隔离：

Act 阶段最值得关注的设计是沙箱执行机制。所有高危工具（如 Shell 命令执行、文件删除）都在隔离的 Docker 容器中运行：

# 沙箱配置
security:
  sandbox:
    enabled: true
    type: "docker"
    resource_limit:
      cpu: 0.5       # 最多使用 0.5 核
      memory: 512m   # 最多使用 512MB 内存
    network: "none"  # 禁止容器内网络访问

沙箱支持三种隔离粒度：session（会话级，最严格）、agent（Agent 级，默认）、shared（共享，性能最佳）。对于高风险操作，系统还会在执行前向用户推送确认请求，体现了"AI 应当在人类监督下行动"的设计理念。

4.3 Observe（观察）阶段——结果收集

Observe 阶段将工具执行的结果以标准化格式追加到会话上下文，供下一轮 Think 阶段的 LLM 参考。

不论工具执行成功还是失败，结果都会被如实记录并传递给 LLM，这是 OpenClaw 的重要设计原则之一：不隐藏错误，让 LLM 自主决策如何应对。

工具结果消息格式（OpenAI 格式）：

{
  "role": "tool",
  "tool_call_id": "call_abc123",
  "content": "文件 /home/user/data.csv 读取成功，共 1024 行，字段：id, name, score, date"
}

错误信息也同样传递：

{
  "role": "tool",
  "tool_call_id": "call_xyz789",
  "content": "错误：文件 /tmp/nonexistent.txt 不存在。提示：可以先使用 list_files 工具查看目录结构。"
}

这种设计使 LLM 能够像一个有经验的开发者一样应对错误——看到错误信息，理解原因，决定是换参数重试、换工具，还是告知用户问题所在。

4.4 Reflect（反思）阶段——评估与决策

Reflect 阶段是四段式循环的"决策节点"，决定循环是继续还是终止。这个阶段并非一个独立的 LLM 调用，而是内嵌在 Think 阶段中的逻辑判断：LLM 在接收到所有工具结果后，会在下一个 Think 轮次中综合评估当前进展，决定下一步行动。

同时，Reflect 阶段也负责更新 Agent 的状态机：

状态	含义
streaming	正在流式输出 AI 响应
compacting	正在执行上下文压缩
error	发生不可恢复的错误
idle	循环结束，等待下一条消息

---

五、工具调用（Function Calling）机制详解

5.1 两大主流协议的格式对比

目前 AI Agent 领域存在两种主流的工具调用协议：

OpenAI Function Calling 格式：

{
  "type": "function",
  "function": {
    "name": "read_file",
    "description": "读取本地文件内容，返回文本",
    "parameters": {
      "type": "object",
      "properties": {
        "path": {
          "type": "string",
          "description": "文件的绝对路径"
        },
        "encoding": {
          "type": "string",
          "description": "文件编码，默认 utf-8",
          "default": "utf-8"
        }
      },
      "required": ["path"]
    }
  }
}

Anthropic tool_use 格式（Claude 原生）：

{
  "type": "tool_use",
  "id": "toolu_01A09q90qw90lq917835lq9",
  "name": "read_file",
  "input": {
    "path": "/home/user/document.txt"
  }
}

OpenClaw 通过 normalizeToolParameters() 函数自动识别并适配这两种格式，开发者在编写 Skills 时无需关心底层使用的是哪家模型的 API。

5.2 并行工具调用（Parallel Tool Calling）

现代 LLM 支持在同一个响应中返回多个工具调用，允许框架并发执行，显著减少整体延迟。例如，当用户说"帮我查一下今天北京和上海的天气，同时看看我的日历今天有什么安排"，LLM 可以一次性输出三个工具调用：

{
  "tool_calls": [
    {"id": "call_1", "function": {"name": "get_weather", "arguments": "{\"city\": \"北京\"}"}},
    {"id": "call_2", "function": {"name": "get_weather", "arguments": "{\"city\": \"上海\"}"}},
    {"id": "call_3", "function": {"name": "read_calendar", "arguments": "{\"date\": \"today\"}"}}
  ]
}

OpenClaw 对这三个独立工具调用采用 Promise.all 模式并发执行，而非依次串行，将响应时间从三次串行调用之和压缩到单次调用时间（约等于最慢那个工具的执行时间）。

5.3 工具调用的完整生命周期

1. 工具定义（SKILL.md 中声明工具 Schema）
         ↓ TypeBox 验证
2. 运行时注册（Pi Agent 启动时加载所有可用 Skills）
         ↓
3. LLM Think（选择工具）
         ↓ tool_calls 数组
4. Policy Pipeline 过滤（权限检查）
         ↓
5. 沙箱执行（Docker / Native 双模式）
         ↓
6. 结果返回 → 追加到 messages
         ↓
7. 重新进入 Think 阶段（Observe → Reflect → Think）

---

六、用代码理解 Agent Loop

下面用一段完整的 Python 代码演示 Agent Loop 的核心逻辑，帮助读者建立清晰的直觉理解：

import json
from openai import OpenAI

client = OpenAI()

# 定义工具（模拟两个真实工具）
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市的当前天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"}
                },
                "required": ["city"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "读取本地文件的文本内容",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {"type": "string", "description": "文件绝对路径"}
                },
                "required": ["path"]
            }
        }
    }
]

# 工具实现
def execute_tool(name: str, args: dict) -> str:
    if name == "get_weather":
        return f"{args['city']}今天晴，气温 18-26°C，适合外出"
    elif name == "read_file":
        try:
            with open(args['path'], 'r', encoding='utf-8') as f:
                return f.read()
        except FileNotFoundError:
            return f"错误：文件 {args['path']} 不存在"
    return "未知工具"

# ========== Agent Loop 核心实现 ==========
def run_agent_loop(user_message: str):
    messages = [{"role": "user", "content": user_message}]
    step = 0

    while True:
        step += 1
        print(f"\n{'='*50}")
        print(f"  Step {step}: Think（思考）阶段")
        print(f"{'='*50}")

        # ① Think：调用 LLM 进行推理
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=tools,
            tool_choice="auto"
        )

        assistant_msg = response.choices[0].message
        messages.append(assistant_msg)

        # ② Reflect：判断是否有工具调用
        if not assistant_msg.tool_calls:
            # 无工具调用 → 任务完成，退出循环
            print(f"\n{'='*50}")
            print(f"  任务完成！")
            print(f"{'='*50}")
            return assistant_msg.content

        print(f"LLM 决定调用 {len(assistant_msg.tool_calls)} 个工具")

        # ③ Act + Observe：执行工具并收集结果
        for tool_call in assistant_msg.tool_calls:
            func_name = tool_call.function.name
            func_args = json.loads(tool_call.function.arguments)

            print(f"\n  Act: 调用 {func_name}({func_args})")
            result = execute_tool(func_name, func_args)
            print(f"  Observe: {result[:100]}...")  # 打印结果摘要

            # 将工具结果追加到消息历史（Observe）
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": result
            })
        
        # 继续下一轮循环（Reflect → Think）

# 运行示例
result = run_agent_loop("北京今天天气怎么样？同时帮我读取 /tmp/notes.txt 文件")
print(f"\n最终回答：{result}")

运行这段代码，可以清晰地看到 Agent Loop 的每个轮次：Think（决定调用工具）→ Act（执行工具）→ Observe（收集结果）→ Think（根据结果决定下一步）→ 最终输出。

---

七、循环终止条件

OpenClaw 秉持 “No Magic（无魔法）” 的设计哲学，不硬编码 max_steps 等隐藏限制。循环的终止由以下条件触发：

条件一（最核心）：任务完成检测。 LLM 的响应中不再包含 tool_calls，直接输出纯文本回复。这意味着 LLM 自主判断认为任务已完成，无需再采取任何行动。

条件二：用户主动中止。 用户通过客户端发送 interrupt 类型消息，强制终止当前运行中的循环。Gateway 接收到中断信号后，会等待当前正在执行的工具调用完成，然后停止循环并推送当前状态。

条件三：上下文窗口压缩触发循环暂停。 当 messages 总 token 数接近模型上下文限制时，系统进入 compacting 状态，执行压缩后继续（详见下节）。

条件四：不可恢复的系统错误。 如模型配置错误、所有备用 Provider 均不可用等情况，循环以 error 状态终止，向用户推送错误信息。

条件五：定时任务超时清理。 通过 Cron 触发的自动化任务默认设有 2 小时超时保护，防止卡死任务无限消耗资源。

与其他框架的终止策略对比：

框架	终止策略
OpenClaw	LLM 自主决策（无内置 max_steps）
LangChain AgentExecutor	max_iterations（默认 15）+ max_execution_time 双重硬限制
AutoGen	max_consecutive_auto_reply（最大连续自动回复次数）
CrewAI	角色任务目标达成判断（Role-based）

LangChain 的硬限制方式简单可控，但可能在复杂任务中途强制截断；OpenClaw 的 LLM 自主决策方式更智能，但对 LLM 的推理能力要求较高——这也是两种框架设计哲学差异的缩影。

---

八、上下文窗口管理：Compaction 机制

8.1 问题背景

随着 Agent 循环的持续执行，每轮新增的工具调用和结果会不断扩展 messages 数组，导致发送给 LLM 的 token 数持续增长。一旦超过模型的上下文限制（如 Claude 的 200K tokens），循环将无法继续。

OpenClaw 通过 context-window-guard.ts 持续监控这一状态，当 token 占用接近模型上限时，触发 compaction.ts 中的压缩算法。

8.2 Compaction 压缩策略

当前消息序列（token 数接近上限）：
[System Prompt] [消息1] [工具1] [消息2] [工具2] ... [消息N] [工具N]
                └── 早期历史（可压缩）──┘  └── 近期历史（保留）──┘

压缩后：
[System Prompt] [早期历史摘要] [近期消息] [近期工具结果]

具体实现采用三步策略：

第一步：滑动窗口截断。 保留最近 N 条消息（可配置），丢弃更早的交互记录。

第二步：LLM 摘要压缩。 对被截断的早期消息，使用 LLM 生成一段紧凑的摘要，概括其中的关键信息和决策过程，插入为一条 assistant 消息，以便后续轮次的 LLM 仍能了解"任务历史"。

第三步：重要信息优先保留。 压缩算法优先保留系统提示词（始终完整保留）、工具定义（始终完整保留）、关键工具执行结果（如文件读取内容、代码执行输出）。

8.3 文件即真相（File-as-Truth）的记忆设计

OpenClaw 的长期记忆不依赖数据库，而是直接存储为文件：

~/.openclaw/
├── memory/
│   ├── MEMORY.md       # 核心长期记忆（人工策展的重要事实）
│   ├── 2026-03-20.md   # 今日增量对话日志
│   └── working/        # 当前任务工作内存（临时文件）
└── sessions/
    └── agent:main:...  # 会话级持久化存储

这种"文件即真相"的设计有几个独特优势：

1. 人类可读可编辑：用户可以直接打开 MEMORY.md，手动添加或修改 Agent 的记忆，无需任何特殊工具。
2. AI 可直接读写：Agent 可以用普通的文件读写工具操作自己的记忆，无需特殊的"记忆 API"。
3. 版本控制友好：内存文件可以纳入 Git 管理，方便追踪 Agent "记忆"的演变历史。

对于需要语义检索的场景，OpenClaw 还支持混合检索策略，将向量相似度与 BM25 全文检索结合：

最终相关度分数 = 0.7 × 向量余弦相似度（sqlite-vec 本地向量扩展）
              + 0.3 × BM25 全文匹配分数

---

九、错误处理与鲁棒性设计

9.1 工具调用失败的处理原则

当工具调用失败时，OpenClaw 遵循一个简单而强大的原则：将完整的错误信息传递给 LLM，让 LLM 自主决定如何应对，而非在框架层面硬编码重试逻辑。

这种设计基于一个深刻洞察：LLM（尤其是 GPT-4、Claude 级别）具备足够的错误分析能力，它往往比预设的重试策略更能灵活应对各种失败情形——可能换参数重试、可能改用其他工具、也可能直接告知用户问题所在。

try {
  const result = await executeTool(toolCall);
  return { success: true, result };
} catch (error) {
  // 不抛出异常，而是将错误封装为工具结果传递给 LLM
  return {
    success: false,
    error: `工具 ${toolCall.name} 执行失败: ${error.message}`,
    hint: "可以尝试使用不同的参数，或选择其他可用工具"
  };
}

9.2 LLM Provider 的故障转移

model-selection.ts 实现了指数退避 + 多 Provider 故障转移机制：

• 首次失败：等待 30 秒后重试同一 Provider
• 二次失败：等待 1 分钟后切换到 fallbacks 列表中的备用 Provider
• 持续失败：按 5 分钟 → 15 分钟 → 60 分钟指数退避，保护目标 Provider
• 卡死任务：2 小时超时自动清理，释放系统资源

这种设计保障了在单一 Provider 故障时（如 OpenAI 服务中断），Agent 能够自动切换到 DeepSeek 或本地 Ollama，维持基本可用性。

---

十、调试与可观测性

10.1 OpenClaw 的实时状态推送

Gateway 通过 WebSocket 将 Agent 的每个状态变化实时推送到所有连接的客户端，让调试变得直观：

{
  "type": "agent_status",
  "sessionId": "agent:main:telegram:direct:user123",
  "status": "streaming",
  "currentTool": "bash",
  "toolArgs": {"command": "ls -la /tmp"},
  "step": 3,
  "tokensUsed": 8420,
  "estimatedCost": 0.025
}

Web UI 的"正在思考…"、"正在执行 bash…"等提示，正是基于这些实时事件渲染的。

10.2 生命周期钩子（Hooks）

OpenClaw 在循环的关键节点暴露了钩子接口，允许开发者注入自定义逻辑（监控、计费、审计等）：

// 可在 config/hooks.ts 中注入
onBeforeTurn(session, message) {}      // 每轮开始前（可用于注入额外上下文）
onToolCall(toolName, args) {}          // 工具调用前（可用于权限二次检查）
onToolResult(toolName, result) {}      // 工具结果返回后（可用于结果过滤）
afterCompaction(compressedCtx) {}      // 上下文压缩后（可用于存档历史）

10.3 与行业可观测工具的集成

对于需要更详细监控的场景，OpenClaw 可与主流可观测平台集成：

Langfuse（推荐，开源）：提供完整的链路追踪、步骤可视化、评估策略（黑盒/玻璃盒/白盒三层）和 Token 成本统计，并遵循 OpenTelemetry（OTEL）标准。

LangSmith（LangChain 官方）：支持全链路追踪，可收集生产环境中的异常案例，构建回归测试集。

---

十一、横向对比：各框架 Agent Loop 实现差异

维度	OpenClaw（Lobster Loop）	LangChain AgentExecutor	AutoGen	CrewAI
循环模式	Think→Act→Observe→Reflect（4段）	ReAct（Thought→Action→Observation）	多 Agent 消息轮转	角色扮演任务分工
终止条件	LLM 自主决策（无 tool_calls）	max_iterations 硬限制	max_consecutive_auto_reply	任务目标达成
工具定义	SKILL.md + TypeBox Schema	Python 函数装饰器 @tool	Python 函数注册	Python 类方法
并行工具	原生支持	LangGraph 支持（旧版不支持）	原生支持（多 Agent）	不支持（顺序执行）
上下文管理	自动 Compaction（文件存储）	ConversationBufferMemory 等	内置对话历史	基础内存
多 Agent	SubAgent 嵌套机制	LangGraph 图结构	核心特性	Crew 团队模式
安全隔离	Docker 沙箱 + 策略管道	无内置沙箱	代码执行沙箱	无内置沙箱
可观测性	WebSocket 实时推送	LangSmith 集成	内置日志	基础日志
设计哲学	平台 + 本地优先	应用开发框架	多 Agent 协作框架	角色驱动框架

这个对比揭示了几个深层差异：

关于适用场景，OpenClaw 最适合"单 Agent + 多工具 + 长期持久化"的个人/团队 AI 助手；AutoGen 最适合需要多个专家角色协作讨论的任务（如 Coder + Reviewer + Tester）；CrewAI 适合结构化的多步骤任务流水线。

关于安全性，OpenClaw 和 AutoGen 都提供了代码执行沙箱，而 LangChain 和 CrewAI 默认在无沙箱环境中执行工具，在赋予 Agent 高权限时需要开发者自行做好安全防护。

关于调试体验，OpenClaw 的 WebSocket 实时状态推送在调试体验上明显领先，用户可以在 Web UI 中实时看到 Agent 的每一步行动，而其他框架主要依赖日志文件或第三方监控平台。

---

小结

Lobster Loop 是 OpenClaw 的智慧核心，它将学术界的 ReAct 理论落地为工程级的四段式闭环：Think（LLM 推理决策）→ Act（沙箱工具执行）→ Observe（结果收集追加）→ Reflect（终止条件判断）。

这套机制的精妙之处在于：整个循环的控制权完全交由 LLM 自主掌握。框架不决定何时调用什么工具、何时结束任务，这些都是 LLM 在接受完整信息后自主推理的结果。框架的职责是提供安全的执行环境、正确的上下文组装、可靠的工具接口，而把"思考"和"决策"完全留给 AI。

这种"框架搭台、AI 唱戏"的设计哲学，或许正是 OpenClaw 能够随着 LLM 能力的持续提升而不断增强的根本原因——当 LLM 变得更聪明，不需要改框架，Agent 自然就变得更强大。

在下一篇（第 009 篇）中，我们将深入探讨驱动 Act 阶段的核心武器库——OpenClaw Skills 技能系统与 ClawHub 技能市场，了解如何为 Agent 赋予各种"超能力"。

---

上一篇：[第 007 篇] 流量枢纽——OpenClaw Gateway 网关深度解析

下一篇预告：[第 009 篇] OpenClaw Skills 技能系统与 ClawHub

---

参考资料

1. ReAct: Synergizing Reasoning and Acting in Language Models - arXiv
2. OpenClaw Agent Loop 机制源码深度分析 - CSDN
3. OpenClaw 技术架构深度拆解：14个子系统的源码级分析 - Axton Liu AI 周刊
4. 深入理解 OpenClaw 技术架构与实现原理 - 腾讯新闻
5. Anthropic Agent 构建指南 - CSDN
6. AI Agent Observability with Langfuse - Langfuse Blog
7. 多 AI 代理框架对比：AutoGen、LangGraph、CrewAI 全面对比 - 搜狐
8. OpenClaw 是"新操作系统"：腾讯云 Agent 架构分析 - 新浪