做 AI 应用这几年，我越来越意识到一个尴尬的事实：Prompt 写得再花哨，Agent 编排得再复杂，到了真实业务里都很难放大规模。不是投入不够，而是这两条技术路线在底层设计上就带着天花板。最近认真研究了 Anthropic 提出的 Skills 设计范式，越看越觉得这是目前少数能正面回答“为什么 Prompt 和 Agent 无法 Scale”这个问题的思路，所以想把我的理解、实操和踩坑过程完整整理出来。
这篇文章适合谁看？如果你正在用大模型做稍微复杂一点的功能，比如客服助手、代码审查机器人、数据分析工具，或者已经在搭多步骤 Agent，却被稳定性、维护成本、上下文爆炸这些问题反复折磨，那这篇文章应该能帮你换一个思考角度。我会先用两个章节拆解 Prompt 和 Agent 各自的瓶颈，再花三个章节讲清楚 Skills 范式到底改了什么、怎么落地，最后聊点规模化路上真正难啃的骨头。
1. 先说结论：Prompt 和 Agent 都卡在同一堵墙上
很多人以为 Prompt 和 Agent 不能 Scale 是因为模型不够聪明，或者算力不够，但我观察下来，真正的瓶颈在于它们都试图用“线性堆叠”来解决“组合爆炸”的问题。一套业务逻辑稍微复杂一点，所有规则、上下文、工具说明全挤在一个上下文窗口里，最后模型要么迷失在长篇指令里，要么被相互矛盾的规则带偏。
1.1 Prompt 为什么扛不住复杂业务
Prompt 的伸缩性问题，本质上是一个信息密度和信息冲突的问题。早期大家写 Prompt，几百字就能解决一个分类任务，效果还不错。但业务一旦复杂起来，你会本能地往 Prompt 里加东西：加格式要求、加业务规则、加 few-shot 示例、加错误案例。加到两三千字的时候，模型开始“选择性失明”，它不再严格遵循每条指令，而是凭概率去猜你更看重哪一段。
我做客服意图识别的时候就遇到过这种情况。一开始 Prompt 里只有 5 个意图，准确率 92%，很漂亮。后来业务方要求增加到 20 个意图，还加了一堆“如果用户提到退换货但语气愤怒，优先转人工”这种条件规则。结果准确率掉到 81%，而且无论我怎么调整措辞、改变规则顺序，都回不到原来的水平。原因不难理解：规则之间产生了隐性的优先级冲突，模型判断“哪条指令权重更高”时靠的是训练统计规律，而不是你的真实业务优先级。
另一个问题是 Prompt 的不可组合性。你想把一个写好的客服 Prompt 复用到另一条业务线，基本只能全文复制粘贴再手工改。没有任何标准的接口，也没有依赖管理，一旦原始 Prompt 更新了业务规则，所有复制出去的分支全部失效。你维护的不是一个 Prompt，而是几十个彼此分离但又共享同一套规则的“变体”，哪个版本更新了、哪个没更新，根本没人说得清。
提示：如果你发现自己在一个 Prompt 里不断追加“注意”“务必”“一定不要”，大概率是设计已经到了瓶颈。补充规则不是不能做，但超过 10 条相互依赖的条件规则时，稳定性会急剧下降。
1.2 Agent 的复杂度失控
Agent 范式本质上是想解决“一条 Prompt 做不了复杂任务”的问题，思路是把任务拆解成多步，每一步由模型决策调用哪个工具、执行哪个动作。听起来很合理，但实际跑起来会发现另一堵墙：组合状态空间太大。
我搭过一个内部用的数据分析 Agent，模型需要自己决定先查哪些表、是否需要写 Python 脚本、结果出来之后要不要画图。单轮任务表现很好，一旦用户连续追问，多轮状态就开始混乱。模型经常忘记之前已经确认过的过滤条件，或者在一个子任务里反复横跳。最典型的场景是：它已经查出了“华东区 6 月销售额”，用户随口说“那再看看华南”，它会重新查一遍华东，因为它把“华南”理解成了新任务的起点，而不是对已有上下文的增量修改。
这种失控的根源在于，Agent 的自由度过高。每一步给模型的选择空间都很大，而模型又不是真正的规划器，它只是根据当前 token 概率做局部最优选择。局部最优叠加上千次，全局行为就变得不可预测。更麻烦的是，出了问题你很难定位：到底是哪一步决策错了？是工具返回的数据有问题，还是模型理解偏了？这种系统没法用传统的日志和断点调试，因为你无法重放模型的“思考过程”。
另一个常被忽略的问题是上下文窗口的占用。Agent 每走一步，工具返回的结果、中间推理、状态记录都会写进上下文，整个上下文越来越大。到第 8 轮、第 10 轮的时候，早期的重要信息被挤到很远的位置，模型的注意力开始衰减。你不得不频繁做“记忆压缩”，但每次压缩都会丢失细节，压缩完模型的行为就又变了。
2. Skills 的设计核心：从堆文字到搭积木
既然 Prompt 和 Agent 都走到了死胡同，那 Anthropic 给出的 Skills 范式到底改了什么东西？我的理解是六个字：把能力模块化。它不再要求把逻辑全部写进一段指令里，也不再让 Agent 在一个超大自由空间里做决策，而是把完成一类任务的完整知识、规则、示例、工具定义打包成一个独立的模块。
2.1 Skills 到底是什么
一个 Skill，用最通俗的话说，就是你可以给模型“安装”的一项专业技能。它不是一个参数文件，也不是一段代码，而是一个结构化的能力包。在 Anthropic 的实现里，一个 Skill 通常包含一个核心文档（类似 SKILL.md），里面写清楚这个技能的目标、使用场景、具体步骤、注意事项，同时可以附带若干参考示例和可调用的工具定义。模型在运行时会根据用户请求的描述，决定是否激活这个 Skill，以及按 Skill 中的步骤执行。
这件事和传统 Prompt 的本质区别在于：Prompt 是一段被动的文本，它永远存在于上下文中，模型读不读、遵不遵守全靠概率；而 Skill 是一种被挂载的能力，它有明确的激活条件、有结构化的执行流程、有配套的工具描述。你不需要把所有业务逻辑都写在一封“给模型的信”里，而是把逻辑拆成一个个可以按需调用的模块。
打个比方，Prompt 时代的做法像是你请了一位什么都会一点但什么也不精的实习生，你把整本《员工手册》塞给他，让他自己判断什么时候该用什么条款。Agent 时代的做法像是在这个实习生身后配备了一个研究团队，让他自由指挥所有研究员，结果他经常瞎指挥。而 Skills 的做法，是给这位实习生一本带目录和索引的手册，每个章节都清清楚楚画好了适用范围，他自己就是图书馆管理员，知道进书库该翻哪本书。
2.2 为什么这套设计能 Scale
Skills 能 Scale 的第一个原因是模块边界清晰。每个 Skill 只描述一件事：要么做数据清洗，要么做代码审查，要么生成周报。业务逻辑被有效地局部化，修改其中一个不会牵动全局。这就回到了软件工程最基本的道理：只有模块化才能并行维护、独立升级、按需组合。
第二个原因是上下文控制的转变。Prompt 范式里，所有背景知识必须常驻上下文，2000 字的背景规则哪怕不适用也要占位置。Skills 范式里，只有 Skill 被激活时，它的指令和示例才会被加载进上下文。这意味着你可以准备 50 个 Skill，但每次任务只消耗几个 Skill 的 token，上下文从“全量常驻”变成了“按需加载”。
第三个原因是可评估性。Prompt 写得好不好，只能在整体效果里模糊感知；而 Skill 可以被单独测试，就像函数可以被单独单测一样。我可以只针对“数据清洗”这个 Skill 做一百条测试，而不需要跑完整套业务。这个特性在工程化落地上至关重要，因为当系统复杂到一定程度，定位问题比解决问题更耗时。
3. 用软件工程的老经验，理解 Skills 的每个决策
如果你写过类库、做过微服务，你会觉得 Skills 的设计范式特别亲切，因为它几乎是把软件工程里验证过的设计原则搬到了 Prompt 工程领域。这一章我用代码开发的视角，逐个拆解 Skills 设计里的关键决策，以及每个决策背后解决的是什么问题。
3.1 接口与描述：决定技能会不会被正确调用
软件工程里，一个函数能不能被正确使用，看的是函数签名和注释说明得好不好。Skill 也是一样，它对外暴露的核心接口就是它的描述字段。模型判断“当前用户需求是否应该激活这个 Skill”，完完全全靠描述文本。
这个描述不能写得太抽象，比如“这个技能用于数据处理”这种描述基本没用。合格的描述应该像好函数的 docstring 一样，包含三个信息：适用范围、典型场景、关键能力边界。比如你的数据清洗 Skill，描述可以写成：“当用户提供原始表格文件、CSV、JSON 或其他结构化数据，并要求去除重复值、处理缺失值、统一字段格式时使用。不适用于非结构化文本清洗，如文案改写。”这段描述里包含了明确的激活条件和排除条件。
我在实际测试中发现一个有趣的规律：描述文本里具体名词越多，模型的激活准确率越高。写“处理用户上传的销售订单 Excel，包括去除空行、合并同 ID 记录、修正日期格式”，比写“清理数据文件”要好用得多。这背后的原因是模型对具体名词的关联能力远强于抽象名词。你给它“销售订单”“日期格式”，它就能和数据清洗的意图建立强关联；你给它“数据质量提升”，它只能猜。
实操技巧：Skill 的描述写完之后，建议做一次“反向测试”——故意输入明显不属于该 Skill 范围的请求，看看模型会不会误激活。误激活是 Skill 系统里最隐蔽的问题，它不报错，但会把任务带偏。
3.2 包管理与版本化：技能变成可交付的业务积木
身为从业者，我最看重的其实是 Skills 带来的版本管理能力。传统 Prompt 很难做版本管理，因为 Prompt 是文本，文本的 diff 只能看出字面变化，看不出行为变化。而 Skill 一旦被结构化，就可以像 npm 或 pip 包一样：有版本号、有作者信息、有变更记录、有依赖关系。
这意味着团队的协作模式可以发生改变。不同同学负责维护不同 Skill，各自独立迭代，互不阻塞。前端业务同学只需要知道“数据处理这个功能由数据 Skill 负责”，而不再需要去读那个 3000 字的 Prompt，从整体上看，这套模式让协作变轻松了。
组合性方面，Skill 最漂亮的设计是它可以嵌套。一个“生成销售周报”的 Skill，可以依赖“查询销售数据”的 Skill 和“生成 Markdown 表格”的 Skill。这种层级组合能力和传统代码里的函数调用是同构的。你可以从一个个小技能开始搭，不断组合成更大的技能。我试过用三个基础 Skill（数据聚合、图表描述、报告排版）组合出一个管理层看板生成器，效果比单写一个巨型 Prompt 稳定得多。
3.3 按需加载与上下文成本
上下文管理是 LLM 应用里最现实的问题。为了确保模型理解全局，我们常常把最大量的信息塞进上下文，然后痛苦地发现模型的响应变慢了、准确率降了。Skills 的按需加载机制，本质上是在帮你做“上下文预算管理”。
知识常驻、按需加载、用完释放，这个模式和操作系统的内存管理有点像，但 Skill 的逻辑界限比传统 Prompt 更清晰。举个具体数字：假设你有一个 2000 token 的数据分析 Skill 和一个 1500 token 的报告生成 Skill，如果每轮任务都需要这两个能力，传统写法就是固定占 3500 token；而用 Skills 以后，纯数据分析任务只需要加载前者，省下了后者的 token 和内存。同时你可以在一个项目中定义 20 个 Skill，模型不必知道它们全部的存在，它只会在需要的时候去翻“目录”。
4. 手把手设计一个 Skill：一次完整复盘
理论讲得再多，不如亲自动手设计一个 Skill。这一章我用一个真实做过的场景——销售周报生成器——来完整复盘设计过程，包括怎么识别可沉淀能力、怎么写核心文档、怎么给示例和工具、以及我在实测中踩过的坑。
4.1 第一步：找到值得沉淀的能力
不是所有需求都适合做成 Skill。我的判断标准有三个：第一，这个任务必须是重复发生的；第二，它的执行逻辑相对固定；第三，它的领域知识可以显式写清楚。
销售周报这个场景完美符合。每周都要做，格式固定（汇总各区域销售额、计算环比、生成结论），而且领域知识明确（什么叫环比、哪些指标需要重点看）。对比之下，一些高度依赖创意、每次要求都不同的任务，就不太适合 Skill——比如“给品牌写一句 slogan”，任务虽重复但结果不可标准化，做成 Skill 反而限制发挥。
我在第一次设计时差点犯一个错误：想把太多东西塞进一个 Skill 里，既要查数，又要分析趋势，还要生成 PPT 文案和邮件正文。后来意识到这四个环节可以拆成四个独立 Skill，每个 Skill 只做一件事。这个拆分逻辑和代码设计里的单一职责原则完全一致。实践下来，拆分后的每个 Skill 都更容易维护，也更容易针对性优化。
4.2 第二步：写 SKILL.md 的三个关键要素
确定好能力边界之后，接下来就是写 Skill 的核心文档。我总结下来，无论如何调整格式，有三个要素是必须写清楚的。
第一个是目标和触发条件。文档开头就应该明确写出“这个 Skill 用于生成销售周报，当用户要求生成周报/汇总本周销售数据时使用”，给模型一个清晰的锚点。第二个是执行流程，最好写成编号步骤，比如 1. 获取数据源 → 2. 校验必填字段 → 3. 按区域聚合 → 4. 计算环比 → 5. 生成结论段落。每一步都应是模型可以执行的动作。第三个是规则和禁忌。这一步的重点是写“不能做什么”，比如“不要计算新客户数，因为数据源里没这个字段”“当某区域数据为空时，输出 N/A 而不是默认为 0”。
执行流程的写法有个技巧：不要写成“经理式的泛泛而谈”，比如“确保数据准确、注意细节”这种话模型没法执行。要写成明确的判别式，比如“当同一区域出现两条数据且日期相同，保留数字较大的一条并记录冲突”。判别式比形容词有用得多，这是我在多次失败后换来的体会。
4.3 第三步：规划示例和工具定义
示例是 Skill 质量的最重要一环。我在项目里总结的经验是：示例宁可少，也不能错。三个高质量、覆盖典型和边界情况的示例，比十五个内容重复的示例有效得多。示例要覆盖到正确路径、边界情况和一个易错情况。正确路径告诉模型“正常怎么走”，边界情况告诉模型“特殊输入怎么处理”，易错情况告诉模型“这里容易踩坑”。
工具定义方面，Skill 通常会绑定几个具体工具，比如数据库查询函数、CSV 处理函数、图表生成接口。工具描述同样要遵循“具体名词优先”原则。例如把“execute_query(sql)”描述成“输入 SQL 语句，返回销售明细表，每行包含区域、销售代表、订单金额、下单日期”，模型就会知道该传哪类参数。
我还踩过工具定义过粗的坑。有一次把图表工具描述成“生成图表”，模型在不确定数据怎么呈现的时候，反复猜测参数格式，浪费了很多轮调用。后来把描述改为“输入 x 轴列表和 y 轴数值列表，生成 PNG 柱状图”，问题立刻消失。你给工具的说明越像一份清晰的 API 文档，模型用错的概率就越低。
4.4 实测中的四个坑
我在真实测试中踩过四个很典型的坑，值得列入避坑清单。
第一个坑是 Skill 描述与真实能力的偏差。我给一个时间管理 Skill 写了“支持查看日历和安排会议”，但实际上绑定的工具只有“创建待办事项”，没有日历读取能力。结果模型经常凭空调用日历读取的假操作，输出结果根本离不开数据支持。这个问题的教训是：Skill 文档里写的能力必须是工具真实支持的，宁可少写也不能瞎写。
第二个坑是 Skill 之间的相互干扰。我有两个 Skill 分别处理“销售周报”和“业绩异常分析”，因为描述里都提到了“销售”“环比”这些词，模型容易激活错误的那个。解决方式是在各自的描述里强化场景隔离，比如前者强调“固定格式周报”，后者强调“发现异常及归因分析”。如果你做过推荐系统的特征工程，这种“特征区分度”的思路会有天然的熟悉感。
第三个坑是示例和规则冲突。某个 Skill 的文档里有一条规则说“所有日期统一输出 ISO 格式”，但示例里却出现了“6月第一周”这种口语化输出。模型在两者之间产生了矛盾，结果随机一趟跑 ISO 格式，随机一趟跑口语格式。教训是示例本身就是另一种规则，它与显式规则冲突时，模型常常更倾向于模仿示例，因为示例在训练和推理里天然带有更高的模式权重。
第四个坑是忽略失败策略。Skill 执行过程中出现异常怎么办？这个没写清楚。比如查询数据库返回空结果，模型往往会当成正常情况直接输出结论，而不是停下来提示“数据为空，无法生成周报”。后来我在 Skill 文档里加了一条规则：任何一步执行失败或返回空数据，必须终止流程并向用户说明原因。加了这一条之后，整套系统的可信度提升非常明显。
5. 没有 Anthropic 的环境，照样用这套范式
我知道很多读者会有一个疑问：Skills 再香，我也未必在 Anthropic 的生态里开发，那我能不能学以致用？答案是肯定的。Skills 表面看是一个具体产品功能，本质上是一套设计范式。这套范式可以无缝迁移到其他模型平台或自己的应用架构中。
5.1 范式迁移：GPTs、MCP 与自研路由
如果你用的是其他平台的类 GPTs 功能，它本身就是一个技能的容器，可以放指令和工具，只是颗粒度和文件管理方式略有差异。你可以把 SKILL.md 写的思路直接迁移过去，核心不变，变的只是配置界面。
更通用的是自研路由方案。核心思想是我在上一节反复强调的三件事：按需加载、接口描述、模块边界。你在自己的代码里定义一个技能注册表，每个技能是一个 JSON 配置，配置里包含触发条件的关键词、执行指令、可用工具列表、参考示例、上下文预算。上层用一个路由模型判断该激活哪个技能，把对应对应的配置注入到上下文里。这套架构完全不依赖特定平台，你完全可以在应用层自己实现。
我第一次在自研系统里尝试这套范式时，在架构上参考了微服务的设计思想：每个技能是一个独立部署的逻辑单元，路由层负责服务发现和请求转发。唯一不同的是，技能间的“通信协议”不是 HTTP，而是上下文注入。这个设计的好处是，你可以逐步把已有的一个巨型 Prompt 拆成多个技能模块，而不需要一次性重写所有逻辑。
5.2 在团队内部从 0 落地的操作建议
落地 Skills 范式，最大的阻力往往不是技术，而是团队习惯。大家已经习惯在一个 Prompt 里不断修修补补，突然要拆成模块，很多人会觉得多此一举。我的建议是从一个真正痛点入手，不要一开始就全量重构。
我建议选一个每周都要被修改的 Prompt 作为改造试点。第一步先梳理它承担的所有职责，你会惊讶地发现一个“客服助手”Prompt 里居然包含了意图识别、情绪判断、话术生成、知识库检索、转人工规则五类任务。第二步把五类任务拆成五个 Skill，每个 Skill 有单独的描述和执行逻辑。第三步在总入口写一个极简的路由 Prompt，只负责判断“用户当前请求属于哪个 Skill”。这一步做完，你会发现每次针对单一任务的修改范围小了很多，测试也简单了很多。
给团队做评审的时候，核心要点是强调“可测试性”。传统 Prompt 的效果好坏是靠人工抽查，而 Skill 可以针对性建立测试集，比如数据清洗 Skill 单独跑一百条测试用例，通过率曲线一目了然。老板和团队成员对于可量化的提升往往有更强的信心，这是一个很好的建立工程共识的策略。
6. 规模化路上真正难啃的骨头
Skills 范式解决了“如何组合能力”的问题，但这不代表规模化就容易了。当你真的把几十个 Skill 铺到业务里，会碰到新的挑战。这一章我聊三个我认为最不好啃的硬骨头。
6.1 评估：技能多了，怎么知道谁在拖后腿
单测里的 Skill 表现很好，但它们组合起来之后，行为会有复杂的涌现效应。A Skill 输出的结果在 B Skill 看来可能格式不对、字段缺失，这种接口契约问题在单测阶段根本发现不了。我建议在评估体系里引入“端到端评测 + 分技能日志”的双层机制。端到端评测保证业务效果，分技能日志保证问题定位。每一次调用都要记录激活了哪些 Skill、每个 Skill 的输入输出摘要。这样当整体效果出问题时，你可以快速回放链路，找到是哪一个节点偏离了预期。
6.2 治理：谁来决定技能能不能上线
当技能数量上去后，另一个常被忽视的问题就是谁有权限发布新版本，谁来负最终责任。我见过团队里每个人都往一个共享技能仓库里加东西，过了两周，同一个数据清洗流程出现了三个互相冲突的版本。
合理的治理机制应该像代码仓库一样严肃：Skill 的变更需要走提交评审，要有明确的作者、更新说明和测试记录。关键业务 Skill 要设置负责人，没有负责人维护的 Skill 应该标记废弃。另外还有一个容易踩坑的点：Skill 升级之后，历史调用链路上的缓存和日志格式也要考虑兼容性，不然旧接口调用方会一脸懵。你做得越规范，后续协作的摩擦力就越小。
6.3 跨项目复用：通用技能与专用技能的平衡
最后一个难题是复用边界的把握。有些团队会追求做一个“无所不包”的超级通用技能，试图通过堆叠内容让各种项目都能用，结果最后每个项目都在抱怨“这个技能不贴合我的场景”。通用和专用之间注定有取舍，我的倾向是核心能力做得通用，业务表达做得专用。
以数据处理为例，底层“去除重复值、统一日期格式、处理空值”是通用能力，完全可以沉淀成公共技能；而“销售订单数据怎么清洗”要落到具体的字段名和业务规则，应该放在业务层技能里。这种分层思路在软件工程里很常见，放在 Skill 体系里同样适用。核心是记住边界，不要指望一键解决所有问题，而是让叠加变得更加可控。
从我个人的实操体会来看，Skills 范式带来的最本质的变化其实不是技术优化，而是思维方式的改变：我不再想“怎么把更多规则塞给模型”，而是想“怎么把一个复杂任务拆成若干可控的模块，再让模型在模块间做选择”。这个思维转变一旦完成，你会发现很多之前无解的问题都有了清晰的入手点。如果你正被复杂的 Prompt 和失控的 Agent 折磨，建议先从一个小业务的技能化开始试试，这可能是当下性价比最高的一次架构调整。
