Skills 到底是什么：为什么 AI Agent 不再只是一个模型，而像一套可安装的能力系统

很多人最初还在问 “AI Agent 到底能不能自己干活”，但真正做过 Agent 的团队，很快会碰到另一种现实主义版本的问题：它为什么总是在同一个地方犯重复的错？

模型明明已经会写、会搜、会看图、会调工具，可一到具体工作里，还是经常卡住。它可能知道什么是财务报表，却不知道你们公司的月结流程；它可能会做 PPT，却不知道你们内部汇报必须保留哪几页；它可能会写营销文案，却不知道哪些表述会踩品牌红线。换句话说，很多 Agent 不是不够聪明，而是没有学会你这套活到底该怎么干。

这就是 Skills 这个概念开始变重要的原因。它解决的不是“模型有没有能力”，而是“能力如何被组织、复用、移植和稳定触发”。你可以把它理解成一种给 AI Agent 安装“能力包”的方式，但如果只停在这个比喻层面，又会把它看浅。真正的 Skills，不只是外挂功能，而是把流程知识、组织上下文、脚本工具和操作习惯一起打包，变成 Agent 随时可调用的工作方法。

Skills 到底是什么：为什么 AI Agent 不再只是一个模型，而像一套可安装的能力系统 — 越来越多团队发现：Agent 的差距不只在模型本身，也在它有没有被装上合适的技能层。

大模型给 Agent 提供的是智力底座，Skills 提供的则更像是“怎么按你们团队的方法把事情做对”。

Skills 到底是什么，为什么它不是“再写一段更长的提示词”

先说一个很重要的前提：Skills 目前不是所有平台都统一采用的单一官方对象。但它已经明显成为 Agent 设计里的一个共识模式。最有代表性的官方产品化版本来自 Anthropic。Anthropic 在 2025 年 10 月 16 日 正式发布 Agent Skills，并把它定义成由 instructions、scripts、resources 组成的文件夹，Agent 在需要时才动态加载。

这个定义之所以重要，不是因为它告诉了我们一个新名词，而是因为它把一个长期存在却经常被忽略的事实说清楚了：真实工作需要的，不只是通用知识，还需要程序性知识和组织上下文。也就是说，模型知道很多事情，不等于它知道你们团队到底怎么做这件事。

因此，在更通用的意义上，Skills 可以理解成：把一类可重复的专业做法，封装成 Agent 能识别、按需加载并反复使用的能力单元。这个能力单元里可能包含说明文档、操作步骤、示例、约束、品牌规则、脚本代码、参考资料，甚至还包括文件模板和外部资源入口。

它和“再写一个更长的系统提示词”最大的区别，在于 Skills 不是把所有东西一次性塞进上下文，而是把能力拆成可管理、可触发、可维护的结构。换句话说，提示词更像你在当场交代任务；Skill 更像你给新同事做了一本可复用的上岗手册，并且附上了几个常用脚本和模板。

问题	普通提示词	Skill
解决什么问题	告诉模型这次任务该怎么答	让 Agent 学会一类任务长期怎么做
内容组织方式	一段连续文本	目录化结构，可含说明、脚本、资源和引用文件
触发方式	通常在当前会话里直接生效	按需匹配、动态加载、可跨任务复用
维护成本	越写越长，容易失控	可拆分、可版本化、可团队共享
典型适用场景	一次性提问、单轮生成	重复出现的 SOP、岗位流程和专业产物

为什么 Skills 会突然变成一个关键概念

原因其实不复杂。前两年大家都把精力放在“模型会不会推理、会不会看图、会不会调工具”上；等真正把 Agent 用进工作流的人越来越多，新的瓶颈就暴露出来了。模型也许什么都懂一点，但在高频、重复、长链路的真实工作里，它依然会反复忘事、反复走偏、反复重复说明。

Anthropic 在工程文章里写得很直白：真实工作需要 procedural knowledge 和 organizational context。翻成人话就是，光有通用智能不够，Agent 还得知道“这个活在你们公司平时是怎么做的”。而 OpenAI 在 Agent Builder 文档里给出的定义同样指向了这个方向：要构建有用的 agent，需要的是 workflow，也就是 agents、tools 和 control-flow logic 的组合。你会发现，整个行业都在从“一个强模型”往“一个能稳定执行流程的系统”迁移。

一旦走到这一步，Skills 的价值就变得非常清晰了。它处在一个刚好够具体、又足够可移植的位置：既比单句提示词更强，又比重新微调模型更轻；既能带组织上下文，又不会把所有内容硬塞进上下文窗口；既能封装经验，又能配合脚本做确定性操作。

