Prompt、Skill、Agent 别再混用：从概念到架构的完整指南

1. 三个词被混着用，是大多数项目翻车的起点

Prompt、Skill、Agent 这三个词，现在几乎出现在每一场技术分享、每一份产品文档、每一次团队评审里。但我观察到一个很普遍的现象：很多人嘴上说着 Agent，手里写的其实是一段 Prompt；嘴上说着 Skill，实际交付的是一份提示词模板；等到真正需要做任务编排的时候，又把所有东西塞进一个巨大的 Prompt 里，然后抱怨模型不稳定、输出飘忽、成本失控。

我自己在带项目的过程中，踩过最贵的一个坑，就是把一个本该做成 Skill 的能力，硬写成了 Prompt。当时的需求是让模型按照公司固定的报告格式输出内容，我图省事，把格式规范、字段说明、示例全部塞进系统提示词，结果每次调用都要带上两千多 token 的格式说明，一个月下来光这部分冗余消耗就相当可观，而且一旦格式要调整，所有调用点都得改。后来把这部分抽成独立的 Skill，提示词只保留任务意图，格式规范作为可复用的能力模块单独维护，token 消耗直接降了一半以上，维护成本也下来了。

这篇文章想做的事情很明确：把 Prompt、Skill、Agent 这三个概念从“感觉上差不多”讲清楚到“结构上完全不同”。我会从它们各自解决什么问题、边界在哪里、怎么组合、什么时候该用哪个讲起，配上可以直接参考的结构设计和实操要点。不管你是刚接触这块的新手，还是已经做过几个项目但总觉得架构别扭的开发者，应该都能从中找到对自己有用的部分。核心关键词 Prompt、Skill、Agent 会贯穿全文，但我不会堆砌术语，而是尽量用实际场景把它们讲透。

先说结论，方便你带着框架往下读：Prompt 是意图的表达，Skill 是能力的封装，Agent 是目标的执行。三者不是替代关系，而是层层叠加的关系。搞混它们，就像把菜谱、厨具和厨师混为一谈——菜谱写得再好，没有厨具做不出菜；厨具再全，没有厨师不会自己动。

2. 先把三个概念拆开看：它们各自到底解决什么问题

2.1 Prompt 的本质：一次意图的精确表达

Prompt 最容易被低估，也最容易被滥用。很多人觉得 Prompt 就是“跟模型说的话”，这个理解不算错，但太浅了。从工程角度看，Prompt 的本质是在单次交互中，把任务意图、上下文约束和输出期望压缩成模型能理解的输入。

它有几个非常明确的特征。第一，Prompt 是无状态的，它不记得上一次说了什么，每次调用都是全新的。第二，Prompt 是一次性的，它的生命周期就是这一次请求。第三，Prompt 的效果高度依赖表达质量，同一个任务，换个说法，输出质量可能差出一大截。

这就解释了为什么会有 prompt engineering 这个方向，也解释了为什么会出现 prompt optimizer 这类工具。因为 Prompt 的写法直接决定了模型能不能理解你要什么。我见过太多人写 Prompt 的方式是“把需求一股脑倒进去”，结果模型抓不住重点，输出自然不理想。

一个结构清晰的 Prompt，通常包含这几个部分：角色设定、任务描述、输入数据、约束条件、输出格式。但这里有个常见的误区，就是以为把这些部分都写上就万事大吉。实际上，约束条件和输出格式才是决定稳定性的关键，角色设定更多是锦上添花。我做过对比测试，去掉角色设定，输出质量下降有限；去掉输出格式约束，输出就开始飘。

还有一个绕不开的问题是 token。Prompt 里的每一个字都要消耗 token，而 token 就是成本。热搜里经常出现 prompt token 这个词，说明大家已经开始关注这个成本维度了。一个常见的浪费是：把大量固定不变的说明性内容反复写进每次调用的 Prompt 里。这部分内容如果抽出来做成 Skill，就能省下大量重复消耗。

提示：判断一段内容该不该留在 Prompt 里，问自己一个问题——它在这次调用之后还有复用价值吗？如果有，它大概率不该待在 Prompt 里。

2.2 Skill 的本质：可复用能力的标准化封装

