如果你正在构建 Agent 应用，大概率经历过这样的场景：给 AI 写了一长串规则，它一开始还挺听话，但随着指令越来越长，它开始跳步骤、遗漏关键环节，甚至在你最不希望它“发挥”的地方自作主张。
这不是模型不够聪明。Anthropic 在其 Agent 设计指南中指出，AI Agent 系统面临的最大挑战并非底层模型的推理能力，而是指令的结构化程度。当指令以松散的对话形式呈现时，即使是最先进的 LLM 也会出现“上下文漂移”——随着上下文增长，模型对任务边界的感知逐渐模糊。
Skills 正是为解决这个问题而生。 它不是更好的提示词，而是一套全新的上下文工程范式。本文将基于 Anthropic 与 Perplexity 公开的设计方法论，以及社区的最佳实践，梳理 Agent Skills 的核心设计原则。

一、先理解本质：Skill 不是什么？

在动手之前，有两个关键认知需要先对齐。
认知转变：从 Prompt Engineering 到 Context Engineering
传统 Prompt Engineering 的核心是优化单次指令，引导模型给出正确输出。而 Context Engineering 关注的完全是另一个层面：在模型做决策之前，如何组织好所有相关信息——包括结构、优先级、加载时机。
Perplexity 的原话说得很直接：如果你像写代码一样写 Skill，你会失败。把 Skill 当 prompt 写，大概率会踩这些坑：一次性把所有信息写在一个文件里、用描述性语言写功能说明而不是触发条件、让模型自己写 Skills。

Python 之禅在 Skill 领域大面积失效

Perplexity 团队发现 PEP20 里至少一半的智慧在写 Skill 时是错误的或误导性的：

最后一条尤其切中要害。很多人写 Skill 的第一反应是写教程式说明文档，但模型已经知道的东西写进去只会浪费上下文窗口。Anthropic 的第一条最佳实践也是同一个意思：不要说显而易见的事，把重点放在能打破模型常规思维模式的信息上。

二、核心原则一：渐进式披露

这是 Skills 最精妙的设计，也是它区别于“长 Prompt”的本质差异。

三层知识架构
一个设计良好的 Skill 遵循三层加载策略：

为什么这样设计？
这个机制解决了两个实际问题：
Token 效率：不把所有知识一股脑塞进上下文，避免信息过载。你可以同时挂载几十个 Skill，而激活判断的成本只是几十行短文本的比对。
注意力聚焦：模型的注意力机制在上下文越长时衰减越明显。渐进式披露让模型在每个阶段只关注最相关的信息——就像人类读一本操作手册，先看目录，再翻到对应章节，最后才查阅附录中的详细表格。
一个值得注意的细节：scripts/ 里的 Python 或 Shell 脚本不会整文件塞进 Prompt。Agent 通过 Bash 工具执行脚本，脚本逻辑留在磁盘上，上下文里只有执行结果 JSON。这正是 Skills 能同时“可编程”又“省 Token”的原因。

三、核心原则二：密度优先，而非长度优先

Perplexity 团队反复强调一个观点：上下文昂贵，每 token 要做到信号密度上限。
description 的三个维度
description 是 SKILL.md 的 YAML frontmatter 中最关键的字段——它直接决定了 Skill 的加载率。一个高质量的 description 应包含三个维度：

•  触发短语：用户在自然语言中可能使用的表述，如“检查安全漏洞”“做一次审计”
• 时序定位：在整体工作流的哪个阶段使用，如“代码完成后、部署前”
• 领域关键词：目标领域的热门术语

可执行示例优于抽象描述
Anthropic 的建议是：用可运行的示例代替抽象描述。例如，与其写“本 Skill 用于处理 PDF 表单填充”，不如在 SKILL.md 中直接提供一条可执行的命令示例，让模型“照猫画虎”。
删除“模型已经知道的事”
这是 Skill 写作中最容易被忽视的坑。很多人写 Skill 的第一反应是写教程式说明文档，但模型已经知道的知识写进去只是浪费上下文。Skill 的价值在于提供模型无法从训练数据中学到的信息——比如企业特定的工作流、团队约定、主观品味判断

