1. 三个概念为什么总被混为一谈刚接触大模型应用开发那阵子我也被这三个词绕晕过。打开任何一个技术社区满屏都是 Prompt、Skill、Agent有人拿它们当同义词用有人又把它们对立起来讲结果越看越糊涂。后来自己动手做了几个项目踩了不少坑才慢慢把这三者的边界摸清楚。这篇文章就从一个一线开发者的视角把这三个概念的区别、联系、各自适用的场景以及实际落地时容易踩的坑一次性讲透。先说结论Prompt 是“怎么说”Skill 是“会什么”Agent 是“做什么”。这三者不是同一维度的东西更不是互相替代的关系而是从微观到宏观、从静态到动态的三层结构。你把它们理解成“一句话”“一套本事”“一个干活的系统”基本就不会跑偏。为什么大家容易混淆因为在实际项目里这三者经常同时出现而且边界模糊。比如你写一个 Agent里面必然有 Prompt也可能调用 Skill。从外面看用户只跟 Agent 交互看不到里面的 Prompt 和 Skill所以很容易把整个系统的能力都归到“Agent”头上。反过来有些场景其实只需要一个精心设计的 Prompt 就能解决但有人非要套一个 Agent 框架结果复杂度上去了效果反而没提升。我见过太多团队在这上面走弯路。有个朋友做客服自动回复一开始上来就搭 Agent 架构接了一堆工具结果调试了两周发现80% 的问题用一个结构化 Prompt 就能搞定剩下的 20% 才需要 Agent 调度。这就是没搞清楚三者区别的代价。所以不管你是刚入门的新手还是已经做过几个项目的开发者把这几个概念理清楚对技术选型和架构设计都有直接帮助。下面我按“从静到动、从简到繁”的顺序逐个拆解。2. Prompt最基础也最容易被低估的一层2.1 Prompt 到底是什么Prompt 就是你给模型的那段输入文本。它可以是一句话也可以是一大段结构化的指令。从技术角度看Prompt 是模型推理的起点模型根据你给的这段文字预测接下来最可能出现的 token 序列。所以 Prompt 的质量直接决定了模型输出的质量。很多人觉得 Prompt 很简单不就是“问问题”吗其实远不止。一个成熟的 Prompt 通常包含这几个部分角色设定、任务描述、上下文信息、输出格式要求、约束条件、示例。这六块缺一块效果可能就差一截。举个例子你要模型帮你写一封商务邮件。如果只说“帮我写封邮件”模型只能瞎猜。但如果你说“你是一位有十年经验的商务拓展经理需要给合作方写一封项目延期说明邮件语气要诚恳但不卑微控制在 200 字以内结尾附上新的时间节点”输出质量立刻不一样。这就是 Prompt 工程的价值。2.2 Prompt 的核心要素拆解我把一个高质量 Prompt 的构成拆成六个要素你可以对照检查自己写的 Prompt 缺了什么要素作用缺失后果角色设定限定模型的知识范围和语气输出泛泛而谈没有专业深度任务描述明确要做什么模型不知道你要什么答非所问上下文提供背景信息输出脱离实际场景输出格式规定结果的结构每次格式都不一样难以程序化处理约束条件划定边界输出超范围内容需要反复纠正示例给出参考样本模型理解偏差需要多轮调试这六个要素不是每个 Prompt 都必须全有但缺得越多你需要的调试轮次就越多。我个人的经验是任务描述和输出格式这两个是刚需其他四个根据场景增减。2.3 Prompt 的常见坑与优化技巧说几个我踩过的坑。第一个是指令冲突。比如你既要求“详细解释”又要求“控制在 50 字以内”模型就会左右为难输出质量不稳定。解决办法是把要求分层主指令放前面约束放后面并且明确优先级。第二个是上下文过长导致注意力稀释。现在模型上下文窗口动辄几十万 token但不代表你塞得越多越好。实测下来关键信息放在 Prompt 的开头和结尾模型捕捉得最准中间部分容易被忽略。所以如果你有一段很长的参考资料最好把最相关的部分摘出来放在显眼位置。第三个是格式要求不具体。你说“用 JSON 输出”模型可能给你带 markdown 代码块的 JSON也可能给你纯 JSON。你得明确说“直接输出 JSON不要任何额外文字和代码块标记”。这种细节不写清楚后面程序解析就得多写一堆容错逻辑。提示写 Prompt 的时候把自己当成在给一个聪明但完全不了解你业务的新人交代任务。你觉得“这还用说”的地方往往就是模型出错的地方。2.4 Prompt 的能力边界Prompt 能解决很多问题但它有明确的天花板。Prompt 无法让模型获取它训练数据里没有的信息也无法让模型执行它做不到的操作。比如你让模型查今天的天气它只能瞎编除非你通过外部手段把天气信息喂给它。这就是 Prompt 的边界。另外Prompt 是一次性的、静态的。你写好了它就在那里不会自己变化。如果任务需要多步骤、需要根据中间结果调整策略单靠一个 Prompt 就很吃力。这时候就需要引入 Skill 和 Agent 的概念。3. Skill把能力封装成可复用的模块3.1 Skill 的本质是什么Skill 这个词在不同平台上有不同叫法有的叫插件有的叫工具有的叫函数。但本质是一样的Skill 是一段封装好的、可被调用的能力单元。它可以是调用一个外部 API可以是执行一段代码可以是查询一个数据库也可以是触发一个工作流。打个比方Prompt 像是你跟助理说的话Skill 像是助理手边的一本操作手册。你说“帮我查一下上个月的销售数据”助理翻到手册里“查询销售数据”那一页按步骤操作把结果拿回来。这个“手册里的一页”就是 Skill。Skill 的核心价值在于复用和解耦。你把“查天气”这个能力封装成一个 Skill任何需要查天气的场景都可以调用它不用每次都重新写一遍 Prompt 去教模型怎么查。同时Skill 把“能力实现”和“能力调用”分开了模型只需要知道“有这个 Skill 可用”不需要知道它内部怎么实现的。3.2 Skill 的典型结构一个完整的 Skill 通常包含三部分描述、参数定义、执行逻辑。描述是给模型看的告诉模型这个 Skill 是干什么的、什么时候该用。参数定义规定了调用这个 Skill 需要传什么信息。执行逻辑是实际干活的代码模型看不到也不需要看到。以“查询订单状态”这个 Skill 为例{ name: query_order_status, description: 根据订单号查询订单的当前状态包括已下单、已发货、已签收、已取消, parameters: { order_id: { type: string, description: 订单编号格式为 ORD 开头加 12 位数字 } } }模型看到这个描述就知道当用户问“我的订单到哪了”的时候应该调用这个 Skill并且需要从用户的话里提取出订单号。至于这个 Skill 内部是查数据库还是调接口模型完全不关心。3.3 Skill 设计的关键原则设计 Skill 有几个原则我按重要性排序第一描述要精准。描述写得好不好直接决定模型会不会在正确的时机调用它。描述里要写清楚“做什么”和“什么时候用”但不要写“怎么做”。我见过有人把描述写成一段技术文档模型反而不知道该不该用。第二参数要少而精。参数越多模型提取的出错率越高。能用一个参数解决的不要用三个。如果确实需要多个参数尽量给每个参数明确的格式说明和示例。第三粒度要适中。Skill 太细模型需要调用很多次才能完成一个任务容易出错Skill 太粗内部逻辑复杂调试困难。我的经验是一个 Skill 对应一个原子操作比如“查订单”“改地址”“取消订单”各是一个 Skill而不是做一个“处理订单所有操作”的大 Skill。第四要有错误处理。Skill 执行失败的时候要返回清晰的错误信息让模型知道是参数错了、还是服务不可用、还是权限不够。这样模型才能决定是重试、还是换个方式、还是告诉用户。3.4 Skill 与 Prompt 的配合方式Skill 不是替代 Prompt 的而是跟 Prompt 配合的。Prompt 负责“理解意图和决策”Skill 负责“执行具体操作”。模型在 Prompt 的引导下判断是否需要调用 Skill、调用哪个 Skill、传什么参数然后 Skill 执行完把结果返回给模型模型再根据结果生成最终回复。这个配合过程有个关键点Skill 的返回结果也需要被 Prompt 处理。比如 Skill 返回了一堆原始数据模型需要把它整理成用户能看懂的话。如果返回结果格式混乱模型整理起来也费劲。所以 Skill 的输出最好也是结构化的方便模型理解。注意Skill 的调用是有成本的。每次调用都意味着一次额外的网络请求或计算而且会增加 token 消耗。所以不要设计那种“为了用而用”的 Skill能靠 Prompt 直接解决的就别绕一圈。4. Agent让模型自己决定怎么干4.1 Agent 的核心特征Agent 跟前面两者的最大区别在于自主性。Prompt 是你告诉模型怎么做Skill 是你给模型提供工具而 Agent 是模型自己决定用什么工具、按什么顺序、做到什么程度。一个 Agent 通常包含四个部分目标、记忆、规划、工具。目标是你给它的任务记忆是它记住的上下文和历史规划是它拆解任务的能力工具就是它可以调用的 Skill 集合。举个实际例子。你让 Agent“帮我安排下周去北京的出差”。它会自己拆解先查航班再查酒店再根据会议时间调整行程最后生成一份行程表。这个过程中它可能调用查航班的 Skill、查酒店的 Skill、查日历的 Skill中间还会根据结果调整策略。比如航班只有早上的它就会把酒店订在会议地点附近减少通勤时间。这些决策不是你在 Prompt 里写死的而是 Agent 自己做的。4.2 Agent 的常见架构模式目前主流的 Agent 架构有这么几种ReAct 模式是最常见的。它的核心是“思考-行动-观察”循环。Agent 先思考当前该做什么然后执行一个动作观察结果再思考下一步。这个模式简单直接适合大多数任务。Plan-and-Execute 模式是先制定完整计划再逐步执行。适合步骤明确、依赖关系清晰的任务比如数据处理流水线。Multi-Agent 模式是多个 Agent 协作各负责一部分。比如一个负责收集信息一个负责分析一个负责生成报告。这种模式适合复杂任务但协调成本高容易出乱子。我个人的建议是新手从 ReAct 模式入手理解 Agent 的基本运作方式再根据实际需求考虑要不要上更复杂的架构。很多场景下ReAct 已经够用了。4.3 Agent 的记忆机制记忆是 Agent 区别于单次 Prompt 调用的关键。没有记忆Agent 每次都是从零开始无法积累上下文。Agent 的记忆通常分短期和长期两种。短期记忆就是当前对话的上下文存在上下文窗口里。长期记忆则是持久化的可能存在数据库、向量库或者文件里。当 Agent 需要回忆之前的信息时就从长期记忆里检索出来放进当前上下文。这里有个坑记忆不是越多越好。你把所有历史都塞进上下文不仅浪费 token还会干扰模型判断。好的做法是只检索跟当前任务相关的记忆并且定期总结和压缩历史信息。4.4 Agent 的适用边界Agent 很强但不是万能的。Agent 适合那些步骤不固定、需要根据中间结果调整策略的任务。如果任务步骤是固定的用工作流引擎就够了不需要 Agent。如果任务只需要一次模型调用用 Prompt 就够了也不需要 Agent。我见过不少项目明明是一个固定流程非要套 Agent结果调试成本翻倍稳定性还下降。判断标准很简单如果任务的执行路径可以提前画成流程图那就不需要 Agent。只有当执行路径取决于运行时的具体情况Agent 才有价值。5. 三者关系与选型决策5.1 从微观到宏观的层次关系把三者放在一起看它们是一个层层递进的关系层次概念核心问题类比微观Prompt怎么说一句话中观Skill会什么一套本事宏观Agent做什么一个干活的系统Prompt 是基础没有好的 PromptSkill 和 Agent 都发挥不出效果。Skill 是能力的封装让 Agent 有工具可用。Agent 是调度中心决定什么时候用什么 Skill、怎么组合 Prompt。这三者不是互斥的而是共存的。一个成熟的 Agent 系统里Prompt 负责意图理解和结果生成Skill 负责具体操作Agent 负责整体调度。你不可能只用其中一层就搞定复杂任务。5.2 选型决策树实际项目里怎么选我总结了一个简单的决策路径第一步问自己这个任务需要外部信息或操作吗如果不需要纯靠模型知识就能回答那一个 Prompt 就够了。比如“解释一下什么是机器学习”不需要 Skill也不需要 Agent。第二步如果需要外部信息问这个操作是固定的吗如果是固定的比如“查天气”“查订单”那就封装成 Skill用 Prompt 引导模型调用。这时候还不需要 Agent。第三步如果操作不固定需要根据情况决定调用哪些 Skill、按什么顺序那就上 Agent。比如“帮我规划一次旅行”需要查航班、查酒店、查景点、比价、调整行程这些步骤的顺序和组合取决于具体情况Agent 才能处理。这个决策路径能帮你避免过度设计。很多项目其实停在第二步就够了硬上 Agent 只会增加复杂度和不确定性。5.3 常见误区澄清有几个误区特别常见我逐个说清楚误区一Agent 一定比 Prompt 好。不对。Agent 的自主性带来灵活性的同时也带来了不确定性。同样的输入Agent 可能每次走的路径都不一样这在需要稳定输出的场景里是缺点。误区二Skill 越多越好。不对。Skill 太多模型选择困难调用出错率上升。而且每个 Skill 都需要维护成本不低。宁可少而精不要多而杂。误区三Prompt 工程过时了。完全不对。Prompt 是基础Agent 和 Skill 都建立在 Prompt 之上。Prompt 写不好Agent 的规划能力再强也白搭。误区四三者必须一起用。不对。根据场景选最合适的方案能用简单的就别用复杂的。技术选型的第一原则是够用就好。6. 实操中的问题排查与经验总结6.1 常见问题速查表问题现象可能原因排查方向模型不调用 SkillSkill 描述不清晰检查描述是否说明了使用场景调用参数错误参数定义不明确补充参数格式说明和示例Agent 循环调用缺少终止条件设置最大迭代次数和退出条件输出格式不稳定Prompt 约束不够增加格式示例和明确约束上下文超限记忆检索过多优化检索策略压缩历史响应速度慢Skill 调用过多合并 Skill 或减少调用次数6.2 我踩过的几个坑第一个坑是Skill 描述写得太技术化。我一开始写 Skill 描述习惯性地写“调用 XX 接口传入 XX 参数”结果模型根本不理解什么时候该用。后来改成“当用户询问订单状态时使用”调用准确率立刻上去了。描述是给模型看的不是给程序员看的要用模型能理解的自然语言。第二个坑是Agent 没有设置最大迭代次数。有一次测试一个 Agent它陷入了一个循环反复调用同一个 Skill烧了一堆 token 才停下来。后来我加了硬性限制最多迭代 10 次超过就强制退出并返回当前结果。这个保护机制是必须的。第三个坑是Prompt 里的示例太少。我一开始觉得给一两个示例就够了后来发现对于格式要求严格的场景示例至少要给三个覆盖正常情况、边界情况、异常情况。示例多了模型输出的稳定性明显提升。第四个坑是忽略 token 成本。Agent 每次调用都要把上下文、Skill 描述、历史记录都带上token 消耗比单次 Prompt 调用高好几倍。如果不做优化成本会失控。我的做法是定期清理无关历史Skill 描述尽量精简能缓存的就缓存。6.3 性能优化的几个实用技巧Prompt 层面把最关键的指令放在开头和结尾中间放参考资料。实测下来模型对首尾信息的注意力最高。Skill 层面把常用的 Skill 放在列表前面减少模型搜索成本。Skill 的返回结果尽量精简只返回必要字段不要一股脑全丢回去。Agent 层面设置合理的迭代上限一般 5 到 10 次就够了。超过这个次数还没完成大概率是任务定义有问题继续迭代也是浪费。缓存层面对于重复性高的查询加一层缓存。比如同一个订单号查了三次后两次直接返回缓存结果不用再调 Skill。6.4 一个完整的选型案例最后分享一个我实际做过的案例。需求是“帮用户解答产品使用问题”。我一开始的方案是纯 Prompt把产品文档塞进上下文让模型根据文档回答。效果还行但有两个问题一是文档太长token 消耗大二是模型有时候会编造文档里没有的内容。后来改成 Skill 方案把产品文档做成检索 Skill用户提问时先检索相关段落再把检索结果和问题一起给模型。这样 token 消耗降下来了回答也更准确因为模型只基于检索到的内容回答。再后来发现有些问题需要多步操作比如“我的账号为什么登录不了”需要先查账号状态再查最近登录记录再查是否有异常。这时候就上了 Agent让它自己决定查哪些信息、按什么顺序查。最终方案是三者结合Agent 负责调度Skill 负责查数据Prompt 负责生成回答。每个部分各司其职整体效果比任何单一方案都好。这个案例说明三者不是选一个用而是根据任务复杂度组合使用。简单任务用 Prompt中等任务加 Skill复杂任务上 Agent。关键是别一上来就上最复杂的方案从简单开始遇到瓶颈再升级。提示每次升级方案之前先问自己“当前方案的具体瓶颈是什么”。如果说不清楚瓶颈那大概率不是方案的问题而是 Prompt 或者 Skill 设计的问题。6.5 关于 token 消耗的补充说明token 是模型处理文本的基本单位可以粗略理解为“字或词的一部分”。中文里一个汉字大约对应一到两个 token英文一个单词大约对应一个多 token。Agent 和 Skill 的调用都会增加 token 消耗因为每次调用都要把上下文、工具描述、历史记录重新传给模型。控制 token 消耗的几个实用方法一是精简 Skill 描述去掉冗余说明二是限制历史记录长度只保留最近几轮对话三是对长文档做摘要或检索不要全文塞入四是设置 Agent 的最大迭代次数避免无限循环。这些方法组合使用能把 token 成本控制在合理范围内。6.6 关于 Agent 安全的一点经验Agent 有自主调用工具的能力这意味着它可能执行一些你没预期的操作。比如你给了它删除文件的 Skill它可能在某种情况下真的去删。所以权限控制很重要敏感操作要加确认机制危险操作要限制调用条件所有操作要有日志记录。我的做法是给 Skill 分级别只读类操作可以直接调用写入类操作需要二次确认删除类操作默认禁用或者需要人工审批。这样即使 Agent 判断失误也不会造成不可逆的后果。另外Agent 的输入输出都要做过滤。输入侧防止恶意指令注入输出侧防止敏感信息泄露。这些安全措施在开发阶段可能觉得麻烦但上线之后能避免很多问题。6.7 关于 Skill 编码和版本管理Skill 多了之后管理是个问题。我建议给每个 Skill 一个唯一编码比如“skill_001”这种方便追踪和引用。同时做好版本管理Skill 更新之后要记录变更内容避免旧版本调用出错。如果团队协作Skill 的接口定义要提前约定好参数格式、返回格式、错误码都要统一。不然各写各的最后拼在一起各种不兼容。我吃过这个亏后来定了规范效率高了很多。6.8 关于 Prompt 的调试方法Prompt 调试没有捷径就是反复试。但有几个技巧能提高效率一是固定变量每次只改一个地方看效果变化二是准备一组测试用例覆盖正常、边界、异常情况每次改完都跑一遍三是记录每次修改的内容和效果避免重复踩坑。我习惯用一个表格记录 Prompt 的迭代过程包括版本号、修改内容、测试结果、备注。这样回头来看能清楚知道哪些改动有效、哪些无效积累经验特别快。6.9 关于 Agent 框架的选择现在 Agent 框架很多各有各的特点。选框架的时候我主要看几点一是社区活跃度遇到问题能不能找到答案二是文档质量上手成本高不高三是扩展性能不能方便地加自定义 Skill四是性能调用开销大不大。不过我的建议是新手先别急着上框架。用最基础的方式手写一个 ReAct 循环理解 Agent 的运作原理再去看框架会清晰很多。框架帮你封装了很多东西但也屏蔽了细节不理解原理的话出了问题很难排查。6.10 最后的经验分享做了这么多项目我最大的体会是技术选型要克制。Prompt 能解决的别上 SkillSkill 能解决的别上 Agent。每增加一层复杂度就多一层出错的可能多一份维护成本。另外测试要覆盖异常路径。正常流程跑通不难难的是异常情况下的表现。Skill 调用失败怎么办Agent 陷入循环怎么办模型输出格式不对怎么办这些都要提前想好应对方案。还有日志要详细。Agent 的决策过程是不透明的出了问题只能靠日志排查。每次 Skill 调用、每次模型输出、每次状态变化都要记录下来。这样出问题的时候才能快速定位。最后别追求一步到位。先做一个能跑的最小版本再根据实际反馈迭代。我见过太多项目一开始设计得很完美结果开发周期太长上线的时候需求已经变了。快速迭代小步快跑才是更靠谱的做法。