1. 从提示词堆砌到能力封装SKILL到底解决了什么痛点如果你最近在折腾各类AI Agent工具大概率会频繁撞见SKILL这个词。有人把它翻译成技能有人叫它能力包还有人干脆把它当成高级版的提示词模板。这些理解都不算错但都没说到点子上。我最初接触SKILL的时候也走过弯路以为无非就是把一段精心调教好的提示词存成文件用的时候调用一下。真正上手做了几个之后才发现SKILL的设计哲学跟存提示词完全是两码事——它要解决的是能力复用与渐进式加载这个更底层的问题。先说清楚它要对付的痛点。假设你有一个Agent需要它既能写代码、又能做数据分析、还能处理文档格式转换。最朴素的做法是把所有能力都塞进系统提示词里一次性喂给模型。这么做的问题很明显上下文窗口是有限的你把几十种能力的说明全塞进去光是描述就占掉一大半token真正留给任务本身的空间被严重挤压。更糟的是模型面对一大堆无关的能力描述时注意力会被稀释选错工具、理解偏差的概率直线上升。SKILL的核心思路是按需加载。它把每一种能力封装成一个独立的模块每个模块有自己的元信息名称、描述、触发条件和具体实现指令、脚本、资源文件。Agent在启动时只需要加载所有SKILL的目录——也就是元信息列表知道我有哪些能力可用。当用户提出某个具体需求时Agent先判断这个需求该用哪个SKILL然后才把那个SKILL的完整内容加载进来执行。这就是所谓的渐进式披露Progressive Disclosure信息不是一次性全给你而是分层、分阶段地暴露。打个生活化的比方。这就像你去一家大型图书馆。如果管理员一上来就把全馆几十万册书的完整内容念给你听你根本没法办事。正确的做法是先给你一张分类目录有哪些区域、每个区域大概讲什么你说我要找烹饪类的管理员再带你去烹饪区你翻到具体某一本才看到完整内容。SKILL的元信息就是那张分类目录SKILL的正文就是具体那本书。这个机制带来的好处是连锁的。第一上下文利用率大幅提升因为同一时刻只有被激活的SKILL占用完整空间。第二能力可以独立迭代你改一个SKILL不会影响其他SKILL。第三组合性变强多个SKILL可以像积木一样被Agent按需拼装。第四可维护性提升团队里不同的人可以各自维护自己擅长的SKILL最后汇总成一个能力库。理解了这一层你就能明白为什么Anthropic会把它作为Agent工程化的一个重点方向来推。它不是让你写更长的提示词而是让你用工程化的方式组织能力。这个区别决定了你是在调教一个模型还是在构建一个系统。2. 拆开一个SKILL看内部目录结构、元信息与资源组织光讲概念容易飘我们直接看一个SKILL在文件系统里长什么样。虽然不同工具链的具体约定略有差异但主流实现基本遵循一套相似的目录结构。理解这套结构是你动手写第一个SKILL的前提。2.1 一个典型SKILL的目录骨架一个完整的SKILL通常是一个独立文件夹里面至少包含一个主描述文件常见命名是SKILL.md以及可选的脚本、模板、参考文档等资源。结构大致如下my-skill/ ├── SKILL.md # 主文件元信息 核心指令 ├── scripts/ # 可选可执行脚本 │ └── process.py ├── templates/ # 可选模板文件 │ └── report.md └── references/ # 可选参考资料 └── api-notes.md这里最关键的是SKILL.md。它承担两个职责一是提供元信息让Agent在不加载全文的情况下知道这个SKILL是干什么的二是提供执行指令当SKILL被激活后告诉Agent具体怎么做。2.2 元信息决定SKILL能否被正确调用的第一道关元信息通常写在文件顶部的结构化区块里包含名称、描述、适用场景等字段。很多人写SKILL时最不重视这块觉得随便写写就行结果就是Agent永远选不对SKILL。我踩过这个坑早期写了一个处理Excel的SKILL描述只写了处理表格数据结果Agent遇到CSV文件时也去调它遇到需要做图表时也去调它因为描述太模糊模型无法区分边界。元信息的写法有几个要点。名称要具体excel-data-cleaner比>