在当今 AI Agent 领域，OpenClaw 无疑是一颗冉冉升起的新星。随着社区讨论的热度不断攀升，越来越多的开发者和企业开始尝试将其落地。然而大多数现有的教程往往停留在表层——教你如何编写一个 Skill，或者如何组织目录结构。这就像是在教你怎么组装乐高积木，却没告诉你积木内部的卡扣原理。

今天我们不想再重复那些基础的操作手册。我们要Zuo的，是像外科医生一样，通过一次真实的请求抓包，把 OpenClaw 的 Skill 运行机制彻底剖开。我们将从源码层面出发，结合 ReAct 范式，探讨 Skill 到底是如何被注入到 System Prompt 中，又是如何一步步驱动大模型完成复杂任务的。此外我们还将深入分析 Skill 与 MCP之间那种既竞争又互补的微妙关系。

一、 Skill 的本质：不仅仅是“技Neng包”

hen多人把 OpenClaw 的 Skill 简单理解为一种“插件”或“技Neng包”，这虽然形象，但不够精准。从技术底层的视角来kan，Skill 的本质其实是结构化 Prompt 与 Tool Calling 的工程化封装。

想象一下Ru果没有 Skill，当你告诉 LLM “帮我查一下红砖平台的春节活动”时模型需要自己去“悟”出该调用哪个 API、参数怎么填、返回结果怎么处理。这就像给厨师一张白纸，让他凭空Zuo一道菜，结果往往不尽如人意。而 Skill，就是那张详细的食谱。它通过 SKILL.md 文件，将 LLM 的行动从“开放式问答”严格约束为“填空题”。

1.1 目录结构：标准化的容器

在深入代码之前，我们先快速回顾一下标准的 Skill 目录结构。这不仅仅是文件摆放的问题，geng是 OpenClaw 识别和加载技Neng的基础。

skill-name/
├── SKILL.md       # 核心指令：包含 YAML 元数据与 Markdown 正文
├── scripts/       # 执行脚本：Python、Bash 或 TypeScript 等可执行文件
├── references/    # 参考数据：按需加载的文档、配置模板等
└── assets/        # 静态资源：图标、模板文件等

这里Zui关键的是 SKILL.md。它不仅是给人kan的文档，geng是给 LLM kan的“触发器”和“操作手册”。OpenClaw 通过解析文件头部的 YAML Frontmatter 来获取 Skill 的身份信息，而正文部分则定义了具体的执行逻辑。

1.2 渐进式加载：Token 效率的艺术

在处理长上下文时Token 的消耗是必须考虑的成本。OpenClaw 在这方面设计得非常精妙，它采用了一种渐进式加载机制

Level 1: System Prompt 中仅包含 name + description
   ↓ 语义匹配命中
Level 2: 按需加载 SKILL.md 核心指引
   ↓ 需要详细数据时
Level 3: references/ 目录下的详细参考数据

这意味着，Ru果用户只是想“查询活动”，LLM 根本不需要去加载“创建活动”的默认配置文档。这种懒加载策略，是 Skill 机制Neng够保持高效运行的关键所在。

二、 源码探秘：Skill 是如何进入 System Prompt 的？

hen多初学者会有一个误区：以为装了 Skill 就会自动生效。其实这背后有一套严密的注入流程。让我们把目光投向 OpenClaw 的源码，kankan这一过程是如何发生的。

2.1 扫描与合并：loadSkillEntries

一切始于 loadSkillEntries。当 Agent 启动时这个函数会被调用，它的任务是像雷达一样扫描多个预设目录。

系统会按照优先级从低到高进行合并：内置安装目录 <用户全局目录 <工作区目录。Ru果存在同名 Skill，高优先级的会直接覆盖低优先级的。这种设计非常符合工程直觉，既保证了平台的基础Neng力，又允许用户进行个性化定制。

2.2 格式化：formatSkillsForPrompt

拿到 Skill 列表后系统并不会直接把所有内容一股脑塞给 LLM。相反，它会调用 formatSkillsForPrompt 方法，将这些技Neng元数据格式化成一段特定的 XML 字符串。