Skill 这个词最近热度很高，从 skill 插件、skill 脚本到各种 skill 编码，讨论很多。但很多人对 Skill 的理解还停留在“一段更长的提示词”这个层面，这是不对的。

Skill 的本质是把某类可复用的能力，封装成有明确输入输出、有独立边界、可以被反复调用的模块。它和 Prompt 最大的区别在于：Prompt 是描述意图，Skill 是封装能力。

打个比方。Prompt 像是你对着厨师说“给我做个番茄炒蛋”，Skill 像是厨房里那套已经配好的番茄炒蛋料理包——里面有处理好的番茄、打好的蛋液、调好的酱汁，厨师拿到就能直接下锅。料理包的好处是什么？标准化、可复用、质量稳定，而且不需要每次重新准备。

一个设计良好的 Skill，通常具备这些特征。它有明确的触发条件，知道什么情况下该被调用。它有清晰的输入契约，知道需要什么参数。它有稳定的输出格式，调用方可以放心依赖。它有独立的维护边界，内部逻辑变化不影响调用方。

这就引出了一个关键的设计原则：Skill 应该按能力维度切分，而不是按任务维度切分。什么意思？比如“生成周报”是一个任务，它可能用到“数据汇总”“格式排版”“语气调整”这几个能力。如果你把“生成周报”整个做成一个 Skill，那这个 Skill 就很难被“生成月报”复用。但如果你把底层能力拆成独立的 Skill，上层任务就可以自由组合。

热搜里提到的 gis 空间分析 skill、codex 论文 skill、打斗动作提示词 skill，其实都是这个思路的体现——把某个垂直领域的能力封装成标准模块。这种做法的价值在于，能力一旦封装好，就可以被不同的 Agent、不同的任务反复调用，边际成本趋近于零。

2.3 Agent 的本质：面向目标的自主执行体

Agent 是三者里最复杂、也最容易被神化的一个。热搜里 agent 架构、agent 框架、agent 开发、agent 记忆、agent 安全这些词频繁出现，说明大家既想搞懂它，又觉得它门槛高。

我的理解是：Agent 的本质是一个能够围绕目标自主规划、调用能力、处理反馈、持续推进的执行体。注意这里的关键词是“自主”和“执行”。Prompt 是被动响应，Skill 是被动调用，只有 Agent 是主动推进的。

一个完整的 Agent 通常包含这几个核心组件：目标理解模块（搞清楚要做什么）、规划模块（拆解成步骤）、能力调用模块（调用 Skill 或工具）、记忆模块（记住做过什么、结果如何）、反馈处理模块（根据结果调整下一步）。

这里要特别说一下 agent 记忆。很多人做 Agent 的时候忽略记忆，结果就是 Agent 每走一步都像失忆一样，无法基于之前的进展做决策。记忆分短期和长期，短期记忆负责当前任务的上下文连贯，长期记忆负责跨任务的经验积累。这两块的设计直接决定了 Agent 能不能处理复杂任务。

还有一个经常被混淆的概念是 harness 和 agent 的区别。简单说，harness 更像是 Agent 的“运行环境”或“测试框架”，它负责给 Agent 提供执行条件、注入能力、收集结果，但本身不做决策。Agent 是决策者，harness 是承载者。搞清楚这个区别，在做架构设计的时候就不会把职责搞混。

注意：Agent 不等于“更长的 Prompt”。如果你写的东西没有规划、没有能力调用、没有反馈循环，那它本质上还是一个 Prompt，只是长了一点。

3. 三者怎么组合：从单点调用到完整系统的演进路径

3.1 组合关系：Prompt 驱动 Skill，Agent 编排全局

理解了三个概念各自的本质，组合关系就清楚了。Prompt 负责表达意图，Skill 负责提供能力，Agent 负责编排执行。这是一个从下到上的支撑关系。

具体来说，Agent 在推进任务的时候，每一步的决策都需要通过 Prompt 来表达，每一步的执行都需要通过 Skill 来落地。Prompt 是 Agent 和模型之间的沟通语言，Skill 是 Agent 和外部能力之间的接口。

