前九节课，我们走过了从零部署到Workspace配置，从Channel接入到Gateway解剖，再到Agent执行循环和三级记忆存储的全过程。你现在应该已经能够亲手搭建一个能跑、能记、能接入聊天软件的OpenClaw实例了。
但你可能正在面对一个更实际的困扰：OpenClaw虽然预置了200多个内置技能，但为什么感觉还是不够用？“我想让AI自动拉取特定API的数据并生成日报，为什么它总是只回复建议不执行？”“我在网上下载了一个社区技能，但装上去后AI仍然像个文档阅读器，完全没有动作。”——这种感觉在开发者社群中被形象地描述为“螃蟹效应”：明明装了技能，Agent却总是含糊回应、不肯真正调度工具。
其实，99%的这种“装了技能没用”现象，根因不在于技能本身坏了，而在于OpenClaw的Skill执行策略并不是“加载即生效”，而更像是一本被翻阅的参考手册，何时翻阅、怎么翻阅，完全取决于Agent如何理解你的指令，以及SKILL.md的写法是否足够清晰。本章就是帮大家搞懂这层逻辑：Skill到底是“插件”还是“说明书”？它和工具（Tool）的核心边界在哪？OpenClaw如何通过渐进式披露（Progressive Disclosure） 的分层加载机制来平衡Token成本与能力覆盖？如何使用SKILL.md和MCP（模型上下文协议）赋予Agent无限的能力扩展？读完并动手实战后，你遇到底层Skill无法单纯依靠社区能力覆盖的业务场景，也能自己设计一个完美的SKILL.md并通过沙箱的安全枷锁。
本节课作为Skills系统的骨架解析，将从架构底层开始，带你看清楚Skill是什么、200+内置技能的分类和典型用法，厘清Skill与Tool的微妙但关键的边界，完整拆解Skill调用协议与参数传递规范，分析技能执行沙箱的安全隔离原理，从官方技能中提炼可复用的设计模式，并讨论性能优化的几个关键方向。这将为你进入第11课开始的具体技能开发实战打好最扎实的地基。
10.1 Skills系统的插件化架构设计
一句话概括：Skill在OpenClaw中不只是一堆功能文件，而是一套轻量化、按需加载的能力组织方式——它把复杂AI能力解构成可描述、可复用的原子模块，通过渐进式披露的分层加载机制来规避上下文污染，用“说明书驱动”的思想让Agent在需要时才读取细节，在不改核心代码的前提下动态扩展知识边界。
2026年的OpenClaw对Skill体系进行了重构，采用“纯文本配置+脚本驱动”的设计，无需复杂的底层开发，仅需掌握基础的脚本编写与配置文件语法，即可快速开发专属Skill。这一点从架构的最初就奠定了Skill的进入门槛极低——会写Markdown就能开发技能，不需要编程基础，不需要懂API，10分钟就能做出可运行、可复用、可分享的技能包。
什么是Skill？——超越“插件”的设计哲学
很多人在接触OpenClaw时，习惯性地把Skill理解为传统意义上的“插件”——认为它是一段提前写好的、可被Agent直接调用的代码。但在OpenClaw的设计语境中，Skill并不等同于传统意义上的插件。插件更像是提前安装好的功能模块，而Skill更接近一种被描述、被理解、被按需调用的能力。它用自然语言定义自己能做什么、适合在什么情况下使用，同时保留足够清晰的边界和限制。
这背后有一个很现实的工程考量：大模型的上下文窗口是有限的。如果一开始就把所有工具、所有能力一股脑塞进去，不但浪费令牌，还会让模型在关键决策时分心。所以Skill的核心思想不是“我能做什么都告诉你”，而是——等你真的需要我时，我再把细节交出来。
在OpenClaw中同时存在两种互补的架构模式：Agent + Skill 架构和主子Agent（Subagent）架构。SKILL.md文件为Agent注入领域知识，就像给一个人发一本操作手册。这两者不是替代关系，而是互补关系——一个Agent可以在读取Skill获得知识后，再创建多个子Agent并行执行任务；子Agent自身也可以使用Skill。
分层级渐进式披露
传统Agent面临的最大问题之一是：工具越加越多，效果反而变差。模型面对大量工具描述时，既要理解当前任务，又要判断该用哪个工具，本身就会出现注意力稀释。渐进式披露正是为了解决这个问题而生的。
在OpenClaw的设计中，Skill的加载被拆成了三个阶段：
- 第一层：索引层：系统启动时，只读取极简的能力索引，用来预判断“哪些Skill可能对当前任务有用”
- 第二层：定义层：当用户的输入真的匹配到某个场景时，才加载对应Skill的完整定义（即SKILL.md的内容）
- 第三层：执行层：真正执行时，才引入具体的上下文、参数和中间结果
这种分层设计的效果非常直观。Agent启动更快了，对话成本更低了，更重要的是——工具选择的准确率明显提升。模型不再是在一堆工具中“猜”，而是在少量、强相关的能力中“选”。
Skill的物理结构
一个Skill本质上是一个包含SKILL.md文件的目录（位于工作区），可选包含一些脚本、资源文件或子目录。可以存放于三处位置：
| 存放位置 | 优先级 | 说明 |
|---|---|---|
~/.openclaw/workspace/skills/ | 最高 | 工作区技能，随当前Agent加载 |
~/.openclaw/skills/ | 中等 | 托管/本地技能，可跨Agent共享 |
| 捆绑技能 | 最低 | 随OpenClaw官方安装包内置，开箱即用 |
三层存放位置的设计满足了从个人调试到团队共享再到官方内置的全链条分发路径。
10.2 预置技能模块的完整盘点
一句话概括：从开箱即用的内置基础技能，到社区贡献的近三千个高质量技能，OpenClaw的Skill生态在2026年已经覆盖了办公自动化、浏览器控制、开发运维、AI调用等12大核心场景，形成了一张巨大的“数字管家能力网”。
截至2026年2月，OpenClaw官方技能市场ClawHub已收录超过5705个社区构建的技能，经过严格筛选后，最终有2868个高质量技能入选热门列表。这个筛选过程会过滤掉垃圾测试技能、加密货币相关技能、重复技能以及恶意技能，从源头保障了生态的纯净度。
内置基础技能
官方内置了53个经过严格安全校验的技能，是当前最安全的选择。阿里云镜像中预置的核心增强Skill包括：
| 技能名称 | 功能描述 | 风险等级 |
|---|---|---|
| agent-browser | 浏览器自动化操作 | 低 |
| self-improving-agent | 自进化能力，“错题本”机制，越用越聪明 | 低 |
| proactive-agent | 提升OpenClaw的主动任务执行能力 | 低 |
| find-skills | 快速发现并安装好用的Skills | 低 |
| skill-vetter | 执行Skills安全扫描 | 低 |
| filesystem | 文件系统读写整理 | 中（需授权） |
内置技能按功能可以归为以下几个大类：
- 浏览器自动化：agent-browser（网页抓取、表单填写、数据采集）
- 文件管理：file-manager（读写、整理本地文件）
- 系统命令：system-command（用自然语言执行服务器指令）
- 消息通道：Telegram、飞书、钉钉等IM集成技能
- 基础工具：read、write、edit、exec等系统级工具对应技能
社区技能生态
官方社区贡献的技能覆盖了12大核心场景：
| 分类 | 数量 | 代表性技能 | 核心用途 |
|---|---|---|---|
| AI & LLMs | 287 | 大模型调用、Prompt工程 | 优化AI交互效果 |
| Search & Research | 253 | 网络搜索、深度研究 | 实时信息获取与研究 |
| DevOps & Cloud | 212 | 云服务部署、服务器监控 | 自动化运维管理 |
| Web & Frontend Dev | 202 | 前端开发、代码生成 | 快速构建网页 |
| Browser & Automation | 139 | 浏览器控制、表单填写 | 解放重复操作 |
| Productivity & Tasks | 135 | 任务管理、日程安排 | 优化时间管理 |
| Coding Agents & IDEs | 133 | 代码调试、语法检查 | 辅助编程开发 |
| Communication | 132 | WhatsApp/邮件集成 | 自动化沟通 |
| CLI Utilities | 129 | 命令行工具集成 | 简化终端操作 |
| Notes & PKM | 100 | 笔记管理、知识库构建 | 沉淀知识资产 |
| Marketing & Sales | 143 | 营销文案、客户跟进 | 自动化营销流程 |
| Media & Streaming | 80 | 视频处理、图像生成 | 快速创作媒体 |
从日常的天气查询、定时提醒到企业级的服务器运维、浏览器自动化，再到A股行情监控，社区近3000个高质量技能覆盖了从生活到工作的方方面面。
ClawHub与VirusTotal深度合作，所有技能均提供安全扫描报告，安装前可直观查看风险等级。但安全风险评估不只是平台的责任——2026年2月爆发的ClawHavoc恶意技能事件中，安全研究团队在ClawHub发现了396个恶意技能，这些技能通过伪造前置条件诱导用户下载含木马的技能包。因此，无论平台如何扫描，安装任何社区技能前都应审核其SKILL.md内容和权限范围。
安装技能的两种方式
# 方式一：通过openclaw-cli命令安装
openclaw skill add browser-automation
# 方式二：在对话中触发find-skills技能安装
＠帮忙找个能自动填表单的浏览器Skill
此处需要强调的是：find-skills本身也是一个Skill，它由阿里云镜像预置内置，用于快速搜索并安装社区Skills，使用自然语言描述需求即可由AI完成安装。
避坑指南：网传OpenClaw内置了“5705个技能”，这是典型的误区。5705是ClawHub技能市场的收录总数，而内置打包仅包含官方校验的53个核心安全技能。大部分社区技能需要单独安装才能用，而不是随OpenClaw安装直接可用。
10.3 技能与工具的职责边界
一句话概括：Skill和Tool的边界极其清晰——Tool是Agent已经“长在身上”的执行器官，Skill则是一份操作说明书，教会大模型如何组合这些器官来完成特定任务。
这是OpenClaw用户群里讨论最热烈的问题之一，也是最容易混淆的概念。很多用户觉得自己装了一大堆skills，AI却“只会答不会做”——其实问题往往在于混淆了Skill与Tool的边界。
“器官”与“教科书”的比喻
Tool（工具）是OpenClaw内置的基础执行能力单元，比如说read读文件、write写文件、exec执行命令、browser控制浏览器——这些是Agent从出生就具备的、原子化的“器官”。无论你有没有skill，这些tool的能力都存在于系统中。
Skill则是指导大模型如何组合使用tool来完成特定任务的说明书。它不是独立的代码模块，而是一份SKILL.md文档，里面写清楚了“在什么场景下、按照什么步骤、调用哪些tool、如何处理异常”。
“Tool是Agent的能力器官，Skill是教AI如何组合这些器官完成任务的教科书。” 厘清二者区别是合理配置、安全使用的基础。
Tool与Skill的核心区别
| 维度 | Tool（工具） | Skill（技能） |
|---|---|---|
| 本质 | 执行器官（函数、命令） | 说明书（SKILL.md） |
| 可否被调用 | 直接可调用 | 需先被加载阅读 |
| 谁发起调用 | Agent核心引擎直接调用 | 模型阅读说明书后明白如何调用tool |
| 能否独立存在 | 可以 | 依赖Tool才能完成动作 |
| 示例 | exec、write、browser | “抓取微信公众号文章”技能 |
理解了这一层，很多“装了skill却又无效”的困惑就迎刃而解了：一个skill的SKILL.md如果没有清晰描述应该调用哪些tool、如何调用，大模型读完仍然不知道怎么做，只能给出文字建议。
MCP协议：扩展工具的“万能接口”
除了内置Tool，OpenClaw还通过MCP（Model Context Protocol）协议支持外部工具生态的接入。MCPporter等中间层工具可以将MCP服务转换为OpenClaw可识别、可调度、可交互的执行单元，实现AI助手与第三方系统的双向通信。
从长远来看，MCP正在成为连接LLM与外部数据源和工具的桥梁。通过MCP，Agent可以动态发现和调用大量第三方MCP Server提供的工具，这些工具被注册为OpenClaw原生Agent工具后，行为等同于内置Tool——这相当于在“器官”层面实现了无限扩展。
快速验证资产清单
如果你分不清一个功能到底是Tool还是Skill，有一个快速判断方法：
- 执行
openclaw tools list：看到的都是Tool（exec、read等） - 执行
openclaw skills list：看到的都是Skill - 一个Skill中可以引用多个Tool来实现复杂任务；反之不能
- Tool的策略配置（allow/deny）决定Skill能否正常工作
10.4 技能调用协议与参数传递规范
一句话概括：Skill的调用不走专门的API路径，而是通过SKILL.md文件的YAML frontmatter声明元数据，Agent在运行时通过Markdown内容理解技能用法，对工具（Tool）的调用才是真正的执行层交互——这一过程遵循标准化的Tool Use协议进行工具名称匹配和参数传递。
SKILL.md文件格式规范
SKILL.md是Skill的核心文件。在OpenClaw 2026年的轻量化重构中，Skill的开发门槛被压到了极低：会写Markdown就能开发，不需要编程基础，10分钟就能做出可运行、可复用的技能包。
一个标准的SKILL.md文件包含YAML frontmatter（元数据）和Markdown内容（使用说明），格式如下：
---
name: my-custom-skill
description: 技能功能的简洁描述（用于索引层判断是否需要加载此技能）
version: 1.0.0
metadata:
openclaw:
requires:
bins: ["curl", "jq"] # 可选：声明此技能依赖的系统命令
---
# 技能标题
完整的执行说明书从这里开始——这是模型真正阅读的部分。
## 使用场景
当用户提到【场景描述】时，可以使用此技能。
## 执行步骤
1. 首先使用 `read` 工具读取配置文件
2. 然后使用 `exec` 工具调用 `curl -X GET '...'`
3. 最后使用 `write` 工具将结果写入报告文件
## 异常处理
- 如果API调用返回401，提示用户检查API Key
- 如果网络超时，重试最多3次
## 可用工具参考
本技能会使用到以下Tool：`read`、`write`、`exec`、`browser`
SKILL.md五要素
实用的SKILL.md应包含以下五个核心要素：
- 描述信息：清晰简洁地简述Skill的功能和使用场景
- 触发器：定义哪些用户输入或意图会激活此Skill
- 使用说明：详细的步骤指南，确保逻辑清晰完整
- 环境变量：列出此Skill需要的环境变量及默认值
- 所需工具：明确列出运行该Skill需要的Tool
Tool Use协议
当Agent通过SKILL.md理解了自己应该“怎么做”之后，真正的执行依赖于底层Tool的调用。OpenClaw调用Tool时遵循Tool Use协议，调用流程大致分为三步：
- Agent引擎构造Tool调用请求：包含Tool名称（如exec、browser）和参数（JSON格式）
- Gateway的Tool策略层进行安全检查：基于allow/deny配置和沙箱策略
- 执行后将结果写入会话转录，格式为
role: "tool"的消息，供模型下一轮读取
参数传递规范
Tool调用的参数传递遵循统一规范：
{
"command": "npm install -g openclaw",
"timeout": 30000,
"elevated": false
}
每条Tool调用的请求-响应都有唯一的toolCallId关联，确保在多轮并行调用中请求和结果不会混淆。
10.5 技能执行沙箱的安全隔离原理
一句话概括：Skills的执行安全依赖三重防护——沙箱隔离决定Tool在哪里运行（Docker容器或宿主机），Tool策略决定哪些Tool可用，提升执行则作为仅限exec的逃生通道，在沙箱中运行时实现受控的对外突破。
在AI Agent的安全领域，一个反复被验证的教训是：永远不完全信任来自大模型的指令。OpenClaw的安全体系围绕Skill执行层构建了一个“三层大坝”——不是简单的“开”或“关”，而是三个独立但协同的控制维度。
安全红线：OpenClaw官方明确声明——这不是完美的安全边界，但当模型做出愚蠢行为时，它能实质性地限制文件系统和进程访问。绝不能把沙箱当作唯一的防线，完整的安全体系还需要配合后续第27课的进一步加固。
沙箱隔离：决定Tool在哪里运行
沙箱隔离是决定工具（Tool）执行位置的第一重防护，配置在agents.defaults.sandbox.mode中：
| 模式 | 含义 | 适用场景 |
|---|---|---|
"off" | 所有内容在宿主机上直接运行 | 仅限开发测试环境，高风险 |
"non-main" | 非主会话进入Docker容器隔离 | 默认值，群聊访问自动沙箱化 |
"all" | 所有会话都在容器中运行 | 多用户生产环境，最安全 |
隔离范围涵盖：工具执行（exec、read、write、edit等）、浏览器进程（可选的agent-browser沙箱）、甚至通过浏览器工具远程控制的CDP端点。隔离作用域scope决定创建多少容器，并可选择以ro（只读）或rw（读写）方式挂载智能体的工作区。
工具策略：决定哪些Tool可用
沙箱解决的是“哪里跑”，工具策略解决的是“什么能跑”。即使你启用了沙箱，如果没有工具策略限制，模型仍然可以通过exec执行任意危险命令。
{
"tools": {
"deny": ["exec", "apply_patch", "browser"],
"allow": ["read", "write", "edit", "filesystem"]
}
}
核心规则：
- deny 永远优先——无论allow如何配置，deny列表中的工具都会被硬性阻止
- 如果allow非空，其他所有未明确允许的工具都被视为阻止
- /exec命令无法绕过被策略拒绝的exec工具——这是硬性阻断
提升执行：仅限exec的逃生通道
提升执行（Elevated Execution）是一个仅针对exec工具的受控逃生通道。当你在沙箱中运行，但有些任务确实需要访问宿主机上的真实资源（如读取某实时数据、操作快捷方式等）时，提升执行就可以提供解决方案。
# 在聊天对话中启用提升执行
/elevated on
- 当退出会话或超时后，提升执行自动关闭
- 仍可能会被审批（approval）策略拦截
需要特别强调：提升执行不会绕过工具策略的deny配置。如果tools.deny中包含exec，即使在沙箱中/elevated on也没用，调用会被直接拒绝。
快速诊断工具
OpenClaw提供了一个强大的检查器，可实时查看当前会话的三重防护生效情况：
openclaw sandbox explain --session main
输出内容包含：
- 生效的沙箱模式/范围/工作区访问权限
- 当前会话是否被隔离
- 生效的工具允许/拒绝配置及来源
- 提升执行阈值和建议
这个工具是在沙箱权限配置混乱时最快定位问题的入口，远好于逐个翻阅复杂的openclaw.json。
10.6 从官方技能中学习设计模式
一句话概括：最好的学习材料就是官方技能的源码——从抓取微信公众号文章失败的“三层防御”案例中，可以学到可复用的设计模式：降级策略、多工具协作、安全边界声明和清晰的错误反馈。
你有没有想过一个问题：假如你给OpenClaw发出指令“帮我抓取这篇公众号文章总结”，为什么它可能失败了？这不是AI的能力不行，而是公众号的页面结构本身设计了三层防御机制来阻止简单的HTTP爬虫：Cookie鉴权、动态渲染和请求头检测。要突破这三层，仅靠一个简单工具是无法完成的，需要Skill提供完整的多层解决方案。
设计模式一：工具组合实现降级策略
官方浏览器自动化技能的设计精妙之处体现在“降级策略”——先识别目标网站的复杂度层级，按需选用不同工具组合：“简单静态HTML网页→直接用read工具抓取”“JavaScript动态渲染页面→启动无头浏览器执行”“需要用户登录的封闭系统→进入交互审批模式”。这种降级策略是对用户Token成本的极大节约。
设计模式二：面对外部API的完整处理脚本
一个好Skill的SKILL.md往往会包含完整的日志记录和错误处理步骤：调用API前的参数校验、调用时的网络超时重试、调用后的状态码解析、最终执行结果是否符合预期。官方Skills总会写明“如果API调用失败，重试最多3次，间隔递增”。
设计模式三：多工具间的编排
Skill中一般不直接写“从日期A到日期B，筛选数据库记录”，而是按照顺序拆分：先用memory_search查找用户此前是否做过同类任务，确认后再用browser打开仪表盘，再执行exec调用报表生成脚本。多工具编排是官方Skill中最值得学习的设计手法。
设计模式四：安全边界声明
官方Skill通常会在SKILL.md中显式声明安全边界：
- 使用场景的白名单（“仅在用户明确要求查询时使用，不主动分析”）
- 工具调用范围限制（“绝对不修改数据库，仅读取视图”）
- 数据隔离提醒（“不将客户的订单号写入任何全局缓存，只保留在会话上下文”）
反向案例：官方Skill可复用的设计和可避免的坑
| 好的设计特征 | 避免的坑 |
|---|---|
| SKILL.md 清晰指出适用场景和禁用场景 | SKILL.md 过于模糊，模型不知道何时调用 |
| 准确列出所有依赖bin和Tool | 缺少工具权限导致调用失败 |
| 提供至少两条示例指令 | 示例不足，模型推测错误用法 |
| 包含异常处理指引 | 无失败处理，任务走到死胡同 |
10.7 技能系统的性能考量与优化方向
一句话概括：技术性能的六个优化方向——Redis缓存、技能预加载策略、渐进式披露限制、MCP中间层降载并行、会话隔离回收和周期性重索引，把OpenClaw从“技能反应慢”升级成“秒级智能管家”。
Skill装得越多，对话越久，OpenClaw就越容易出现响应慢、卡顿、延迟高的问题。根源往往不在CPU或大模型API，而在数据存储层——每次请求都要读写大量上下文和Skill元数据，如果没有缓存机制，磁盘I/O就成了瓶颈。
第一：Redis缓存是性价比最高的入门优化
Redis把高频读写的数据放在内存里，用空间换时间。部署在同服务器的Docker容器中，指定一个强密码并关闭外网访问。接入后在.env中配置REDIS_URL，重启后验证命中率是否≥80%。实测复杂对话从5-8秒降低到2-3秒。
第二：技能预加载策略
高频使用的Skill（如browser自动化、数据报表）可通过配置预加载，将SKILL.md提前缓存到内存，显著降低延迟。可通过agents.defaults.skills配置将特定技能纳入预加载列表,或设置agents.defaults.skills: "unrestricted"默认预加载所有技能,但后者的Token成本较高。
第三：渐进式披露的限制优化
在默认三层加载基础上，通过调优索引层的行为（配置agents.defaults.skills.quickApproval，设定只索引描述和触发器）可以减少每次都需要完整读取SKILL.md的预开销。
第四：MCP中间层的降载与并行
MCPporter等中间层能支持将MCP服务封装为Skill，同时实现跨API请求的并行执行。当关联对外API调用时，可显著降低累积耗时。
第五：会话隔离与自动清理回收
维护agents.defaults.sandbox.scope: "session"为每个会话分配独立的沙箱。设置清理策略session.pruneAfterDays: 7，定期删除历史会话文件。
第六：周期性全技能重索引
执行openclaw skills reindex --force命令低峰期重建索引，提升社区的skill-discovery匹配响应速度。
10.8 本节小结
本节课作为Skills系统的骨架解析，我们从插件化架构解析开始，盘点了OpenClaw丰富的预置技能，厘清了Skill与Tool的本质区别，分析了SKILL.md规范与Tool Use协议，拆解了沙箱隔离的三重安全机制，从官方技能中提炼了设计模式，并给出了性能优化的系统方案。
核心知识点可以浓缩为：
- Skill是指南，Tool是器官——Skill通过SKILL.md指导Agent如何组合使用Tool完成任务
- 渐进式披露的三层加载（索引层→定义层→执行层）保障了Token成本可控
- 200+内置Skill，社区近3000个技能覆盖12大场景
- 安全三重防护：沙箱隔离（exec在容器/宿主机）、工具策略（allow/deny）、提升执行（elevated）
- MCP协议连接外部工具生态，是技能扩展的未来骨干
- 性能优化的起点是Redis缓存——从5-8秒降到2-3秒
掌握了这节课的内容，你才算真正进入了Skills的“高手区”。第10课和第11课之间有个重要的转化——从抽象架构层面转向具体的自定义技能开发实践。
10.9 课后习题
1. Tool vs Skill 区分实践
找出你的OpenClaw环境中一个已安装的社区Skill（如浏览器自动化），执行openclaw skills show <skill名>打开它的SKILL.md文件。回答：这个Skill里引用了哪些具体的Tool？如果把这个Skill搬走，这些Tool本身还能被调用吗？
2. 沙箱安全配置演练
在你的测试环境里，将agents.defaults.sandbox.mode从off改为non-main（如果之前是off），让非主会话进入沙箱隔离。分别通过WebUI主会话和群聊Channel向Agent发送系统命令echo hello，查看日志中工具执行的宿主信息差异。尝试执行/elevated on，观察输出变化。
3. 性能优化对比实验
分别统计在不同Skill负载下5次对话的平均响应延时：场景A（无Redis，预加载关）；场景B（有Redis，预加载关）；场景C（有Redis，高频Skill预加载）。对比结果最令你惊讶的发现是什么。
4. 自定义Skill设计
根据你日常办公中遇到的一个高频重复场景（比如每周整理本周聊天记录中的关键决策），尝试用自然语言写一个SKILL.md草稿。确保它包含：名称、描述、触发器、至少3个执行步骤、明确列出依赖的Tool、异常处理。
5. MCP扩展推演
搜索OpenClaw MCP生态的一个服务（如GitHub MCP Server），思考如果通过MCPorter将其集成，理论上Agent可以用自然语言完成哪些原本需要手动触发的任务。你认为集成后的Skill应该在SKILL.md中如何描述这个能力。
🔗《30节课精通 OpenClaw》系列课程导航
第一部分（第1-5课） ：基础认知与入门部署——解决“这是什么、怎么搭建”的问题；
第二部分（第6-10课）：核心原理深度剖析——解决“底层怎么工作”的问题；
第三部分（第11-15课） ：应用场景与平台集成——解决“能用来做什么”的问题；
第四部分（第16-21课） ：技能开发与定制扩展——解决“如何自己扩能力”的问题；
第五部分（第22-26课）：高级特性与性能优化——解决“怎么用得更好”的问题；
第六部分（第27-30课） ：安全、运维与生态进阶——解决“如何安全可靠地规模化”的问题；
