Anthropic 官方总结了 14 个 Agent Skills 设计模式，但它真正想教会大家的，其实是怎么把 Agent 做成工程系统

这段时间 Agent Skills 之所以越来越热，不是因为大家突然都喜欢写 Markdown 说明书了，而是因为越来越多人开始意识到，Agent 真正难的地方，从来不是多写一句提示词，而是怎么把能力变成一个能长期复用、能按需加载、能稳定执行的系统。

所以当一篇文章开始讲 Anthropic 官方总结的 Agent Skills 最佳实践、设计模式时，我反而觉得最值得看的，不是“14 个模式”这个数字本身，而是 Anthropic 终于把很多人心里模模糊糊那套东西说清楚了：

Agent 要进入真实世界，靠的不是一个万能 prompt，而是一套工程化的能力组织方式。

Anthropic 这套思路，核心不是 Skill 文件，而是 progressive disclosure

Anthropic 在官方工程文章里反复强调的一个核心设计原则，叫 progressive disclosure，也就是渐进式披露。

说白了，就是别把所有上下文一股脑全塞进模型，而是先给最轻量的技能元信息，让 Agent 知道“什么时候该用这个能力”；等真的判断相关了，再去读完整的 SKILL.md；如果任务还需要更深信息，再继续读 skill 目录下的其他参考文件、脚本和资源。

这个设计看着像是节省 token，实际上更重要的是，它重新定义了 Agent 能力该怎么组织。

以前我们的直觉总是“上下文越多越好”，现在越来越清楚，真正靠谱的做法是“让对的上下文，在对的时候被加载进来”。

这不是 prompt 工程的小修小补，这是上下文工程的基本盘。

为什么 Skills 会变成 Agent 的关键基础设施

Anthropic 对 Skills 的定义其实很朴素：一个目录，里面放 SKILL.md，再加上一些脚本、参考资料和资源文件。

但这东西真正厉害的地方，在于它把经验从“聊天记录里的偶然发挥”，变成了“可执行、可组合、可迁移的能力单元”。

一旦能力被包装成 Skill，很多之前非常飘的东西就落地了：

• 什么时候触发这项能力
• 触发后该先看哪些说明
• 什么时候该读参考资料，什么时候该跑脚本
• 哪些操作要走代码执行，哪些只需要语言理解
• 这项能力能不能在别的团队、别的平台上复用

说到底，Skill 不是一个知识片段，而是一种任务封装。

你把它理解成“给 Agent 的 SOP 包”会更准确。

官方最佳实践背后，其实在回答 4 个更大的问题

如果把 Anthropic 那套文章和公开 skills 仓库放一起看，会发现它真正回答的不是“Skill 怎么写”，而是下面这四个问题。

1. Agent 的能力该怎么拆

Anthropic 明确不鼓励把所有规则堆进一个巨大的主提示词，而是鼓励把能力拆成独立技能。

这意味着未来 Agent 的构建方式，越来越像搭系统积木，而不是打磨一段万金油 prompt。

谁能把能力拆得清楚，谁的 Agent 就更容易维护、评估、共享和迁移。

2. 上下文该怎么控

Skill 元信息预加载，正文按需读，参考文件继续按需展开，脚本必要时直接执行，这整套逻辑其实就是在管理上下文预算。

这件事非常关键，因为 Agent 一旦进入复杂工作流，真正稀缺的往往不是模型聪明不聪明，而是上下文窗口里到底装什么。

3. 什么时候该让代码接管

Anthropic 官方特别强调，很多任务不该靠 token 一个字一个字“猜”出来，而该交给确定性代码完成。

比如排序、解析、提取 PDF 表单字段、结构化转换，这些天然更适合脚本。

这个判断特别重要，因为它直接切开了“语言模型负责什么，传统程序负责什么”的边界。一个真正靠谱的 Agent，从来不是让模型硬扛一切，而是让模型学会在合适的时候调用确定性系统。

4. Skill 应该怎么持续迭代

Anthropic 还给了一个很实用的建议：不要一开始就空想 Skill 长什么样，而要先从评估开始，看 Agent 在真实任务里哪里掉链子，再反过来补技能。

这个思路很对。

因为很多人做 Agent，最容易犯的错就是一上来就闭门造 prompt，写一堆“应该有用”的规则，结果一落到真实任务里，全跑偏。

而 Skill 的正确生长方式，应该更像软件迭代：先观察失败，再抽象模式，再补成可复用模块。

所谓“14 个设计模式”，真正值钱的是模式意识

我其实一直觉得，具体是 14 个、12 个还是 20 个，不是最关键的。

真正关键的是，Anthropic 这波在公开传递一个信号：

Agent 能力不是灵感式产物，而是可以被总结、被命名、被复用、被迁移的模式。

一旦你开始用模式眼光看 Agent，你做事情的方式就会彻底变。

你不再只是问“怎么让它这次答对”，而会开始问：

• 这类任务是不是值得沉淀成 Skill
• 这个 Skill 的触发条件是什么
• 哪些上下文该预加载，哪些按需读
• 哪些操作适合脚本化
• 成功和失败的评估标准是什么

这才是从“玩 Agent”到“做 Agent 系统”的分界线。

Anthropic skills 仓库为什么能冲到十几万星

根据 GitHub 公开数据，anthropics/skills 现在已经有超过 12 万星。

它受欢迎当然有品牌因素，但更深层的原因，是它正好踩中了 AI Agent 发展里最需要被标准化的那个位置。

模型层大家都在卷，工具协议层有 MCP，真正夹在中间、最贴近工作流的那层，一直缺一个更清楚的表达。Skills 恰好补上了这个空位。

它让大家第一次比较系统地看到：

原来“如何给 Agent 注入专业能力”这件事，不一定要做成一个独立 Agent，也不一定非得写死在系统提示词里，它可以是一种轻量、可移植、可组合的能力封装格式。

这件事一旦成立，后面的生态就会很自然地长出来。

对做产品和做团队的人，这事的现实意义更大

很多团队现在已经不是不会用 Agent，而是不会让 Agent 稳定地按团队方式工作。

同一个模型，A 团队用着像神器，B 团队用着像玩具，差别往往不在模型，而在有没有把自己的流程、规范、术语、例外情况、工具习惯，沉淀成一套 Agent 真能拿来执行的东西。

Skills 的价值，恰恰就是把这种“组织经验”从人脑里搬出来。

你可以把品牌规范做成 Skill，把设计评审流程做成 Skill，把代码审查要求做成 Skill，把财务报表处理流程做成 Skill。只要一旦沉淀出来，它就不再依赖某个老员工、某次临场发挥，或者某句运气好的 prompt。

最后给个更直接的判断

Anthropic 官方现在讲 Agent Skills 最佳实践，看起来像是在教大家怎么写技能，实际上是在偷偷教整个行业一件更底层的事：

未来真正有竞争力的 Agent，不是最会说话的那个，而是最会加载、组织、执行和复用能力的那个。

这才是 Agent 工程化真正开始成熟的信号。

后面你再看什么“Skill 最佳实践”“Skill 模式”“Skill 标准”，别只把它当教程看。它本质上是在定义下一代 Agent 软件栈里，能力这一层该长成什么样。

顺手说一句，如果后面真准备把这些 Skills、脚本和工作流落到自己环境里跑，底层部署别糊弄。像雨云这种偏实干型的云服务，拿来跑轻量自动化、对象存储、测试环境和一些 Agent 配套服务，反而挺顺手。很多团队不是没有 Skill，而是没有一个能稳定挂这些 Skill 和执行链路的环境。