Prompt、Skill 与 Agent 有什么区别：面向产品研发的工作性拆分

本文采用的是基于所列项目与资料的工作性理解，不是行业统一定义。不同平台对 Prompt、Skill、Agent 的命名和边界并不完全一致；下文的区分，主要服务于 AI 应用、网站、小程序与产品研发中的可执行判断。

先给一个可落地的工作性区分

如果从产品设计角度快速区分，本文建议这样理解：

• Prompt：一次任务的文字入口。你明确给模型一段指令，让它按这个方式完成当前任务。
• Skill：一组可复用、可按需加载的任务知识与流程封装。它不是每次都全部进入上下文，而是先暴露“我会什么”，在需要时再展开细节。[1][3]
• Agent：能够围绕目标持续行动的执行主体。它不仅接收指令，还会在任务过程中选择是否调用 Skill、是否使用工具，以及如何把多步过程串起来。[1][3]

这个区分的关键，不在名词本身，而在三个维度：

1. 谁来触发
2. 知识何时进入上下文
3. 能力是“写在提示里”，还是“可持续组织与执行”

Prompt：适合直接表达当前任务

根据 Claude 官方文档，Skill 与 Prompt 的一个直接区别是：Prompt 更接近“会话级的一次性指令”，适合 one-off task，也就是当前这次对话里要做的具体事情；Skill 则被设计为可复用资源，用来减少跨对话反复输入相同指导。[3]

这意味着在产品里，Prompt 更像：

• 一个输入框里的用户请求
• 一个预设模板
• 一个 slash command 对应的说明文本
• 某个页面、按钮、工作流节点上的“立即执行指令”

从给定资料看，社区讨论里也有一个接近的说法：Prompt 是结构化文本，通常由用户显式调用；它可以指导或建议工具使用，但它本身更像“你现在要怎么做”的直接说明。[2]

Prompt 的优点

• 上手成本低
• 适合临时任务
• 易于在前端界面里暴露给用户
• 适合 A/B 测试不同表达方式

Prompt 的局限

如果把大量稳定流程、长说明、例外规则、格式规范都塞进 Prompt，会出现两个研发层面的常见问题：

• 上下文变重：每次都把整套规则重复放进去
• 复用性变差：同一套能力散落在多个 Prompt 版本里，难维护

因此，Prompt 适合作为入口，但不一定适合作为长期承载复杂任务知识的唯一形态。

Skill：适合沉淀“可复用的做法”

Anthropic 对 Skill 的描述比较具体：Skill 是一种基于文件系统的可复用资源，用于给 Claude 提供特定领域的工作流、上下文和最佳实践，从而把通用 Agent 变成更专业的执行者。[3]

在 Anthropic 的工程文章里，这个结构更进一步被解释为：一个 Skill 最简单可以是一个包含 SKILL.md 的目录，文件开头有 YAML frontmatter，并至少包含 name 和 description。Agent 启动时，会先把每个已安装 Skill 的 name 和 description 预加载到 system prompt 中。[1]

这件事很重要，因为它说明 Skill 并不是“所有内容一上来全部塞进上下文”。官方描述的是一种progressive disclosure 机制：

• 第一层：只先加载元数据，让 Agent 知道“有哪些 Skill 存在、什么时候该用”[1][3]
• 第二层：当 Agent 判断当前任务相关时，再把对应 SKILL.md 正文读入上下文[1][3]
• 还可以继续引用附加文件，把更细的说明拆出去，只在更具体场景下读取[1]

Skill 与 Prompt 的核心差异，不只是“能不能复用”

很多团队会把 Skill 理解成“更长的 Prompt”。这个理解不算完全错，但不够实用。

按照给定资料，Skill 更值得关注的差异是：

1. Skill 是按需加载，不是默认全量加载

Claude 文档明确写到：启动时只加载元数据，因此可以安装很多 Skill，而不会马上带来完整上下文成本；Claude 只知道每个 Skill 的存在以及何时使用。[3]

这和把一整套规则永久写进 system prompt 不一样。

2. Skill 承载的是程序化知识

官方文档把 SKILL.md 正文描述为 procedural knowledge，也就是流程、最佳实践和操作指导。[3]

