Agent Skill从原理到使用全面解析：从能力封装到测试用例生成实战

Hopitalʕ ᵔᴥᵔ ʔ

340人浏览 · 2026-07-21 17:19:48

Hopitalʕ ᵔᴥᵔ ʔ · 2026-07-21 17:19:48 发布

摘要

在 AI 智能体（Agent）如火如荼发展的今天，"Skill" 这个概念频繁出现在各类技术文章中。但大多数文章只是浅尝辄止地介绍其概念，很少有文章把它的运行机制、设计哲学和实际落地讲透。

本文将从 Agent Skill 的本质出发，由浅入深地带你理解：Skill 与普通 Prompt 究竟有何不同、它的三层渐进式架构如何工作、它与 MCP 和 Tool 的分工边界在哪里，以及最重要的 —— 你如何在实际工作中设计并使用一个 Skill 来解决真实问题。

本文特别适合以下读者：刚开始接触 AI Agent 开发的新手、希望将团队测试经验沉淀为可复用能力的 QA 工程师，以及对 Agent 架构设计感兴趣的技术人员。

一、先理解大图：宏观调用架构

在学习 Skill 的具体细节之前，我们有必要先建立一个全局认知：在一套完整的 AI Agent 系统中，各个角色是如何分工协作的。很多新手容易产生一个误解 —— 以为大模型是 "万能" 的，什么都能做。但实际上，大模型的能力边界非常明确。

1.1 三足鼎立：用户、平台、大模型

一个典型的 Agent 调用链路由以下三个核心角色构成：

角色	职责	类比
用户 (User)	发起任务请求，提供输入和上下文，接收最终输出结果	餐厅的食客 —— 提出需求，享用菜品
平台 (Platform)	管理 Skill 注册与匹配、执行工具调用、调度资源、编排流程、管理对话状态	餐厅的厨房调度系统 —— 接单、分派、协调、出餐
大模型 (LLM)	理解用户意图、进行逻辑推理、生成文本输出、决定何时调用哪个工具，但本身不执行工具	餐厅的主厨 —— 思考菜怎么做，但不亲自切菜洗碗

关键理解：大模型只负责 "思考" 和 "说话"，它不执行任何实际的工具操作。

让我们用一个具体的例子来说明。

1.2 一个请求的完整旅程

假设用户在聊天界面输入：「帮我查一下北京明天天气，如果下雨就提醒我带伞。」下面我们逐步拆解这个请求在三个角色之间是如何流转的：

步骤一：用户输入到达平台 用户在前端界面输入文字后，这段文本被发送到平台（Agent Runtime）。平台接收到消息后，将其追加到当前会话的对话历史中，并为后续处理做准备。
步骤二：平台将消息转发给大模型 平台将完整的对话上下文（包括历史消息、当前输入、可用的 Skill 列表摘要）打包发送给大模型。注意：平台发送的不只是用户消息，而是一个经过组装的 Prompt，里面包含了系统指令、Skill 元数据列表等额外信息。
步骤三：大模型进行逻辑推理 大模型收到输入后开始推理。它识别出用户意图包含两个子任务：(1) 查询天气 (2) 根据结果判断是否需要带伞。大模型发现自己需要一个天气查询工具，于是它输出一个 "工具调用请求"（Tool Call / Function Call），告诉平台：「请帮我调用 get_weather 工具，参数是 city = 北京，date = 明天」。
步骤四：平台执行工具调用 平台收到大模型返回的工具调用指令后，真正去执行 API 请求 —— 调用高德天气 API 或其他天气 API 获取数据。这一步大模型完全不参与，它只是在等待。
步骤五：平台将工具结果回传，大模型继续推理 平台将天气 API 返回的 JSON 数据（例如：{"weather": "中雨", "temperature": "18-25°C"}）再次发送给大模型。大模型基于这个结果进行二次推理，得出结论 "明天会下雨"，然后生成最终回复：「明天北京中雨，气温 18-25°C，建议你出门带伞哦～」
步骤六：平台将最终回复返回给用户 平台接收大模型的最终文本输出，将其展示在用户界面上。一次完整的 Agent 调用就此完成。

核心要点

大模型 = 大脑（思考 + 语言输出）
平台 = 身体（执行动作、调用工具、管理状态）
用户 = 需求的起点和结果的终点

理解了它，你就能理解为什么 Skill 要放在平台层而不是模型层 —— 因为 Skill 本质上是一套 "操作规范"，它指导模型思考，但最终由平台来落地执行。

二、Agent Skill 的本质：不只是"高级Prompt"

很多人第一次接触 Skill 时会觉得："这不就是一个写得更详细的 Prompt 吗？" 这个直觉只对了一半。

2.1 Prompt 与 Skill 的根本区别

普通的 Prompt 和 Agent Skill 之间的差异，类似于 "口头交代任务" 和 "制定 SOP 标准作业流程" 的区别。

对比维度	普通Prompt	Agent Skill
指令方式	一次性发送全部内容给模型	分层披露，按时机逐步加载
结构化程度	自由文本，格式不固定	有严格的 Metadata + Instruction + Resource 结构
可复用性	每次手动复制粘贴或重写	编写一次，团队共享，持续迭代
执行保证	依赖模型自行理解，输出不稳定	提供详细约束和检查点，输出更可控
工具调用	需要在 Prompt 中手动描述工具	内置工具定义和调用规范
Token消耗	全部内容一次性消耗	按需加载，节省 Token
版本管理	散落在各处，难以追踪	可作为代码用 Git 管理