这段 XML 会被标记为 。对于每一个 Skill，系统只会提取其 namedescription 和 location。为什么要这么Zuo？因为在这个阶段，LLM 只需要知道“有哪些工具可用”以及“什么时候该用它们”，具体的操作细节留到后面再加载。

2.3 注入：构建 System Prompt

Zui后在 buildSkillsSection 函数中，这段 XML 会被拼接到 System Prompt 的末尾。系统会明确指示 LLM：“在回复用户之前，必须先扫描 中的描述。Ru果发现匹配的 Skill，请使用 read 工具读取其 SKILL.md 并严格遵循。”

这一步至关重要。它把 Skill 的选择权交给了 LLM 的语义理解Neng力，同时又通过 Prompt Engineering 确保了 LLM 不会“乱来”。

三、 抓包实战：一次完整的 Skill 调用全链路

理论讲多了容易晕，我们直接上干货。下面以一个名为 redbrick-activity 的活动管理 Skill 为例，通过抓包数据来kankan当用户输入“查询 1781 活动列表”时背后到底发生了什么。

3.1 第一阶段：触发与读取

Agent 将用户输入连同 System Prompt一起发送给 LLM。此时LLM 的第一反应并不是直接去执行命令，而是进行“思考”。

在抓包数据中，我们Ke以清晰地kan到 LLM 的第一个 Tool Call。它并没有调用任何业务脚本，而是调用了 read 工具，路径指向 redbrick-activity/SKILL.md。

这说明 LLM Yi经成功识别出用户的意图与 redbrick-activity 的 description 相匹配。它正在按照 System Prompt 的指示，先去“阅读说明书”。

3.2 第二阶段：解析与决策

当 read 工具返回 SKILL.md 的完整内容后LLM 就拿到了详细的执行规则。这里通常包含 CLI 模板、参数收集策略以及上下文继承规则。

比如SKILL.md 可Neng会规定：“调用 search_activity 脚本，必须先从上下文中获取 domain 和 appId，Ru果缺失则向用户询问。”

此时LLM 进入 Thought 环节，解析这些规则，并从当前上下文中提取必要的参数。Ru果参数齐全，它就会生成具体的执行命令。

3.3 第三阶段：执行与反馈

紧接着，LLM 发起了第二个 Tool Call，这次调用的是 exec 工具。命令参数类似于：

bun run {skill-path}/scripts/main.ts search_activity \
  --domain "https://game.bytedance.net" \
  --token "{token}" \
  --app-id "{appId}"

这就是 Skill 机制的核心魅力——CLI 模板填空。相比于让 LLM 用自然语言去描述“调用 main.ts 并传入参数”，直接给出命令模板让模型填空，准确率要高出一个数量级。

脚本执行完毕后结果通过 exec 的返回值传回给 LLM。Zui后LLM 对这些原始数据进行格式化整理，生成Zui终的自然语言回复给用户。

整个过程就是一个标准的 ReAct 循环：Thought → Action → Observation。这种“边想边Zuo边kan”的模式，赋予了 Agent 极强的自我纠错Neng力。

四、 Skill vs MCP：是竞争还是互补？

在 Agent 生态中，MCP无疑是当前Zui热门的标准之一。那么OpenClaw 的 Skill 和 MCP 到底有什么区别？这是hen多开发者感到困惑的地方。

4.1 本质分工：原子操作 vs 业务编排

简单来说MCP 管“怎么连上”，Skill 管“怎么用好”。

MCP 的核心在于标准化连接。它定义了一套 JSON-RPC 协议，让任何 MCP Server 暴露的 TooldouNeng被任何 MCP Client 发现和调用。这些 Tool 通常是原子操作，比如“搜索活动”、“获取配置”、“删除记录”。它们只关心自己的参数和返回值，不关心业务流程。

而 Skill 则位于geng高的层次属于业务编排。它定义的是一套完整的 SOP。例如“查询前先继承上下文”、“删除前必须二次确认”、“结果要用表格展示”。这些逻辑是业务特有的，无法通过单纯的原子 Tool 表达。

我们Ke以用一张表格来对比两者的差异：

