Agent Skills 原理及其在中后台页面中的实践

作者：王培杰

一、前言

还没彻底搞清楚Agent skill，GitHub上已经冒出各种看似抽象的skill，「前任Skill」「自己Skill」「永生Skill」... 这个「自己Skill」听着好像有点意思，在座的各位哪个不是六边形战士，生成一个完完全全的自己可能有点困难。但是，💡有没有可能在某一个场景下，我们可以生成一个类似的skill，按照我们的工作流程、习惯做一些事情呢？

在此之前我们需要对agent skill及其特性有一个基础的认识和了解。

二、什么是 Agent Skills

Claude官方定义：每个技能都包含指令、元数据和可选资源（一般是脚本或模版），Claude 会在需要时自动使用这些资源。

"Skills" 这个概念可以追溯到 Anthropic 公司，本是扩展其大模型 Claude 能力的一种模块化功能。简单来说，它为Claude提供了预置的技能也允许用户创建自定义的技能。伴随着这套机制变得成熟，并被社区广泛接受，如今主流的ai编程Agent以及IDE都集成了这一能力。

核心形式：

• 一个 Skill 通常是以一个文件夹的形式存在，里面必须有一个 SKILL.md 文件（包含说明和元数据），可选的其他资源文件（如脚本、示例、参考文档）。
• SKILL.md中必须包含name以及description，这个也被称为元数据，Claude 会在启动时加载这些元数据并将其包含在系统提示符中。
• 简单来说，相当于是给AI模型提供了一本百科全书，AI可以根据任务内容的相关性自动调用书中的经验和内容。我们会比较容易把skill认为是一个"知识包"，其实它的本质 应该是「一个带有边界约束的任务执行单元」。

三、Agent Skills 和 MCP 的区别

我们在用AI应用的时候，还会经常遇到MCP这个概念。它和本文说的Agent Skills有什么区别呢

(关于MCP的详细解释可以看我们往期的文章导航 )

MCP（Model Context Protocol）

我们先来看看MCP是什么吧，Model Context Protocol (MCP) 是由 Anthropic 公司推出的一个开放协议，它标准化了应用程序如何向大型语言模型 (LLM) 提供上下文和工具的方式。

简单而言，Agent 想要完成复杂任务，需要两种能力：

1. 获取知识 ：对应Agent Skills，执行任务流程与获取知识。
2. 执行动作 ：对应MCP，通过mcp这一协议形式调用外部工具。它解决的是下面这些问题：
   1. 工具如何描述
   2. 模型如何调用
   3. 上下文如何传递

总的来说，它们都是AI Agent发展过程中两个非常重要的能力扩展机制

维度	Agent Skills	MCP
本质	任务模板	工具协议
作用	定义任务流程	提供执行能力
内容	Prompt + Workflow + 决策边界	API / Tool
是否执行代码	可以	必须
复杂度	较低	较高
适用场景	知识型、经验型任务	系统集成

那么结合上面的内容，我们可以得出这样的信息：

1. Agent skill可以认为是知识型、经验型任务的沉淀。
2. 适用于复杂程度较低、重复程度较高的工作。
3. Prompt + Workflow + 决策边界的内容形式，让它拥有了约束的越严格，输出的越规范的特性。

四、skill在中后台页面的实践

问题背景

在b端业务中，经常会涉及到中后台页面的开发。其中又可以分为两类需求:

• 存量页面修改：第一类需求是对已有的页面逻辑进行调整。
• 页面新增：第二类的需求是新增菜单、页面进行搭建。

存量页面可能存在一些比较重的历史包袱以及历史的写法可能并不是很规范，需要更精细的设计以及修改。然而新增的页面的功能相对简洁，从0到1更适合根据已有规范进行页面搭建。结合上面提到的skill的特性，我们对skill适用的场景进行判断：

1. 重复度高：同样的流程，每次对不同的业务对象走一遍
2. 复杂度较低：核心是搭架子，不是进行复杂逻辑推理
3. 规范性强：文件放哪里、命名怎么定、组件怎么用，都有明确规定

我们会发现中后台列表页、详情页完美命中这三点！这简直就是天选的适合skill运用的场景！

开发流程拆解

