OpenClaw 的核心组件是什么?
如果把 OpenClaw 看成一个 AI 员工,那么真正让 Agent 能够完成任务的,不只是大模型。
它背后可以抽象成几个核心能力:
LLM
Agent 大脑
│
↓
Agent Loop
思考 / 决策 / 执行
│
┌──────────┼──────────┐
↓ ↓ ↓
Task Plan Tools Skills
任务规划 工具执行 技能扩展
└──────────┼──────────┘
↓
Memory / Context
记忆与上下文
一、LLM:Agent 的“大脑”
LLM 负责最核心的语言理解和推理。
比如用户说:
“帮我查一下今天上海的天气,再告诉我适不适合出门。”
模型首先要理解用户到底想干什么,然后决定下一步需要哪些能力。
OpenClaw 可以接入不同的模型 Provider,例如 GPT、Claude、GLM 等。
但要注意:
LLM 负责思考,不代表所有事情都由 LLM 自己完成。
查天气、操作文件、访问数据库这些事情,还得交给工具。
二、Agent Loop:真正的执行循环
Agent 的关键并不是“问一次模型,返回一次答案”。
复杂任务往往会形成一个循环:
用户提出任务
↓
LLM 理解需求
↓
决定下一步做什么
↓
需要工具?
↙ ↘
是 否
↓ ↓
调用工具 直接回答
↓
拿到结果
↓
再次交给 LLM 判断
↓
继续执行 / 完成任务
这就是常说的 Agent Loop。
比如:
“帮我查天气”
理解需求
↓
决定调用天气工具
↓
获取天气数据
↓
分析结果
↓
组织自然语言
↓
回复用户
所以 Agent 和普通聊天机器人的一个重要区别,就是它不仅能“说”,还能够根据任务决定下一步做什么。
三、Tools:Agent 的“手脚”
模型本身不能凭空读取你的数据库,也不能凭空操作服务器。
这些实际动作需要通过 Tools 完成。
例如:
搜索网页
读取文件
调用 API
查询数据库
执行 Shell
操作其他系统
可以简单理解成:
LLM 负责决定做什么,Tool 负责真正执行。
例如:
LLM:
“我需要查询数据库。”
↓
Tool:
执行 SQL
↓
返回查询结果
↓
LLM:
分析结果并回复用户
这样模型的推理能力才能真正连接现实世界。
四、Memory / Context:Agent 的“记忆”
如果没有上下文,每次聊天 Agent 都会像第一次见你一样。
因此还需要 Memory / Context:
Session
→ 当前会话上下文
Memory
→ 需要长期保留的信息
比如:
用户:我这个项目用的是 MySQL。
过了一会儿:
用户:帮我写个建表语句。
Agent 能理解这里应该优先按照 MySQL 来写,就是因为前面的信息进入了当前上下文或相应记忆。
所以:
LLM 决定 Agent 聪不聪明,Memory 决定 Agent 能不能“接着聊”。
五、Skills:把能力封装起来
Skills 可以理解成给 Agent 准备好的能力包/操作说明。
一个 Skill 往往围绕某类任务组织相关指令、流程以及可使用的工具。
例如:
代码审核 Skill
数据分析 Skill
文档处理 Skill
运维 Skill
这样 Agent 不需要把所有业务规则全部塞进一个巨大 Prompt。
需要处理某类任务时,再使用对应能力。
可以简单记成:
Tool 是一个具体工具,Skill 更像一套“怎么完成某类任务”的能力说明。
六、这些组件到底怎么配合?
一条复杂任务可以抽象成:
用户指令
↓
Gateway / Channel
↓
Agent
↓
LLM 理解任务
↓
Agent Loop 决策
↓
┌───────────────┐
│ Tools │ → 执行具体操作
│ Skills │ → 提供专业能力
│ Context │ → 提供当前上下文
│ Memory │ → 提供必要记忆
└───────────────┘
↓
LLM 综合结果
↓
生成最终回复
↓
Gateway
↓
用户
因此,OpenClaw 的核心不能简单理解成:
OpenClaw = 大模型。
更准确的理解是:
LLM 是大脑,Agent Loop 是决策循环,Tools 是手脚,Memory 是记忆,Skills 是能力扩展,Gateway 则负责把外部消息送进来、再把结果送出去。
把这几个组件搞清楚以后,OpenClaw 的整体架构基本就串起来了。
下一步再理解 Agent 到底怎么运行、为什么会不断“思考 → 调工具 → 看结果 → 再思考”,就会非常顺。