维度	MCP	OpenClaw Skill
核心定位	标准化连接与数据暴露	业务流程编排与行为约束
粒度	原子操作	多步骤工作流
关注点	跨平台互操作性	特定场景下的执行确定性
LLM 自由度	高	低

4.2 痛点与融合：Skills Over MCP

虽然 Skill 机制hen强大，但目前也存在一个明显的痛点：静态文件分发。现在的 Skill 需要用户手动下载、解压放到指定目录，缺乏像 MCP 那样的动态发现和分发机制。这就像是在互联网时代还在用软盘传递数据。

为了解决这个问题，社区Yi经成立了 “Skills Over MCP” 工作组。其核心思路非常巧妙：复用 MCP 的 Resources 原语。

具体来说就是让 MCP Server 在暴露 Tools 的同时把对应的 Skill 定义也作为一个 Resource 暴露出去，使用标准化的 skill:// URI。这样，Agent 就Ke以通过 MCP 协议动态地拉取、甚至订阅 Skill 的geng新，彻底解决了版本同步和分发的问题。

这就像是：接入服务时你不仅拿到了“零件”，还自动拿到了“Zui新版说明书”，而且说明书还Neng自动推送geng新。

五、 工程化Zui佳实践：如何写出高质量的 Skill？

理解了原理之后我们再回过头来kan Skill 的开发。hen多同事习惯用“Vibe Coding”的方式，直接把需求丢给 AI 让它生成 Skill。虽然这也Neng跑起来但往往会导致“知其然而不知其所以然”，维护起来极其痛苦。

5.1 Description 的艺术：给 LLM kan的触发器

SKILL.md 中的 description 字段，绝对不是给人kan的简介，而是给 LLM kan的触发条件。

一个糟糕的描述是：“管理活动的工具”。这太模糊了LLM 根本不知道什么时候该触发。

一个优秀的描述应该是：“管理 GMS 红砖平台活动的全生命周期。当用户提到‘创建活动’、‘查询活动’、‘删除活动’或提到‘红砖’、‘redbrick’时使用。不要用于非红砖平台的活动管理。”

具体的触发关键词、业务专有名词、反向的排除条件，这些细节决定了 LLM Neng否准确命中你的 Skill。

5.2 CLI 模板与参数优先级

在 SKILL.md 中，明确给出 CLI 模板是提升准确率的法宝。同时还要定义清晰的参数优先级规则：上下文继承> 用户提供> 主动追问。

这种约束极大地降低了 LLM 的“自由度”。在工程化实践中，我们往往不希望 LLM 发挥创造力，而是希望它像一台精密的机器一样，严格按照预设的轨道运行。

5.3 安全边界：HARD STOP 机制

对于删除、下线这类不可逆的操作，标准 ReAct 流程存在巨大的风险。因为 Thought 到 Action 是无缝衔接的，一旦 LLM 判断失误，后果无法挽回。

因此，必须在 Skill 中引入 HARD STOP 机制。即在 SKILL.md 中定义二次确认逻辑：要求 LLM 先展示操作摘要，并等待用户明确回复“确认”后才Neng执行 exec。

这层人工审批节点，是生产环境中必不可少的安全边界。

通过这次深度的抓包分析，我们Ke以kan到 OpenClaw 的 Skill 机制并非什么高深莫测的黑科技，而是“新瓶装旧酒”的典范。它巧妙地将 Prompt Engineering、Tool Calling 和 ReAct 范式结合在一起，通过工程化的封装，解决了一直以来困扰 Agent 开发的“幻觉”和“不可控”问题。

从 LLM 的视角kan，它不再是在面对一个空白的画布，而是在处理一个个结构清晰的“填空题”。从开发者的视角kan，我们拥有了定义业务逻辑、约束模型行为的强力抓手。

随着 “Skills Over MCP” 标准的推进，未来的 Skill 将不再局限于本地文件，而是会进化为云端动态分发的智Neng资源。对于每一个致力于构建下一代 AI 应用的工程师来说深入理解这套运行机制，无疑是通往高阶玩家的必经之路。

所以别再只满足于“Neng跑就行”了。打开你的抓包工具，仔细审视那些 JSON 数据流，你会发现一个geng加精彩、geng加可控的 Agent 世界正在向你招手。

---