1. 三个概念为什么总被混为一谈刚接触大模型应用开发那阵子我也被这三个词绕晕过。社区里有人把一段精心写的提示词叫“Agent”有人把封装好的工具函数叫“Prompt”还有人把整套自动化流程统称为“Skill”。名字乱飞讨论就没法对齐最后大家各说各话。我踩过的第一个坑就是拿着一个本该用 Skill 解决的场景硬写了两百多行 Prompt结果模型稍微换个输入就崩维护成本高得离谱。先把这三个词放回它们各自的位置。Prompt提示词是你对模型说的一段话是单次交互里的指令与上下文模型读完就执行执行完就结束它本身没有状态、没有记忆、不会主动做第二件事。Skill技能是一段被封装好的、可复用的能力单元它通常包含固定的输入输出约定、一段稳定的提示词模板、可能还有配套的脚本或工具调用逻辑本质上是“把某类任务的做法固化下来”。Agent智能体则是一个会自己决定下一步做什么的执行主体它拥有目标、能调用工具、能根据中间结果调整策略、能循环推进直到任务完成。用生活里的例子类比一下。Prompt 像是你对厨师说“来份番茄炒蛋少放糖”Skill 像是餐厅菜单上那道标准化的“番茄炒蛋”配方固定、谁来做都差不多Agent 像是你雇的一个私人助理你说“我想吃顿舒服的家常菜”他会自己判断今天该买什么菜、做几道、要不要顺带煮个汤中间还会根据冰箱里剩什么临时调整。这三者的关系不是并列而是层层递进。Prompt 是最小单位Skill 是 Prompt 加上封装和复用约定Agent 是 Skill 加上决策循环和工具调度。搞不清这个层次就会出现两种典型错误一种是把 Agent 当 Prompt 写指望一段话解决所有分支另一种是把 Prompt 当 Agent 用明明只需要一次生成却套了一堆循环框架白白烧 token。提示判断你手上这个需求到底属于哪一层最快的办法是问自己一句——这件事需要模型“自己决定下一步”吗不需要就是 Prompt 或 Skill需要才轮到 Agent。热搜里那些词其实都在指向同一个混乱现场。“prompt闪退”“invalid prompt: your prompt was flagged”说的是 Prompt 层面的输入校验问题“skill编码193”“skill编码247”是某些平台对 Skill 的错误码定义“agent安全”“agent架构”“agent记忆”则全是 Agent 层面的工程话题。把这些词按层次归位很多困惑自然就散了。2. Prompt 的本质一次性的指令与上下文2.1 Prompt 到底由什么构成很多人以为 Prompt 就是那句“帮我写个文案”其实一个完整的 Prompt 至少包含四块角色设定、任务描述、约束条件、输出格式。角色设定告诉模型“你是谁”任务描述告诉它“做什么”约束条件告诉它“不能做什么、要注意什么”输出格式告诉它“结果长什么样”。缺了哪一块输出就会往你不想要的方向漂。举个我实际用过的例子。早期我让模型“总结这篇文章”结果它有时给三句话有时给一整段有时还自己加评论。后来我把 Prompt 改成结构化写法输出立刻稳定了角色你是一名严谨的技术编辑。 任务阅读下面的文章提炼核心观点。 约束只保留作者明确表达的观点不添加你的评价如果文章有数据保留关键数字。 输出格式3 条要点每条不超过 40 字用有序列表。 文章内容{此处粘贴正文}改完之后同一个模型、同一个任务输出的一致性肉眼可见地提升。这就是 Prompt 工程里最朴素也最有效的一条经验把隐式期望写成显式约束。2.2 Prompt token 是怎么被吃掉的热搜里“prompt token”这个词出现频率很高因为 token 直接等于钱和延迟。Prompt 的 token 消耗分两部分输入 token 和输出 token。输入里角色设定、约束、示例、上下文全都算钱。我见过有人为了“让模型更懂”在 Prompt 里塞了三千字的背景说明结果每次调用都贵得心疼而实际有效的可能就那两百字。控制 token 有几个实操技巧。第一把稳定不变的部分前置并复用很多平台支持缓存前缀重复调用时这部分不计费或计费更低。第二示例要精选不要堆砌两三个高质量示例比十个平庸示例更省 token 也更有效。第三约束用短句不用长段落能用列表就别写成散文。第四上下文按需裁剪不是把所有历史对话都塞进去而是只保留与当前任务相关的部分。我做过一个对比测试同一个分类任务一版 Prompt 用了 800 输入 token另一版精简到 260 token准确率只差了不到两个百分点但成本降了三分之二。对于高频调用的场景这个差距非常可观。2.3 Prompt 的边界在哪里Prompt 最大的局限是它没有状态、没有记忆、不会自己重试。你给它什么它处理什么处理完就结束。热搜里“invalid prompt: your prompt was flagged as potentially violating our usage p”和“you can prompt the model to try again or start a new conversation if the err”说的就是这种边界——当输入被判定不合规时Prompt 本身没有任何自救能力只能靠外部逻辑重新发起。所以当你发现需求开始出现“如果……就……否则……”的多分支或者需要“先查资料再回答”“先算一步再决定下一步”那就说明 Prompt 这一层已经不够用了该往上走到 Skill 或 Agent。硬用 Prompt 扛复杂逻辑结果就是提示词越写越长、越写越脆最后变成没人敢改的祖传代码。3. Skill 的价值把做法固化成可复用单元3.1 Skill 和 Prompt 的分界线Skill 和 Prompt 最本质的区别是复用性与封装性。Prompt 是一次性的对话内容Skill 是沉淀下来的能力资产。一个 Skill 通常包含明确的适用场景、固定的输入参数、稳定的提示词模板、可选的配套脚本或工具、以及约定的输出结构。它把“这类任务该怎么做”这件事从人的脑子里搬到了代码里。打个比方Prompt 是你每次做菜现想配方Skill 是你把配方写进菜谱、还配好了量勺和步骤图。下次谁来做照着菜谱走就行不依赖某个人的手感。热搜里“skill插件”“skill脚本”“codex skill”“workbuddy skill”说的都是这种封装形态——把某类能力打包让它可以被反复调用、被不同流程引用。3.2 一个 Skill 应该长什么样我拿一个实际做过的“文章去 AI 味”Skill 来拆解。热搜里正好有“去ai味的skill”这个词这类需求很典型。它的结构大致是这样name: remove-ai-flavor description: 将一段文字改写得更像真人写作去除模板化表达 inputs: - text: 待改写的原文 - tone: 期望语气可选 casual/professional outputs: - rewritten: 改写后的文本 prompt_template: | 你是一名有十年经验的写作者。请改写下面的文字要求 1. 删除“通过……可以……”“随着……的发展”这类模板句式 2. 把被动语态改成主动 3. 保留原意不新增事实 4. 语气{tone} 原文{text}这个 Skill 一旦定义好任何需要去 AI 味的场景都能直接调用不用每次重新想提示词。这就是 Skill 的核心价值把一次性的聪明变成可重复的稳定。3.3 Skill 编码错误码说明了什么热搜里“skill编码193”“skill编码247”这类词反映的是 Skill 在工程化落地时的现实问题。Skill 不是写完就完事它要接入平台、要处理输入校验、要应对超时和异常。编码 193 这类错误通常指向参数不匹配或输入格式错误编码 247 往往和依赖缺失或权限有关。这些错误码的存在恰恰说明 Skill 已经是一个工程组件而不是一段随手写的文字。我在部署 Skill 时踩过的坑里最常见的是输入契约不清晰。比如一个 Skill 期望输入是 JSON调用方传了个纯字符串直接报错。解决办法是在 Skill 定义里写清楚 schema并在入口处做一次校验把错误拦在提示词之前。另一个坑是输出不稳定模型偶尔不按格式返回导致下游解析失败。我的做法是在 Skill 里加一层输出解析和重试格式不对就带着错误信息再问一次通常一次重试就能修正。注意Skill 的提示词模板要尽量“防呆”。把格式要求写在最前面和最后面各一遍中间放任务描述模型对首尾位置的指令遵循度明显更高。3.4 Skill 的适用与不适用Skill 适合那些做法相对固定、会被反复调用、输入输出可预期的任务。比如格式转换、内容改写、信息抽取、固定风格生成。它不适合需要动态决策的场景——如果任务本身每次的路径都不一样硬做成 Skill 只会得到一堆分支判断还不如直接上 Agent。判断标准很简单如果这个任务的做法能被写成一份“操作手册”那它就适合做成 Skill如果做法取决于中间结果、需要临场判断那它更适合 Agent。热搜里“agent skill教程”“agent skill”这类词其实是在讨论 Skill 如何作为 Agent 的能力组件被调用这正好引出下一层。4. Agent 的架构会自己决定下一步的执行体4.1 Agent 和 Skill 的根本差异Agent 和 Skill 的分水岭在于决策循环。Skill 是“你给我输入我按固定流程给你输出”Agent 是“你给我目标我自己决定用什么 Skill、按什么顺序、要不要重试”。Agent 内部通常有一个循环观察当前状态、决定下一步动作、执行动作、观察结果、再决定下一步直到目标达成或触发终止条件。热搜里“harness和agent区别”这个词很值得说。Harness 通常指承载 Agent 运行的外壳或框架负责调度、状态管理、工具注册、日志记录这些基础设施Agent 则是跑在 Harness 里的那个“会思考的执行者”。打个比方Harness 是厨房Agent 是厨师Skill 是厨具和菜谱。厨房提供场地和工具厨师决定今天做什么、怎么做。4.2 Agent 的核心组件拆解一个能用的 Agent 至少要有四块目标理解、工具调用、记忆管理、终止判断。目标理解负责把用户的模糊需求转成可执行的任务描述工具调用负责在需要时调用 Skill 或外部接口记忆管理负责保存中间结果和上下文避免重复劳动终止判断负责决定什么时候算完成、什么时候该放弃。热搜里“agent记忆”“agent架构”“agent框架”全是围绕这几块展开的。记忆这块尤其关键。没有记忆的 Agent 每轮都从零开始效率极低记忆设计得不好又会把无关信息越堆越多最后把上下文撑爆。我的经验是分层记忆短期记忆放当前任务的中间结果长期记忆放跨任务可复用的结论两者分开管理定期清理短期记忆。4.3 Agent 安全为什么是绕不开的话题热搜里“agent安全”这个词出现得很频繁这不是危言耸听。Agent 能调用工具、能执行动作一旦被诱导去做不该做的事后果比一段 Prompt 出问题严重得多。常见风险包括被注入的指令劫持、调用高危工具、在循环里无限消耗资源。我在设计 Agent 时会加几道闸。第一工具白名单Agent 只能调用明确授权的工具不能自己发明。第二动作确认涉及写操作、删除操作、对外发送的操作必须经过确认或二次校验。第三循环上限给 Agent 设一个最大步数超过就强制终止并报告。第四输入隔离把用户输入和系统指令在结构上分开降低被注入劫持的概率。提示Agent 的能力越强越要假设它会犯错。设计时先想“它最坏能做什么”再决定给它多少权限而不是先给满权限再补限制。4.4 Agent 开发的常见误区热搜里“agent开发”“agent开发教程”“agent项目”“ai agent搭建”这些词说明很多人正在动手做 Agent。我见过最多的误区有三个。第一个是过度设计明明一个 Skill 能解决的事非要套一个 Agent 循环结果又慢又贵还不稳定。第二个是工具太多给 Agent 注册几十个工具它反而不知道该用哪个选择困难导致表现下降。第三个是没有评估做完就上线没有一套测试用例来衡量它到底行不行。我的做法是从最小可用 Agent 开始。先只给它一个工具、一个目标、一个终止条件跑通了再逐步加能力。每加一个工具就补一组测试用例确保旧能力没被破坏。这样迭代虽然慢一点但系统始终是可控的。5. 三者如何协同一个完整场景的拆解5.1 场景设定自动生成周报我拿一个真实做过的场景来串这三层自动生成团队周报。需求是读取本周的任务记录整理成结构化周报语气正式突出进展和风险。这个场景里三层都用上了。Prompt 层负责单次生成。比如“把下面这段任务记录改写成一句正式的进展描述”这就是一个 Prompt输入一段、输出一句简单直接。Skill 层负责固定流程。比如“周报生成 Skill”它定义了输入是任务列表、输出是固定结构的周报、提示词模板固定、格式校验固定。Agent 层负责调度。它先判断本周有没有数据、数据够不够、要不要补充信息、生成后要不要检查格式、格式不对要不要重试。5.2 各层职责的边界在这个场景里Prompt 只管“这一句话怎么写好”Skill 只管“周报按什么结构生成”Agent 只管“整个流程怎么推进”。职责清晰改起来就方便。想调整语气改 Prompt想调整结构改 Skill想调整流程改 Agent。如果三层混在一起改任何一处都可能牵动全身。我见过反例有人把整个周报流程写成一个超长 Prompt包含数据读取说明、格式要求、语气要求、异常处理结果模型经常顾此失彼。拆成三层之后每层都简单整体反而更稳。5.3 成本与性能的权衡三层拆开还有个好处是成本可控。Prompt 调用最便宜Skill 次之Agent 因为有循环和多次调用最贵。所以能用 Prompt 解决的绝不上 Skill能用 Skill 解决的绝不上 Agent。热搜里“agent token是什么意思”问的就是这个——Agent 每循环一次就消耗一轮 token步数一多成本就上去了。我的经验是给 Agent 设一个预算上限比如最多调用 10 次模型、最多消耗多少 token超了就停。这样即使遇到异常情况也不会失控烧钱。同时把能缓存的中间结果缓存起来避免重复计算。6. 常见问题与排查速查6.1 概念混淆类问题现象真实原因处理方式把 Agent 当 Prompt 写越写越长需求本身需要决策循环拆出 Skill 和 Agent 层把 Prompt 当 Agent 用套了循环框架任务其实一次生成就够退回 Prompt去掉多余框架Skill 里塞了大量分支判断任务路径不固定考虑升级为 AgentAgent 表现不稳定工具太多或目标太模糊精简工具明确目标6.2 工程落地类问题热搜里“invalid prompt”“prompt闪退”这类问题多数出在输入校验和格式约定上。我的排查顺序是先看输入是否符合 Skill 定义的 schema再看提示词模板里的占位符是否都被正确替换最后看输出解析是否容错。很多时候问题不在模型而在上下游的数据契约没对齐。“skill编码193”“skill编码247”这类错误码建议直接查平台文档同时在自己的 Skill 入口加日志把原始输入和错误上下文都记下来。光看错误码很难定位有了日志基本一眼就能看出是参数问题还是依赖问题。6.3 我的避坑清单写 Prompt 时把约束和格式要求放在首尾中间放任务遵循度更高。做 Skill 时先定义输入输出 schema再写提示词顺序反了会返工。做 Agent 时先设终止条件和预算上限再给它加能力不然容易失控。任何一层都要有日志出问题时能复现比什么都重要。不要追求一次做完美先用最小可用版本跑通再逐步加能力。7. 我个人的分层实践体会这几年做下来我最大的体会是这三层不是选择题而是分工题。很多人纠结“到底该用哪个”其实正确问法是“这个需求里哪部分该用哪层”。一个成熟的大模型应用往往是 Prompt、Skill、Agent 三层同时存在各司其职。我现在的习惯是拿到需求先画一条线哪些是单次生成能搞定的归 Prompt哪些是固定流程可复用的归 Skill哪些是需要动态决策的归 Agent。画完这条线架构基本就清楚了剩下的就是填细节。这个习惯帮我省了大量返工时间也让我在跟别人讨论时能快速对齐——大家说的“Agent”到底指哪一层一说就明白。最后分享一个小技巧如果你不确定某个需求该放哪层就先按最便宜的那层做做不动了再往上加。先用 Prompt 试Prompt 扛不住就封装成 SkillSkill 扛不住就升级成 Agent。这样永远不会过度设计每一步的复杂度都是被真实需求逼出来的而不是提前猜出来的。