OpenClaw 入门指南：核心概念说明

核心结论（TL;DR）

• LLM 负责"理解与生成"，不是数据库；输出质量高度依赖上下文。
• 可以先把 OpenClaw 理解为自托管多渠道 Gateway：把聊天渠道连接到可执行的 AI 能力。
• Skills 用来沉淀可复用任务规则，让结果从"偶尔正确"变成"持续稳定"。
• 记忆用于跨会话复用稳定信息：在常见配置下，系统会自动整理部分内容；关键事实建议人工指定。
• Agent 可理解为执行单元，常见形态是 LLM + 工具 + Skills + 记忆 + 规则 + 会话状态。
• 落地路径：先跑通对话，再固化流程，最后做复用与治理；高风险场景通常应人工复核。

说明：本文聚焦核心概念与方法，不展开具体版本差异与部署细节。

1. 先搞清楚：什么是 LLM

现在看到的很多 AI 聊天产品（例如豆包、DeepSeek 等），虽然界面和功能各不相同，但核心生成能力大多都建立在 LLM 之上。

LLM（Large Language Model，大语言模型）可以理解为"会读、会写、会归纳、会改写"的通用语言引擎。

它不是按固定模板回答，而是根据你的输入，动态生成"下一步最可能有用"的内容。

1.1 LLM 的工作原理

你可以把它理解成三步：

• 第一步：读上下文。它先读你的问题、历史对话和补充材料。
• 第二步：做概率预测。它不是"查到唯一标准答案"，而是在大量可能表达里选最合适的一种。
• 第三步：逐词元（token）生成。它会一段一段往下写，所以前面的提示会影响后面的结果。

这就是为什么同一个问题，提问方式不同，答案质量会明显不同。

1.2 为什么它有时很强，有时会错

• 强在模式能力：擅长总结、改写、分类、对比、结构化表达。
• 弱在事实保证：如果问题需要最新事实或精确数据，它可能"说得像对的"，但细节不准。
• 受上下文影响大：背景给得越具体、约束越清晰，输出越稳定。

一句话：LLM 更像"高水平文字与推理助手"，不是"绝对正确的数据库"。

1.3 三个通俗例子：为什么上下文最重要

• 例子 A（实习编辑）：口语记录能很快改成正式周报，但日期和数字仍需你核对。
• 例子 B（会议速记员）：能整理要点和行动项，但"谁最终拍板"不能只靠它判断。
• 例子 C（旅行助手）：能给路线和预算建议，但票价、天气、政策建议再确认。

这三个例子都指向同一个结论：LLM 的效果高度依赖上下文。

上下文就是"让模型理解你真实意图的背景信息"，通常包含四类：

• 任务目标：到底要它做什么。
• 使用场景：给谁看、在什么场合用。
• 约束条件：字数、语气、格式、时效、禁用项。
• 已知信息：你已有的事实、数据、草稿。

可以把上下文理解为"给 AI 的工作说明书"。

它不是越长越好，关键是相关、准确、结构化。

同一个任务对比很明显：

• 弱上下文：帮我写一段请假消息。
• 强上下文：请写给直属经理的请假消息，原因是家里临时有事，需明天下午请假半天；语气礼貌简洁，不超过 80 字，给正式版和自然版各 1 条。

很多"AI 不稳定"的问题，本质不是模型能力不够，而是上下文不完整。

1.4 两个关键认知：本质是数学过程

LLM 不是魔法，也不是搜索引擎。

它的推理过程表现为数值计算：输入经过多层神经网络计算，得到"下一个词元最可能是什么"的概率分布，并逐步生成完整内容。

但需要注意：模型能力并不来自"计算本身"，而来自训练过程中学习到的语言模式与知识表示。因此它既不是简单计算器，也不是数据库，而是"基于统计学习的生成模型"。

2. 一句话先定义：OpenClaw 是什么

OpenClaw 可以先理解为一套自托管（self-hosted）的 AI 执行系统 。

其中，Gateway 是它的消息入口组件：把飞书、钉钉、微信等聊天渠道连接到 AI 智能体（Agent），并负责消息接入与会话路由。

OpenClaw 以 LLM 为核心引擎，在此基础上做了系统级扩展，把原本偏"问答"的能力，升级为可接入渠道、可调用工具、可管理会话与记忆的执行能力。

2.1 概念边界速览（统一口径）