四、核心原则三：单一职责与标准化

一个 Skill 只做一件事
单一职责原则在 Skill 设计中同样适用：一个 Skill 只负责完成一项核心业务能力，杜绝“大而全”的臃肿设计。比如文档解析 Skill 只负责文件内容提取，数据统计 Skill 只负责数据汇总计算。
这样设计的好处是：粒度清晰、复用性强、排查问题简单。当粒度足够细时，你可以通过组合多个原子 Skill 来构建复合能力，而不是维护一个庞大而脆弱的单体 Skill。
原子技能与复合技能分层
通用方案是将 Skill 划分为两类：

• 原子技能：最小粒度的基础能力，不可再拆分，直接封装底层工具。如 PDF 解析、文本清洗、关键词提取。设计关键是极致通用，不绑定具体业务场景。
• 复合技能：基于多个原子技能编排组合的场景化能力，面向具体业务问题。如“SEO 内容优化流程”可能包含关键词提取、内容分析、格式规范等多个原子 Skill 的组合。

输入输出标准化
所有 Skill 应定义统一的入参、出参数据结构。不管底层工具如何迭代，对外调用接口保持不变，避免上层 Agent 频繁适配修改。

五、核心原则四：可观测与可迭代

日志是迭代的基础
每个 Skill 执行时应记录完整日志：调用时间、入参、执行步骤、返回结果、报错信息、耗时数据。没有数据支撑的“优化”往往是臆想。

用 Eval 套件持续验证
Perplexity 的研究表明，LLM 自己写的 Skills 平均没有收益——他们的原话是“模型无法可靠地编写它们受益的程序性知识”。高质量的 Skill 必须由人类基于实战经验编写，再通过 Eval 套件持续验证。

区分“需要 Skill”和“不需要 Skill”的场景
Anthropic 和 Perplexity 的判断标准很明确：
需要 Skill 的情况：模型没有特殊上下文就会犯错、需要跨运行保持行为一致性、知识是持久的但不在训练数据中、涉及企业特定工作流或团队约定。
不需要 Skill 的情况：模型本来就能做对的事情、信息变化速度超过维护速度、和系统 prompt 重复的指令。

六、Skill 与 MCP：各司其职

很多人第一次接触 Skills 时会困惑：既然 MCP 也能挂工具，为什么还要多一层？
一个形象的类比：
• MCP 给 Agent 工具——解决“能用什么”的问题，是连接外部系统和数据服务的协议层
• Skill 给 Agent 操作手册——解决“怎么一步步把事情做好”的问题，是流程和经验的封装层
两者是互补关系。Agent 通过 MCP 获取工具能力，通过 Skills 获取做事方法。在实际工作中，一个 Skill 可以调用 MCP 提供的工具，也可以引用 references/ 中的参考文档，还可以执行 scripts/ 中的确定性代码。

写在最后：把 Agent 当成算法来用

一位社区实践者分享了一个很有启发性的视角：把 Agent 当成一个算法来用——给它输入，它给你指定格式的输出，中间的过程是可预期的、可恢复的。
这不是要消灭 LLM 的“智能”，而是把确定性的事情从它脑子里拿出来，交给结构化的轨道。让 Agent 保留它最擅长的“理解人话、做判断、组织表达”的能力，但把所有流程顺序、数据格式、API 调用、状态管理交给 Skill 架构来承载。
Skills 的价值不在于单次输出的效果有多好，而在于可重复的标准化工作流程所带来的复合效率提升。无论是企业级财务流水线还是个人的内容创作工作流，核心逻辑一致：把反复输入的提示词和行业经验变成一次性封装、持续复用的专业技能。

  最后说一句，技术成长不只是写代码，职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料，适合想在职场上走得更远的朋友看看。

  资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。