换句话说，Skill 更适合沉淀这类内容：

• 某个垂直任务的步骤顺序
• 特定输出格式的检查清单
• 某种工具组合的推荐用法
• 常见异常情况的处理方式

3. Skill 可以带附加资源

Anthropic 工程文中明确提到，Skill 不只是一份主文档，还可以和额外文件一起打包。例如核心 SKILL.md 之外，再放 reference.md、forms.md，让 Agent 在更具体任务里再读取。[1]

这使 Skill 更接近“能力包”而不是单条提示词。

Agent：重点不是提示词，而是持续协调执行

在本文的工作性理解里，Agent 最核心的特征不是“有个对话框”，而是它会围绕目标持续推进任务。

结合资料，可以把 Agent 理解为：

• 它知道当前目标是什么
• 它能看到有哪些 Skill 可用[1][3]
• 它会判断何时读取某个 Skill 的完整内容[1][3]
• 它可能会进一步使用工具来完成步骤

也就是说，Prompt 是你给出的任务表达，Skill 是它可调用的知识封装，Agent 是把任务、知识和工具串起来的执行层。

这也是为什么在 Anthropic 的工程描述里，Skill 的设计对象不是“单次回答”，而是“equip agents for the real world”。[1]

Skill 不等于 Tool，Agent 也不等于 Skill

这是研发中最容易混淆的一层。

给定资料里，非官方讨论有一个有用的观察：工具更像直接能力接口，例如 shell、API 连接、数据库访问；而 Skill 编码的是“如何把这些能力用于特定工作流”的知识。[4]

虽然这段来自博客观察，不能直接当作行业结论，但作为产品拆分方法，它很有参考价值。结合官方文档，我们可以做一个更稳妥的工作性区分：

• Tool：让模型“能做某事”的接口能力
• Skill：让模型“更知道该怎么做”的流程知识与上下文封装[1][3]
• Agent：在具体任务里组织是否调用 Tool、是否读取 Skill、如何继续执行的主体

一个简单例子：

• 你给模型一个“读取网页”的工具，这属于 Tool
• 你再给它一个“竞品页面拆解 Skill”，里面写明抓取顺序、字段结构、输出模板、异常页面处理，这属于 Skill
• 最终负责接收“帮我分析这 5 个官网”的那个系统，是 Agent

从触发方式看三者差异

如果你在做网站后台、企业知识助手、小程序内 AI 功能，最实用的判断之一是：用户是否需要显式触发。

给定来源中的讨论提到，Prompt 往往由用户显式调用，而 Skill 可以被 Agent 自动激活。[2] 官方文档虽然没有用完全相同的话，但其“预加载元数据、按需触发正文”的机制，确实支持这种产品设计方式。[1][3]

因此可以考虑这样理解：

这个表不是标准定义，而是本文为了产品设计做的工作性归纳。

为什么这个区分对产品研发有用

如果不区分 Prompt、Skill、Agent，常见后果是把所有问题都丢给“改提示词”。但很多问题其实不是提示词问题，而是系统结构问题。

什么时候该继续写 Prompt

如果你的需求符合以下条件，通常先不要急着设计 Skill：

• 任务低频
• 规则很短
• 不需要跨会话复用
• 用户愿意显式选择模板
• 不依赖复杂步骤或附加资料

例如：

• 帮用户生成一段商品描述
• 把一段会议记录压缩成摘要
• 按固定风格改写标题

这类需求往往用 Prompt 就够了。

什么时候更适合沉淀为 Skill

如果出现以下特征，可以考虑把能力从 Prompt 提升为 Skill：

• 同一类任务反复出现
• 需要较长的流程说明
• 依赖参考文档、规范、样例或检查清单
• 不希望每次都把全部说明灌进上下文
• 希望 Agent 能自动判断“这次该不该使用这套知识”

这与官方文档强调的优势是一致的：Skill 可复用、按需加载，并减少在多个会话中重复提供同样指导。[3]

例如在垂直数字化场景里：

• 内容审核辅助的规则整理
• 电商商品信息结构化流程
• 客服工单归类与回复草拟流程
• 网站页面巡检与问题记录格式

