别再把 OpenClaw 当黑盒了:一文讲透它是怎么“长出一个 Agent”的

很多人第一次跑通 OpenClaw，会有一种错觉：“这不就是调了几个 prompt + 调 API 吗？”

但你真去看源码就会发现，OpenClaw 真正在做的，是把“只能输出语言的 LLM”，改造成“能自主决策、自动执行的可落地系统”—— 它不是简单的“问答工具”，而是一个完整的 Agent 执行框架。

这篇文章，不聊表面功能，不做概念美化，只从源码出发，拆透它的真实骨架、核心机制，纠正所有容易被误解的关键点。

一、先把一句话说透：OpenClaw 到底在干嘛？

一句话总结：

OpenClaw = LLM（Function Calling 能力） + 工具/代码沙盒系统 + 上下文记忆 + 自动反馈闭环

划重点：

它没有显式的“状态机”，核心是「循环+上下文」；

也没有提前规划全局步骤的“规划器”，核心是「单步推理+动态执行」。

也就是说，它的核心价值不是“问答”，而是：

👉 无需人工干预，完成“任务驱动的多步自动决策与执行”

二、源码结构拆解：真实四层架构

OpenClaw 的源码看似繁杂，但核心可拆解为四层，每层职责清晰、无交叉。

1️⃣ Interface 层（入口层：无智能，只做“传递”）

核心职责：接收用户输入，将输入转化为 Agent 可识别的初始上下文，不做任何智能决策。

示例：

user_input = "帮我分析一下特斯拉（TSLA）股票近期走势"

Interface 层仅做一件事：将该输入封装为初始 context，直接传递给 Agent Core，全程无任何逻辑处理 —— 它就是一个“输入输出中转站”。

2️⃣ Agent Core（核心层：大脑，负责“决策”）

这是 OpenClaw 的核心，也是最容易被误解的部分 —— 它没有独立的“Planner”“Tool Selector”模块，而是通过 LLM 单步推理，统一输出动作指令，核心包含 3 个关键单元：

（1）Action Generator（动作生成器）

作用：接收当前上下文（用户需求+历史执行结果），通过 LLM 的 Function Calling 能力，生成结构化的动作指令 —— 不是“先规划完整步骤”，而是“走一步、看一步”。

示例（用户需求：分析 TSLA 股票）：

初始上下文 → LLM 推理 → 输出动作指令：

{ "action": "call_tool",

"tool": "getstockprice",

"args": {"symbol": "TSLA"} }

本质：LLM 基于当前信息，自主判断“下一步该做什么”，直接输出可执行的动作，而非先拆分“1. 获取数据、2. 分析趋势”这类全局步骤。

（2）Executor（执行器：无智能，只做“落地”）

核心职责：解析 Action Generator 输出的指令，严格执行对应操作，不做任何决策判断

可执行的操作包括：

· 调用外部 API（如股票数据接口）

· 执行 Python 代码（通过内置代码沙盒，OpenClaw 核心创新点）

· 查询数据库、调用第三方服务等

示例：

解析指令后，

执行 stockapi.getprice("TSLA")，

获取结果：{ "symbol": "TSLA", "price": 210, "trend": "上涨（近7天）" }

（3）Memory（记忆系统：负责“上下文管理”）

关键点：不是简单的“中间结果 append”，而是分层管理的上下文系统，核心作用是“保存历史执行痕迹，供 LLM 下一次推理参考”，避免重复操作、解决推理混乱。

OpenClaw 源码中，Memory 分为两层：

· 短期记忆：保存当前任务的执行步骤、工具返回结果，实时更新

· 工作记忆：对短期记忆进行摘要压缩，避免 Token 爆炸（工程级核心优化）

示例：

将“调用 getstockprice 工具，返回 TSLA 价格 210、趋势上涨”这一结果，压缩后存入 Memory，供 LLM 下一步推理使用。

3️⃣ Tool System（工具系统：Agent 的“能力扩展”）

这是 OpenClaw 与普通 Prompt 调用最大的区别 —— 工具不是简单的函数，而是“带标准化描述的能力单元”，核心作用是“让 LLM 看懂工具、正确调用”。

工具的标准格式（源码原生格式）：

