LLM - Agent Skills 智能体新范式-CSDN博客

文章目录

概述
1. 当下的 Agent，究竟卡在哪里？
2. 什么是 Agent Skills？
3. 核心机制：渐进式披露（Progressive Disclosure）
4. Skills 与工具调用、RAG、MCP 有何不同？
5. Skill 范式的工程价值：从个人效率到组织级资产
- 5.1 面向个体：「第二大脑」的可编程化
- 5.2 面向团队：把 SOP 变成「可执行程序」
6. 如何从零开始写一个 Skill？
7. 安全与治理：技能其实是一种「软件包」
8. Skills 的未来：从人写技能，到 Agent 自己长技能
9. 写在最后：给今天就在用 LLM 的工程师一些建议
Claude Skills × OpenAI Function Calling × Spring AI Tools × MCP 对照表
Anthropic Agent Skills / AI Agents 延伸阅读合集

在这里插入图片描述

概述

过去两年，Agent 成了生成式 AI 场景里的头号热门词：从自动写代码、跑流水线，到帮你看文档、写邮件，几乎所有团队都在造各式各样的 Agent。
但现实很骨感：Demo 惊艳，上线翻车；单个场景勉强可用，换个任务就「智商在线、业务不行」。越来越多人发现，问题不在于「Agent 不够聪明」，而在于它们缺少可以沉淀和复用的「技能」。

2025 年，Anthropic 把这种直觉正式产品化：Agent Skills——一个以「文件夹」为基本单位的技能系统，并公开喊话：“不要再到处造新的 Agent，而是给一个通用 Agent 装上可组合的 Skills。”

在这里插入图片描述

接下来我们就从工程视角拆开这个新范式：它到底解决了什么问题，具体怎么工作，和 MCP / 工具调用 / RAG 有什么不同，开发者在实践中该如何落地。

1. 当下的 Agent，究竟卡在哪里？

从开发体验看，今天主流的 Agent 搭建方式大致有三类路线：

Prompt 工程 + 一些工具调用
通过长 System Prompt + 指令模板，把模型「调教」成一个 Agent，再给它挂上若干工具（搜索、数据库、脚本执行等）。
工作流编排 / Orchestration
例如用各种 Agent 框架，把复杂任务拆成多节点、多 Agent 的有向图，节点间传递中间结果。
针对场景微调 / RAG
用特定领域数据做检索增强，或者定制微调，使 Agent 在某个垂直领域更专业。

这些方案看似不同，本质却有共性的问题：

知识与流程都「糊」在 Prompt / 代码里，难以复用与版本管理。
一个好用的 Agent，往往是 Prompt、工具选择、调用策略和业务约束的混合体，很难拆成独立、可移植的组件。
上下文是一次性、易遗忘的。
模型再「聪明」，没有结构化的程序性记忆，依然像一个刚入职、啥都得现问的实习生：每次任务都要重新讲一遍 SOP。
缺乏统一抽象，生态难以形成。
不同团队、不同框架的 Agent 互不兼容，很难像 App 一样被分享、组合和「安装」。

Anthropic 的判断是：继续堆更复杂的 Agent 结构，很难治本；真正缺的是一种能被模型理解、被工程体系管理、又能跨项目复用的「技能载体」。

2. 什么是 Agent Skills？

在这里插入图片描述

Anthropic 给出的定义高度务实：

一个 Skill，本质上就是一个文件夹（目录），里面装着让 Agent 完成某类任务所需的所有「操作说明 + 工具脚本 + 资源」。

典型的 Skill 目录结构大致如下：

my-skill/
  SKILL.md        # 必选：技能说明与元数据
  scripts/        # 可选：可执行脚本（bash / python / …）
  templates/      # 可选：各类模板（文档、代码片段等）
  resources/      # 可选：参考文件（示例、规范、数据字典等）

其中：

SKILL.md 是大脑入口：
里面以结构化 Markdown 写明技能的用途、适用场景、关键步骤、输入输出格式、注意事项等，同时包含模型用来检索与触发该技能的元数据（name、description、tags 等）。
scripts 提供「可执行动作」：
比如 PDF 解析、Excel 操作、批量重命名、调用内部 API 的封装脚本等。模型不需要记住细节，只要知道「调用哪个脚本完成这一步」。
其他资源作为补充记忆：
模板、规约、案例，用来保证输出风格与公司标准一致。

换句话说：Skill 是一种“人类可读 + 机器可执行”的工作说明书，既不是纯 Prompt，也不是黑箱 API，而是介于两者之间的一种「程序化知识包」。

3. 核心机制：渐进式披露（Progressive Disclosure）

如果把大量业务流程都写进 Skill，显然会遇到一个经典问题：上下文爆炸。
Anthropic 的解决方案是「分层加载」——渐进式披露：

可以粗略理解为三个层次：