换句话说，Skills 会变热，不是因为它听起来新鲜，而是因为它正好补上了 Agent 落地时最痛的一个缺口：把零散经验变成可重复执行的能力。

真正最容易被混淆的，不是 Skill 本身，而是它和 Tool、MCP、Workflow 的边界

很多团队刚接触这个概念时，第一反应通常是：“这不就是插件吗？”或者“这不就是 MCP 吗？”再或者，“那是不是把系统提示词写长一点就行？”这些理解都抓到了一部分，但都不完整。

Skill 和 Tool 不一样

Tool 解决的是“Agent 能做什么动作”。比如搜索、读文件、执行 Python、调用 CRM、创建日历事件、发邮件。工具更像手和脚，是动作接口。OpenAI 和 Anthropic 这两年都在大力扩展这条线，比如 OpenAI 的 Responses / Agent Builder 生态、Anthropic 在 2025 年 5 月 22 日 推出的 code execution tool 和 MCP connector，都是在给 Agent 安手脚。

而 Skill 解决的不是“有没有这只手”，而是“这只手在什么场景下该怎么用”。一个 Agent 可能已经有写表格和生成图表的工具，但没有财务周报 skill 时，它未必知道先对齐口径、再抓异常、再按你们公司模板出结论。Tool 提供动作，Skill 提供做法。

Skill 和 MCP 也不一样

MCP 更接近一种连接协议。它解决的是“Agent 如何安全、标准化地接入外部系统、数据源和服务”。OpenAI 在 MCP 文档里把它称为 becoming the industry standard for extending AI models with additional tools and knowledge；Anthropic 在工程文章里也明确写到，未来会探索 Skills 如何和 MCP server 互补。

两者最直观的区别可以这样理解：MCP 给 Agent 接口和触角，Skill 给 Agent 方法和套路。MCP 让它能连到 Box、Stripe、Asana、内部知识库；Skill 则告诉它，连上这些系统之后，应该按怎样的顺序拿哪些数据、套哪些模板、走哪些检查步骤。一个是连线，一个是干法。

Skill 也不等于 Workflow

Workflow 是更高一层的东西。OpenAI 在 Agent Builder 文档里说得很清楚，workflow 是 agents、tools 和 control-flow logic 的组合。它关心的是整条流程如何推进：谁先执行、谁后执行、分支怎么走、审批在哪里插入、结果怎么回传。

Skill 更像其中一个可复用模块。你可以把一个“品牌审校 skill”“财务周报 skill”“PDF 表单处理 skill”插进不同工作流里反复使用。也就是说，Workflow 是流程蓝图，Skill 是流程里可移植的做法组件。

概念	它主要解决什么	更像什么
Prompt	这次任务怎么说清楚	当场交代需求
Tool	Agent 能做哪些动作	手和脚
MCP	Agent 怎么接外部系统	标准接口和总线
Skill	一类任务长期应该怎么做	岗位手册 + 模板 + 脚本
Workflow	这些能力最终如何编排成流程	作业流程图

一个成熟的 Skill，通常长什么样

Anthropic 在工程文章里给了一个非常清晰的结构：Skill 本质上是一个目录，最核心的入口是 SKILL.md。这个文件前面有元数据，比如 name 和 description。Agent 启动时先预加载这些轻量描述，只有在任务相关时才会进一步读取完整内容。这种做法很聪明，因为它解决了一个现实问题：不是所有技能都应该时时刻刻占用上下文。

更进一步，Skill 还可以分层。核心说明放在 SKILL.md，细分场景说明拆到其他参考文件里，脚本放在脚本目录里，模板和资源也都可以打包进去。Agent 只在需要时继续展开。这种 progressive disclosure 的思路本身就很值得科普，因为它直接回应了大模型时代最现实的一个限制：上下文不是无限的，好的组织方式比盲目堆信息更重要。

---
name: brand-review
description: 审核营销内容是否符合品牌语气、禁用词规则和法务边界
---

当任务涉及品牌文案、活动页面或对外宣传材料时：
1. 先读取 brand-guidelines.md
2. 如涉及禁用词检查，读取 compliance-checklist.md
3. 必要时运行 scripts/check_claims.py
4. 输出时先给风险点，再给修改建议

参考文件：
- brand-guidelines.md
- compliance-checklist.md
- scripts/check_claims.py

这段骨架没有什么炫技成分，但它已经能说明 Skill 的关键价值：它不是让模型“知道更多”，而是让模型“按一套稳定方法做事”。

为什么很多 Agent 看起来很聪明，但没有 Skill 就还是不够像“可用同事”

