---
author: Peter Pang
date: '2026-01-22'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=0HIlhRl38QA
speaker: Peter Pang
tags:
  - prompt-engineering
  - agent-skills
  - dependency-management
  - token-control
  - software-engineering-paradigm
title: 'AI Agent Skills: Prompt Engineering 的工程化飞跃与未来'
summary: 演讲者锐评AI Agent Skills，将其类比为包管理器，强调其本地运行、可控性和对提示词工程的革新，并预测了未来发展。
insight: ''
draft: true
series: ''
category: software-development
area: tech-engineering
project: []
people: []
companies_orgs:
  - OpenAI
  - Google
  - Anthropic
products_models:
  - GPT
  - Gemini
  - Claude
media_books: []
status: evergreen
---
### Agent Skill 概念解析
我将认真锐评一下**skill**（技能）这个概念。众所周知，作为业界的三巨头，**OpenAI**最擅长炒作，**Google**最擅长算法，而**Anthropic**最擅长开发。自从2024年底发布了**MCP**（Meta-Cognitive Programming）标准后，2025年底，**Anthropic**又带来了**agent skill**（智能体技能）这一新概念。skill一经发布，业界便知晓AI开发即将迎来新一轮升级。

其实，skill这一概念本身并无颠覆性的重大突破，甚至可以说它是一种返璞归真的方式。它旨在解决一个非常现实的问题：如何用最少的**token**（令牌）处理最多的事务。其核心在于将提示词（prompt）进行拆解，根据能力范围进行打包，彼此之间保留指针引用，然后实时按需导入，从而实现动态的提示词构建。

### 依赖管理模式
这正是**skill**概念最有潜力成功的关键所在。它让我想起了**maven**、**npm**、**crate**、**pip**等大家熟悉的**依赖管理**（dependency management）工具。尽管我们可能会批评当前一些技术框架过度依赖依赖，一个简单的“hello world”应用就可能安装上千个依赖，但不可否认的是，正是这种**积木结构**（building block structure）带来了无穷的可能性。

### 集成简便与安全
从技术层面而言，**skill**相较于大模型和**MCP**，其集成到工作流的难度更低、可接受度也更高。以大模型为例，即使是频繁更新的**VSCode**，至今仍需依赖第三方插件来支持不同的模型。而**MCP**的整合则更为复杂繁琐，尤其是在经历了去年一系列**MCP安全漏洞事故**后，现在稍微专业的平台都会对**MCP**的接入增加多层验证机制。我曾尝试将**AWS**上的一个AI服务接入**GitHub**的**MCP**，从查找资料到生成各种密钥，耗时近一个小时才完成。

相比之下，**skill**以一种最简洁的方式解决了这些问题：它支持**完全本地运行**。所有代码存储在本地，所有指令也在本地执行。一切都是公开透明的，没有跨网络通信，自然也就避免了**RPC漏洞**（Remote Procedure Call vulnerability）等安全问题。

### 实践：宁滥勿缺
我认为，**skill**的出现标志着**prompt engineering**（提示词工程）首次真正具备了“工程”的属性。在此之前，我们对提示词的使用更像是进行实验：由于尚未完全摸清大模型这一“生物”的特性，我们只能对其进行零散的调整，观察其反应。而如今，随着大模型对**function call**（函数调用）等基本机制的稳定支持，**skill**这种有结构、有规模的软件工程范式才得以真正普及。

这对我这样的软件工程师而言，是一个重要的契机。在大模型迭代的**上半场**，主角是算法科学家，他们提出的概念我们往往难以理解，只能作为用户。而现在进入应用落地的**下半场**，软件工程的理念将发挥更大作用，我们这些软件工程师将成为懂行者。

为了深入了解当前的**skill生态**，我搜集了互联网上大约300个开源skill，涵盖了文件处理、数据分析、网页生成、安全检测、项目管理等领域，并将它们全部安装到了IDE中。由于目前尚无类似**npm**的包管理框架，这些skill需要一个个导入，过程略显繁琐。之所以选择将所有skill一股脑地安装进去，而非按需选用，是因为我们永远无法预知何时会用到何种skill。例如，在让AI完成一个完整数据可视化项目时，其设计方案可能涉及处理**CSV**数据源、使用**D3.js**可视化框架，以及用**Playwright**进行前端测试。正因我预先安装了对应skill，AI在系统提示词中发现这些需求后，便能直接导入相关的提示词和参考代码。

同理，即使后续AI方案要求使用**Excel**作为数据源、**Echarts**作为可视化框架，或采用**property based testing**进行测试，我也无需担忧，因为这些skill也早已备好。这种**按需导入**（on-demand import）的机制，决定了我们在安装skill时，应遵循“**宁滥勿缺**”（better safe than sorry）的原则。能找到多少就安装多少，找不到的就自己创造，因为构建skill比想象中更容易——它甚至可以是一个只有几句话的Markdown文档，在此基础上再逐步拓展功能、增加可执行脚本和补充案例。

### Skill 构建与迭代
以我近期开发的用于分析CVE漏洞和相关事故的skill为例。起初，它的功能非常简单：找到官方报告，提取漏洞代码及官方解释，最后生成总结。随后，我逐步补充了更详细的拆解要求，并在让AI进行分析时，明确了需要关注的要点，引导其做出更有针对性的解读。再后来，我还为一些步骤增加了执行脚本，例如在收集官方报告时，我指定了特定的爬取网页脚本，以确保数据获取的准确性。拥有了这个漏洞分析skill后，我在日常询问AI技术问题时，它便能提供更专业的回答，而非像之前那样仅给出笼统的漏洞分析。

### Token 可控的价值
作为一个实用主义者，在我看来，**skill**最大的价值在于赋予了输入**token**数量的**可控性**。在没有skill的情况下，我们几乎无法控制AI会花费多少token、爬取多少外部网页、导入多少参考代码才能完成一个小动作。但在skill的加持下，我们能够精确控制每一个输入的字符。如果想要更细致的操作，可以提供更多提示；若希望输出更稳定，则可以增加更多参考案例，反之亦然。同时，我们也能在不影响输出效果的前提下，适当地削减提示词，以减轻token的负担。

近期在粉丝群里，关于“token额度又没了”、“基础套餐完全不够用”的抱怨最多。我自己还好，通常不购买基础套餐，而是专注于利用免费资源，因为大模型（如**GPT**、**Gemini**、**Claude**）的运行成本高昂，每一个都消耗大量token，我甚至怀疑它们是否是故意的。

基于此，我大胆推测，未来**skill**的发展可能会效仿大模型，出现不同等级的分类，例如更节省token的**Lite Skill**，提示词更详细的**Pro Skill**，以及预算充足的**Max Skill**等。而像我这样的“羊毛党”，则会继续使用免费的IDE，运行最经济的Lite Skill，做一个勤俭持家的好男人。