OpenClaw的Agent循环则是：

用户指令 → 意图解析 → 任务拆解 → 工具调用 → 结果评估 ↑                                          ↓ └──────── 是否需要继续？←────────────────────┘

关键差异在于：OpenClaw的每次推理都是一个状态机。LLM不仅决定"做什么"，还决定"做完了没有"。如果工具调用的结果不满足预期，Agent会自动调整策略、重新规划、再次执行，直到任务完成或达到迭代上限。

2.2 循环的五个核心阶段

阶段一：意图解析（Intent Parsing）

当用户输入"整理本周邮件并生成周报"时，OpenClaw不是简单地调用一个"整理邮件"的Skill。它首先进行意图分解：

• 子任务1：读取邮件（需要邮件API访问权限）
• 子任务2：提取关键信息（需要NLP理解能力）
• 子任务3：按格式排版（需要文档处理工具）
• 子任务4：生成文档（需要文件写入权限）

这个分解过程本身就是一次LLM推理，模型需要理解任务间的依赖关系和执行顺序。

阶段二：工具路由（Tool Routing）

OpenClaw维护着一个工具注册表，每个Skill在安装时会声明自己能提供的工具（tools）。Agent根据任务需求，从注册表中选择最合适的工具组合。这不是简单的关键词匹配，而是基于任务语义和工具描述的匹配。

例如，同样是"读取文件"，Agent会根据上下文选择：

• 需要读取代码文件？→ 使用

• 需要读取Excel数据？→ 使用专门的

• 需要读取网页内容？→ 使用

阶段三：执行与监控（Execution & Monitoring）

工具调用不是"fire-and-forget"。OpenClaw会监控每次工具调用的：

• 返回状态（成功/失败/超时）
• 输出内容是否符合预期
• 是否需要重试或降级

阶段四：结果评估（Result Evaluation）

每次工具调用后，LLM会评估返回结果是否满足当前子任务的目标。这是Agent循环中最关键的"决策点"——如果评估不通过，Agent会：

• 调整参数重新调用同一工具
• 切换到备选工具
• 修改任务分解方案

阶段五：循环控制（Loop Control）

OpenClaw的Agent循环不是无限循环。它有明确的终止条件：

• 所有子任务完成
• 达到最大迭代次数（防止无限循环）
• 用户主动中断
• 遇到不可恢复的错误

三、Gateway：不只是"网关"，而是Agent的操作系统

3.1 Gateway的核心定位

OpenClaw的官方文档有一句非常精辟的话："Gateway只是控制平面——产品本身就是助手。"

这句话揭示了OpenClaw的架构哲学：Gateway不是Agent本身，而是Agent运行的基础设施。类比到操作系统，如果Agent是"应用程序"，那么Gateway就是"操作系统内核"。

3.2 Gateway的三大职责

职责一：会话管理（Session Management）

每个对话都是一个独立的Session，Gateway负责：

• Session的创建、销毁和状态持久化
• 多Session间的隔离（一个Session的工具调用不会影响另一个）
• Session历史记录的压缩与存储（LCM机制的核心场景）

职责二：工具调度（Tool Dispatch）

Gateway是所有工具调用的中枢：

• 接收Agent的工具调用请求
• 路由到对应的Skill实现
• 管理工具的权限和沙箱
• 返回执行结果

职责三：渠道适配（Channel Adapter）

OpenClaw支持40+消息平台（Telegram、Discord、WhatsApp、飞书等），Gateway负责：

• 将不同平台的输入格式统一为Agent可理解的内部格式
• 将Agent的输出适配为各平台支持的格式（Markdown、HTML、纯文本等）
• 管理各平台的连接和认证状态

3.3 Gateway配置的工程实践

gateway.yaml 核心配置结构

gateway: port: 18789 auth: token: "your-gateway-token"  # API鉴权 models: default: "anthropic/claude-sonnet-4-20250514" fallback: ["openai/gpt-4o", "deepseek/deepseek-v4"] sessions: maxConcurrent: 10 historyCompression: true  # 启用LCM

这份配置揭示了Gateway的几个关键设计决策：

• 模型降级
  
  ：默认模型不可用时自动切换到备选模型，保证Agent可用性
• 并发控制
  
  ：限制同时运行的Session数，防止资源耗尽
• 历史压缩
  
  ：启用LCM（Lossless Context Management），这是OpenClaw解决上下文窗口限制的核心机制

四、LCM：让Agent拥有"无限记忆"的秘密

4.1 问题的本质

大语言模型有上下文窗口限制（即使是200K token的Claude，也只够处理约15万字）。对于一个持续运行的Agent，对话历史很快就会撑爆上下文窗口。

传统方案是"截断"——丢弃最早的对话记录。但这对Agent来说是灾难性的：它可能因此忘记用户之前交代的关键约束，导致后续行为偏离预期。

4.2 LCM的无损压缩原理

OpenClaw的LCM（Lossless Context Management）采用了一种"摘要+索引"的架构：

原始对话历史 ↓ [压缩层] 生成摘要（sum_xxx），保留关键信息 ↓ [索引层] 构建DAG（有向无环图），建立摘要间的关系 ↓ [检索层] 按需展开（expand），恢复原始细节

核心机制：

1. 1分层摘要：对话历史被分成多个chunk，每个chunk生成一个摘要。摘要本身也会被进一步摘要，形成树状结构。

1. 1DAG索引：摘要之间通过DAG建立引用关系。当Agent需要回忆某个细节时，可以沿着DAG从高层摘要向下展开到具体消息。

1. 1按需展开：不是把所有历史都塞进上下文窗口，而是根据当前任务的需要，只展开相关的摘要分支。这就像人类回忆——你不会同时想起所有事，而是根据当前情境提取相关记忆。

4.3 LCM的三层API

OpenClaw提供了三个核心工具来操作LCM：

这种设计让Agent在理论上可以拥有"无限长"的对话历史，而不会受到上下文窗口的限制。

五、Skill架构：从"插件"到"能力单元"的进化

5.1 Skill不只是插件

在大多数框架中，"插件"只是功能的封装。但OpenClaw的Skill更像是Agent的"能力单元"——它不仅提供工具，还定义了工具的使用规则、前置条件和后置处理。

一个Skill的标准结构：

my-skill/ ├── SKILL.md          # 技能描述和使用规则 ├── scripts/          # 实现脚本 │   └── main.py ├── config.yaml       # 配置模板 └── tools.json        # 工具声明