因为多数工作并不是一道知识问答题，而是一段有顺序、有隐含规则、有内部口径的流程。比如“帮我做一份周报”这句话，对人类同事来说已经包含了很多默认知识：要看哪些数据、要不要先过滤异常、要不要按部门拆分、标题用什么格式、结尾要不要给建议。模型虽然知道什么是周报，但未必知道“你们的周报”是什么样。

没有 Skill 的 Agent，常常会表现出一种很典型的“聪明但不熟行”：它能做对 70%，但最关键的 30% 总会偏。要么漏掉必须检查的步骤，要么没有遵守既定模板，要么虽然调用了工具，却顺序不对。Skill 的意义，就是把这 30% 里最有组织特征、最容易反复出错的部分固化下来。

Anthropic 在 Skills 发布页里给出的例子很能说明这一点：Claude 可以利用 Anthropic 创建的 skills 读写带公式的 Excel、PowerPoint、Word 和 fillable PDFs；还可以通过 Box 相关 skill，把存储在 Box 里的内容转成符合组织标准的文档和演示文件。这里真正被打包进去的，不只是“文件格式能力”，更是对专业产物和组织标准的遵循方式。

四个真实案例，足够说明 Skill 为什么不是纸上概念

案例一：PDF 表单技能，说明 Skill 的价值常常来自“把最后一公里补齐”

Anthropic 工程文章里专门拿 PDF skill 做了解剖。Claude 本来已经很擅长理解 PDF，但对“如何直接填表”这种任务并不天然拿手。于是他们把这一类能力做成了技能：说明文件告诉 Agent 在何时触发，辅助文件专门解释 form-filling 的场景，脚本则负责提取表单字段。这样一来，模型不需要把一整套 PDF 操作知识全记在主上下文里，遇到这类任务时再加载就行。

这个案例很典型，因为它说明 Skill 常常不是为了解决宏大愿景，而是为了补齐一个在真实流程里非常烦人的短板。很多团队真正应该做的第一个 Skill，往往也不是“全能运营助理”，而是某个反复出现、又总靠人工兜底的具体动作。

案例二：Excel / PowerPoint / Word 技能，说明 Skill 的核心不只是会生成文件

Anthropic 在 2025 年 10 月 16 日 的发布里明确写到，Anthropic-created skills 可以让 Claude 读写带公式的 Excel、PowerPoint、Word 和 fillable PDFs。这件事值得注意，不是因为“终于能导出 Office 文件了”，而是因为办公产物从来都不是只看字面内容。它们往往有格式要求、计算逻辑、页结构、常用模板和组织规范。

所以，文件生成类 Skill 真正做的，是把“工具能力 + 产物标准 + 操作顺序”绑在一起。这和单纯让模型吐出一段文字，再由人自己贴进文档，是完全不同的成熟度。

案例三：Box 相关技能，说明 Skill 正在成为组织上下文的载体

Anthropic 发布页里还给了 Box 的例子：Skill 可以教 Claude 如何处理 Box 里的内容，把文件转成符合组织标准的 PowerPoint、Excel 和 Word。这个案例很有代表性，因为它揭示了 Skill 最值钱的部分：组织不是缺知识，而是缺“知识怎么按本组织的方式被使用”。

同样一份产品资料，在一个公司里要写成销售 deck，在另一个公司里要改成董事会摘要，在第三个公司里又要先走品牌审校和法务检查。Skill 的出现，本质上是在把这种组织级做法显式化，而不是继续依赖“老员工心里都知道”。

案例四：MCP + Tool + Skill 的组合，说明 Agent 开始从“会回答”走向“会工作”

Anthropic 在 2025 年 5 月 22 日 推出 code execution tool、MCP connector、Files API 和 extended prompt caching 时，给了一个项目管理 Agent 的例子：通过 MCP connector 连 Asana，用 Files API 上传相关报告，用 code execution 分析风险。这一套能力本身已经能工作，但如果再加上一层项目汇报 skill，事情就会变得更像真实同事：它不只会拉数据和做分析，还知道你们的项目复盘通常先看里程碑、再看风险、最后给行动建议。

这也是为什么我会说，Tool、MCP、Skill 并不是彼此替代的关系，而是越来越像一条完整 Agent 栈上的不同层次。前者解决“能不能连、能不能做”，后者解决“要不要按团队的方法做对”。

技能越多，Agent 就一定越好吗？未必