在上文我们知道skill是对领域经验的沉淀、规范化我们的流程，那么首先我们应该对于现有的工作流程进行拆解、去定义出所谓规范的步骤（这里以报货业务中的列表页为例）：

页面功能分析

在报货业务中一个列表页面可以这样拆分：

• 基础的表单筛选项
• 列表表格展示
• 列表额外的功能：新建、导入、其他的业务动作

开发流程分析

日常我接到一个新增页面的需求，涉及到的实际开发流程可以如此概括：

基于上图的流程，可以抽象出下面的工作流：

1. 页面基础信息配置：
   1. 确定页面的path->新建页面目录
   2. 确定常量，枚举存放地址，构造方式
   3. 确定接口存放地址，命名新增接口
2. 页面基础功能搭建：
   1. 分析理解prd的内容、原型，查看接口定义的字段
   2. 修改筛选项配置
   3. 修改表格项配置
3. 页面额外功能、复杂逻辑编写：
   1. 比如表单中一些定制的展示逻辑和校验
   2. 页面tab切换组件、抽屉组件等其他样式

开始实践

创建 skill：从配置到生成

1. 基于上面的内容，我们可以确定初步的skill配置方案：

2. 这里我们通过codex内置的skill creator进行skill的创建：

// ⬇️ 明确目标

根据模板文件，帮我创建一个名称为mars Booking列表页的skill，这个skill用于创建以mars-kit套件(对应项目的组件库包名)为基础组件的列表页面。

// ⬇️ 定义基础配置

你需要根据用户给的需求原型和需求描述、接口信息定义以及用户输入的基础配置信息，如果没有使用默认的基础配置信息，进行list页面的搭建

包含以下配置：

1. 基础配置：
   1. 文件默认存放地址：/mars-booking/xxx
   2. 页面配置地址：app.json
   3. 接口默认存放地址：
   4. 常量枚举存放地址：
2. 模版构建：
   1. 参照参考文件完成fields配置(表单配置)
   2. 参照参考文件完成column配置(表格配置)
   3. 构建过程中不确定的信息，可以进行数据mock
3. 内容输出配置：
   1. 本次新增页面的基础信息
   2. 提示本次模板缺失的内容。

可以通过指定刚刚创建的skill的方式生成模版。同时将产品需求原型图和接口信息（JSON格式）以及基础信息配置的位置一并输入。

生成效果与问题分析

在经过一段时间的等待后，我们先来看下展示效果：

原型图:

skill生成界面：

从效果来看，页面的还原度已经有八九分的程度了。但是仔细观察下还是存在一些问题。

1. **生成时间长，上下文Token占用量大：**生成时间在13分钟左右，我用的codex账号是plus账户，这一次页面直接占用了当前窗口20%的额度，消耗了将近50k的上下文。

2. 代码冗余，写法风格不一致： 额外定义了一些冗余的类型，ai的思考方式更贴近于如何把逻辑写的完善，不贴近项目中实际开发的内容。
3. 组件匹配不够精确，写法不一致： 核心在于ai能够根据提供的prd内容以及接口信息以及mars-kit组件库套件信息，判断筛选项以及表格项（在表格中组件为只读态）匹配对应组件类型，以及写法。说的通俗点，就是正确渲染出字段是对应哪一种组件，输入框或者是下拉框等。

优化方案与实践

那么至此，我们已经找到了问题所在，剩下要做的便是逐一击破：

🚀解决Token占用量大的问题

对于token占用量大的问题，我们可以让codex对刚刚的创建流程进行自我分析，得出有以下几个原因：

1. codex为了了解我们的代码结构和风格，读取的较广范围进的项目页面进行模仿书写。
2. 因为要识别并匹配正确组件类型，codex会多次读取mars-kit文档（可以理解为是我们的组件库文档）。
3. 部分接口缺少信息，做了额外不必要的推断。
4. 未固定skill输出顺序，导致来回思考和重复读取文件

同时它也给我们推荐了一些可优化的内容：

根据上面的内容，我们得到了几个优化方向：

• 我们需要限制codex读取的信息量，对读取文件的数量进行约束。
• 要做到精确的匹配以及提升匹配效率，不能只依赖读取全量文档信息。
• 给出的信息应该明确清晰，不要让codex进行过多的推断。