用一个生活中的例子帮助理解：

普通 Prompt 就像给一个实习生口头交代："帮我把这份数据整理一下。" 实习生可能会按自己的理解去做，结果千差万别；

Agent Skill 就像你给实习生一本《数据整理操作手册》，里面包含了：数据格式规范、整理步骤、常见问题处理方式、输出模板。无论哪个实习生拿到这本手册，产出的结果都高度一致。

2.2 Skill 定义了四个关键问题

一个好的 Skill 需要明确回答以下四个问题：

1、如何分析任务？ —— 当用户提出请求时，模型应该从哪些维度来理解这个任务？

2、按什么流程执行？ —— 任务的执行步骤是什么？有没有必须遵循的顺序？

3、输出什么格式？ —— 最终结果应该以什么样的结构呈现？表格？JSON？自然语言？

4、什么时候调用额外资源？ —— 什么条件下需要去查参考文档？什么时候触发脚本执行？

这四个问题的答案，就是 Skill 的核心内容。下面我们深入了解它的结构。

三、Agent Skill 的基础结构：一个最小可用的 Skill 长啥样

从文件组织的角度来看，一个 Skill 就是一个包含配置文件和可选资源文件的文件夹。 最简单的 Skill 只需要一个文件就可以工作。

3.1 目录结构

my-skill/

├── skill.md ← 核心文件：技能定义（Metadata + Instruction）

├── reference/ ← 可选：补充知识文档（.md / .txt）

│ ├── api-docs.md

│ └── style-guide.md

└── scripts/ ← 可选：可执行脚本（.py / .sh / .js）

└── validate.py

skill.md 是 Skill 的 "身份证" 加 "操作手册"。它分为两大部分：Metadata 和 Instruction。

3.2 Metadata：技能的名片

Metadata 部分使用 YAML Frontmatter 格式，位于 skill.md 文件的最顶部，用 --- 包裹：

---

name: code-reviewer

description: 对代码变更进行全面的代码审查，覆盖安全性、性能、可维护性和代码风格

---

Metadata 的作用只有一个：让平台在不需要加载完整 Skill 内容的情况下，快速判断这个 Skill 是否和当前用户的任务相关。

举个例子，当用户在聊天框输入 "帮我 review 一下这个 PR"，平台会遍历所有已注册的 Skill 的 Metadata，发现 code-reviewer 的描述中包含 "代码审查" 关键词，于是判定匹配，触发加载。这个过程非常轻量，几乎不消耗额外的 Token。

设计 Metadata 的小技巧

description 应该包含 2-4 个核心关键词和典型使用场景描述，帮助平台在 "Skill 发现阶段" 准确命中。

好的 description：对代码变更进行全面的代码审查，覆盖安全性、性能、可维护性和代码风格

不好的 description：一个帮助写代码的工具（太模糊，平台不知道什么时候该用它）

3.3 Instruction：技能的灵魂

如果说 Metadata 是名片，那 Instruction 就是详细的产品说明书。它通常包含以下内容：

（1）角色定义

给模型指定一个 "人设"，帮助它进入正确的思维模式。例如：

你是一名拥有 10 年经验的资深软件安全审计专家。你擅长从攻击者的视角审视代码，发现隐藏的安全漏洞。你的审查风格严谨但不刻薄，注重给出可操作的修复建议。

为什么角色定义重要？因为大模型对不同的角色身份会调用不同的知识区域。"资深安全专家" 这个角色会激活模型关于 OWASP Top 10、CWE 漏洞分类、安全最佳实践等知识。如果你不指定角色，模型可能只会做最基础的代码风格检查。

（2）执行流程

定义模型应该按什么步骤来完成任务。以 code-reviewer 为例：

1、读取并理解代码变更的上下文（这个 PR 要解决什么问题？）

2、从以下维度逐一审查：安全性 → 正确性 → 性能 → 可维护性 → 代码风格

3、对每个发现的问题标注严重级别（Critical / Major / Minor / Suggestion）

4、给出具体的问题描述和修复建议代码

5、最后输出一份结构化的审查报告

明确的执行流程就像给模型画了一张 "行军路线图"，有效防止它在执行过程中 "跑偏" 或遗漏关键步骤。

（3）约束条件

告诉模型什么能做、什么不能做。这些约束是 Skill 质量保证的关键：

约束条件：

- 禁止输出没有建设性的纯批评（如"这段代码很烂"）

- 每个问题必须附带具体的修复代码建议

- 如果发现安全漏洞，必须标注为 Critical 并放在报告最前面

- 不要评价代码的作者，只评价代码本身

- 如果你不确定某个问题是否存在，请明确标注"需要人工确认"

（4）输出格式

明确指定输出的结构和格式，确保每次执行的结果风格一致：

输出格式：

## 代码审查报告

### 总览

- 审查文件数：{n}

- Critical：{n} 个

- Major：{n} 个

- Minor：{n} 个

- Suggestion：{n} 个

### Critical 问题

| # | 文件 | 行号 | 问题描述 | 修复建议 |

|--- | ------ | ------ | ---------- | ---------- |

### Major 问题

...

### Minor 问题

