作者：CSDN博客
“Skills”在 2025–2026 年的语境里，已不仅是“可复用提示词模板”，而逐渐演化为一种可移植的、可工程化治理的“过程性能力包”：以文件夹为最小分发单元，包含 SKILL.md（YAML frontmatter + Markdown 指令）、可选的 references/（按需加载知识/规程）、assets/（模板/静态资源）与 scripts/（可执行脚本），并以“渐进式信息披露（progressive disclosure）”降低上下文成本、提升可维护性与可审计性。AgentSkills 规范将这一模式标准化：启动时仅加载元数据（name/description），触发后加载 SKILL.md 正文，执行时再按需读取资源或运行脚本。
OpenClaw（开源、可自托管的常驻 Agent 平台）把“Skills”作为核心扩展机制，并显式实现了：多目录技能加载与覆盖优先级、基于 metadata 的加载时过滤（OS / binaries / env / config 依赖）、将“可用技能清单”以紧凑 XML 形式注入系统提示、以及与 Slash Commands（/...）的联动（可选择绕过模型，直接把命令分发到工具以获得确定性）。同时，围绕 Skills 的开放生态（ClawHub 注册中心、第三方 skills）也带来了显著的供应链与提示注入风险，促使社区与安全厂商提出“把 Skills 当作不可信代码”的运行与隔离建议。
本文从 Prompt 到 Scripts的谱系，逐层给出定义、作用、示例与误区；进一步系统分解 Skill 的组成成分、运行流程与 LLM 交互模式（同步/异步、流式/批量），并给出可落地的伪码与 Mermaid 序列图；随后给出两张对比表（Prompt/Memory/MCP/Skills；以及 LLM→工具调用→Agent→多 Agent→增强记忆→Workflow/Manus→OpenClaw），最后用两个端到端示例展示从 prompt 到 skill 触发、执行、结果整合的完整链路。
从 Prompt 到 Scripts：可操作上下文的分层谱系
1.1 Prompt
定义：Prompt 是一次模型推理的“输入上下文集合”，通常包含：系统级指令、用户输入、对话历史、工具/函数定义与工具返回、以及（可能的）外部检索片段或记忆摘要等。它不是单一字符串，而是多段结构化内容在运行时拼装后的整体。
作用：Prompt 的核心作用是把“任务意图 + 约束 + 可用能力边界 + 证据”对齐到一次或多次模型调用中。提示工程研究与实践普遍认为：结构更清晰、约束更明确的输入，通常能降低幻觉与偏航概率，但过度复杂的提示也可能带来收益递减。
示例（伪码）：- prompt = [ system("你是一个工程助理。遵循安全与权限规则。"), system("可用工具: search_web, fetch_url, run_script"), user("总结最近的 OpenClaw skills 安全事件，并给出缓解建议。"), tool_result("search_web", {...}), // 后续回填]response = LLM.generate(prompt)
常见误区：把 Prompt 等同于“几段话术”；把所有背景一次性塞进上下文导致窗口膨胀；在缺乏证据时要求模型“给出权威结论”，诱发编造。
1.2 普通提示词
定义：普通提示词指以自然语言为主的指令/问答式输入，输出期望也通常是自然语言。它强调“人类可读”，但对模型而言约束较松。
作用：快速表达意图与评估模型能力；适合探索性对话、创意生成、粗略方案讨论。
示例：- 请用中文解释 OpenClaw 的 skills 机制，说明它与 MCP、工具调用的关系，并给出工程化最佳实践。
常见误区：把复杂工作流交给一个“长句”提示；把“过程”隐藏，只要“结果”，导致模型在中间步骤难以自纠错。
1.3 结构化提示词
定义：结构化提示词是指把输入/输出组织为明确结构（如分隔区块、YAML/JSON、表格约束、或直接使用函数/工具调用的 JSON Schema 合约）。在现代 API 里，它往往与“工具调用（tool/function calling）”与“结构化输出（structured outputs）”绑定。
作用：把部分“语言问题”变成“接口问题”：模型只负责选择工具与生成参数，运行时负责执行与校验，从而提升确定性与可测试性。
示例（OpenAI 风格工具定义，JSON Schema）（示意）：- { "tool": { "name": "search_web", "description": "在互联网上检索最新信息并返回结果列表", "parameters": { "type": "object", "properties": { "q": { "type": "string" }, "recency_days": { "type": "integer" } }, "required": ["q"] } }}
最佳实践：
把“结构”用在真正需要确定性的地方（工具参数、输出格式、可审计报告）；对 schema 做“向后兼容”设计（可选字段、版本号）；将工具返回做成“短而有效”的上下文，不把大段日志原封不动塞回模型。
常见误区：以为“给了 JSON schema 就必然严格遵守”；在流式场景下把工具调用 JSON 当作字符串拼接，造成半截 JSON/非法 JSON；把“结构化提示”误用为“更长的模板”，反而增加 token 负担。
1.4 Command
定义：Command 是“绕过自然语言推理、直接驱动控制流”的输入形式。典型表现是 Slash Commands（/...）或 CLI 子命令，其语义更接近“操作系统命令/协议帧”而不是问答。OpenClaw 的文档将其明确为由 Gateway 处理：多数命令必须是以 / 开头的独立消息；并存在“directives”（如 /think、/model、/exec）这类会在进入模型前被剥离的控制指令。
作用：
把“会话状态”（模型选择、推理强度、是否允许 exec、队列模式等）显式化；在安全与可预期性要求更高的场景下，把路径从“模型决定”改为“确定性分发”。OpenClaw 甚至允许 skill 声明 command-dispatch: tool，使某些 skill 命令直接路由到工具而完全不经模型。
示例（OpenClaw）：- /status/skill pdf-processing ./input.pdf/think high/exec host=sandbox security=allowlist ask=on-miss
常见误区：把 commands 当作“更强 prompt”，把敏感信息与权限开关暴露在群聊或不可信入口；把“命令执行成功”误判为“任务已安全完成”，忽视命令链路带来的副作用（例如环境被修改、凭据常驻、配置漂移）。
1.5 Metadata description
定义：Metadata description 是“给模型/运行时用于发现、筛选、触发与治理”的紧凑描述层。在 AgentSkills/Skill 体系里，它通常落在 SKILL.md 的 YAML frontmatter（至少 name 与 description），决定“这个 skill 何时该被使用”。
OpenClaw 在此基础上扩展了更强的运行时 metadata：其技能解析器要求 frontmatter key 多为单行，并建议 metadata 为单行 JSON 对象；metadata.openclaw 可声明依赖（需要哪些 bins/env/config）、平台限制（OS）、安装器规格、以及与 skills.entries.<name> 的注入与配置绑定。
作用：
发现与触发：启动时只加载 name/description，让模型用低成本“知道有哪些技能”，再在匹配时加载正文。过滤与治理：运行时据 metadata 决定 skill 是否“eligible”（可用），例如缺少二进制依赖或环境变量则不加载，避免“模型看到不可执行能力”导致失败循环。安全与权限边界：通过 disable-model-invocation 让 skill 不进入模型提示，仅允许用户显式调用；或通过 command-dispatch: tool 走确定性路径。
示例（一个合并“规范 + OpenClaw gating”的 SKILL.md 头部）：- ---name:web-researchdescription:面向技术调研的证据检索与引用汇总。用户提到“最新/近况/对比/引用来源”时使用。metadata:{"openclaw":{"os":["darwin","linux"],"requires":{"config":["web.enabled"]}}}user-invocable:truedisable-model-invocation:false---
常见误区：description 过于抽象（“帮助你更高效”）导致检索泛化；metadata 与实际行为不一致（“只读”却要求执行脚本）；将复杂 JSON 放入 OpenClaw 不支持的多行 frontmatter，导致解析失败。
1.6 Reference
定义：Reference 是“技能执行时按需加载的补充材料”，典型形态是独立 Markdown 文档、表单填写指南、API 参考、政策/规范等。AgentSkills/Claude 的最佳实践明确建议：SKILL.md 类似目录（table of contents），详细材料放到 reference.md、FORMS.md、examples.md 等文件里，必要时再加载。
作用：
把上下文窗口当作“公共资源”：只在需要时消耗 token；让参考资料成为可审计资产（版本控制、diff、评审）；让技能正文保持短小，降低触发成本。
示例（目录结构）（来自 Claude 最佳实践示意）：- pdf/├── SKILL.md├── FORMS.md├── reference.md├── examples.md└── scripts/ ├── analyze_form.py ├── fill_form.py └── validate.py
常见误区：把 reference 当作“知识仓库倾倒点”，导致加载成本巨大；把敏感信息（密钥、内网地址）放入 reference，形成泄漏面；引用链过深（reference 里再引用 reference）使 agent 在执行时迷失。
1.7 Scripts
定义：Scripts 是技能包内的可执行代码（Python/Bash/JS 等），其关键点在于：脚本应被“执行”而不是“加载进上下文”。Claude 的技能目录示例明确标注 scripts 为“executed, not loaded”。AgentSkills 规范也把 scripts/resources 放在渐进式披露的第 3 层：仅在需要时才使用。
作用：把确定性步骤外包给传统程序：解析/校验/格式化/批处理等；从而提升可测试性、可复现性，并降低“让模型凭 token 模拟执行”的错误率。
示例（SKILL.md 中声明可用脚本）：- ## Available scripts- scripts/extract_citations.py — 从网页抓取结果中抽取主张与证据片段- scripts/normalize_md.py — 把输出归一化为团队博客模板执行规则：优先运行脚本，不要尝试在对话中“脑补执行”。
运行脚本前先做输入校验与最小权限（workspace-only、deny-by-default）；将脚本视作供应链依赖：需要签名、审计、锁版本与 CI 验证；把“验证步骤”写进 skill（例如 validate.py），形成反馈闭环，避免错误一路传播到最后一步。
常见误区：把 scripts 当作“更强的 prompt”，允许其在宿主机任意执行；从不审计第三方 skills/scripts；将“安装依赖”写成一条不透明的 curl | bash 指令，制造典型社会工程入口。
2.1 “Skill”在 2026 语境下的严格定义
从规范与主流实现看，一个“Skill”更接近如下定义：
Skill = 可发现的元数据 + 可执行/可操作的过程性指令 + 可选资源（references/assets/scripts） + 渐进式加载策略 +（可选）权限/环境门控。
AgentSkills 规范给出了最小合约：skill 是包含 SKILL.md 的目录；启动时加载 name/description，激活时加载正文，运行时按需加载 resources。 Claude、GitHub Copilot、VS Code 等实现都围绕这一文件系统布局展开，并强调“目录名与 name 匹配、description 要写清何时使用”。 OpenClaw 明确声明其 skills 文件夹兼容 AgentSkills，并在运行时做额外 gating 与命令联动。
2.2 Skill 的组成成分拆解
下面给出一个面向工程实现的“Skill 组件清单”（不是唯一标准，但与主流规范兼容）。
接口（Interface）：Skill 对外至少暴露“何时使用（trigger）”与“如何调用（instructions）”。在实践里，接口由两层构成：
发现接口：name/description（以及可选 trigger hints、兼容性信息）；执行接口：正文指令 + 告诉 agent 需要哪些工具、需要读哪些 reference、要运行哪些 scripts。
Schema（合约/结构）：
对“工具调用”的 schema：通常是 JSON Schema（OpenAI/Anthropic 工具接口）或 MCP 的 tool schema；对“skill 输入”的 schema：行业里有两种常见做法：
轻量做法：让 skill 在指令中要求模型先提取字段并以固定格式呈现；强约束做法：将 skill 暴露为一个 tool（SkillTool），用 JSON Schema 约束 skill 的输入参数，再由运行时装载 skill 正文与资源。
能力描述（Capability description）：description 是核心，决定检索命中质量。学术综述将其视为“Pattern-1：Metadata-Driven Disclosure”的关键风险面：元数据写错会导致误检索或被投毒。
输入/输出（I/O）：
输入：用户原始意图 +（可选）从对话中结构化提取的槽位参数 +（可选）执行上下文（workspace 路径、会话状态、工具权限）；输出：对用户的自然语言结果 +（可选）结构化产物（JSON、补丁、文件、外部系统状态变更）。OpenAI 的 Responses API 设计把“tool call”与“tool output”作为可关联的 item（call_id），便于回放与评估。
状态/上下文（State/Context）：技能执行往往依赖会话状态（已检索到的证据、已生成的 artifacts、已运行的命令与返回码）。在工程实现上，常见做法是将其放入 Agent state（LangGraph/LangChain 语境）或 SDK 提供的内置 agent loop 状态。
错误处理（Error handling）：技能的价值之一是“把错误处理流程也固化下来”：例如命令失败时要收集 stderr、调整参数重试、或回退到保守策略。SoK 指出：把“恢复（recovery）”当作一等技能，会带来可治理性与可信度上的要求（恢复 skill 必须至少与被恢复 skill 同等可信）。
2.3 Skill 的运作流程：触发、解析、执行、回调与结果整合
下面用一个“兼容 AgentSkills/OpenClaw”的通用流水线描述技能生命周期（阶段名与 OpenClaw/AgentSkills 的术语做了对齐）。（图在评论区置顶）- flowchart TD A[Discover: 扫描技能目录] --> B[Index: 仅加载name/description等元数据] B --> C{Match: 与用户意图匹配?} C -- 否 --> D[继续普通对话/工具调用] C -- 是 --> E[Activate: 加载SKILL.md正文] E --> F{Need refs/assets?} F -- 是 --> G[Load refs/assets: 按需读取文件] F -- 否 --> H[Execute: 进入Agent Loop] G --> H H --> I{Need scripts/tool calls?} I -- 工具调用 --> J[Tool call -> 执行 -> tool result回填] I -- 运行脚本 --> K[Run script -> stdout/stderr -> 回填] J --> H K --> H H --> L[Integrate: 汇总结果与证据] L --> M[Respond: 输出给用户 + 可选产物]
在 OpenClaw 中，上述阶段还会叠加若干运行时细节：
多来源与覆盖优先级：bundled → ~/.openclaw/skills → <workspace>/skills，同名 skill 可被更高优先级覆盖。Load-time gating：读取 metadata.openclaw.requires（bins/env/config）决定 skill 是否 eligible；并支持在一次 agent run 内注入 env、结束后还原。Prompt 注入策略：把“可用技能清单”以紧凑 XML 列表注入系统提示，并给出确定的字符成本公式，便于估算 token 开销。Slash command 联动：user-invocable skill 会暴露为 slash command；并可选择“转发给模型”或“command-dispatch: tool”确定性执行。
2.4 Skill 与大模型的交互模式：同步/异步、流式/批量
同步 vs 异步：
同步：模型发起工具调用，运行时立即执行并回填，再让模型生成最终结果；这是传统函数调用/agent loop 的默认形态。异步：长耗时任务（爬取、编译、批处理）常被放入后台队列/进程；OpenClaw 的 exec 支持前台/后台以及配套的 process 工具来管理后台会话。 工程建议是：把异步当成“第一类控制流”，否则技能一旦遇到长任务就会出现超时、截断或上下文漂移。
流式 vs 批量：
流式：模型边生成边产出工具调用片段、或边生成边汇总结果；流式对“结构化输出”更苛刻，容易出现半截 JSON，需要修复策略。批量：将多个 tool call 规划好后批量执行，再一次性把关键结果回填；在强调效率与可复现的技能里更常见。
与 MCP 的关系：MCP（在 LLM 生态中通常指 Model Context Protocol）把“工具/资源/提示”等能力以标准化的 JSON-RPC 客户端/服务器架构暴露给 Host 应用，并支持多种传输；它解决的是“怎么连工具与数据源”的 N×M 集成问题，而 Skills 更偏“教 agent 怎么用这些工具完成 SOP”。
2.5 示例实现：一个最小 Skill 引擎（伪码）与序列图
下面给一个“最小技能引擎”伪码：它体现 AgentSkills 的 5 步最小要求（discover → load metadata → match → activate → execute）。- class SkillIndexItem: name: string description: string path: string metadata: mapclass SkillEngine:def discover(skills_dirs) -> list[SkillIndexItem]: items = [] for dir in skills_dirs: for skill_dir in list_subdirs(dir): if exists(skill_dir+"/SKILL.md"): fm = parse_yaml_frontmatter(skill_dir+"/SKILL.md") items.append(SkillIndexItem( name=fm.name, description=fm.description, metadata=fm.metadata, path=skill_dir )) return itemsdef eligible(item, runtime_env) -> bool: # OpenClaw 风格：按 OS/bins/env/config 门控 return satisfies(item.metadata, runtime_env)def match(user_msg, index_items) -> SkillIndexItem?: # 最简：embedding/关键词；工程上应加投毒防护与阈值 return best_semantic_match(user_msg, index_items)def run(user_msg): index = [i for i in discover(dirs) if eligible(i, env)] skill = match(user_msg, index) ifnot skill: return llm_generate(normal_prompt(user_msg, index)) full = read_file(skill.path+"/SKILL.md") # Activate prompt = build_prompt(user_msg, index, full) # 注入 skill 清单 + 正文 whileTrue: # Agent loop out = llm_generate(prompt, stream=True) if out.is_tool_call: result = execute_tool(out.tool_name, out.args) prompt.append(tool_result(out.call_id, result)) else: return out.final_text
- sequenceDiagram participant U as User participant G as Gateway/Agent Runtime participant M as LLM participant T as Tools/Sandbox U->>G: message G->>G: discover+load metadata (name/description) G->>G: match & activate (load SKILL.md) G->>M: prompt (skills index + skill body) M-->>G: tool_call(args) G->>T: execute tool / script T-->>G: tool_result(stdout/stderr/data) G->>M: tool_result (call_id关联) M-->>G: final answer (integrated) G-->>U: response
机制对比：Prompt / Memory / MCP / Skills
Prompt 更像“当前对话的瞬时指令”，优势是低门槛与即时性，劣势是不可持久与难治理；Skills 像“可版本化 SOP 包”，在一致性、可复用、可审计上更强，但引入供应链与权限治理成本。MCP 的核心价值在“标准化连接外部工具/数据（协议层）”，而 Skills 的核心价值在“标准化可复用过程（方法层）”；二者互补：MCP 给“手”，Skill 给“操作手册”。
| 机制 | 定义 | 持久性 | 可编程性 | 可组合性 | 调用延迟 | 示例场景 | | 提示词（Prompt） | 一次推理的输入上下文集合（系统/用户/历史/工具结果等） | 低（默认随会话消失） | 低到中（主要靠提示工程） | 中（可拼接模板，但易冲突） | 低（单轮调用） | 快速问答、头脑风暴、一次性总结 | | 记忆（Memory） | 跨轮保存的对话/状态/检索片段（短期或长期），供后续调用检索 | 中到高（取决于存储与策略） | 中（需要检索、压缩、冲突处理） | 中（可被多个技能/工具复用） | 中（检索+融合） | 个性化助理、长任务跟踪、跨会话项目协作 | | MCP | Model Context Protocol：以 JSON-RPC 标准化“LLM 应用 ↔ 外部工具/数据源”连接 | 中（server/connector 常驻） | 高（工具/资源以协议暴露） | 高（多 server 组合） | 中（网络/鉴权/执行） | IDE 接入代码库、企业系统连接（CRM/DB/工单） | | Skills | 以目录为单位的可移植能力包：SKILL.md +（可选）references/assets/scripts；渐进式披露加载 | 高（版本化、可共享） | 高（可运行脚本/约束流程） | 高（可同时加载多个 skill） | 中到高（匹配+激活+执行） | 代码评审 SOP、自动化报表、受控的数据处理流水线 |
备注：这里的 “MCP” 在 LLM 场景下通常指 Anthropic 提出的 Model Context Protocol。
从 LLM → Tool Calling → Agent 的演进，本质是在把“控制流”从人类手工（写提示、点按钮）转移到运行时（agent loop），再用更强的结构（skills/workflow）把不确定性收束到可治理范围。OpenClaw 的“产品化差异”在于：它把 agent 变成常驻基础设施（多入口聊天应用 + 本地执行 + 可安装技能市场），因此其主要挑战从“能不能做事”转向“能不能在开放生态里安全地做事”。
[table][tr][td]阶段[/td][td]架构层级[/td][td]控制流[/td][td]状态管理[/td][td]扩展性[/td][td]典型实现/开源项目[/td][td]适用场景[/td][td]优缺点[/td][/tr][tr][td]LLM[/td][td]单次生成[/td][td]人工组织 prompt[/td][td]低（主要靠对话历史）[/td][td]低[/td][td]通用对话 API / 提示工程总览[/td][td]问答、生成、分析[/td][td] |
广告