这是 Skills 这个话题特别容易被讲歪的地方。很多人一听到“能力包”“可安装”“技能目录”，就很自然地往应用商店的方向想，仿佛技能越多，Agent 就越强。现实通常没有这么简单。因为 Skill 不是纯加法，它本身也会带来维护成本、冲突成本和安全风险。

Anthropic 在工程文章里明确提醒，malicious skills 可能引入环境漏洞，或者指使 Claude 外传数据、执行意外动作，所以要只安装可信来源的 skills，并审计其中的代码依赖和资源。OpenAI 在 MCP 和 connectors 的安全文档里同样反复强调 prompt injection、approval flow、只连接官方服务器、记录第三方数据共享等问题。把这些信息放在一起看，你会发现一个很清晰的现实：Agent 越能干活，技能和接口越多，治理就越重要。

所以，技能不是堆得越多越好，而是越应该讲究边界。一个好的 Skill 应该清楚回答：它处理什么任务，不处理什么任务；它能访问什么资源，不能访问什么资源；哪些动作可以自动执行，哪些动作必须走人工审批。没有这些边界，Skills 很容易从“能力增强”变成“不可控复杂度”。

场景	更适合做成 Skill	不适合急着做成 Skill
重复出现的专业流程	是	一次性任务
明确有模板、步骤和验收标准	是	目标和标准都不稳定的探索任务
需要脚本或确定性代码配合	是	纯靠即兴创造力的开放式任务
涉及高敏感动作但没有审批流	谨慎	不应直接自动化
组织内部 know-how 反复被新人问到	非常适合	无统一做法、人人口径不一致

如果一个团队真的想开始做 Skills，第一步往往不是写代码，而是找重复劳动

这是我觉得最容易给读者带来启发的一点。很多团队一听到 Skill，会先想技术实现；但现实中更关键的，往往是先找出那些“每周都会有人重复交代、重复检查、重复修正”的任务。只有这种任务，才值得被 Skill 化。

比如这些问题，通常就很适合作为第一批候选：

每次做月报，都要重复解释一遍模板、字段口径和结论顺序。
每次做品牌内容，都要人工提醒禁用词、语气边界和 CTA 规则。
每次处理客户文档，都要按一套固定步骤抽取信息、改格式、回填模板。
每次项目复盘，都要先读某几类文件、再生成某几类图表、最后输出同样的结构。

这类任务有一个共同特征：它们不是特别有创意，但很吃规范；不是特别难理解，但很怕走偏。这样的工作最适合被 Skill 化。因为你不是在教 Agent “思考世界”，而是在教它“按我们的方法做这类活”。

一个实用的 Skill brief，往往比花哨的实现更重要

Skill 名称：这项技能要解决哪一类重复任务？
触发条件：用户提什么类型的问题时，它应该被加载？
目标产物：最终想输出什么？报告、表格、演示文稿、审校意见，还是执行结果？
必读规则：哪些约束、模板、禁用项必须先看？
可调用脚本：哪些操作应该交给代码而不是语言模型？
外部依赖：它是否要访问 MCP 服务器、文件系统或第三方服务？
人工审批点：哪些步骤必须在执行前让人确认？
评估标准：怎么判断这个 Skill 到底有没有让结果更稳？

这份 brief 最大的价值在于，它会逼团队先把“这项技能到底负责什么”说清楚。很多 Agent 工程最后失控，不是因为模型太弱，而是因为 Skill 定义得太宽，最后变成一个什么都想做、却什么都做不稳的黑箱。

最后的判断：Skill 不会取代模型，它会重新定义“把经验装进 Agent”的方式

如果说大模型解决的是“让机器有通用智力”，那么 Skills 解决的就是“如何让这份智力开始带着岗位经验、组织习惯和流程纪律去工作”。这两者不是一个层面的东西。前者更像大脑，后者更像职业训练。

这也是为什么我觉得 Skills 这个概念会持续变重要。因为 Agent 真正进入工作流以后，大家慢慢发现，最难积累的并不是模型本身，而是组织做事的方法。提示词可以临时写，工具可以临时接，MCP 可以临时连，但“我们团队到底怎么做这类事”这部分经验，如果不被封装下来，Agent 每次都还是像一个刚入职的新同事，要从头摸一遍。

从这个角度看，Skill 不是一个小功能，而是一种非常实际的知识工程方法。它让 Agent 从“会答题”慢慢走向“会按一套成熟方法做事”。而当这种能力逐渐普及之后，真正拉开差距的可能就不再是你接了多少模型，而是你有没有把自己的流程、模板、标准和 know-how 变成一套可移植、可治理、可复用的技能系统。

参考资料

# AI科普馆

文章版权归作者所有，未经允许请勿转载。