...

### 优化建议

...

（5）示例

如果 Skill 的任务比较特殊或复杂，可以在 Instruction 中附带 1-2 个输入输出的示例，帮助模型更好地理解期望的行为模式。示例是提升 Skill 输出质量最直接有效的手段之一。

四、深入运行流程

理解了 Skill 的结构之后，我们来深入探究它的运行时行为。整个过程可以分为三个核心阶段：

4.1 阶段一：Skill 发现（Discovery）

当用户发送一条消息后，平台首先进入 "Skill 匹配" 阶段。这一阶段的目标是：从所有已注册的 Skill 中筛选出和当前任务相关的候选者。

具体的匹配逻辑通常是：

1、平台将用户的消息文本与所有 Skill 的 name 和 description 进行语义匹配（通常使用向量相似度或关键词匹配）

2、根据匹配得分进行排序，选出 Top-K 个最相关的 Skill

3、如果最高得分超过阈值（比如 0.85），自动选择该 Skill

4、如果多个 Skill 得分接近，或得分低于阈值，可以提示用户选择

这个过程非常像你在搜索引擎中输入关键词，搜索引擎返回最相关的网页 —— 只不过这里搜索的对象是 Skill 的描述文本。

举个例子： 用户输入 "帮我检查一下这段 SQL 有没有注入风险"。平台匹配后发现 sql-security-scanner 这个 Skill 的描述中包含 "检测 SQL 注入、数据库安全" 等关键词，得分最高，于是选中它。

4.2 阶段二：Skill 加载（Loading）

Skill 被匹配后，平台将 skill.md 的完整内容加载到当前会话的上下文中。

具体表现为：

1、将 Instruction 拼接到 System Prompt 中，使模型 "化身" 为该 Skill 定义的角色

2、将约束条件和输出格式要求注入到 Prompt 中

3、如果 Skill 定义了可用的 Tool / MCP / Script，将这些工具的定义也注册到当前会话

加载完成后，模型就 "披上" 了该 Skill 的 "战甲"—— 它以 Skill 定义的角色和规则来响应当前会话中的所有后续消息，直到会话结束或切换到其他 Skill。

4.3 阶段三：资源调用（Resource Invocation）

在执行过程中，模型可能会判断当前任务需要额外的知识或需要执行某些操作。这时就会触发第三层 —— 按需加载 Reference 文档或执行 Script 脚本。我们会在下一章详细展开。

时序流程图文字版：

用户发送消息

│

▼

┌─────────────┐

│ Skill 发现 │ ← 用 Metadata 做语义匹配，选中最相关的 Skill

└──────┬──────┘

│

▼

┌─────────────┐

│ Skill 加载 │ ← 将 Instruction 注入 System Prompt，注册工具 └──────┬──────┘

│

▼

┌─────────────┐ 需要更多信息？

│ 模型推理 │────────── 是 ──▶ 加载 Reference（知识文档）

│ + 文本生成 │────────── 是 ──▶ 执行 Script（自动化脚本） └──────┬──────┘

│

▼ 返回结果给用户

五、渐进式披露机制：用最少的 Token 传递最多的信息

渐进式披露（Progressive Disclosure）是 Skill 架构中最精妙的设计之一。它的核心理念是：不要一次性把全部内容塞给模型，而是像剥洋葱一样，一层一层地按需展开。

5.1 为什么需要渐进式披露？

大模型的上下文窗口是有限的（虽然有 200K 甚至更长的窗口，但上下文中信息越多，模型的注意力越分散，输出质量反而可能下降），而且 Token 是计费的。如果一个 Skill 把所有的参考文档、示例代码、历史案例都一次性塞进 Prompt，会造成三个问题：

1、Token 浪费： 假设一个 Skill 附带了 50KB 的参考文档，但当前任务只用到了其中 2KB 的内容，其余 48KB 的 Token 就白白浪费了。

2、注意力稀释： 过多无关信息会干扰模型的判断，就像你让一个人在一本 500 页的手册中找一条规则，他很容易遗漏。

3、响应变慢： Prompt 越长，首 Token 延迟（TTFT）越高，用户体验越差。

渐进式披露就是为解决这些问题而生的。

5.2 三层架构详解

Skill 的内容被组织为三个层级，加载时机各不相同：

层级	内容	加载时机	Token 消耗	典型大小
第一层：Metadata	name + description	始终加载，随 System Prompt 驻留在上下文	极低（约 50-200 Token）	每个 Skill 2-3 行
第二层：Instruction	角色定义、执行流程、约束条件、输出格式	Skill 被匹配选中后加载	中等（约 500-3000 Token）	50-200 行
第三层：Resource	Reference 知识文档、Script 执行脚本	模型判断需要时才按需加载	可变（取决于文档长度）	不限

第一层 ——Metadata：常驻的 "雷达"

Metadata 就像一个始终开机的雷达。它体积极小（每个 Skill 大约几十个 Token），因此平台可以在 System Prompt 中始终携带所有已安装 Skill 的 Metadata 列表，供 Skill 发现阶段使用。对模型来说，这就像眼前始终放着一张 "能力清单"，随时知道自己可以调用哪些能力。

第二层 ——Instruction：被激活的 "作战手册"