Level 1：元数据常驻（Metadata）
- 每个 Skill 的名称、简短描述、标签会被放进 Agent 的系统提示或一个轻量索引中。
- Agent 在接到任务时，先在这层做「哪几个技能可能相关？」的快速筛选。
Level 2：说明按需加载（Instructions）
- 当 Agent 判断某个 Skill 适配当前任务，就通过类似 bash / 文件访问接口读取对应的 SKILL.md 具体内容。
- 此时，详细步骤、边界条件、格式要求才被带入上下文。
Level 3：资源与脚本再按需调用（Resources & Code）
- 若说明里引用了脚本或资源，Agent 会在需要时再去执行脚本或读取文件，而不是一次性塞进上下文。
- 代码在模型外执行，结果以结构化输出回传，更稳定也更省 Token。

这种设计有两个直接好处：

上下文成本可控、可扩展：
可以挂很多 Skill，但大部分时间只占用极少上下文空间。
技能可以变得很「长」，而不会拖垮性能：
复杂流程也可以详细写清楚，反而提高执行稳定性和可解释性。

从工程视角看，这更像是把「Prompt 工程」拆成了一个个可独立存储、按需加载的文件，而不是永远堆在系统提示里。

4. Skills 与工具调用、RAG、MCP 有何不同？

很多工程师第一反应是：「这不就是条件化加载的长 Prompt + 工具脚本吗？」
差别在于：Anthropic 把这套实践上升成了一个统一抽象与生态接口。

可以用一张表来粗对比：

方案	核心抽象	主要作用	典型问题	Skills 的关系
传统工具调用	工具 / API	执行具体动作（算、查、调接口）	不包含流程与业务语义	Skill 内可以封装对工具的调用方式
RAG	知识库 + 检索	提供事实知识与上下文	缺少「怎么做」的流程指引	Skill 的说明部分可引用 RAG 结果
MCP / 插件	第三方服务能力	接入外部系统功能	接口统一但行为语义分散	Skills 更偏「工作说明书」，MCP 是「外部 API」
Agent Skills	文件夹 + SKILL.md + 脚本	打包特定任务的完整操作流程与工具	需要最佳实践与生态沉淀	与以上方案互补而非替代

关键区别在于：

工具调用偏「能做什么」；Skill 更强调「应该怎么做」。
Skill 把调用哪些工具、按照什么顺序调用、怎样判断成功、如何兜底等都写清楚。
RAG 解决「知道什么」，Skill 解决「怎么干」。
一个财务分析 Skill 可以用 RAG 查政策和历史报表，但流程和输出格式由 Skill 固定。
MCP / 插件是「通向外部世界的门」，Skill 则像「操作手册 + 自动操作者」。
两者可以组合：Skill 里定义如何调用 MCP，什么时候调用，输入输出如何转换。

从开发者视角，这意味着：你不需要在 Agent 代码里把所有细节写死，而是把大量「如何完成某类任务」迁移到可版本化的 Skill 目录中。

5. Skill 范式的工程价值：从个人效率到组织级资产

如果只把 Skills 看成「高级 Prompt 模板」，就低估了它的工程意义。更有价值的，是它在知识工程与组织资产管理上的作用。

5.1 面向个体：「第二大脑」的可编程化

对个人开发者和独立工程师来说，Skills 提供了一种组织个人经验的方式：

把自己在「代码重构」「写技术 RFC」「评审 PR」「写测试用例」上的套路，拆成一个个 Skill。
日常只要告诉 Agent「按 X Skill 帮我处理这个 PR」，而不是一次次解释个人偏好和边界条件。

长远看，这相当于为自己搭了一层「可执行的工作习惯」，而不是一堆散落在各处的 Prompt 片段。

5.2 面向团队：把 SOP 变成「可执行程序」

在企业场景，更有杀伤力的是把传统意义上的 SOP / 手册 / Wiki，系统性地转成 Skills：

合规审批流程 Skill
包含合规检查要点、必填字段、风险项列表、升级路径与拒绝模板。
内部数据分析 Skill
封装数据源连接、指标定义、常用 SQL 模板与可视化配置。
品牌内容审核 Skill
根据品牌手册、禁用词、审查标准进行自动审核和修订建议。

这样做有几个收益：

新人或非技术员工可以「直接用」，而不是「先看 30 页文档再来问」。
知识更新可以在 Skill 层完成，一次修改，全体 Agent 生效。
知识资产可以跨团队、跨项目流通，形成真正的「组织级复用」。

在这个视角下，Skill 更接近「组织记忆的代码化形式」。

6. 如何从零开始写一个 Skill？

Anthropic 在官方文档和 GitHub 仓库里给出了多个示例与最佳实践，可以抽象出一套通用方法论。

6.1 选一个足够窄但高频的任务

好 Skill 的起点是「一个定义清晰、边界明确、日常高频」的任务，而不是一句模糊的「帮我做增长分析」。例如：

「根据 Jira 任务，生成本周迭代汇总邮件」
「把一堆发票 PDF 整理成标准报销表 Excel」
「按公司文案规范重写产品更新日志」

让 Skill 去覆盖一个可度量的、可验证的输出，有助于迭代。

6.2 把人类的做法拆成结构化步骤

观察一个熟练员工怎么做这件事，然后抽象成步骤：

输入与前置条件检查
信息收集 / 检索
处理与决策逻辑
结果生成与格式化
质量检查与错误处理