我用一个实际场景来说明。假设你要做一个“自动生成竞品分析报告”的系统。如果只用 Prompt，你会写一段很长的提示词，把分析框架、数据来源、输出格式全塞进去，然后祈祷模型能一次做对。这种做法在简单任务上能用，但一旦任务变复杂，稳定性就崩了。

如果用 Skill 的思路，你会把“数据抓取”“数据清洗”“趋势分析”“图表生成”“报告排版”分别封装成独立的 Skill。每个 Skill 有明确的输入输出，可以单独测试、单独优化。这时候 Prompt 只需要负责“告诉模型现在该调用哪个 Skill、传什么参数”。

如果再加上 Agent，整个系统就活了。Agent 会先理解“生成竞品分析报告”这个目标，然后规划出步骤：先抓数据，再清洗，再分析，再生成图表，最后排版。每完成一步，Agent 会根据结果决定下一步怎么做。如果数据抓取失败，它会尝试换一个数据源；如果分析结果异常，它会回溯检查数据质量。这就是 Agent 的价值——它不是执行一条固定路径，而是围绕目标动态调整路径。

3.2 选型判断：什么场景该用哪个

很多人纠结的问题不是“三者有什么区别”，而是“我这个场景到底该用哪个”。我整理了一个判断框架，可以直接对照使用。

这个表的核心逻辑是：能用 Prompt 解决的，不要上 Skill；能用 Skill 组合解决的，不要上 Agent。每往上加一层，复杂度、成本、调试难度都会上升。我见过不少项目，明明一个 Prompt 就能搞定的事情，非要搭一套 Agent 框架，结果开发周期翻了三倍，效果还不如直接写 Prompt。

反过来，也有该上 Agent 却硬用 Prompt 的情况。比如需要多轮工具调用、需要根据中间结果做分支决策的任务，硬塞进一个 Prompt 里，模型很容易在中途“迷路”，输出前后矛盾。这种时候，Agent 的规划能力和记忆能力就是刚需。

3.3 演进路径：从 Prompt 到 Agent 的自然过渡

实际项目中，我建议的演进路径是这样的：先用 Prompt 跑通最小闭环，再把稳定复用的部分抽成 Skill，最后在需要动态决策的地方引入 Agent。

这个路径的好处是，每一步都有明确的收益，不会一上来就陷入过度设计的泥潭。先用 Prompt 验证需求是否成立、模型能力是否够用；验证通过后，把其中重复出现的部分抽成 Skill，降低成本和维护难度；当任务复杂度上升到需要动态规划时，再引入 Agent。

我自己的一个项目就是这么走的。最开始是一个简单的 Prompt，用来生成产品描述。跑了一段时间发现，描述里的格式要求、语气要求、禁用词要求反复出现，于是把这些抽成了一个“产品描述规范”Skill。后来又发现，不同品类的产品需要不同的描述策略，而且需要根据用户反馈动态调整，这时候才引入了 Agent 来做策略选择和效果追踪。整个过程是渐进的，每一步都解决了当时的实际问题，没有为了用新技术而用新技术。

4. 核心细节与实操要点：每个环节的坑和技巧

4.1 Prompt 编写：稳定性的关键在于约束而非描述

写 Prompt 最容易犯的错误，是把大量精力花在“描述任务”上，而忽略了“约束输出”。我做过一个对比实验，同一个任务，一版 Prompt 详细描述任务背景但输出格式模糊，另一版 Prompt 任务描述简洁但输出格式严格约束。结果是第二版的输出稳定性明显更高。

具体来说，输出约束要覆盖这几个维度：格式约束（JSON、Markdown、纯文本）、长度约束（字数范围、条目数量）、内容约束（必须包含什么、禁止包含什么）、风格约束（语气、人称、专业度）。

还有一个实操技巧是用示例代替描述。与其花一百字描述“输出要简洁专业”，不如直接给一个简洁专业的示例。模型对示例的理解能力远强于对抽象描述的理解能力。这就是 few-shot 的核心价值。

关于 prompt 闪退和 invalid prompt 这类问题，通常和输入内容触发了某些限制有关。遇到这种情况，排查思路是：先简化输入，确认是内容问题还是格式问题；再逐步加回内容，定位触发点；最后调整表达方式，用更中性的措辞替换可能引起问题的表述。这类问题的处理经验是，保持输入内容的清晰和中立，避免模糊或容易引起歧义的表达，能规避大部分异常。