当某个 Skill 被匹配选中后，其 Instruction 才被加载到上下文。这相当于 "作战手册" 被翻开 —— 模型开始按照手册中定义的流程、规则和格式来工作。未被选中的 Skill 的 Instruction 不会被加载，因此不会浪费 Token。

第三层 ——Resource："弹药库" 按需取用

在任务执行过程中，模型判断遇到一个只靠 Instruction 无法解决的问题。比如，它需要查询某个 API 的详细参数规范，或者需要运行一个脚本来验证输入。这时第三层才被触发 —— 平台加载指定的 Reference 文档或执行 Script。

5.3 一个递进加载的实例

假设你安装了一个名为 api-doc-generator 的 Skill，它帮助生成 API 文档。当用户在聊天中说 " 帮我给 /user/login 接口写个文档 " 时：

始终层： 平台在 System Prompt 中已经携带了所有 Skill 的 Metadata 列表，包括 api-doc-generator 的 name 和 description。

匹配层： 平台发现用户意图和 api-doc-generator 匹配，加载其 Instruction（约 800 Token），告诉模型："你现在是一个 API 文档撰写专家，按以下模板输出……"

按需层： 模型发现自己不清楚 /user/login 接口的请求参数格式，于是通过 MCP 工具查询了项目的 Swagger 定义文件。拿到参数信息后，模型按照模板生成了格式规范、内容完整的 API 文档。

整个过程对用户来说是无感的 —— 用户只看到最终的文档输出，但背后经历了三个层级的有序展开。

六、Reference 与 Script：Skill 的 "知识库" 和 "工具箱"

Reference 和 Script 是 Skill 的两大辅助资源类型，它们解决不同的问题，使用时机的判断逻辑也不同。

6.1 Reference：当模型需要 "查资料"

Reference 适用于以下场景：你有一些固定不变或变化缓慢的知识，希望模型在特定条件下 "翻阅"。典型的使用场景：

产品需求文档（PRD）：当生成测试用例时，模型需要参考产品的详细功能描述。
公司编码规范：当进行代码审查时，模型需要知道团队约定的命名规则和架构风格。
API 接口文档：当生成集成代码时，模型需要知道接口的 URL、参数类型和返回值结构。
行业法规 / 合规要求：当审查合同时，模型需要对照 GDPR、网络安全法等条款。

Reference 的一个关键特性是：它的内容会进入模型上下文，因此会消耗 Token。 这意味着你需要做好 Reference 的内容管理 —— 只放入真正需要的信息，避免让模型阅读无关的长篇大论。

Reference 设计原则

单一职责：一个 Reference 文件只覆盖一个主题，方便模型按需选择

结构化：使用 Markdown 格式，善用标题、表格、列表，方便模型定位信息

适度拆分：不要把 50 页的文档放在一个文件里，拆成 5-10 个主题文件按需引用

标注版本和更新日期：避免模型使用过时信息

6.2 Script：当模型需要 "动手做"

Script 适用于以下场景：有些操作无法通过纯文本推理完成，需要真正执行一段代码。典型的使用场景：

数据验证脚本：检查用户上传的 CSV 文件是否符合格式要求
代码质量检查：运行 ESLint 或 Pylint 并返回结果
文件格式转换：将 Markdown 转换为 PDF，或将 JSON 转换为 YAML
API 可用性检测：发送一个探测请求确认接口是否在线

Reference 和 Script 的核心区别：

维度	Reference	Script
作用	提供知识（"知道什么"）	执行动作（"能做什么"）
加载方式	文本内容进入模型上下文	代码在平台环境中执行
Token 消耗	会消耗 Token	不消耗 Token（只返回执行结果）
适用内容	静态知识文档、规范、指南	需要实际运行才能得到结果的操作
安全考量	无执行风险	需沙箱隔离，脚本不应有破坏性操作

6.3 模型如何判断该调用哪个资源？

这是很多新手感到困惑的地方。答案是：在 Skill 的 Instruction 中提前写好判断规则。 例如，在一个 test-case-generator 的 Skill 中，Instruction 可能这样写：

资源调用规则：

- 如果用户提到了具体的功能模块名称，但未提供详细需求描述：

→ 先查看 reference/product-spec.md 获取该模块的需求详情

- 如果用户要求生成的测试用例需要包含 API 层面的测试：

→ 先查看 reference/api-docs/ 目录下的接口文档

- 如果用户要求验证生成的测试用例格式是否正确：

→ 执行 script/validate_testcase.py 进行格式校验

模型在推理时会读取这些规则，当发现当前情况满足某条规则的触发条件时，就会输出一个资源调用指令，由平台去执行实际的加载或运行操作。

七、Skill 与 MCP 的关系：各司其职，协同作战

MCP（Model Context Protocol）是 Anthropic 提出的一个开放协议，旨在标准化 AI 模型与外部数据源 / 工具之间的连接方式。很多人会混淆 MCP 和 Skill 的职责边界，这里我们做一个清晰区分。

7.1 一句话区分

MCP 解决 "数据从哪里来" 的问题；
Skill 解决 "业务怎么做" 的问题。

举个例子对比：

MCP Server 就像一个 "快递员"—— 它负责从外部系统（数据库、API、文件系统）把数据取回来，交到模型手上。
Skill 就像一个 "老师傅"—— 它告诉模型拿到数据之后该怎么处理，按什么流程，出什么结果。

7.2 完整的协作链路