• OpenClaw：完整系统/框架；Gateway、Agent、Skills、记忆等都属于它的能力组成。
• Gateway：消息接入与路由组件，负责"把请求送到正确的执行链路"。
• Agent：具体执行任务的单元，负责理解目标、组织步骤、调用能力并产出结果。
• LLM：提供语言理解与生成能力的模型内核；通常被 Agent 调用，不直接承担系统接入与治理。
• Skills：可复用的任务规则包；Prompt 更像一次性指令，通常不包含长期复用与治理结构。
• 记忆：跨会话复用的稳定信息层；会话上下文是当前会话的临时信息，两者用途不同。

再用入门者更容易理解的话补充它的价值：

• 渠道层：一个 Gateway 对接多个聊天渠道。
• 智能体层：支持工具调用、会话管理、记忆与多智能体路由。
• 可扩展层：可通过插件与 Skills 扩展能力。
• 控制权层：自托管部署，数据与权限边界由你控制。

与常见的"Prompt + LLM"使用方式相比，OpenClaw 更强调"可运行、可管理、可复用"的系统能力：

不仅是让模型回答问题，还包括消息路由、会话隔离、工具执行、记忆落盘和能力复用（Skills）。

3. 上手阶段建议优先理解的能力与边界

3.1 它特别擅长

• 起草：邮件、汇报、方案初稿。
• 整理：长文总结、会议纪要、信息归纳。
• 改写：口语转书面、压缩字数、统一风格。
• 结构化：把散乱想法变成清单、表格、步骤。

3.2 你需要自己把关

• 事实准确性（时间、价格、政策、引用）。
• 高风险建议（医疗、法律、投资）。
• 关键业务决策的最终判断。

一句话：先让 AI 产出高质量初稿，最终判断与责任仍由你承担。

3.3 安全边界（建议优先了解）

• 敏感信息边界：不把密钥、密码、身份证号、客户隐私等原文直接输入；必要时先脱敏。
• 权限边界：只给最小必要权限，避免让助手长期持有高权限访问能力。
• 执行边界：涉及"发消息、改数据、调用外部系统、执行脚本"的动作，建议默认先确认再执行。
• 记忆边界：长期记忆只保存低敏感、稳定信息，定期清理过时或错误记忆。
• 合规边界：涉及合同、财务、人事、医疗、法律内容时，AI 输出只能作参考，不可直接生效。
• 可追溯边界：关键任务保留输入、输出与版本记录，方便事后审计与回溯。

可以用一条简单规则判断是否要谨慎：只要这次输出"会影响钱、权限、合规或用户数据"，通常都应人工复核。

4. 从"会聊"到"会做事"：OpenClaw 如何完成一次任务

理解 OpenClaw 最容易卡住的点是：知道它"是什么"之后，不知道它"怎么工作"。

先把这条链路看清，后面理解 Skills 会顺很多。

4.1 一次请求的完整执行链路

把一次任务拆开看，通常会经过这几个环节：

• 消息接入：请求先从聊天渠道进入 Gateway。
• 会话定位：系统识别"这是谁、在哪个会话、对应哪个任务上下文"。
• 上下文组装：把你的本轮输入、历史对话、可用 Skills 和记忆信息拼成可执行上下文。
• 推理与执行：LLM 先理解并规划；需要外部信息时再调用工具补齐数据或执行动作。
• 结果回传：OpenClaw 按约定结构返回结果，并给出不确定项或风险提示。
• 动作前确认：进入发送、改数据、提交决策等真实动作前，先由你做最后确认。

你可以把它记成一句话：人给目标 -> LLM 做推理 -> OpenClaw 负责编排 -> 人在关键动作前把关。

这也是为什么 OpenClaw 不只是在"回答问题"，而是在把一次请求变成可管理的执行过程。

流程稳定性的关键，集中在三个可控点：

• 输入是否结构化（目标、约束、边界有没有写清）。
• 工具权限是否可控（只给必要能力，避免越权执行）。
• 输出是否有契约（固定格式、必填字段、风险提示）。

4.2 从一次完成到稳定复用：三层进阶

• 层级 A（对话层）：一次一问一答，适合快速草稿和临时整理。
• 层级 B（流程层）：同类任务重复做，开始固定输入输出格式。
• 层级 C（能力层）：把流程固化成 Skills，团队可复用、可迭代、可治理。

很多人感觉"OpenClaw 还不够稳"，通常不是模型不行，而是停在了层级 A，没有进入流程层和能力层。

