在智能体工程（Agent Engineering）体系中，Skill（技能 / 能力模块） 是指将特定业务目标的角色设定、工具调用、执行流程（SOP）与输出约束高度封装的可复用软件能力单元。
💡 核心定位：如果说大模型（LLM）是通识知识库，Harness 是运行底盘与操作系统，那么 Skill 就是给 AI 装备的“专业技能工具包”。通过将零散的 Prompt 和多步骤工具调用固化为 Skill，AI 能够摆脱不可靠的临时自由发挥，实现高稳定性、高复用度的工业级任务自动闭环。
能力抽象演进阶梯：
Prompt (文本意图) ➔ Tool (原子接口) ➔ Skill (能力模块) ➔ Workflow (流程编排) ➔ Agent (自治实体)$$\text{Production Skill} = \text{Role (角色定位)} + \text{Tools (工具绑定)} + \text{Workflow (执行流程)} + \text{Schema (输出约束)}$$
🔗 相关矩阵速查：AI Agent Harness 工程架构与核心机制速查表 · 大模型与智能体技术概念全景词典速查表 · 4大 Always-on Agent 横向对比速查表 · Claude Code 常用命令速查表 · 金融与投研 AI Skill 榜 TOP10 指南
1. 普通聊天 vs 加装 Skill 的执行范式对比
flowchart LR
subgraph Chat ["普通对话模式（无 Skill）"]
direction TB
U1(["用户提问"]) --> A1["AI 裸模型直接推理"]
A1 --> R1(["输出临时回答\n(易幻觉、不可复用)"])
end
subgraph SkillMode ["Skill 结构化执行模式"]
direction TB
U2(["用户目标需求"]) --> S1["1. 意图识别与 Skill 匹配"]
S1 --> S2["2. 装载 Skill 规范与工具"]
S2 --> S3["3. 依序执行 SOP 与条件分支"]
S3 --> S4["4. 结构化校验与合规过滤"]
S4 --> R2(["交付确定性结果\n(高稳定、可复用)"])
end
style Chat fill:#f8fafc,stroke:#94a3b8,stroke-width:1px;
style SkillMode fill:#eff6ff,stroke:#2563eb,stroke-width:2px;
style R1 fill:#fef2f2,stroke:#ef4444;
style R2 fill:#ecfdf5,stroke:#059669;核心能力横向对比
| 核心维度 | 普通聊天对话 (Prompt Chat) | 具备 Skill 的智能体 (Skill-based Agent) |
|---|---|---|
| 交互逻辑 | 即问即答：用户单次输入，AI 凭上下文概率预测回复 | 任务闭环：识别意图 ➔ 唤醒技能 ➔ 逐步执行 ➔ 验证输出 |
| 复用程度 | 一次性消耗：每次都要把角色、规则、要求重新输入一遍 | 开箱即用：一次封装成标准 Skill，全团队随时一键触发 |
| 工具协同 | 通常无外部工具：仅凭模型自身内部静态权重知识回答 | 动态调度外部工具：可调用 CLI、数据库、REST API、MCP 协议 |
| 执行深度 | 浅层单步：无法承载多分支、跨工具、需要中间回滚的长任务 | 多步 SOP：具备条件判断、重试策略、异常分支与状态管理 |
| 输出确定性 | 随机性大：容易出现格式错乱、口语化发散或隐蔽幻觉 | 强契约约束：遵循严格的 JSON/Markdown Schema 与安全底线 |
| 记忆与维护 | 依赖临时会话：多轮对话后容易遗忘或注意力漂移 | 版本化持久存储：作为代码资产随 Git 仓库版本化迭代维护 |
2. 一个标准 Skill 的 4 大核心构成要素（架构卡片）
01 · 角色定位与目标意图
Role & Intent Trigger
认知锚点
定义 Agent 在执行当前技能时的专家身份、目标职责与触发唤醒规则。
- ▸身份角色声明：明确专业设定（如“资深数据库调优专家”、“高可靠爬虫工程师”）。
- ▸意图触发词 (Triggers)：声明何时唤醒此技能（如匹配关键词、用户自然语言意图或特定 Slash 命令）。
- ▸职责边界限定：明确本技能“做什么”与“绝不做什么”，防止越界执行不相关任务。
- ▸前置条件检查：校验运行环境所需的凭证、密钥（API Token）或配置文件是否存在。
02 · 工具与外部服务绑定
Tools & External Services
行动能力
声明完成此技能必须具备的原子工具集、外部 API、本地命令或协议端点。
- ▸原子工具清单：声明本技能有权调用的原子工具（如 `run_command`、`read_file`、`http_request`）。
- ▸MCP 协议服务：接入标准 Model Context Protocol 工具服务器（如 GitHub MCP、Postgres MCP）。
- ▸执行权限级别：明确工具调用的安全权限（只读 Read-only vs 写操作 Write vs 敏感审批确认）。
- ▸参数 Schema 契约：以强类型 Schema 声明输入输出参数格式，拦截非法调用。
03 · 执行流程与分支路由
Execution DAG & Workflow SOP
逻辑中枢
将复杂的业务任务固化为严密的标准化操作程序（SOP）、分支判断与自愈策略。
- ▸分步操作指令 (SOP)：按 `第 1 步 ➔ 第 2 步 ➔ 第 3 步` 的确定性因果链条组织执行。
- ▸条件分支与决策树：定义 `If-Else` 逻辑分支（如：如果测试报错，执行回滚与错误修复分支）。
- ▸反思重试机制 (Loop)：遇到临时性网络故障或小错误时，内置重试阈值与回退策略。
- ▸任务终止条件 (Stop Condition)：明确何种情况判定为完工交付，避免无限死循环。
04 · 输出格式与安全规则
Output Schema & Guardrails
交付契约
严格规范结果交付的格式、排版结构、合规安全准则与必须避免的禁区。
- ▸结构化交付契约：指定产出格式（如标准 Markdown 表格、JSON 对象、Git Patch 或 Mermaid 流程图）。
- ▸正文质量准则：禁止出现口语化套话、未经求证的技术断言或泄露敏感中间过程。
- ▸防幻觉底线：无法确定事实时必须如实报告未知，严禁虚构不存在的参数或 API 接口。
- ▸脱敏与安全护栏：自动过滤 API Key、真实密码、内部内网 IP 等敏感数据泄露。
3. 工业级 5 级梯队辨析：Prompt vs Tool vs Skill vs Workflow vs Agent
在现代 AI 系统架构中，这 5 个层级自底向上构成完整的技术栈：
| 抽象层级 | 核心定义与本质 | 典型载体 / 表现形式 | 自主决策自由度 | 经典现实比喻 |
|---|---|---|---|---|
| 1. Prompt (提示词) | 自然语言给出的意图指示与上下文约束 | System Prompt / 用户输入字符串 | 0（无决策权） 纯文本输入，受大模型采样概率支配 | “给工人的一句口头交代” |
| 2. Tool (原子工具) | 执行特定功能的单一原子操作接口 | 单个 Python 函数、Shell 命令、RESTful API | 0（无自主权） 只负责接受参数并返回结果 | “工具箱里的一把扳手” |
| 3. Skill (能力组件) | 面向业务目标封装的高阶可复用技能包（整合 Prompt + Tools + 流程） | SKILL.md 规范文件、模块化 Python 包 | 中等（局部自主） 能在技能范围内自主按 SOP 步骤调度多工具 | “一位懂得如何修漏水水管的专业师傅” |
| 4. Workflow (工作流) | 严格按照确定性 DAG 图流转的业务流水线 | Dify / LangGraph / n8n 连线流程图 | 极低（确定性执行） 严格按条件连线推进，节点不可随意跳步 | “工厂标准化流水作业装配线” |
| 5. Agent (智能体) | 具备环境感知、长期记忆、自主规划、技能调度与反思纠错的数字实体 | Claude Code、Devin、Google Antigravity | 极高（完全自主） 自主拆解目标、动态组装 Skills、试错与自愈 | “全权包工、保质保量交付完工的项目总监” |
4. 工业级标准 SKILL.md 规范开发模板
在当前主流智能体平台（如 Antigravity、Claude Code、OpenHands）中，标准 Skill 通常以工程目录下的 SKILL.md（包含 YAML Frontmatter 元数据与结构化 Markdown 正文）进行持久化管理：
---
name: code-refactor-expert
description: >-
用于对既有项目源码进行质量扫描、重构优化与单元测试验证的专业技能。
当用户提出代码优化、消除坏味道、提升性能或重构请求时主动激活。
version: 1.2.0
tools:
- run_command
- read_file
- edit_file
---
# 代码重构专家技能 (Code Refactor Expert Skill)
## 1. 角色与任务目标
你是资深软件重构专家。你的核心目标是在**严格保持既有行为逻辑不变（Behavior-Preserving）**的前提下，
消除代码坏味道（Code Smells）、提升模块可读性与可维护性。
## 2. 前置检查 (Pre-Flight Checks)
在修改任何文件前，必须按序执行：
1. 调用 `run_command` 执行全量已有测试用例，确保当前分支为“全绿”基准状态；
2. 若初始测试未能通过，立即终止并提示用户先修复既有缺陷，严禁在破损代码上实施重构。
## 3. 标准操作程序 (SOP 执行流程)
- **步骤 1：坏味道定位**：调用 `read_file` 审查目标文件，提取长函数、过大类或重复逻辑；
- **步骤 2：小步安全修改**：每次仅执行一处微重构（如提取函数、重命名变量），调用 `edit_file`；
- **步骤 3：即时回归验证**：每次修改后立刻重新运行测试，确保退出码为 0；
- **步骤 4：Diff 合理性审计**：比对代码变更，确认无死代码残留与格式破坏。
## 4. 严格限制准则 (Guardrails)
- ❌ 严禁在一次重构中同时引入新的业务特性需求；
- ❌ 严禁删除或跳过已有的单元测试断言；
- ❌ 严禁在未经用户允许的情况下升级核心第三方依赖大版本。
## 5. 交付产出格式
完成任务后，必须输出结构化重构报告：
- **重构类型**：[提取函数 / 多态替代条件 / 参数对象化]
- **变更文件清单**：受影响文件及行号
- **测试通过证据**：测试执行耗时与通过用例数5. Skill 设计与开发的 5 大黄金工程法则
开发高品质的生产级 Skill 时，建议严格践行以下 5 大设计铁律：
法则 1：单一职责与高内聚 (Single Responsibility)
一个 Skill 专注解决一个明确的业务领域问题，避免将互不相关的多重能力杂糅成无法维护的“庞然大物”。
法则 2：幂等性与可恢复 (Idempotency & Reversibility)
Skill 的执行过程应尽量设计为幂等操作；关键修改步骤提供备份或回滚机制，重复执行不会导致脏数据。
法则 3：上下文防膨胀 (Context Budgeting)
Skill 指导词必须精简直接，避免塞入数万字的背景读物；工具回显的大日志必须在中间层截断提炼，避免撑爆模型窗口。
法则 4：参数强类型校验 (Strict Schema Validation)
工具输入输出绝不依赖纯自由文本猜测，必须配置严格的 JSON Schema / Pydantic 模型，非法输入在进入执行层前即刻被拦截。
法则 5：防御性异常处理 (Defensive Graceful Degradation)
执行流程中必须预设“如果工具报错/网络超时该怎么办”的兜底降级方案，给出建设性的错误说明，而不是直接抛出空指针或无限重试。