场景： 财务人员说 "帮我生成上季度的销售报表，并标注出环比下降超过 10% 的产品。"

1、Skill 发现 → 匹配到 report-generator Skill

2、Skill 加载 → 模型获得 "报表生成专家" 的角色和输出模板

3、模型判断需要数据 → 触发 MCP 工具调用

4、MCP Server 执行 → 从公司数据库查询上季度销售数据，返回 JSON

5、模型接收数据 → 按照Skill定义的规则进行分析：

计算环比增长率
筛选下降超过 10% 的产品
按模板格式组织报表

6、模型输出 → 格式规范的销售分析报表

7、平台展示 → 将报表呈现给用户，并提供 PDF 导出选项

组件	在这一步做了什么
Skill	定义报表的格式模板、数据筛选规则（环比下降 10%）、分析维度
MCP	连接公司数据库，执行 SQL 查询，返回原始销售数据
大模型	理解需求、计算指标、筛选数据、生成报告文字
平台	协调 Skill 加载和 MCP 调用、管理会话上下文、展示结果
Tool	提供 PDF 导出等最终的文件生成功能

7.3 为什么不能混为一谈？

如果把 MCP 和 Skill 的职责混在一起，会带来以下问题：

1、耦合度高： 数据获取逻辑和业务处理逻辑绑定，修改任何一个都会影响另一个

2、复用性差： 同一个数据源（如用户数据库）可能需要被多个 Skill 使用，如果数据获取逻辑写死在 Skill 里，就会造成大量重复

3、维护困难： 当数据库的表结构变化时，需要修改所有引用了该数据库的 Skill

正确的做法是：MCP Server 作为独立的数据连接层，可以被任意 Skill 复用；Skill 聚焦于业务规则和处理逻辑，不关心数据的物理来源。

八、实战：构建一个 test-case-generator Skill

理论说再多，不如动手做一个。下面我们以 "测试用例生成" 这个高频需求为例，从零构建一个完整的 Skill。

8.1 痛点分析

在产品迭代过程中，测试团队面临几个普遍痛点：

维度遗漏： 依赖个人经验编写测试用例，容易遗漏异常场景、边界条件和安全测试
格式不统一： 不同测试工程师输出的用例格式各异，评审和归档成本高
经验难复用： 资深测试工程师的思考方式无法沉淀，新人上手慢
效率瓶颈： 手动编写用例耗时，尤其是在需求频繁变更时

一个好的 test-case-generator Skill 可以同时解决这四个问题。

8.2 Skill 完整设计

（1）目录结构

test-case-generator/

├── skill.md ← Skill 核心定义

├── reference/

│ ├── test-dimensions.md ← 测试维度详解（功能/异常/边界/兼容/性能/安全）

│ └── priority-rules.md ← 优先级判定规则详解

└── scripts/

└── validate_cases.py ← 测试用例格式校验脚本

（2）skill.md 完整内容

---
name: test-case-generator
description: 根据软件功能需求，自动生成覆盖功能、异常、边界、兼容、性能、安全六大维度的完整测试用例，支持标准表格格式输出
---
## 角色定义
你是一名拥有 12 年经验的资深软件测试架构师。你曾在多家互联网大厂负责核心业务
的测试策略设计。你擅长从用户视角和攻击者视角双向审视功能，确保不遗漏任何关键
测试场景。你的测试设计风格是：严谨但不冗余，覆盖全面但聚焦核心风险。

## 执行流程
### 第一步：需求理解
- 仔细阅读用户提供的功能需求描述
- 识别核心功能点、涉及的角色/权限、输入输出边界
- 如果需求描述不清晰，先向用户提问澄清，不要猜测

### 第二步：多维度测试点拆解
从以下六个维度系统性地设计测试点：
#### 2.1 功能测试（Functional Testing）
- 正常流程：用户按照预期路径完成操作的 Happy Path
- 功能组合：多个功能同时使用或连续使用时的交互行为
- 状态转换：功能在不同状态之间的切换（如登录→超时→重登录）

#### 2.2 异常测试（Exception Testing）
- 错误输入：非法字符、超长字符串、空字符串、特殊符号（如 SQL 注入 Payload）
- 网络异常：超时、断网重连、弱网环境下的行为
- 权限异常：低权限用户尝试执行高权限操作
- 数据异常：并发写入冲突、脏数据、数据不一致

#### 2.3 边界测试（Boundary Testing）
- 数值边界：最小值-1、最小值、最小值+1、最大值-1、最大值、最大值+1
- 集合边界：空列表、单元素、满容量、超容量
- 时间边界：开始时间=结束时间、跨天、跨月、跨年、闰年
- 字符边界：0字符、1字符、最大长度-1、最大长度、最大长度+1、Emoji

#### 2.4 兼容性测试（Compatibility Testing）
- 浏览器/设备：Chrome、Safari、Firefox 最新版 + 上一个主要版本
- 操作系统：Windows、macOS、iOS、Android
- 分辨率：1920×1080、1366×768、375×667（移动端）
- 数据兼容：旧版本创建的数据在新版本中能否正常使用

#### 2.5 性能测试（Performance Testing）
- 响应时间：单用户操作的首屏加载时间、API 响应时间
- 并发压力：多用户同时操作的竞态条件和数据一致性
- 资源消耗：CPU、内存、网络流量在操作前后的变化

