1. 从一个真实困惑说起为什么这三个词总被混着用刚接触大模型应用开发那阵子我在一个技术群里看到有人问我想让模型帮我自动整理会议纪要到底该写 Prompt 还是搭个 Agent底下回答五花八门有人说写个好点的提示词就够了有人说这得上 Agent 框架还有人甩出一句你先搞清楚 Skill 是什么再说。提问的人更懵了回了一句这三个不是一个东西吗。这个场景我太熟悉了。Prompt、Skill、Agent 这三个词在当下的技术讨论里几乎天天出现但它们之间的边界却经常被模糊掉。有人把 Skill 当成高级 Prompt有人把 Agent 当成能多轮对话的 Prompt还有人觉得 Agent 就是套了个壳的 Prompt 集合。这些理解不能说全错但都停留在表面一旦落到实际项目里选型就会出问题——该用 Prompt 的地方硬上 Agent结果成本和复杂度爆炸该用 Skill 的地方只写 Prompt结果复用性和可维护性一塌糊涂。我打算把这三个概念彻底拆开讲清楚。不是给你背定义而是从它们各自解决什么问题在系统里处于什么位置什么时候该用哪个这几个角度切入。看完之后你应该能对着一个具体需求快速判断出该写 Prompt、该封装 Skill还是该搭 Agent。这篇文章适合已经用过大模型 API、做过一些提示词调优但对整体架构还没形成清晰认知的开发者也适合产品经理和项目负责人用来对齐团队认知。先说一个我常用的类比后面会反复用到把大模型想象成一个能力很强但完全不了解你业务的外包专家。Prompt 是你跟他的一次性沟通话术Skill 是你给他的一套标准化作业手册Agent 是你给他配的项目经理工具箱工作流。这三者的关系不是替代而是层层叠加。2. Prompt 的本质一次对话里的意图压缩2.1 Prompt 到底在做什么很多人以为 Prompt 就是你输入的那段话这个理解太窄了。从工程角度看Prompt 是在单次推理中把任务意图、上下文约束、输出格式要求压缩成一段模型能理解的输入。它的核心特征是无状态、单次、即时。你写一句帮我把这段话翻译成英文这是 Prompt。你写一大段你是一个资深法律顾问请根据以下合同条款用表格形式列出风险点每行包含条款编号、风险等级、修改建议这也是 Prompt只不过是个结构化程度更高的 Prompt。区别只在于信息密度和约束强度本质没变——都是在一次调用里把话说清楚。这里有个关键点容易被忽略Prompt 的效果上限取决于模型本身的能力上限。你提示词写得再花哨模型不会做的事还是不会做。我见过有人花三天时间调一个提示词想让模型准确计算一个复杂财务公式最后发现不如直接调个计算工具来得快。这就是没认清 Prompt 的边界。2.2 为什么 Prompt 会闪退和被标记热词里出现了prompt闪退和invalid prompt: your prompt was flagged as potentially violating our usage这两个现象其实指向同一个底层问题Prompt 是直接暴露给模型服务方的输入它会经过内容审核和长度校验。闪退通常发生在几种情况输入 token 超过模型上下文窗口、请求格式不符合 API 规范、或者触发了服务端的异常处理逻辑。而被标记则是内容安全层面的拦截说明你的提示词里包含了服务方判定为不合规的内容。这两个问题的共同点是——它们都不是模型理解不了而是请求在到达模型之前就被拦下了。实操中我的建议是把 Prompt 的长度控制在上下文窗口的 60% 以内给模型的输出留足空间对于可能触发审核的敏感词提前做本地过滤或改写。这些是工程细节但踩过一次就知道有多耽误事。2.3 Prompt 的复用困境Prompt 最大的问题不是写不好而是难以复用和版本管理。你今天为一个客服场景写了一段精心调优的提示词明天另一个场景要用类似逻辑你只能复制粘贴再改。改着改着团队里就出现了十几个看起来差不多但细节不同的提示词版本谁也不敢删谁也不知道哪个是最新的。这就是 Prompt 的天花板它是面向单次任务的天生不具备模块化和组合能力。当你发现自己在反复复制同一段提示词时就该考虑把它升级成 Skill 了。3. Skill 的定位把会做的事封装成可调用的能力单元3.1 Skill 不是更长的 Prompt这是最需要澄清的一点。很多人觉得 Skill 就是写得更详细、更结构化的 Prompt这个理解会导致你把它用错地方。Skill 的本质是一个封装了特定能力的可复用单元它通常包含一段固定的指令模板、可能依赖的外部工具或数据源、明确的输入输出接口。它和 Prompt 的核心区别在于——Prompt 是一次性的话术Skill 是标准化的作业流程。举个例子。你要让模型做合同风险审查。如果写成 Prompt你每次都要把审查规则、输出格式、注意事项全部重新描述一遍。如果封装成 Skill你只需要定义好这个 Skill 的输入合同文本和输出风险清单内部的审查逻辑、格式要求、甚至调用的法条数据库都固化在里面。下次用的时候直接调用这个 Skill 就行不用再重复描述规则。热词里提到的skill编码193skill编码247skill插件codex skill豆包skill这些本质上都是在说 Skill 的封装形态和调用方式。不同平台对 Skill 的实现不一样但核心思想一致把能力打包按需调用。3.2 Skill 的三种常见封装形态根据我这几年接触到的实践Skill 大致有三种封装形态理解它们有助于你在不同场景下做选择。第一种是纯提示词型 Skill。它本质上还是一段提示词但被固化成了模板有明确的变量占位符。比如一个周报生成 Skill输入是本周工作要点输出是格式化周报内部就是一段固定的提示词模板。这种 Skill 实现简单适合规则明确、不需要外部工具的场景。第二种是工具增强型 Skill。它在提示词之外还绑定了外部工具或数据源。比如一个GIS空间分析 Skill它内部可能调用了地理计算库一个测试 Skill它可能连接了测试用例管理平台。这种 Skill 的能力边界由它绑定的工具决定提示词只负责调度和结果整理。第三种是流程编排型 Skill。它把多个步骤串起来形成一个完整的工作流。比如论文精读 Skill可能包含提取摘要→识别方法→总结结论→生成笔记四个步骤每个步骤可能调用不同的模型或工具。这种 Skill 已经有点接近 Agent 了区别在于它的流程是预定义、固定的不具备自主决策能力。3.3 Skill 的复用价值和维护成本Skill 最大的价值就是复用。一旦封装好团队里任何人都可以调用不用关心内部实现。这带来的直接好处是能力标准化、维护集中化、迭代可控。但 Skill 也有它的成本。封装一个 Skill 需要额外的工作量你要定义接口、处理边界情况、写文档。如果这个能力只用一两次封装 Skill 反而是浪费。我的经验法则是同一个能力如果预计会被调用超过五次或者需要被不同人使用就值得封装成 Skill。另外Skill 的维护是个长期问题。业务规则变了Skill 内部的提示词或工具调用逻辑就要跟着改。如果 Skill 数量多了没有好的版本管理和测试机制很容易出现改了 A 场景的 SkillB 场景跟着崩的情况。热词里的测试skill去ai味的skill其实都指向这个痛点——Skill 需要被测试、被调优、被持续维护。4. Agent 的真相自主决策背后的架构与代价4.1 Agent 和 Skill 的分水岭在哪里如果说 Skill 是预定义流程那 Agent 的核心特征就是自主决策。Agent 面对一个任务时不是按照固定步骤执行而是自己判断现在该做什么下一步该调用哪个工具结果是否满足要求要不要重试或换方案。这个区别听起来抽象举个例子就清楚了。你让系统帮我分析这份销售数据并给出建议。如果是 Skill流程是固定的读取数据→计算指标→生成报告每一步都是预设好的。如果是 Agent它会自己判断数据格式是什么需要清洗吗该用哪个分析工具分析结果异常要不要重新算报告该侧重哪个维度这些决策不是预设的而是 Agent 在运行时根据情况自己做的。热词里harness和agent区别agent架构agent框架agent记忆这些讨论的都是 Agent 的架构问题。一个完整的 Agent 通常包含几个核心组件规划模块决定做什么、工具调用模块执行动作、记忆模块记住历史、反思模块评估结果并调整。这四个模块的组合方式决定了 Agent 的能力和成本。4.2 Agent 的四种典型架构我接触过的 Agent 实现大致可以归为四类架构各有适用场景。ReAct 架构是最经典的一种核心是推理-行动循环Agent 先推理当前该做什么然后执行一个动作观察结果再推理下一步。这种架构实现简单适合任务步骤不多、每步反馈明确的场景。缺点是容易陷入循环或者在长任务中忘记最初目标。Plan-and-Execute 架构是先规划再执行Agent 先把整个任务拆解成步骤列表然后逐步执行。这种架构适合步骤明确、可以提前规划的任务比如生成一份市场调研报告这种有固定流程的工作。缺点是如果执行中发现计划不合理调整起来比较麻烦。多 Agent 协作架构是让多个 Agent 分工合作比如一个负责检索、一个负责分析、一个负责写作。这种架构适合复杂任务但协调成本高容易出现Agent 之间互相等待或重复劳动的问题。带记忆的持续 Agent是在上述架构基础上增加了长期记忆能跨会话记住历史信息。热词里的agent记忆hermes agent obsidian指向的就是这个方向。这种 Agent 适合需要持续跟踪的场景比如个人助理、项目监控但记忆的存储、检索、更新都是工程难题。4.3 Agent 的成本陷阱Agent 很强大但它的成本经常被低估。我见过不少团队兴冲冲搭了个 Agent跑起来才发现 token 消耗是普通调用的十倍以上响应时间从秒级变成分钟级而且结果还不稳定。原因很简单Agent 的每一步决策都是一次模型调用一个复杂任务可能涉及几十次调用。而且 Agent 的自主性意味着它可能走弯路、可能重试、可能陷入循环。这些探索成本在 Skill 和 Prompt 里是不存在的。所以我的建议是能用 Skill 解决的不要上 Agent。只有当任务确实需要动态决策、无法预先定义流程时才考虑 Agent。而且上线前一定要做成本预估和兜底机制比如设置最大步数限制、超时中断、失败降级。热词里的agent安全agent anywhere基于rust语言ai agent这些反映的是 Agent 在安全性、部署形态、性能优化方面的探索。这些方向都很重要但前提是你已经确认自己真的需要 Agent。5. 三者对比一张表看清边界与选型5.1 核心维度对比把前面讲的内容浓缩成一张表方便你快速对照。维度PromptSkillAgent本质单次沟通话术可复用的能力单元自主决策的执行体状态无状态通常无状态有状态含记忆流程无流程预定义流程动态决策流程复用性低靠复制高标准化调用中配置复杂成本低中高适用场景简单、一次性任务规则明确、需复用复杂、需动态决策典型问题难维护、难复用封装成本、版本管理成本高、不稳定这张表不是绝对的实际项目中三者经常混用。比如一个 Agent 内部会调用多个 Skill每个 Skill 内部又包含 Prompt。理解它们的层级关系比记住定义更重要。5.2 选型决策树面对一个具体需求我会按这个顺序判断第一步问自己这个任务的流程是否固定。如果固定往下走如果不固定可能需要 Agent。第二步问自己这个能力会不会被反复使用。如果会封装成 Skill如果只用一次直接写 Prompt。第三步问自己任务是否需要外部工具或数据。如果需要Skill 或 Agent 都要绑定工具如果不需要纯 Prompt 可能就够。第四步问自己能否接受不确定性和高成本。如果能Agent 可行如果不能退回 Skill 方案。这个决策树不是万能的但能帮你避开大部分选型错误。我见过最常见的错误就是跳过前几步直接上 Agent结果发现用 Skill 就能解决白白增加了复杂度和成本。5.3 一个完整的选型案例假设你要做一个自动回复客户咨询的系统。怎么选如果咨询问题种类少、答案固定直接写 Prompt 就行把常见问题和标准答案塞进提示词模型负责匹配和改写。如果咨询问题种类多、但回复规则明确封装成 Skill 更合适。把回复规则、话术模板、知识库检索都固化在 Skill 里每次调用传入客户问题即可。如果咨询问题复杂、需要多轮追问、需要查订单查物流查库存那就需要 Agent。它要自己判断该查什么、该问什么、该调哪个接口还要记住对话历史。这个案例里三种方案的成本和效果差异巨大。选错了要么效果不够要么成本爆炸。6. 实操中的经验与踩坑记录6.1 从 Prompt 升级到 Skill 的时机我踩过的一个坑是太早封装 Skill。有个功能我预计会用很多次花了两天封装成 Skill结果业务方向调整这个功能只用了三次就废弃了。封装成本完全没摊回来。后来我调整了策略先用 Prompt 快速验证确认这个能力确实会被反复使用、且规则相对稳定后再封装成 Skill。验证阶段用 Prompt 的成本几乎为零改起来也快。等验证通过了再花时间做标准化封装。这个先 Prompt 后 Skill的路径帮我省了不少无用功。判断标准也很简单如果你发现自己在复制同一段提示词超过三次或者有第二个人来问你要这段提示词那就是封装 Skill 的信号。6.2 Agent 上线前必须做的三件事如果你确定要上 Agent这三件事我建议一定要做都是血泪教训。第一设置最大步数限制。Agent 陷入循环是常态没有步数限制的话它可能一直转下去烧钱又耗时。我一般设置 10 到 15 步超过就强制中断并返回当前结果。第二做好失败降级。Agent 不是每次都能成功失败时要有个兜底方案。比如降级到 Skill 流程或者返回需要人工处理的提示。千万别让 Agent 失败后直接报错用户体验会很差。第三记录完整的执行轨迹。Agent 的每一步决策、每次工具调用、每个中间结果都要记下来。出问题时这些轨迹是唯一的排查依据。我见过没有日志的 Agent 出故障排查了两天才找到原因就是因为中间过程完全不可见。6.3 关于去 AI 味和 Skill 调优热词里去ai味的skill这个说法很有意思它反映了一个真实需求Skill 的输出不能太像机器生成的。这个问题在客服、写作、营销场景里特别突出。我的做法是在 Skill 内部加一层风格约束。不是简单地说请用自然的语言而是给出具体的风格示例、禁用词列表、句式要求。比如禁用首先其次最后这种结构词禁用总之综上所述这种总结词要求句子长短交替要求适当使用口语化表达。这层约束放在 Skill 里比放在 Prompt 里更合适因为它是可复用的。所有调用这个 Skill 的场景都自动继承了这套风格要求不用每次重新描述。6.4 内网部署 Skill 的注意事项热词里deepseek harness附带skill怎么部署到内网服务器这个问题涉及的是 Skill 的私有化部署。这个场景在企业里很常见因为数据不能出内网。内网部署 Skill 的核心难点不在 Skill 本身而在它依赖的模型和工具。如果 Skill 需要调用外部模型 API内网环境可能访问不了如果 Skill 绑定了外部数据源也要做本地化替代。我的建议是内网部署前先把 Skill 的依赖清单列清楚逐个确认内网是否可用。模型方面考虑本地部署开源模型工具方面考虑用内网服务替代外部 API。这个过程比较繁琐但比上线后才发现跑不通要好得多。7. 把三者放进同一个系统里看单独理解 Prompt、Skill、Agent 不难难的是理解它们如何协同。在一个成熟的系统里这三者通常是嵌套关系Agent 负责决策和调度Skill 负责封装具体能力Prompt 负责单次交互的表达。举个我实际做过的例子。一个智能数据分析助手顶层是个 Agent它负责理解用户意图、决定分析路径、协调各个 Skill。中间层是若干 Skill比如数据清洗 Skill指标计算 Skill图表生成 Skill报告撰写 Skill。底层是每个 Skill 内部的 Prompt负责具体的指令表达。用户说帮我看看上个月销售为什么下滑Agent 会自己判断先调数据清洗 Skill 处理原始数据再调指标计算 Skill 算出同比环比然后调图表生成 Skill 出图最后调报告撰写 Skill 生成分析文字。整个过程用户只提了一个需求背后是多个 Skill 和 Prompt 的协作。这种分层架构的好处是每层职责清晰Agent 只管决策Skill 只管能力Prompt 只管表达。改一层不影响其他层维护起来轻松很多。坏处是搭建成本高调试复杂需要团队对三层都有清晰认知。我的建议是不要一上来就搭三层架构。从 Prompt 开始遇到复用需求升级成 Skill遇到动态决策需求再引入 Agent。让架构随着需求自然生长而不是一开始就设计一个完美但用不上的复杂系统。我见过太多团队在需求还没验证清楚的时候就搭了一套完整的 Agent 架构最后发现大部分 Skill 根本用不上Agent 的决策逻辑也过于复杂维护成本远超收益。回到最开始那个问题想让模型帮我自动整理会议纪要该写 Prompt 还是搭 Agent我的答案是先写 Prompt把整理规则和输出格式调清楚。如果这个需求每周都要用封装成 Skill。如果会议纪要还需要自动关联项目进度、自动分配待办、自动跟进那再考虑 Agent。技术选型不是越先进越好而是越匹配越好。
1. 从一个真实困惑说起为什么这三个词总被混着用刚接触大模型应用开发那阵子我在一个技术群里看到有人问我想让模型帮我自动整理会议纪要到底该写 Prompt 还是搭个 Agent底下回答五花八门有人说写个好点的提示词就够了有人说这得上 Agent 框架还有人甩出一句你先搞清楚 Skill 是什么再说。提问的人更懵了回了一句这三个不是一个东西吗。这个场景我太熟悉了。Prompt、Skill、Agent 这三个词在当下的技术讨论里几乎天天出现但它们之间的边界却经常被模糊掉。有人把 Skill 当成高级 Prompt有人把 Agent 当成能多轮对话的 Prompt还有人觉得 Agent 就是套了个壳的 Prompt 集合。这些理解不能说全错但都停留在表面一旦落到实际项目里选型就会出问题——该用 Prompt 的地方硬上 Agent结果成本和复杂度爆炸该用 Skill 的地方只写 Prompt结果复用性和可维护性一塌糊涂。我打算把这三个概念彻底拆开讲清楚。不是给你背定义而是从它们各自解决什么问题在系统里处于什么位置什么时候该用哪个这几个角度切入。看完之后你应该能对着一个具体需求快速判断出该写 Prompt、该封装 Skill还是该搭 Agent。这篇文章适合已经用过大模型 API、做过一些提示词调优但对整体架构还没形成清晰认知的开发者也适合产品经理和项目负责人用来对齐团队认知。先说一个我常用的类比后面会反复用到把大模型想象成一个能力很强但完全不了解你业务的外包专家。Prompt 是你跟他的一次性沟通话术Skill 是你给他的一套标准化作业手册Agent 是你给他配的项目经理工具箱工作流。这三者的关系不是替代而是层层叠加。2. Prompt 的本质一次对话里的意图压缩2.1 Prompt 到底在做什么很多人以为 Prompt 就是你输入的那段话这个理解太窄了。从工程角度看Prompt 是在单次推理中把任务意图、上下文约束、输出格式要求压缩成一段模型能理解的输入。它的核心特征是无状态、单次、即时。你写一句帮我把这段话翻译成英文这是 Prompt。你写一大段你是一个资深法律顾问请根据以下合同条款用表格形式列出风险点每行包含条款编号、风险等级、修改建议这也是 Prompt只不过是个结构化程度更高的 Prompt。区别只在于信息密度和约束强度本质没变——都是在一次调用里把话说清楚。这里有个关键点容易被忽略Prompt 的效果上限取决于模型本身的能力上限。你提示词写得再花哨模型不会做的事还是不会做。我见过有人花三天时间调一个提示词想让模型准确计算一个复杂财务公式最后发现不如直接调个计算工具来得快。这就是没认清 Prompt 的边界。2.2 为什么 Prompt 会闪退和被标记热词里出现了prompt闪退和invalid prompt: your prompt was flagged as potentially violating our usage这两个现象其实指向同一个底层问题Prompt 是直接暴露给模型服务方的输入它会经过内容审核和长度校验。闪退通常发生在几种情况输入 token 超过模型上下文窗口、请求格式不符合 API 规范、或者触发了服务端的异常处理逻辑。而被标记则是内容安全层面的拦截说明你的提示词里包含了服务方判定为不合规的内容。这两个问题的共同点是——它们都不是模型理解不了而是请求在到达模型之前就被拦下了。实操中我的建议是把 Prompt 的长度控制在上下文窗口的 60% 以内给模型的输出留足空间对于可能触发审核的敏感词提前做本地过滤或改写。这些是工程细节但踩过一次就知道有多耽误事。2.3 Prompt 的复用困境Prompt 最大的问题不是写不好而是难以复用和版本管理。你今天为一个客服场景写了一段精心调优的提示词明天另一个场景要用类似逻辑你只能复制粘贴再改。改着改着团队里就出现了十几个看起来差不多但细节不同的提示词版本谁也不敢删谁也不知道哪个是最新的。这就是 Prompt 的天花板它是面向单次任务的天生不具备模块化和组合能力。当你发现自己在反复复制同一段提示词时就该考虑把它升级成 Skill 了。3. Skill 的定位把会做的事封装成可调用的能力单元3.1 Skill 不是更长的 Prompt这是最需要澄清的一点。很多人觉得 Skill 就是写得更详细、更结构化的 Prompt这个理解会导致你把它用错地方。Skill 的本质是一个封装了特定能力的可复用单元它通常包含一段固定的指令模板、可能依赖的外部工具或数据源、明确的输入输出接口。它和 Prompt 的核心区别在于——Prompt 是一次性的话术Skill 是标准化的作业流程。举个例子。你要让模型做合同风险审查。如果写成 Prompt你每次都要把审查规则、输出格式、注意事项全部重新描述一遍。如果封装成 Skill你只需要定义好这个 Skill 的输入合同文本和输出风险清单内部的审查逻辑、格式要求、甚至调用的法条数据库都固化在里面。下次用的时候直接调用这个 Skill 就行不用再重复描述规则。热词里提到的skill编码193skill编码247skill插件codex skill豆包skill这些本质上都是在说 Skill 的封装形态和调用方式。不同平台对 Skill 的实现不一样但核心思想一致把能力打包按需调用。3.2 Skill 的三种常见封装形态根据我这几年接触到的实践Skill 大致有三种封装形态理解它们有助于你在不同场景下做选择。第一种是纯提示词型 Skill。它本质上还是一段提示词但被固化成了模板有明确的变量占位符。比如一个周报生成 Skill输入是本周工作要点输出是格式化周报内部就是一段固定的提示词模板。这种 Skill 实现简单适合规则明确、不需要外部工具的场景。第二种是工具增强型 Skill。它在提示词之外还绑定了外部工具或数据源。比如一个GIS空间分析 Skill它内部可能调用了地理计算库一个测试 Skill它可能连接了测试用例管理平台。这种 Skill 的能力边界由它绑定的工具决定提示词只负责调度和结果整理。第三种是流程编排型 Skill。它把多个步骤串起来形成一个完整的工作流。比如论文精读 Skill可能包含提取摘要→识别方法→总结结论→生成笔记四个步骤每个步骤可能调用不同的模型或工具。这种 Skill 已经有点接近 Agent 了区别在于它的流程是预定义、固定的不具备自主决策能力。3.3 Skill 的复用价值和维护成本Skill 最大的价值就是复用。一旦封装好团队里任何人都可以调用不用关心内部实现。这带来的直接好处是能力标准化、维护集中化、迭代可控。但 Skill 也有它的成本。封装一个 Skill 需要额外的工作量你要定义接口、处理边界情况、写文档。如果这个能力只用一两次封装 Skill 反而是浪费。我的经验法则是同一个能力如果预计会被调用超过五次或者需要被不同人使用就值得封装成 Skill。另外Skill 的维护是个长期问题。业务规则变了Skill 内部的提示词或工具调用逻辑就要跟着改。如果 Skill 数量多了没有好的版本管理和测试机制很容易出现改了 A 场景的 SkillB 场景跟着崩的情况。热词里的测试skill去ai味的skill其实都指向这个痛点——Skill 需要被测试、被调优、被持续维护。4. Agent 的真相自主决策背后的架构与代价4.1 Agent 和 Skill 的分水岭在哪里如果说 Skill 是预定义流程那 Agent 的核心特征就是自主决策。Agent 面对一个任务时不是按照固定步骤执行而是自己判断现在该做什么下一步该调用哪个工具结果是否满足要求要不要重试或换方案。这个区别听起来抽象举个例子就清楚了。你让系统帮我分析这份销售数据并给出建议。如果是 Skill流程是固定的读取数据→计算指标→生成报告每一步都是预设好的。如果是 Agent它会自己判断数据格式是什么需要清洗吗该用哪个分析工具分析结果异常要不要重新算报告该侧重哪个维度这些决策不是预设的而是 Agent 在运行时根据情况自己做的。热词里harness和agent区别agent架构agent框架agent记忆这些讨论的都是 Agent 的架构问题。一个完整的 Agent 通常包含几个核心组件规划模块决定做什么、工具调用模块执行动作、记忆模块记住历史、反思模块评估结果并调整。这四个模块的组合方式决定了 Agent 的能力和成本。4.2 Agent 的四种典型架构我接触过的 Agent 实现大致可以归为四类架构各有适用场景。ReAct 架构是最经典的一种核心是推理-行动循环Agent 先推理当前该做什么然后执行一个动作观察结果再推理下一步。这种架构实现简单适合任务步骤不多、每步反馈明确的场景。缺点是容易陷入循环或者在长任务中忘记最初目标。Plan-and-Execute 架构是先规划再执行Agent 先把整个任务拆解成步骤列表然后逐步执行。这种架构适合步骤明确、可以提前规划的任务比如生成一份市场调研报告这种有固定流程的工作。缺点是如果执行中发现计划不合理调整起来比较麻烦。多 Agent 协作架构是让多个 Agent 分工合作比如一个负责检索、一个负责分析、一个负责写作。这种架构适合复杂任务但协调成本高容易出现Agent 之间互相等待或重复劳动的问题。带记忆的持续 Agent是在上述架构基础上增加了长期记忆能跨会话记住历史信息。热词里的agent记忆hermes agent obsidian指向的就是这个方向。这种 Agent 适合需要持续跟踪的场景比如个人助理、项目监控但记忆的存储、检索、更新都是工程难题。4.3 Agent 的成本陷阱Agent 很强大但它的成本经常被低估。我见过不少团队兴冲冲搭了个 Agent跑起来才发现 token 消耗是普通调用的十倍以上响应时间从秒级变成分钟级而且结果还不稳定。原因很简单Agent 的每一步决策都是一次模型调用一个复杂任务可能涉及几十次调用。而且 Agent 的自主性意味着它可能走弯路、可能重试、可能陷入循环。这些探索成本在 Skill 和 Prompt 里是不存在的。所以我的建议是能用 Skill 解决的不要上 Agent。只有当任务确实需要动态决策、无法预先定义流程时才考虑 Agent。而且上线前一定要做成本预估和兜底机制比如设置最大步数限制、超时中断、失败降级。热词里的agent安全agent anywhere基于rust语言ai agent这些反映的是 Agent 在安全性、部署形态、性能优化方面的探索。这些方向都很重要但前提是你已经确认自己真的需要 Agent。5. 三者对比一张表看清边界与选型5.1 核心维度对比把前面讲的内容浓缩成一张表方便你快速对照。维度PromptSkillAgent本质单次沟通话术可复用的能力单元自主决策的执行体状态无状态通常无状态有状态含记忆流程无流程预定义流程动态决策流程复用性低靠复制高标准化调用中配置复杂成本低中高适用场景简单、一次性任务规则明确、需复用复杂、需动态决策典型问题难维护、难复用封装成本、版本管理成本高、不稳定这张表不是绝对的实际项目中三者经常混用。比如一个 Agent 内部会调用多个 Skill每个 Skill 内部又包含 Prompt。理解它们的层级关系比记住定义更重要。5.2 选型决策树面对一个具体需求我会按这个顺序判断第一步问自己这个任务的流程是否固定。如果固定往下走如果不固定可能需要 Agent。第二步问自己这个能力会不会被反复使用。如果会封装成 Skill如果只用一次直接写 Prompt。第三步问自己任务是否需要外部工具或数据。如果需要Skill 或 Agent 都要绑定工具如果不需要纯 Prompt 可能就够。第四步问自己能否接受不确定性和高成本。如果能Agent 可行如果不能退回 Skill 方案。这个决策树不是万能的但能帮你避开大部分选型错误。我见过最常见的错误就是跳过前几步直接上 Agent结果发现用 Skill 就能解决白白增加了复杂度和成本。5.3 一个完整的选型案例假设你要做一个自动回复客户咨询的系统。怎么选如果咨询问题种类少、答案固定直接写 Prompt 就行把常见问题和标准答案塞进提示词模型负责匹配和改写。如果咨询问题种类多、但回复规则明确封装成 Skill 更合适。把回复规则、话术模板、知识库检索都固化在 Skill 里每次调用传入客户问题即可。如果咨询问题复杂、需要多轮追问、需要查订单查物流查库存那就需要 Agent。它要自己判断该查什么、该问什么、该调哪个接口还要记住对话历史。这个案例里三种方案的成本和效果差异巨大。选错了要么效果不够要么成本爆炸。6. 实操中的经验与踩坑记录6.1 从 Prompt 升级到 Skill 的时机我踩过的一个坑是太早封装 Skill。有个功能我预计会用很多次花了两天封装成 Skill结果业务方向调整这个功能只用了三次就废弃了。封装成本完全没摊回来。后来我调整了策略先用 Prompt 快速验证确认这个能力确实会被反复使用、且规则相对稳定后再封装成 Skill。验证阶段用 Prompt 的成本几乎为零改起来也快。等验证通过了再花时间做标准化封装。这个先 Prompt 后 Skill的路径帮我省了不少无用功。判断标准也很简单如果你发现自己在复制同一段提示词超过三次或者有第二个人来问你要这段提示词那就是封装 Skill 的信号。6.2 Agent 上线前必须做的三件事如果你确定要上 Agent这三件事我建议一定要做都是血泪教训。第一设置最大步数限制。Agent 陷入循环是常态没有步数限制的话它可能一直转下去烧钱又耗时。我一般设置 10 到 15 步超过就强制中断并返回当前结果。第二做好失败降级。Agent 不是每次都能成功失败时要有个兜底方案。比如降级到 Skill 流程或者返回需要人工处理的提示。千万别让 Agent 失败后直接报错用户体验会很差。第三记录完整的执行轨迹。Agent 的每一步决策、每次工具调用、每个中间结果都要记下来。出问题时这些轨迹是唯一的排查依据。我见过没有日志的 Agent 出故障排查了两天才找到原因就是因为中间过程完全不可见。6.3 关于去 AI 味和 Skill 调优热词里去ai味的skill这个说法很有意思它反映了一个真实需求Skill 的输出不能太像机器生成的。这个问题在客服、写作、营销场景里特别突出。我的做法是在 Skill 内部加一层风格约束。不是简单地说请用自然的语言而是给出具体的风格示例、禁用词列表、句式要求。比如禁用首先其次最后这种结构词禁用总之综上所述这种总结词要求句子长短交替要求适当使用口语化表达。这层约束放在 Skill 里比放在 Prompt 里更合适因为它是可复用的。所有调用这个 Skill 的场景都自动继承了这套风格要求不用每次重新描述。6.4 内网部署 Skill 的注意事项热词里deepseek harness附带skill怎么部署到内网服务器这个问题涉及的是 Skill 的私有化部署。这个场景在企业里很常见因为数据不能出内网。内网部署 Skill 的核心难点不在 Skill 本身而在它依赖的模型和工具。如果 Skill 需要调用外部模型 API内网环境可能访问不了如果 Skill 绑定了外部数据源也要做本地化替代。我的建议是内网部署前先把 Skill 的依赖清单列清楚逐个确认内网是否可用。模型方面考虑本地部署开源模型工具方面考虑用内网服务替代外部 API。这个过程比较繁琐但比上线后才发现跑不通要好得多。7. 把三者放进同一个系统里看单独理解 Prompt、Skill、Agent 不难难的是理解它们如何协同。在一个成熟的系统里这三者通常是嵌套关系Agent 负责决策和调度Skill 负责封装具体能力Prompt 负责单次交互的表达。举个我实际做过的例子。一个智能数据分析助手顶层是个 Agent它负责理解用户意图、决定分析路径、协调各个 Skill。中间层是若干 Skill比如数据清洗 Skill指标计算 Skill图表生成 Skill报告撰写 Skill。底层是每个 Skill 内部的 Prompt负责具体的指令表达。用户说帮我看看上个月销售为什么下滑Agent 会自己判断先调数据清洗 Skill 处理原始数据再调指标计算 Skill 算出同比环比然后调图表生成 Skill 出图最后调报告撰写 Skill 生成分析文字。整个过程用户只提了一个需求背后是多个 Skill 和 Prompt 的协作。这种分层架构的好处是每层职责清晰Agent 只管决策Skill 只管能力Prompt 只管表达。改一层不影响其他层维护起来轻松很多。坏处是搭建成本高调试复杂需要团队对三层都有清晰认知。我的建议是不要一上来就搭三层架构。从 Prompt 开始遇到复用需求升级成 Skill遇到动态决策需求再引入 Agent。让架构随着需求自然生长而不是一开始就设计一个完美但用不上的复杂系统。我见过太多团队在需求还没验证清楚的时候就搭了一套完整的 Agent 架构最后发现大部分 Skill 根本用不上Agent 的决策逻辑也过于复杂维护成本远超收益。回到最开始那个问题想让模型帮我自动整理会议纪要该写 Prompt 还是搭 Agent我的答案是先写 Prompt把整理规则和输出格式调清楚。如果这个需求每周都要用封装成 Skill。如果会议纪要还需要自动关联项目进度、自动分配待办、自动跟进那再考虑 Agent。技术选型不是越先进越好而是越匹配越好。