4.2 Skill 设计：边界清晰比功能强大更重要

设计 Skill 的时候，最容易犯的错误是“贪大求全”。一个 Skill 什么都想做，结果什么都做不好，而且无法复用。

我的经验是，一个 Skill 只做一件事，并且把这件事做到极致。判断标准很简单：如果你无法用一句话说清楚这个 Skill 的输入和输出，那它就太大了，需要拆。

Skill 的输入契约要尽可能明确。需要什么参数、参数类型是什么、是否必填、默认值是什么，这些都要定义清楚。输出契约同样重要，输出格式、字段含义、异常情况的处理方式，都要有明确约定。这样做的好处是，调用方可以放心依赖，不需要每次调用都去猜。

还有一个容易被忽略的点是 Skill 的版本管理。Skill 一旦被多个调用方依赖，它的变更就会产生连锁影响。所以 Skill 的接口应该保持稳定，内部逻辑可以迭代，但输入输出契约尽量不要破坏性变更。如果必须变更，要做好版本兼容。

热搜里提到的 skill 编码 193、skill 编码 247 这类内容，我理解是在讨论 Skill 的标识和分类体系。在实际项目中，给 Skill 建立清晰的命名和分类规范确实很重要，尤其是当 Skill 数量多起来之后，没有规范就会乱成一团。我的做法是按“领域-能力-版本”三层来命名，比如“report-format-v2”，一看就知道是报告领域的格式能力第二版。

4.3 Agent 架构：规划能力和记忆能力是分水岭

做 Agent 开发，最核心的两个模块是规划和记忆。这两个模块的设计质量，直接决定了 Agent 是“智能”还是“智障”。

规划模块的关键是任务拆解的粒度和动态调整的能力。拆得太粗，每一步都太重，容易失败；拆得太细，步骤太多，容易迷失。我的经验是，拆解到“每一步都有明确的可验证结果”这个粒度比较合适。比如“分析数据”太粗，“计算环比增长率”就比较合适，因为后者有明确的输出可以验证。

动态调整能力体现在：当某一步失败时，Agent 能不能换一种方式重试；当某一步的结果和预期不符时，Agent 能不能回溯检查。这需要 Agent 有失败处理和结果校验的机制。很多 Agent 项目失败，就是因为没有这两块，一旦某一步出问题，整个流程就卡死了。

记忆模块的设计要区分短期和长期。短期记忆负责当前任务的上下文，通常用对话历史或任务状态来维护。长期记忆负责跨任务的经验，需要持久化存储和检索机制。这里有个实操要点：短期记忆要控制长度，长期记忆要控制精度。短期记忆太长会拖慢推理，长期记忆太杂会干扰决策。

关于 agent 安全，这是最近讨论很多的话题。核心关注点是：Agent 调用的能力是否有权限边界、Agent 的决策是否可审计、Agent 的输出是否经过校验。我的做法是给 Agent 的能力调用加一层权限控制，每个 Skill 明确声明自己需要什么权限，Agent 只能在授权范围内调用。同时，关键决策点要有日志记录，方便事后追溯。

4.4 三者协同：接口设计决定系统上限

Prompt、Skill、Agent 协同工作时，接口设计是关键。Prompt 和 Skill 之间的接口是参数传递，Agent 和 Skill 之间的接口是调用协议，Agent 和 Prompt 之间的接口是意图表达。

参数传递要明确类型和格式，避免隐式转换带来的问题。调用协议要定义清楚成功、失败、超时等各种情况的处理方式。意图表达要简洁准确，避免歧义。

我踩过的一个坑是，Agent 调用 Skill 的时候没有定义超时处理，结果某个 Skill 响应慢，整个 Agent 就卡在那里。后来加了超时机制和降级策略，Agent 的稳定性明显提升。这个经验说明，接口设计不只是定义正常流程，更要定义异常流程。

5. 实操过程：从零搭一个三层次协同的最小系统

5.1 需求定义与架构设计

我拿一个具体需求来演示：做一个“自动整理会议纪要”的系统。输入是会议录音转写的文本，输出是结构化的会议纪要，包含议题、结论、待办事项。