{

"name": "getstockprice", // 工具名称（唯一标识）

"description": "获取指定股票的实时价格及近7天趋势，仅支持美股代码", // 关键：让 LLM 知道该工具的用途和限制

"parameters": { // 标准化参数，约束 LLM 输出格式

"symbol": { "type": "string", "description": "股票代码，如 TSLA、AAPL" }

}

核心关键点：

❗ LLM 不是“自主判断要不要调用工具”，而是通过解析工具的 description，结合当前任务，直接生成“调用工具”或“结束任务”的动作 —— 没有独立的“Tool Selector”模块，动作生成与工具选择是一体化的。

另外，OpenClaw 的工具调用依赖 LLM 官方 Function Calling 能力，不是自定义解析 JSON。

4️⃣ Loop（闭环执行层：Agent“自主运行”的关键）

这是 OpenClaw 最核心的一层，也是它区别于普通 LLM 问答的本质 —— 不是“一次性输出”，而是“自动循环、动态调整”，核心逻辑（源码简化版）：

while not task_done:

#1生成动作：LLM基于当前 Memory 推理

action = LLM.generate(context=Memory.get())

#2解析动作：判断是调用工具还是结束任务

if action["action"] == "call_tool":

#3执行动作：调用工具并获取结果

result =Executor.run(action["tool"], action["args"])

#4更新记忆：将结果存入 Memory，供下一轮推理

Memory.update(result)

else: #action["action"] == "finish"

#5. 结束任务：输出最终结果

output_final_result(Memory.get_summary())

task_done = True

划重点：这是「反馈闭环」，不是「状态机」—— 没有预设的状态转移表，所有决策都依赖 LLM 实时推理和 Memory 反馈，灵活且可落地。

三、核心机制拆解

机制一：Tool Calling 不是“函数调用”，是“LLM 驱动的动作决策”

很多人容易误解：“代码判断该调用哪个工具”，但真实逻辑是：

👉 LLM 通过 Function Calling 能力，生成标准化的动作指令（JSON 格式），系统仅负责解析和执行 —— 决策权完全在 LLM，代码不做任何工具选择判断。

举个反例：

if "获取数据" in plan:

call_api("stock_api") → 这是硬编码，OpenClaw 完全不这么做。

真实逻辑：

LLM 看到用户需求“分析 TSLA 股票”，结合 Memory 中“无当前股票数据”的信息，再对照 Tool System 中 getstockprice 的 description，自主生成“调用该工具”的指令 —— 全程无硬编码判断。

机制二：ReAct 思想（推理+行动交替，而非“规划+执行”）

OpenClaw 本质上完美实现了 ReAct（Reason + Act + Observe）范式，这是它“看起来聪明”的核心。

OpenClaw 的 ReAct 循环（真实流程）：

Thought（推理）：我需要获取 TSLA 股票的实时数据（LLM 基于用户需求和空 Memory 推理）

Act（行动）：调用 getstockprice 工具，传入参数 symbol="TSLA"（LLM 生成动作指令，Executor 执行）

Observe（观察）：工具返回结果（价格210、近7天上涨），存入 Memory

重复循环：Thought（基于现有数据，可分析趋势）→ Act（无需调用工具，生成结论）→ Observe（无新结果）→ 结束任务

关键区别：

机制三：为什么它“看起来很聪明”？（3个核心原因）

不是 LLM 本身变强了，而是 OpenClaw 给 LLM 加了“三个辅助buff”，解决了普通 LLM 的三大痛点：

✅ 1. 外部能力扩展（解决“知识滞后、不会计算”的问题）

LLM 不会实时获取股票数据？→ 调用股票 API；

LLM 不会复杂计算？→ 调用代码沙盒执行 Python 运算；

LLM 不知道冷门知识？→ 调用检索工具。

核心：OpenClaw 的代码沙盒，是它区别于其他 Agent 框架的关键 —— LLM 可以写代码、运行代码，实现更复杂的任务（如数据可视化、批量处理）。

✅ 2. 分层记忆（解决“推理混乱、Token 爆炸”的问题）

普通 LLM：问题 → 直接输出（无中间校验，容易胡编）；

OpenClaw：问题 → 单步推理 → 执行动作 → 保存结果 → 再推理 → 最终输出（每一步都有校验，推理更严谨）。

同时，通过记忆摘要压缩，避免上下文过长导致的 Token 溢出和推理混乱。

✅ 3. 异常反馈闭环（解决“执行出错、无法恢复”的问题）

如果工具返回异常（如：{"error": "symbol not found"}，股票代码错误），OpenClaw 不会直接崩溃 —— Memory 会保存异常信息，LLM 会基于异常重新推理：

例如：判断“TSLA”是否拼写错误，或尝试查询“特斯拉”对应的正确股票代码，重新调用工具。

四、源码里最容易忽略的“隐形关键点”

🔥 1. Prompt 是“Agent 行为的规则手册”，而非“作文”

源码中，很多核心逻辑没有写在代码里，而是藏在 Prompt 中 —— 这些 Prompt 不是感性的“作文”，而是严格的“规则定义”，例如：

“你是一个自主执行 Agent，仅能调用 Tool System 中的工具；调用工具时必须严格遵循 JSON 格式，参数不能为空；若工具返回异常，需先修正错误再重新调用；任务完成后，输出简洁的结论。”

核心：Agent 的行为的是“被 Prompt 定义”的，而非代码硬编码 —— 这也是 OpenClaw 灵活可配置的关键。

🔥 2. JSON Schema 是“约束 LLM 输出”的核心，避免格式崩溃

没有 Schema 约束，LLM 可能输出混乱文本（如：“我觉得可以查一下 TSLA 的价格”），无法被系统解析；OpenClaw 强制给 LLM 传入 JSON Schema，约束输出格式：

示例 Schema：

{

"type": "object",

"properties": {

"action": {"type": "string", "enum": ["call_tool", "finish"]},

"tool": {"type": "string"},

"args": {"type": "object"}

"required": ["action"]

}

本质：OpenClaw 一直在做“自然语言 → 可执行结构化指令”的转化，而 Schema 是转化的“标准模板”。

🔥 3. 状态管理（Memory）决定 Agent 的上限

源码中，状态管理的复杂度直接决定了 Agent 能处理的任务难度：

· 简单实现：context += new_info（适合简单任务，易 Token 爆炸）；

· 高级实现：分层记忆（短期/工作）+ 工具调用日志 + 异常记录 + 摘要压缩（适合复杂任务，推理更清晰）。

如果状态管理不到位，会出现两个致命问题：Token 溢出、推理混乱（无限循环思考，无法结束任务）。

🔥 4. 代码沙盒是 OpenClaw 的“核心竞争力”

OpenClaw 最强大的地方，不是 Tool Calling，而是内置的代码沙盒 —— 允许 LLM 生成 Python 代码，在隔离环境中运行，获取执行结果后再继续推理。

例如：用户需求“分析 TSLA 近30天股价趋势，生成折线图”，OpenClaw 会：

调用股票 API 获取30天数据；

生成 Matplotlib 代码，在沙盒中运行，生成折线图；

将图表结果返回给用户。

这是普通 Agent 框架做不到的，也是 OpenClaw 能处理复杂任务的关键。

五、一个完整执行流程（工程级还原）

假设用户输入：“帮我分析特斯拉（TSLA）股票近期走势，给出简单结论”

OpenClaw 实际执行流程（无任何简化，贴合源码）：

Step 1：入口传递

Interface 层接收用户输入，封装为初始上下文 context = {"user_input": "帮我分析特斯拉（TSLA）股票近期走势，给出简单结论"}，传递给 Agent Core。

Step 2：第一次推理（生成动作）

Action Generator 调用 LLM，传入初始 context + Tool System 中所有工具的 description + JSON Schema，LLM 推理后输出动作指令：

{

"action": "call_tool",

"tool": "getstockprice",

"args": {"symbol": "TSLA"}

}

Step 3：执行动作 + 更新记忆

Executor 解析指令，调用 getstockprice 工具，获取结果：

{

"symbol": "TSLA",

"price": 210,

"trend": "上涨（近7天）",

"update_time": "2026-03-31"

}

Memory 将该结果压缩后存入，更新后的 context 包含：用户需求 + 工具调用记录 + 工具返回结果。

Step 4：第二次推理（判断是否继续）

Action Generator 再次调用 LLM，传入更新后的 context，LLM 推理：“已获取 TSLA 近期价格和趋势，无需进一步调用工具，可直接输出结论”，生成动作指令：

{

"action": "finish",

"result": "特斯拉（TSLA）当前股价210，近7天呈上涨趋势，短期走势向好。"

}

Step 5：结束任务，输出结果

Loop 层检测到 action 为“finish”，终止循环，通过 Interface 层将结果输出给用户。

👉 关键提醒：整个过程是“单步推理+动态调整”的循环，不是“先规划、再执行”的线性流程 —— 这是 OpenClaw 最核心的执行逻辑。

六、很多人踩的坑（工程级真实场景）

❌ 1. 以为多加工具就更强

错。工具越多，LLM 越容易出现“选择困难”，甚至乱调用工具（如：明明不需要查天气，却调用天气工具）。

正确做法：工具需“精准匹配任务场景”，每个工具的 description 要清晰、无歧义，避免工具功能重叠。

❌ 2. Prompt 写得像作文，没有明确规则

错。Agent Prompt 核心是“定规则、定格式、限行为”，不是“写优美文案”。

正确写法：明确 Agent 的权限（能做什么、不能做什么）、输出格式（必须遵循 JSON Schema）、错误处理方式（工具异常如何应对）。

❌ 3. 没做错误处理，工具异常直接崩

错。真实场景中，工具调用大概率会出错（API 超时、参数错误、返回异常），如果没有异常处理，系统会直接崩溃。

正确做法（源码原生逻辑）：

try:

result = tool.run()

except Exception as e:

记录异常信息，存入 Memory

Memory.update({"error": str(e), "tool": action["tool"]})

重新生成动作，让 LLM 修正错误

action = LLM.generate(context=Memory.get())

❌ 4. 没有终止条件，Agent 无限循环

错。如果没有终止条件，Agent 会一直“推理→调用工具→推理”，陷入无限循环（如：反复调用同一个工具，获取相同结果）。

正确做法：

步骤限制：最多执行 N 步（如 10 步），超过则强制终止，输出当前结果；

任务完成判断：LLM 输出“finish”动作，或 Memory 中包含“满足用户需求的结果”，则终止循环。

❌ 5. 忽略 Token 限制，导致推理崩溃

错。这是工程中最常见的坑 —— 上下文（Memory）过长，导致 Token 溢出，LLM 无法正常推理。

正确做法：启用 Memory 摘要压缩，定期对历史记录进行精简，保留核心信息，删除冗余内容。

七、说点本质：OpenClaw 的真正价值是什么？

它不是“帮你写代码”，也不是“高级 Prompt 调用”，而是：

👉 把 LLM 从“只能输出语言的被动工具”，升级成“能自主决策、自动执行、能改变环境的主动系统”。

用一张表，清晰区分 Prompt、RAG、OpenClaw（Agent）的核心区别：

核心区别：RAG 是“检索信息”，Agent 是“执行动作” —— OpenClaw 是能“做事”的系统，而不是能“说话”的工具。

八、最后一个判断标准

你有没有真的理解 OpenClaw，看这一点就够了：

👉 你能不能回答这个问题：“LLM 是什么时候决定调用工具的？”

如果你的答案是这两个，说明你还没懂：

❌ “代码里 if 判断”（硬编码，OpenClaw 不这么做）

❌ “开发者写死”（无自主决策，不是 Agent）

正确答案：

✅ LLM 在每一轮推理中，结合当前上下文（用户需求+历史执行结果）、工具描述，自主生成“调用工具”或“结束任务”的动作指令 —— 决策权完全在 LLM，系统仅负责解析和执行。

结尾

很多人把 Agent 当“高级 Prompt”，其实完全低估了它。OpenClaw 做的事情，本质是用语言模型驱动一个可自主执行的决策闭环系统 —— 它的核心不是 API 调用，不是 Prompt 技巧，而是“系统设计能力”。

看懂它的真实架构（无显式状态机、无全局规划器、核心是 ReAct 循环+代码沙盒），理解它的核心机制（LLM 驱动动作决策、分层记忆、异常反馈），你才能真正用好 OpenClaw，甚至搭建自己的 Agent 系统。