当你发现某类流程反复出现时，就可以把它沉淀为 Skills，这也是 OpenClaw 的核心能力之一。

5. 从流程到能力：为什么是 Skills

前面讲了执行流程；这一段要回答的是"如何让这套能力长期稳定复用"。核心做法就是把流程沉淀为 Skills。

你可以把 Skills 理解为"可复用能力包"，它不是一句提示词，而是一套可执行规则。

5.1 Skills 和普通提问的区别

• 普通提问：一次性，依赖当次上下文，结果波动大。
• Skills：把"触发条件、输入要求、输出结构、执行约束"打包，长期复用。

一句话：Skills 让 AI 从"会回答问题"升级为"按你团队标准做事"。

5.2 一个实用的 Skill 通常包含什么

• 目标定义：这个 Skill 到底解决哪一类问题。
• 触发条件：在什么场景下调用，什么情况不要调用。
• 输入规范：必填字段、可选字段、缺失字段的处理策略。
• 执行步骤：先做什么、后做什么，是否需要调用工具。
• 输出契约：固定结构、字段顺序、字数或风格限制。
• 失败与兜底：信息不足时如何提示，冲突信息如何处理。
• 观测与评估：记录常见失败样例与修复策略，便于后续版本迭代。

5.3 Skills 如何管理与迭代

Skills 不是"一次写完"，而是要随业务持续迭代。实践里可以抓住这五点：

• 小步起步：先覆盖一个明确场景，避免一开始做成"大而全"。
• 版本化管理：每次调整都记录变更点（触发条件、输入字段、输出结构）。
• 反馈驱动：把失败样例沉淀下来，优先修复高频问题（字段缺失、语气跑偏、结构不稳）。
• 生命周期治理：业务规则变化时，及时停用或替换旧 Skills，避免旧规则误触发。
• 关键动作加闸：把外发、写入系统、权限变更等动作标记为"需确认"，降低误执行风险。

这类 Skills 的价值不在"写得花"，而在"可持续维护、长期稳定可用"。

6. 记忆：是什么，以及如何影响对话

Skills 解决的是"怎么做事"，记忆解决的是"下次还记得你的做事偏好和背景"。

6.1 记忆是什么

你可以把记忆理解为"跨会话复用的上下文层"：把稳定信息写下来，供后续对话持续使用，而不是每次从头说明。

在 OpenClaw 的常见实现里，记忆通常不是"模型脑内自动长期记住"，而是落在可管理的持久化内容里（常见形态是文本文件或等价存储）。

只有被记录和可检索的信息，才更可能在后续对话中持续生效。

常见适合写入记忆的信息：

• 你的偏好：语言风格、输出格式、常用模板。
• 你的背景：岗位职责、常见任务类型、协作对象。
• 你的流程：固定检查清单、交付结构、审批约束。

在默认或常见配置下，OpenClaw 往往会自动把一部分可复用信息整理进记忆；具体行为会受版本、配置和策略影响。

但对你特别重要、希望长期稳定生效的信息，建议你人工明确指定"请记住这条"，例如：

• 我的岗位与职责边界是什么（例如：负责后端接口，不负责前端实现）。
• 我默认的交付偏好是什么（例如：先给结论，再给步骤，并附风险清单）。

6.2 记忆如何影响对话内容

记忆会直接影响模型拿到的上下文，因此会影响输出的语气、结构和决策倾向。

典型影响有三类：

• 影响表达：如果记忆里有"偏好简洁、先结论后细节"，回复会更接近这种风格。
• 影响结构：如果记忆里有固定交付模板，输出通常会更贴近该模板字段。
• 影响判断：如果记忆里有历史约束或决策前提，模型会优先按这些前提组织建议。

这也是为什么记忆一旦过时，会导致"回答看起来合理但不符合当下情况"。

所以高质量记忆管理，本质上是在提升后续每一次对话的稳定性与准确性。

7. Agent：OpenClaw 的执行单元

前面讲了 Skills 和记忆，这里补上执行视角：真正把这些能力串起来完成任务的是 Agent。

7.1 Agent 是什么

在 OpenClaw 里，Agent 不等于一次模型回答，而是一个可持续运行的执行单元，通常由这些部分组成：