#### 2.6 安全测试（Security Testing）
- 权限控制：水平越权（同角色访问他人数据）、垂直越权（低权限调用高权限接口）
- 数据安全：敏感信息是否明文传输/存储、日志中是否打印了密码/Token
- 注入攻击：SQL 注入、XSS、命令注入

### 第三步：优先级判定
根据以下规则标记优先级：
- P0（阻塞级）：核心功能不可用、数据丢失、安全漏洞 —— 必测，失败则阻塞发版
- P1（重要级）：主要功能异常、边界处理缺失 —— 必测，影响用户体验
- P2（一般级）：次要功能问题、兼容性问题、UI瑕疵 —— 建议修复
- P3（建议级）：优化建议、非常规场景 —— 可排入后续迭代

### 第四步：格式校验
生成用例后，使用 script/validate_cases.py 进行格式校验，确保：
- 所有必填字段均已填写
- 优先级标签合法（仅 P0/P1/P2/P3）
- 编号唯一且连续

## 约束条件
- 禁止猜测需求中没有提到的功能行为——不确定就问
- 禁止跳过异常和边界测试维度——每个功能都必须覆盖
- 禁止生成重复或用例内容高度相似的测试用例
- 每条测试用例的操作步骤必须具体可执行，不能用"测试XX功能"搪塞
- 如果用户需求涉及多个角色，必须为每个角色分别设计权限相关的测试用例
- 安全测试中如果发现潜在的严重漏洞，用【安全告警】标记并在用例表格前单独列出

## 输出格式
### 需求理解
（简要重述你对需求的理解，确认理解是否正确）
### 【安全告警】（如果有）
| 告警 | 风险描述 | 严重程度 |
### 测试用例总览
- 总计：{n} 条
- P0：{n} 条 / P1：{n} 条 / P2：{n} 条 / P3：{n} 条
- 覆盖维度：功能 {n} / 异常 {n} / 边界 {n} / 兼容 {n} / 性能 {n} / 安全 {n}
### 详细用例
| 编号 | 测试维度 | 测试点 | 前置条件 | 操作步骤 | 预期结果 | 优先级 |

## 示例
### 输入
"用户登录功能：用户输入邮箱和密码，点击登录按钮后跳转到首页。"
### 输出（摘录）
| 编号 | 测试维度 | 测试点 | 操作步骤 | 预期结果 | 优先级 |
|------|----------|--------|----------|----------|--------|
| TC001 | 功能 | 正确邮箱+正确密码登录 | 输入正确凭证，点击登录 | 登录成功，跳转首页 | P0 |
| TC002 | 异常 | SQL注入测试 | 邮箱输入 ' OR '1'='1 | 登录失败，不执行注入 | P0 |
| TC003 | 边界 | 密码最小值-1 | 密码输入7位（要求最少8位） | 提示"密码至少8位" | P1 |
| TC004 | 边界 | 密码最大值+1 | 密码输入65位（限制64位） | 提示"密码不能超过64位" | P2 |
| TC005 | 安全 | 暴力破解防护 | 连续输错密码6次 | 第6次后账号临时锁定30分钟 | P0 |

8.3 配套 Reference 文档示例

（1）reference/test-dimensions.md 节选

# 测试维度详解
## 功能测试详细指南
### 正常流程（Happy Path）
正常流程是最基本、最核心的测试场景。设计原则：
- 覆盖用户完成目标的最短路径
- 每个步骤使用最典型的输入值
- 验证每个步骤的预期中间状态

### 功能组合
当系统存在多个功能模块时，需要测试它们的交互：
- 功能A执行过程中触发功能B → 验证状态一致性
- 功能A的结果作为功能B的输入 → 验证数据传递正确性
- 同时执行功能A和功能B → 验证无竞态条件

## 边界测试详细指南
### 等价类划分法
将输入域划分为若干等价类，从每个类中选取代表值：
- 有效等价类：符合需求规范的输入集合
- 无效等价类：不符合需求规范的输入集合
示例（年龄输入框，范围 1-150）：
- 有效等价类：1-150 之间任意整数 → 选 25, 75, 150
- 无效等价类1：0 及负数 → 选 -1, 0
- 无效等价类2：大于 150 → 选 151, 9999
- 无效等价类3：非整数 → 选 3.14, "abc"

### 边界值分析法
边界是缺陷的高发区。对于范围 [min, max] 的输入：
- min-1（刚好低于下限）
- min（下限本身）
- min+1（刚好高于下限）
- max-1（刚好低于上限）
- max（上限本身）
- max+1（刚好高于上限）

（2）scripts/validate_cases.py 示例

#!/usr/bin/env python3
"""测试用例格式校验脚本：验证生成的测试用例是否符合规范"""
import sys
import json
def validate_test_cases(cases: list[dict]) -> dict:
required_fields = ['编号', '测试维度', '测试点', '前置条件', '操作步骤', '预期结果', '优先级']
valid_priorities = {'P0', 'P1', 'P2', 'P3'}
errors = []
ids = []
for i, case in enumerate(cases):
# 检查必填字段
for field in required_fields:
if not case.get(field, '').strip():
errors.append(f"第{i+1}条用例缺少必填字段：{field}")
# 检查优先级合法性
priority = case.get('优先级', '').strip()
if priority and priority not in valid_priorities:
errors.append(f"第{i+1}条用例优先级非法：{priority}（仅允许 P0/P1/P2/P3）")
# 收集编号
case_id = case.get('编号', '').strip()
if case_id:
ids.append(case_id)
# 检查编号唯一性
if len(ids) != len(set(ids)):
errors.append("存在重复的用例编号")
return {
'valid': len(errors) == 0,
'error_count': len(errors),
'errors': errors
}
if __name__ == '__main__':
data = json.loads(sys.stdin.read())
result = validate_test_cases(data['test_cases'])
print(json.dumps(result, ensure_ascii=False, indent=2))
sys.exit(0 if result['valid'] else 1)

