Agent开发困境与转变
传统的Agent在使用时需要海量的的提示词，内容模式则是依赖于工具的API、文档、规则将所有的内容都塞进单个Prompt，并形成一个较长的上下文。但是这样会带来几个核心的问题：
- Token爆炸增加成本高 ：每次请求都携带完整上下文，
API的调用费用呈指数上升 - 模型幻觉风险加剧 ：因提供的上下文超长，信息
Agent的信息量过载导致模型的注意力过于分散，输出质量下降 - 维护困难 ：经常会为
Agent提供上千行代码已满足需求，不但版本不好控制，而且面对多人协作时会频繁产生冲突
然而随着近些年Agent的不断发展，Agent Skills模块化的方法逐渐进入到大家的视野，Agent Skills是由AI研究公司Anthropic在2025年初推出的概念，旨在将专业知识打包为标准化程序，让通用智能体（Agent）具备真实世界的专业能力。该模式通常被定义为原子化的单一能力封装，用于让Agent能够与外部工具和数据交互，属于一种开放的标准化协议。
Agent Skills的方案提出后在整体开发上出了解决上述问题：
- 上下文纯净 ：
Agent只需要加载必要的技能信息，在整体Token消耗上有明显的降低 - 降低幻觉 ：由于上下文的降低，
Agent可以更精准的匹配技能，对输出的准确性有显著提升 - 支持协作 ：
Git具有友好的版本控制，多人协作开发无冲突
Skill剖析
Skill使用的是文件夹即系统的架构思想，通过标准化的文件组织形式推展Agent的专业能力，在开发或使用Skill时，我们需要给Agent准备技能锦囊，让Agent可以更好的当前Skill的能力。
一个标准的Skill需要包含如下的目录结果，每个目录都有其对应的职责：
- Skill ：技能开发的根目录
- SKILL.md ：为
markdown编写的技能说明书，里面包含了对当前skill的描述，以及所需要使用的参数，和对应的使用场景 - scripts/ ：存放
python代码、脚本代码或工具函数，Agent在执行阶段可通过命令直接调用。 - references/ :存放
SKILL.md中无需立即加载的详细文档（如API规范、公司政策、完整指南），帮助控制初始加载的Token量。Agent在执行阶段，会主动按需读取这些文件的内容 - assets/ :存放不加载到上下文中的静态文件（如图标、PPT/代码模板），
Agent不会主动阅读它们，而是直接复制其内容作为最终输出的一部分
- SKILL.md ：为
我们对Skill的包含的基础目录结构有了一定了解后，通过一个案例了解一下Agent运行时Skill的协作过程：
假设存在一个用于处理PDF的Skill，其执行流程如下：
- 第1步：发现阶段。系统启动，只加载
SKILL.md元数据，Agent知道有一个PDF编辑器可用。 - 第2步：激活阶段。当用户请求旋转PDF ，
Agent根据匹配的描述激活该Skill，加载完整的SKILL.md指令。 - 第3步：执行阶段。
Agent依据SKILL.md指令逐步操作：- 根据指令，运行
scripts/rotate_pdf.py来处理文件。 - 运行脚本时，若遇到复杂设置，会主动读取
references/pdf_api.md查阅指南。 - 最终，它将
assets/目录里的模板文件report_template.html与处理结果结合，生成最终报告。
- 根据指令，运行
说了这么多只是了解Skill的基本原理，对于Skill是通过什么机制防止Skill自身变成与prompt一样，避免占用大模型海量上下文以及产生严重的幻觉的呢？Agent Skills是如何解决这一系列的问题的？我们带着这些问题一起往下看。
Skill的三层渐进式策略
Skills通过把信息进行了三次分层，分别是元数据层、指令主体层和扩展资源层。为了直观的理解Skills分层机制，可以把这三层分别理解为发现、激活与执行 ，通过这种按需加载的机制，让Agent避免了传统Prompt带来的信息过载问题。
动态上下文加载
发现(Discovery) - 元数据层
在上举例时细心的话可以发现，示例中提到了元数据 ，每个Skill都会有一份元数据，元数据是写在SKILL.md中第一行中的内容，元数据中包含了Skill如下信息：
- 名称：
Skill的名字 - 描述：描述
Skill的使用场景 - 标签：协助
Agent辅助检索与路由，进一步提升按需加载的效率和准确性
因为元数据的内容是非常少的，所以对于Token的消耗是很低的。
激活(Activation) - 指令主体层
当用户发出指令后，与元数据中的技能描述相匹配后，此时Agent才会动态的将完整的技能说明书（即：SKILL.md）和提到的相关参数一并交给Agent进行对应具体对话交互，获取用户更加具体的意图。
执行(Execution) - 扩展资源层
经过第二步获知用户最终意图后，通过文字的方式无法达成用户最终想要的结果，扩展资源层则是根据需要调用脚本(scripts/ )或检索参考资料(references/)，来完成具体的执行任务。
扩展资源层机制
在对**scripts/**进行介绍时，其中包含了python代码、脚本代码如过代码中已经形成了较大的体积，不可能直接将代码交给Agent本身。
其实Agent在运行过程中，Agent并不会去理解和推理代码中的含义，而是交到一个运行时环境中去执行（即：沙箱），Agent只负责在恰当的时机触发、执行并接收对应的结果输出。
- Agent ：更像是一个调度员，根据用户的指令，选择正确的
Skill，并在需要时调用Skill中指定的脚本 - 代码执行 ：作为一个黑箱工具。脚本在受控的沙箱环境中独立运行，其行为由代码本身和输入参数决定，具有完全确定性
写在最后
Agent Skills通过三层渐进式策略，结合脚本执行时的封闭环境就可以做到，对Agent的节省大量Token的占用也可以为Agent提供非常强大和可控的能力。
三层渐进式策略（元数据层→指令主体层→扩展资源层）的设计，让Agent摆脱了"塞满提示词"的传统模式。这套机制的本质，是将Agent从"记忆所有指令"转变为"按需调用工具"。