这些都更像“长期维护的做法”，而不只是一次对话里的文案。

什么时候你其实需要的是 Agent 设计

有些团队明明遇到的是 Agent 问题，却一直在改 Prompt 或 Skill。

如果你面对的是下面这些问题，可以优先检查 Agent 层：

• 任务需要多步推进，而不是一次生成
• 需要在多个工具之间切换
• 需要根据中间结果调整下一步
• 需要判断何时读取哪一个 Skill
• 需要长期维护执行状态、任务队列或人工接管节点

这时，Prompt 和 Skill 都只是组件；真正决定体验上限的是 Agent 的编排逻辑。

一个面向研发的三层模型

为了方便团队协作，本文建议把三者拆成三层：

第一层：交互层，用 Prompt 表达用户意图

这一层解决的是：

• 用户怎么提需求
• 前端给用户哪些模板入口
• 不同页面如何组织提问方式

目标是降低输入门槛，而不是承载全部规则。

第二层：能力知识层，用 Skill 沉淀稳定流程

这一层解决的是：

• 哪些任务值得长期复用
• 哪些知识应该模块化维护
• 哪些附加资料要和主流程拆开

Anthropic 提供的 progressive disclosure 机制，对这一层很有启发：先暴露能力名与描述，再按需加载正文和附加文件。[1][3]

第三层：执行编排层，用 Agent 组织行动

这一层解决的是：

• 当前目标拆几步
• 先读哪个 Skill
• 什么时候调用工具
• 出错时怎么回退或请求用户补充

把这三层分开后，很多“模型不稳定”的问题会更容易定位。

对网站和小程序产品的具体建议

以下内容属于我们的建议，不是来源中的统一结论。

1. 不要把所有经验都写进系统提示

如果你已经有很多稳定流程，优先考虑模块化。按照官方 Skill 机制的思路，至少在内部设计上把“能力名/用途说明”和“详细流程说明”拆开，会比把所有内容永久堆在全局提示里更容易维护。[1][3]

2. 把高频任务从 Prompt 升级为 Skill 候选

可以用一个简单标准筛选：

• 过去一段时间里是否反复出现
• 是否每次都要贴相同说明
• 是否需要样例、规范或参考资料
• 是否存在明显步骤顺序

满足越多，越值得做 Skill 化。

3. 先设计“何时触发”，再设计“写什么内容”

Skill 的关键不只是内容质量，还包括 Agent 能否判断何时使用。因为官方机制本身就依赖元数据先进入 system prompt，再决定是否加载正文。[1][3]

所以写 Skill 时，name 和 description 的可判别性非常重要。[1]

4. 把 Skill 当成产品资产，而不是聊天技巧

从官方结构看，Skill 已经接近一种可维护资源：有目录、有主文件、有元数据、可附带其他文件。[1] 这意味着它更适合进入版本管理、评审和更新流程，而不是只存在某个同事的聊天收藏夹里。

5. 不要把 Agent 概念滥用到所有 AI 功能上

如果一个功能只是“用户点按钮，模型返回一段结果”，那它未必真的需要 Agent。给简单功能贴上 Agent 标签，通常不会自动提高体验，反而可能让架构变复杂。

更稳妥的做法是先问：

• 它有没有持续执行过程？
• 会不会自主决定读取哪类知识？
• 需不需要跨步骤协调工具和状态？

如果没有，可能 Prompt 或 Skill 就足够了。

一个简明结论

基于当前资料，本文的工作性理解是：

• Prompt 解决“这次要做什么”
• Skill 解决“这类事通常怎么做，并且只在需要时加载”[1][3]
• Agent 解决“谁来把目标、知识和工具组织成持续执行”

对产品研发来说，三者不是互斥关系，而是不同层次的设计对象。

如果你在做 AI 网站、小程序或企业内部数字化工具，一个很实用的判断方式是：

• 临时任务，先用 Prompt
• 高频、稳定、可复用流程，沉淀成 Skill
• 多步执行、需要协调工具和状态的任务，再上 Agent

这样拆分，通常比笼统地讨论“提示词工程”更接近真正可落地的系统设计。