九、Agent 调用 Skill 完整示例

现在让我们完整走一遍 Agent 调用 test-case-generator Skill 的真实流程。

9.1 用户输入

用户输入：
"请为'无人机智能跟随功能'生成完整的测试用例。"
功能说明：
1. 用户在 App 上框选一个目标（人/车/动物）
2. 无人机自动锁定目标并保持一定距离跟随
3. 跟随过程中如果目标暂时被遮挡（如经过树后），无人机悬停等待目标重新出现
4. 如果目标消失超过 30 秒，无人机自动返航
5. 跟随速度根据目标移动速度自动调节，最高 60km/h
6. 支持手动取消跟随（点击 App 取消按钮或遥控器急停键）
7. 电池电量低于 15% 时自动终止跟随并返航"

9.2 Agent 执行全过程

第一步：Skill 发现（平台执行） 平台收到用户消息后，提取核心语义 "生成测试用例"，与所有已注册 Skill 的 Metadata 做匹配。test-case-generator 的描述 "根据软件功能需求，自动生成覆盖功能、异常、边界、兼容、性能、安全六大维度的完整测试用例" 得分最高，匹配成功。

第二步：Skill 加载（平台执行） 平台将 test-case-generator/skill.md 的完整内容注入 System Prompt，同时注册了以下资源：reference/test-dimensions.md（测试维度参考）、reference/priority-rules.md（优先级规则）、script/validate_cases.py（格式校验脚本）

第三步：需求理解（模型执行） 模型按照 Skill 定义的 "第一步：需求理解" 开始分析，输出：

## 需求理解
无人机智能跟随功能的核心是一个目标追踪系统，包含以下关键要素：
- 目标选择方式：App 框选（人/车/动物三类目标）
- 跟随行为：锁定 → 追踪 → 距离保持 → 速度适配
- 异常处理：短暂遮挡悬停 → 长期消失返航 → 低电量返航
- 取消方式：App 取消按钮 + 遥控器急停键（两个独立通道）
- 涉及角色：普通用户（框选跟随）、设备（自动飞控）
请确认以上理解是否正确？

第四步：多维度测试点设计（模型执行） 模型加载了 reference/test-dimensions.md 作为参考，按照六大维度系统性地设计了测试点：

功能测试： 正常跟随流程、目标类型切换（人→车→动物）、取消跟随（两个通道分别测试）、自动返航、速度自适应

异常测试： 目标框选后立即取消、跟随中 App 崩溃重启、GPS 信号丢失、遥控器断连、目标剧烈移动

边界测试： 最慢速度（目标静止）、最高速度（60km/h）、遮挡时间边界（29 秒 / 30 秒 / 31 秒）、电量边界（16%/15%/14%）

兼容性测试： iOS/Android App、不同无人机固件版本、不同手机屏幕尺寸

性能测试： 从框选到开始跟随的延迟、跟随过程中的图传延迟、最高速跟随时画面稳定性

安全测试： 未经授权获取无人机控制权、App 崩溃时物理急停键是否仍可用

第五步：格式化输出 + 优先级标注（模型执行） 模型按照 Skill 规定的表格格式组织输出，自动标注优先级：核心跟随功能 → P0，遮挡恢复 → P1，边界值 → P2……

第六步：格式校验（平台执行 Script） 模型生成用例后，平台自动调用 script/validate_cases.py，将用例数据以 JSON 格式传入脚本。脚本检查所有必填字段、优先级标签合法性、编号唯一性后，返回校验通过。

第七步：最终输出（平台展示） 平台将经过校验的完整测试用例表格呈现给用户。整个过程对用户来说，就是 "输入需求 → 等待片刻 → 拿到一份高质量的多维度测试用例"，用户甚至不需要知道背后经历了 Skill 加载、Reference 查阅、Script 执行这些步骤。

9.3 生成结果示例（摘录）