先做架构判断。这个任务需要多步骤处理：文本清洗、议题识别、结论提取、待办整理、格式输出。步骤之间有依赖关系，而且需要根据中间结果调整。所以适合用 Agent 编排，Skill 提供能力，Prompt 做意图表达。

架构设计如下：Agent 负责整体流程控制和动态调整；Skill 层包含“文本清洗”“议题识别”“结论提取”“待办整理”“格式输出”五个能力模块；Prompt 层负责每个环节的意图表达和参数传递。

5.2 Skill 层的实现要点

先实现最基础的“文本清洗”Skill。它的职责是去掉转写文本里的语气词、重复内容、无关闲聊，保留有效信息。

输入契约：原始文本（字符串）、清洗强度（枚举：轻度/中度/重度）。输出契约：清洗后文本（字符串）、清洗掉的片段列表（数组）。

实现的时候，清洗强度这个参数很关键。轻度清洗只去语气词，中度清洗额外去重复，重度清洗还会做语义压缩。为什么要分强度？因为不同场景需求不同，有的会议需要保留完整讨论过程，有的只需要结论。把选择权交给调用方，Skill 本身保持通用。

“议题识别”Skill 的输入是清洗后文本，输出是议题列表，每个议题包含标题、相关段落、时间戳。这里有个技巧：让 Skill 输出置信度。每个识别出的议题附带一个置信度分数，Agent 可以根据置信度决定是否需要人工复核。这个设计在实际使用中很有价值，因为会议文本的议题边界往往模糊，有置信度参考，Agent 的决策质量会高很多。

5.3 Agent 层的编排逻辑

Agent 的核心逻辑是一个循环：理解目标、规划步骤、调用 Skill、评估结果、决定下一步。

具体到这个场景，Agent 的初始规划是：调用文本清洗 Skill，然后调用议题识别 Skill，再对每个议题调用结论提取 Skill，然后调用待办整理 Skill，最后调用格式输出 Skill。

但实际执行不会这么顺利。比如议题识别可能返回置信度较低的议题，Agent 需要决定是接受还是重新识别。待办整理可能发现某些待办缺少负责人，Agent 需要标记出来等待补充。这些动态决策就是 Agent 的价值所在。

我的实现里，Agent 有一个“决策规则表”，定义了各种情况的处理策略。比如置信度低于阈值的议题，标记为“待确认”；缺少负责人的待办，标记为“待分配”。这些规则不是硬编码在 Prompt 里，而是作为 Agent 的配置，可以灵活调整。

5.4 Prompt 层的意图表达

Prompt 层的工作是让每个环节的意图清晰传达。以议题识别为例，Prompt 需要告诉模型：现在要做的是从会议文本中识别议题，议题的判断标准是什么，输出格式是什么。

这里的关键是Prompt 要简洁。因为 Skill 已经封装了大部分逻辑，Prompt 只需要表达当前这一步的意图。比如：“从以下文本中识别讨论议题，每个议题包含标题和相关段落，输出 JSON 格式。”就这么简单。

对比一下，如果把所有逻辑都塞进 Prompt，可能会写成几百字的长文，既难维护又浪费 token。分层之后，Prompt 变得轻量，Skill 承担了复杂度，整体结构清晰很多。

5.5 联调与效果验证

系统搭好之后，联调是重头戏。我准备了十份不同风格的会议文本做测试，覆盖正式会议、头脑风暴、一对一沟通等场景。

第一轮测试发现，头脑风暴场景下议题识别效果差，因为讨论发散，议题边界模糊。排查后发现是议题识别 Skill 的提示词偏向正式会议的表达习惯。调整后，增加了对发散讨论的处理逻辑，效果明显改善。

第二轮测试发现，待办整理经常遗漏隐含待办。比如“这个事我们下周再看看”，这其实是一个待办，但表述不明确。解决方法是给待办整理 Skill 增加一个“隐含待办识别”的子能力，专门处理这类模糊表述。

第三轮测试关注稳定性。同样的输入跑十次，看输出是否一致。发现格式输出环节偶尔会出现格式偏差，排查后是 Prompt 里的格式说明不够严格。把格式约束改成用示例代替描述后，稳定性提升明显。