把这些写进 SKILL.md，并用清晰标题、列表、示例和「Do / Don’t」形式呈现，模型更容易遵循。

6.3 决定哪些步骤应当「外包给脚本」

不是所有事情都该在模型里「硬算」。典型适合放进 scripts/ 的包括：

解析与生成复杂文件格式（Excel、PDF、PPT、二进制日志）。
重复性强的结构化转换（数据清洗、字段映射）。
调用内部 API、执行 Shell 命令等需要确定性与安全控制的操作。

在 SKILL.md 里，只需要写清「在第 N 步调用 xxx 脚本，输入格式为 X，输出格式为 Y」，以及如何根据脚本输出判断下一步。

6.4 用「示例 + 评估标准」固化预期

Skill 需要自带「什么叫做好结果」的定义，可以包含：

正例 / 反例片段（注意避免敏感数据）。
打分准则：例如合规性、完整性、风格一致性等。
常见错误与对应修正策略。

这不仅帮助模型，更方便人类回顾和迭代 Skill 本身。

7. 安全与治理：技能其实是一种「软件包」

由于 Skill 可以挂脚本、读写文件甚至访问网络，它在安全和合规上的地位，更接近一个软件包，而不是一段无害的 Prompt。

几个必须重视的点：

来源可信与代码审计：
和安装第三方包一样，Skill 仓库也有供应链风险。需要有白名单、签名或内部审核流程。
最小权限原则：
Skill 内脚本应只访问完成任务必需的资源，避免一把钥匙开全公司门的局面。
执行与日志：
对脚本执行进行日志记录，便于溯源与事后审计。
敏感数据脱敏与隔离环境：
在需要处理敏感数据的 Skill 中采用沙箱、脱敏或专用环境，避免无意扩散。

总结起来：把 Skill 当软件工程，而不是当 Prompt 玩具。

8. Skills 的未来：从人写技能，到 Agent 自己长技能

目前大部分 Skill 仍由人类设计和维护，但 Anthropic 在演讲和文章中都明确提到：希望未来的 Agent 能够主动总结自己的成功经验，抽象成新的 Skill。

可能的演进方向包括：

Agent 在重复完成某类任务后，自动归纳出一套稳定流程，并生成草稿版 SKILL.md。
人类只需做最后的审核与微调，而不必从零撰写。
多个 Agent 之间可以共享 Skills，形成类似「技能市场 / 技能 App Store」。

从这一点看，Skills 更像是为下一阶段的「自我改进型 Agent」打地基：
当 Agent 能够通过 Skills 记录和重用自己的经验时，才真正具备持续成长的「程序性记忆」。

9. 写在最后：给今天就在用 LLM 的工程师一些建议

如果你已经在生产环境使用 LLM / Agent，这里有几条非常务实的建议，可作为迁移到 Skill 范式的起点：

先选一个痛点明显的高频任务，做一个 POC Skill，而不是一口气重构所有 Agent。
把现有长 System Prompt 和散落的 SOP、工具说明整理进 Skill 目录，逐步「解耦」逻辑与 Agent 代码。
为团队设定简单的 Skill 规范：命名、目录结构、文档模板、评估方法。
在安全上，把 Skill 当「内部软件包」看待，建立代码审查和权限控制。

从长远看，「一个强大的通用 Agent + 一个不断增长的 Skill 仓库」，比无数孤立、不可维护的垂直 Agent 更有机会成为企业的长期基础设施。

Claude Skills × OpenAI Function Calling × Spring AI Tools × MCP 对照表

维度	Claude Skills	OpenAI Function Calling	Spring AI Tools / Functions	MCP (Model Context Protocol)
核心定位	Agent 的“技能系统”	模型调用函数的接口能力	Java 世界的 Tool / Function 抽象	Agent 能力的运行时协议
抽象层级	高（Agent 行为层）	低（模型 API 层）	中（应用框架层）	很高（跨系统基础设施层）
能力单位	Skill（带语义、上下文、执行逻辑）	Function（结构化输入输出）	Tool / Function（Java 方法）	Server / Capability
谁定义能力	Agent / 开发者	开发者	开发者	外部系统 / 服务
谁决定调用	Agent（模型自主）	模型（在 prompt 约束下）	模型 + 应用框架	Agent（通过协议发现）
是否支持能力发现	✅ 原生支持	❌ 不支持	⚠️ 有限（代码级）	✅ 核心设计目标
是否支持动态更新	✅（Skills Catalog）	❌	⚠️（需重启 / 配置）	✅（Runtime 动态）
是否强调上下文管理	✅ 极强（Skill = Context）	❌ 几乎没有	⚠️ 由应用控制	✅ 明确协议级支持
是否跨语言 / 跨进程	⚠️ 偏 Anthropic 生态	❌ API 级	⚠️ JVM 为主	✅ 原生跨语言
是否面向 Agent 时代	✅ 完全为 Agent 设计	❌ 仍是 LLM 时代产物	⚠️ 向 Agent 过渡	✅ 为 Agent 原生
典型使用场景	复杂自治 Agent	结构化工具调用	Java 业务系统接 AI	企业级 Agent 基础设施