编号	维度	测试点	操作步骤	预期结果	优先级
TC001	功能	框选行人并启动跟随	1.App 画面中框选行人 2. 点击 "开始跟随"	无人机锁定目标，保持 5-10m 距离跟随	P0
TC002	功能	跟随中手动取消（App 按钮）	点击 App"取消跟随" 按钮	无人机停止跟随并悬停	P0
TC003	功能	跟随中急停（遥控器）	按下遥控器急停键	无人机立即悬停，停止跟随	P0
TC004	异常	目标被短暂遮挡（<30s）	目标经过树后短暂消失	无人机悬停等待，目标出现后恢复跟随	P1
TC005	异常	目标消失超过 30 秒	目标进入建筑后消失，等待 30s	无人机触发自动返航	P0
TC006	边界	目标静止（速度 = 0）	框选静止目标，启动跟随	无人机悬停于目标上方保持位置	P1
TC007	边界	目标最高速度 60km/h	目标驾车加速至 60km/h	无人机以 60km/h 跟随，不丢失目标	P1
TC008	边界	电量 15% 边界测试	启动跟随，飞行至电量降到 15%	电量 15% 时触发告警并自动返航	P0
TC009	边界	电量 16%（高于阈值）	电量 16% 时启动跟随	正常跟随，不触发返航	P1
TC010	兼容	Android 设备兼容	在 Android 14 设备上执行 TC001	功能正常，界面布局无异常	P1
TC011	性能	跟随启动延迟	点击开始跟随，用秒表计时	从点击到开始移动 < 1 秒	P2
TC012	安全	未授权访问测试	他人手机尝试连接并调用跟随 API	连接被拒绝，提示未授权	P0
TC013	安全	App 崩溃时急停可用性	模拟 App Crash，按下遥控器急停键	急停键独立于 App 工作，无人机立即停止	P0

十、Skill 的核心价值：不仅仅是 "省时间"

很多人把 Skill 的价值简单概括为 "提高效率、节省时间"。但它的真正价值远不止于此。

10.1 提升覆盖率：从 "凭经验" 到 "靠体系"

没有 Skill 的情况下，测试工程师靠个人记忆和经验来覆盖测试维度。一个工作 3 年的工程师和一个工作 10 年的工程师，产出的测试方案质量可能天差地别。而 test-case-generator Skill 在 Instruction 中硬编码了六大测试维度，每一维度下还有细分的子项（如边界测试中的数值边界、集合边界、时间边界、字符边界）。这意味着：即使是第一天入职的新人，使用这个 Skill 生成的测试用例，也不会遗漏任何一个关键维度。

10.2 提升一致性：让 "标准" 真正落地

很多公司都有测试用例编写规范，但实际执行中往往 "一人一个样"。因为规范文档是 "静态的"—— 它被写在 Wiki 里，很少有人主动查阅。 而 Skill 将规范 "动态化" 了 —— 每次生成测试用例时，模型都会严格按照 Skill 中定义的格式和规则来输出。规范不再是 "建议"，而是 "强制执行"。

10.3 降低经验门槛：让新人也能接近专家水平

资深测试工程师的 "第六感"—— 为什么他们总能想到边界条件、总能猜到哪个地方容易出 bug？这种经验不是玄学，而是有规律可循的。Skill 做的事情，本质上就是把这种 "隐性经验" 转化为 "显性规则"。当这些规则被写入 Skill 的 Instruction 后，任何调用这个 Skill 的人都能享受到同等级别的测试思维加成。

10.4 持续进化：Skill 是可以 "生长" 的

Skill 不是一次性产物。团队可以在使用过程中不断迭代：

发现新的常见缺陷模式？ → 补充到 Instruction 中
新的测试维度被业界认可？ → 更新 reference 目录的参考文档
校验规则需要增强？ → 修改 script 的校验逻辑
所有团队成员使用同一个 Skill → 所有人的经验都可以沉淀到一个 Skill 中

经过半年的迭代，这个 Skill 所蕴含的测试智慧可能远超团队中任何一个个体成员。这才是 Skill 最深层的价值。

十一、总结与展望

11.1 回顾：五个核心认知

本文从宏观到微观、从理论到实战，带你完整理解了 Agent Skill。让我们回顾五个最核心的认知：

认知一：用户 - 平台 - 大模型的三足架构

用户发起需求，平台负责调度和执行，大模型负责推理和生成。大模型只动脑不动手，所有实际的工具调用、数据获取都由平台完成。理解这个分工，是理解 Agent 系统设计的基石。

认知二：Skill ≠ 高级 Prompt

Skill 是一套结构化的任务规范。它用渐进式披露机制解决 Token 浪费问题，用分层架构解决复用性问题，用规则和约束解决输出不稳定问题。

认知三：渐进式披露是 Skill 设计的核心智慧

Metadata 常驻 → Instruction 按需加载 → Resource 条件触发。这种设计让 Skill 同时实现了 "信息充分" 和 "Token 节约"。

认知四：MCP 取数据，Skill 定流程，Tool 做执行

三者各司其职。MCP 解决 "连得上"，Skill 解决 "做得好"，Tool 解决 "做得成"。不要混为一谈。

认知五：Skill 的真正价值在于经验沉淀

效率提升只是短期的红利。长期的、真正不可替代的价值在于：将个体的隐性经验转化为团队的显性资产，让经验可以复制、可以迭代、可以传承。

11.2 展望：未来的 AI 应用架构

Agent Skill 已经从一个 "锦上添花的可选功能" 逐渐成为 AI Agent 工程化的标配组件。展望未来，我们认为智能应用的架构将收敛为：大模型 + Skill + MCP + Tool + 数据

每个组件各司其职，协同构建出真正可靠、可维护、可进化的智能系统：

组件	职责	类比
大模型	意图理解、逻辑推理、文本生成	大脑
Skill	业务能力封装、流程规范、输出模板	作战手册 / SOP
MCP	外部数据源和服务的标准化连接	神经系统（感知外部世界）
Tool	原子化的具体操作执行（计算、文件操作、API 调用）	手和脚
数据	业务知识库、历史案例、行业规范	记忆和经验