提示：联调阶段一定要做“同输入多次运行”的稳定性测试。单次跑通不代表系统可靠，多次运行结果一致才是真的稳。

6. 常见问题与排查技巧实录

6.1 概念混淆类问题

最常见的问题是分不清什么时候该用哪个。我整理了一个速查表，遇到纠结的时候可以直接对照。

6.2 实操异常类问题

Prompt 相关异常：遇到 invalid prompt 或类似提示时，先检查输入内容是否包含容易引起歧义的表述。处理方法是简化输入、逐步加回、定位触发点。经验是保持输入清晰中立，能规避大部分问题。

Skill 调用异常：常见的是参数不匹配和超时。参数不匹配通常是输入契约定义不清，解决方法是严格定义参数类型和必填项。超时则需要设置合理的超时时间和降级策略，避免单个 Skill 拖垮整个流程。

Agent 决策异常：表现为反复重试同一步骤、或者跳过关键步骤。前者通常是失败处理逻辑有问题，需要检查重试条件是否过于宽松。后者通常是规划模块的步骤依赖没有定义清楚，需要补充步骤间的前置条件。

6.3 性能与成本优化技巧

Prompt 层优化：去掉冗余描述，用示例代替说明，控制上下文长度。一个实用的检查方法是，把 Prompt 里所有“解释性”内容标出来，问自己这些内容能不能移到 Skill 里。

Skill 层优化：合并高频调用的小 Skill，减少调用开销；对耗时 Skill 做结果缓存，避免重复计算；对输出做精简，只返回调用方需要的信息。

Agent 层优化：控制规划粒度，避免过细导致步骤爆炸；设置最大迭代次数，防止无限循环；对低置信度结果做批量处理，减少交互轮次。

6.4 独家避坑经验

第一个坑是过早引入 Agent。我见过一个项目，需求只是“把用户输入分类”，硬是搭了一套 Agent 框架，结果开发两周，效果还不如一个 Prompt。判断标准很简单：如果任务步骤固定、不需要动态调整，就不需要 Agent。

第二个坑是Skill 粒度过细。有人把每个小操作都做成 Skill，结果一个简单任务要调用十几个 Skill，调用开销比任务本身还大。Skill 的粒度应该以“有独立复用价值”为准，没有复用价值的不要单独拆。

第三个坑是忽略记忆设计。Agent 没有记忆，就像人没有记性，每一步都要重新理解上下文。短期记忆和长期记忆都要有，短期保证当前任务连贯，长期保证经验积累。

第四个坑是不做稳定性测试。单次跑通就上线，结果实际使用中输出飘忽。一定要做同输入多次运行的测试，观察输出一致性。一致性不达标，说明约束不够，需要加强。

7. 我个人的一些实践体会

做了几个项目之后，我对这三个概念最大的体会是：它们不是技术选型问题，而是思维方式问题。Prompt 思维是“我要说什么”，Skill 思维是“我能提供什么能力”，Agent 思维是“我要达成什么目标”。这三种思维方式对应三种不同的系统设计哲学。

实际项目中，我越来越倾向于“能用简单方案解决就不用复杂方案”。一个 Prompt 能搞定的，绝不拆成 Skill；几个 Skill 能组合搞定的，绝不引入 Agent。因为每加一层，调试成本、维护成本、沟通成本都会上升。技术的价值在于解决问题，不在于用了多少新概念。

另一个体会是，接口设计比内部实现更重要。Prompt 和 Skill 之间的接口、Skill 和 Agent 之间的接口，这些边界定义清楚了，整个系统就清晰了。边界模糊，内部实现再好也会乱。我现在做设计的时候，会先花时间把接口定义清楚，再动手写实现。

最后分享一个小技巧：如果你不确定某个能力该做成 Prompt 还是 Skill，先把它写成 Prompt，用一段时间。如果发现它反复出现、反复调整、反复消耗 token，那就说明它该被抽成 Skill 了。让实际使用情况告诉你答案，比一开始就纠结架构更有效。这个内容后续还可以这样扩展：把 Skill 的版本管理和灰度发布机制做起来，让能力迭代更平滑；把 Agent 的决策日志做成可视化面板，方便排查问题和优化策略。