发布时间：2026-07-11
标签：AI Agent｜LLM｜Skills｜Prompt｜概念辨析｜工程实践

---

系列导航

上一篇：AI Agent 工程实践（06）：Knowledge 如何演化成 Rules？
下一篇：AI Agent 工程实践（08）：Workflow——什么时候应该拆成 Multi-Agent？
本文是 [AI Agent 工程实践] 系列的第 07 篇。

---

带新人第一次写 Agent，我让他"把审查逻辑写进系统"。

他回了我一个 2000 字的 system prompt——把每一步该做什么全写进去了。

我问他："那下次要做测试呢？再写 2000 字？"

他愣了："Prompt 不就是 Agent 吗？"

那一刻我意识到，太多人把 Prompt 和 Agent 画了等号。他们以为"会写 prompt"就等于"会做 Agent"。

其实 Prompt 只是 Agent 最小的一个零件。真正的 Agent，是 Prompt、Skill、Rule、Workflow、Memory 共同组装出来的——而 Skill，是其中最容易被人忽略、却最该被重视的那块。

---

本文你将学到

✓ 为什么"Prompt = Agent"是个危险误解
✓ Prompt / Skill / Rule / Workflow / Memory / Agent 六个概念各自的边界
✓ Skill 和 Prompt、Rule、Workflow 到底差在哪
✓ 什么时候该用 Prompt，什么时候该抽成 Skill

适合阅读

✓ 刚接触 Agent 开发、被一堆名词绕晕的新人
✓ 用 Claude Code / Cursor / Coze / Dify 但混淆概念的人
✓ 想系统理解 AI Engineering OS 各层"分别是什么"的人

---

问题背景

前 6 篇把系统的每一层都拆开了讲。但还有一个更基础的混乱没解决：这些名词到底指什么、边界在哪。

我看到的现象是，新人（包括半年前的我）习惯用一个词概括一切：

• 把 system prompt 当 Agent
• 把"很长的 prompt"当 Skill
• 把"一堆规则"当 Workflow
• 把"存了点东西"当 Memory

这种混淆不是文字游戏——它直接导致架构设计错误：该抽 Skill 的塞进 Prompt，该固化成 Rule 的写在 Workflow 里，该持久化的放进会话变量。

一句话：分不清概念，就搭不对系统。 这一篇把六个最容易混的概念，一次性厘清。

---

错误尝试

第一次：一切靠 Prompt

最初我做 Agent，所有能力都塞进一个超长 system prompt：审查逻辑、测试规范、风格要求……全写进去。

结果：和第 02 篇说的一样——prompt 爆炸、不同任务互相干扰、关键约束被淹没。把"所有能力"压进"一句话里"，等于没有能力分层。

第二次：以为 Skill = 更长的 Prompt

吸取教训，那我把 prompt "封装"成 Skill——其实就是把那段 2000 字单独存成文件，调用时整段塞回去。

结果：本质没变。它只是"更长的 prompt"，没有触发条件、没有输入输出契约、不能被其它 Skill 组合、不能按需加载。它没理解 Skill 是"可复用能力单元"，而不是"更长的文字"。

两次尝试指向同一个教训：Prompt 是一次性指令，Skill 是可复用能力——把前者当后者，就是把"一句话"当"一家公司"。

---

关键观察

我把六个概念按"解决的问题"做了一次归位，差异立刻清晰：

概念	它解决什么	生命周期	粒度	例子
Prompt	这次怎么干（一次性指令）	单次对话	一句话/一段	"把这个函改成异步"
Rule	必须/不得做什么（约束）	跨任务常驻	约束	"修改前先 Read 原内容"
Skill	能做什么（可复用能力）	按需加载	能力单元	"代码审查 skill"
Workflow	多步怎么编排（流程）	任务级	流程	"需求→设计→实现→测试"
Memory	记住什么（状态）	会话/长期	数据	用户偏好、项目约定
Agent	谁在执行（主体）	系统级	角色	Claude Code / Hermes

pie title 新人把"Prompt"误当的概念占比
    "以为 Prompt=Agent" : 40
    "以为长 Prompt=Skill" : 30
    "以为规则堆=Workflow" : 20
    "其它" : 10

Prompt 是一次性指令，Skill 是可复用能力——把前者当后者，就是把"一句话"当"一家公司"。

六个概念不是同义词，是不同层级的零件，各自有边界、有生命周期、有职责。

定位真正原因

混淆的根源，是没看清每个概念的生命周期和复用粒度：

• Prompt 活在"一次对话"，用完即弃，解决"这次"
• Rule 常驻"所有任务"，被动生效，解决"必须"
• Skill 按需"加载复用"，主动调用，解决"这类"
• Workflow 编排"多个步骤"，解决"流程"
• Memory 存"状态"，解决"记得住"
• Agent 是"主体"，把以上全部组装并执行

它们是组装关系，不是替代关系。 Agent 不是其中任何一个，而是承载所有、执行任务的那个"壳"。

---

最终方案：六个概念的分层与边界

逐个讲清边界，重点是 Skill 和另外三个的区别。

Skill vs Prompt：一次性 vs 可复用

这是最大的误区。核心差异三处：

维度	Prompt	Skill
复用	一次性，用完即弃	跨任务复用
结构	自由文本	有 trigger / 输入 / 步骤 / 输出契约
组合	不可组合	可被 Workflow 或其它 Skill 调用

Prompt 是"这次怎么干"，Skill 是"这类怎么干"。当你发现同一段 prompt 要写第二次，那就是该抽成 Skill 的信号。

Skill vs Rule：能力 vs 约束

很多人把 Skill 和 Rule 混为一谈，但它们方向相反：