• LLM：负责理解和生成。
• 工具：指 Agent 可调用的操作接口，用于"查"和"做"（例如读写文件、执行命令、查询记忆、调用外部服务）。
• Skills：负责提供可复用的任务规则（面向具体任务类型），指导 Agent 在不同场景下稳定执行。
• 记忆：负责跨会话复用稳定信息。
• 规则：负责全局治理约束（如权限边界、安全策略、统一输出规范），不绑定某一个具体任务。
• 会话状态：负责把当前任务放在连续上下文中处理。

可以把它理解为：LLM + 工具 + Skills + 记忆 + 规则 + 会话状态。

7.2 Agent 相关对象速览（总结表）

先用一张表把 Agent 与相关对象的角色边界放在同一视图里：

对象	解决什么问题	是否跨会话	是否直接执行动作	一句话理解
Gateway	接入、路由、会话隔离	否	否	消息入口与调度层
LLM	理解与生成	否	否	语言与推理引擎
Agent	组织一次任务执行	视实现而定	是	执行单元
Skills	固化某类任务规则	是	间接	可复用能力包
记忆	复用稳定偏好与背景	是	否	跨会话上下文层
工具	查数据 / 做动作	否	是	外部能力接口
规则	统一约束与治理	是	间接	全局边界

7.3 Agent 在 OpenClaw 架构里的位置

一个常见链路是：
聊天渠道 -> Gateway -> Agent -> (LLM/Tools/Memory) -> Agent -> Gateway -> 聊天渠道

这里分工很重要：

• Gateway 负责接入、路由、会话隔离和消息回传。
• Agent 负责理解任务、决定是否调用工具、组织结果。
• LLM 负责生成与推理，是 Agent 的核心引擎但不是全部。

所以 OpenClaw 的"强扩展"本质上是：让 Agent 在 LLM 之上具备可执行、可管理、可复用的系统能力。

7.4 什么时候用单 Agent，什么时候用多 Agent

先从单 Agent 开始，通常就能覆盖大多数个人与小团队场景。

更适合多 Agent 的情况：

• 任务角色差异很大：比如"资料检索"和"最终成稿"需要不同风格与约束。
• 权限边界要隔离：比如一个 Agent 只读数据，另一个 Agent 执行写操作。
• 任务可并行：多个子任务可以同时推进，再汇总结果。

实操建议：先把单 Agent 流程跑稳，再按"角色、权限、并行度"拆成多 Agent。

8. 最小 Skill 示例与贯穿式工作流

8.1 最小 Skill 示例（weekly-report）

下面是一个可直接理解的最小 Skill 结构，用来约束"周报整理"任务稳定输出：

Skill 名称：weekly-report
目标：把原始工作记录整理成固定结构周报
输入：本周事项列表（必填）、下周计划（可选）、风险信息（可选）
输出：本周进展 / 风险与阻塞 / 下周计划
约束：总字数 <= 300；每段不超过 3 条；语气专业克制
兜底：若输入缺失，先列出缺失项并给出补全提问
执行保护：若涉及外发或系统写入，建议先人工确认后执行

8.2 贯穿式工作流案例（飞书周报）

场景：你在飞书里发一句"帮我整理周报"。

执行链路如下：

1. 消息从飞书进入 Gateway。
2. Gateway 定位会话与用户身份，并完成路由。
3. Agent 判断该任务命中 weekly-report Skill。
4. Agent 从记忆读取你的稳定偏好，例如"先结论后分点、语气克制"。
5. 如果输入不全，Agent 先追问缺失项（如本周事项、下周计划、风险信息）。
6. 信息齐备后，按固定结构生成周报内容。
7. 若涉及外发或提交系统，先让你确认，再执行对应动作。

你会看到，这个流程不是"模型一次回答"，而是 Gateway、Agent、Skills、记忆与工具共同完成的一次任务执行。

9. 总结

从"会提问"到"能执行"，表面看是使用方式变化，往深处看其实是工作方法在变化。

这条演化并不是"换个模型就更强"的故事，而是把 LLM 放进可管理系统：通过 Gateway、Agent、Skills 和记忆，把一次性对话升级为可复用执行流程。

同时，这条路的推进节奏也不会一蹴而就。任务复杂度、工具成熟度、团队协作方式和业务约束，会决定你现在更适合"单 Agent 跑通"还是"多 Agent 协作"。

所以更实用的做法是：先把一条流程跑稳，再逐步沉淀 Skills、整理记忆、扩展 Agent 分工。方向很清楚，胜负取决于谁能把 模型、规则 与 工程执行 长期稳定地协同起来。