🚀解决代码冗余，写法风格不一致

这本质上还是我们对于写法的约束不够到位。这里也提供一些约束的技巧。

核心约束的原则：

• 约束越重要，越要写成可执行规则；越容易误解，越要写成「在什么条件下，生成什么」这一形式
• 不要只写"保持简洁"这种比较宽泛没有明确标准的指令，要写"不要创建 XxxQueryParams / XxxListResponse，除非 xxx"。

🚀解决组件匹配效率低的问题

组件匹配不够精确，匹配效率低。这其实可以结合如何减少codex多次读取文档的问题一同思考。

现有的方式是根据prd内容和接口信息再结合组件库文档信息输出页面筛选项和表单项组件结构，本质上也是让Codex 进行"推测性编程"，效率低且稳定性差。那么，能否找到一种方法，让我们可以完全不依赖全量读取组件库文档。

有的，有的兄弟。其实组件库文档中包含的组件信息、方法的描述是超出我们日常使用范围，其次则是我们应该遵循一开始设定的规则，我们的skill应该只做70%-80%可以覆盖基础重复内容的工作，这也是能够规范化、模版化的关键。所以在这里我们可以设置一个匹配规则解决推断不确定、组件构造不符合要求的问题。如何构建匹配规则呢，交给codex，这也是对话构建skill的好处之一。这里采用的是长期维护匹配规则的思想，这可以让我们的模版输出更加确定、规范，可以理解为手动维护了一个平常开发中常用到的组件库。

匹配规则生成的流程如下：

🚀优化后的skill方案

总结上面的问题和解决方案，我们可以抽象为这几个维度：

1. 增强约束：
   1. 只读取5个以内的列表文件进行参考
   2. 参照路由文件的尾部确定path写法
   3. 参考置顶service文件确定接口的写法和命名
   4. 确定构建顺序，避免来回思考、重复读文件
2. 增加匹配规则，减少重复读取组件库文档的上下文
3. 增加对结果的校验，为了避免来回思考导致时间和上下文的增加，我们对输出的内容仅作校验，提示用户对结果进行补充完善，不进行二次修改。

所以根据上面的内容，继续完善我们的skill方案就会有下面的几个阶段。根据这三个层级的划分，补充我们的skill能力。

根据上面的方案对我们的skill进行优化，这一次我们来看下优化后的效果：

与第一版的kill能力进行比较：

维度	第一次生成	本次生成	对比结果
页面展示			生成的页面交互效果差别不是很大
时间	13min23s	5min32s	对比第一次，减少了一半的生成时间
规范性/易用性	1.配置文件信息落的位置不符合预期 2.枚举定义不符合规范 3.接口文件存在冗余定义	基本满足生成即用，仅需少量兼容修改	生成的规范性显著提升
可拓展性	差	skill有清晰的层级划分	方便后期的维护

这次生成用时5min，但完成了平常需要半个小时左右的工作量，而且输出的质量和规范性也兼具了保障。当时看到这个结果后还是有些兴奋的，说明这确实是一个可以实践的场景。

对中后台skill长期建设的思考：

1. **核心原则：Skill 永远专注那 70%-80% 的重复工作。**越想让 Skill 覆盖复杂场景，它的约束就越难维护，边际收益急剧下降。剩下的 20% 我们进行手动地补充。
2. 新的skill层级允许我们长期地经营维护约束层和匹配层，来提升skill的能力，提升输出代码的规范和稳定性，以及匹配的精确性。在开发中遇到和使用的问题，我们也可以在总结之后再反馈到skill设计上。
3. 将列表页skill和详情页skill持续打磨，同时打通两个skill之间的关联性。

五、写在最后

看完上面的内容，大家可能会感觉到步骤会些繁琐。

但实际上，这个skill的创建以及优化过程基本上是和codex聊出来的。 我们更多的是做出要求约束，让其分析自己的工作流程，再提出改进的方案。接着便是根据他给出的方案，提出更进一步的改进意见。

💡你目前的项目中，有哪些重复的工作、场景可以被封装成一个 Skill呢？

如果你也在探索 Skill 开发，或者有什么新奇好用的 Skill ，欢迎在评论区分享交流！