• Rule 是"必须/不得"——被动约束，Agent 不调用它，它也在生效（如 core 常驻）
• Skill 是"能够"——主动能力，Agent 需要时调用它（如代码审查）

Rule 回答"红线在哪"，Skill 回答"工具箱里有什么"。一个限制你，一个赋能你。

Skill vs Workflow：单能力 vs 多步编排

• Skill = 单一能力单元（做一件事做好）
• Workflow = 多个 Skill/工具按序编排（做一串事）

Workflow 是 Skill 的"编排者"，不是 Skill 的"加长版"。一个代码审查 Skill 不能被拉长成"需求到上线"的 Workflow——那是编排，不是能力。

Memory 与 Agent：数据 vs 主体

• Memory 是数据层（03 篇讲过），存状态，不产生行为
• Agent 是执行主体，加载 Rule、调用 Skill、跑 Workflow、读 Memory，最终产出

Agent 不是任何一个零件，它是把所有零件组装起来并执行的那个角色。

实际收益（厘清概念后）

指标	全靠 Prompt	概念厘清后（各归其位）
同类任务开发成本	每次重写 prompt	复用 Skill，零重写
约束可靠性	靠 prompt 里"求它"	Rule 常驻强制
多步任务	人工拼接	Workflow 自动编排
系统可维护性	一团 prompt	各层职责清晰

为主观估算，非严格 A/B Test，但反映了"概念清晰"对架构正确性的直接影响。

---

架构图 / 流程图

六个概念的层级与组装关系

关键点：Prompt 在链最外（一次性触发），Rule/Skill/Workflow/Memory 是 Agent 内部的零件，Agent 是组装它们的主体。Prompt 不是 Agent，而是激活 Agent 的那一下。

何时该抽 Skill（决策流转）

图片多样性：用了 Mermaid 的 pie / flowchart / stateDiagram 三种；发文时可再补一张 ProcessOn/draw.io 版的概念关系图，提升 CSDN 图片多样性得分。

---

代码或配置示例

Skill 的真实结构（对比 Prompt）

Skill 之所以不是"长 prompt"，因为它有结构——带触发条件、输入输出契约、可复用：

# skills/code-review/SKILL.md
name: code-review
trigger:
  task_type: ["review", "refactor"]   # 什么时候该被调用
input:
  - diff: "待审查的代码变更"
output:
  - issues: "问题列表（描述+反例+建议）"
steps:                 # 能力如何被执行，不是一段自由文本
  - 识别设计问题
  - 检查正确性
  - 给出改进建议

对比一个 Prompt——它只有"指令"，没有 trigger / 契约 / steps：

# 纯 Prompt（一次性）
"请审查下面的代码，指出设计问题、正确性问题，并给改进建议。"

同样是"审查"，Skill 能被 Router 自动加载、能被 Workflow 编排、有输入输出契约；Prompt 不能。这就是"一句话"和"一家公司"的差距。

抽 Skill 的判定（伪代码）

def should_extract_skill(prompt_log: list[str]) -> bool:
    """出现≥2次相似 prompt，就该抽成 Skill"""
    similar = group_similar(prompt_log)        # 归并相似指令
    for cluster in similar:
        if len(cluster) >= 2:                  # 第二次出现即触发
            return True
    return False

逻辑极简，但说的是铁律：当你要写第二遍同样的 prompt，就是抽 Skill 的时候。

---

设计权衡

候选方案	优点	缺点	为什么不选
全靠 Prompt	零结构、上手快	不可复用、易膨胀、难维护	规模一大必崩
长 Prompt 当 Skill	封装感	本质还是一次性文本	没触发/契约/组合，空有壳
规则堆当 Workflow	看似流程化	缺编排语义、不可调用	混淆约束与流程
六概念各归其位	复用高、约束可靠、可维护	需先厘清概念成本	选择理由：正确的边界才能长出正确的系统

不是所有都该抽 Skill。 一次性的临时任务，纯 Prompt 就够了——抽成 Skill 反而是过度工程。判断标准就一条：同样的需求会不会出现第二次。 会，就抽；不会，就 Prompt。

---

总结

✅ Prompt ≠ Agent。Prompt 只是激活 Agent 的那一下一次性指令，Agent 是组装所有零件的 execute 主体。
✅ 六个概念是不同层级的零件：Prompt（一次性）/ Rule（约束）/ Skill（能力）/ Workflow（编排）/ Memory（状态）/ Agent（主体）。
✅ Skill 区别于 Prompt：可复用、有触发/契约/步骤、能被组合；区别于 Rule：能力而非约束；区别于 Workflow：单能力而非多步编排。
✅ 抽 Skill 的信号只有一个：同样的 prompt 要写第二遍。
✅ 概念清晰了，架构才不会错——分不清零件，就组装不出机器。

---

参考资料

• Anthropic — Claude Skills 官方文档（[待补链接]）→ Skill 的标准结构与触发机制，本文 Skill 定义的直接依据
• 第 02 篇：为什么 Rules 要分层 → Rule 与 Skill 的边界（约束 vs 能力），本文对比的来源
• 第 03 篇：Memory 设计 → Memory 作为数据层、不产生行为的界定
• 第 05 篇：Rule Router → Skill/Rule 如何被 Router 按需加载，概念在工程里如何运转
• Coze / Dify 工作流文档 → Workflow 编排多步能力的参考实现

---

系列导航

上一篇：AI Agent 工程实践（06）：Knowledge 如何演化成 Rules？
下一篇：AI Agent 工程实践（08）：Workflow——什么时候应该拆成 Multi-Agent？
本文是 [AI Agent 工程实践] 系列的第 07 篇。