直接把标题当成引子来写。先从一个让很多人都有共鸣的现象切入——精心调好的Prompt过一阵子就失效改动一两行就可能让效果断崖式下跌这种体验其实指向了Prompt根本上的不可规模化。然后逐步展开解释为什么会这样再把Anthropic Skills的设计范式拿出来对照落到工程实操层面给出可复用的拆解方案。1. 从“聪明的小技巧”到“失控的补丁”——Prompt和Agent的扩展困境我身边越来越多做AI应用的朋友开始承认一件事精心调出来的Prompt上线跑两个月之后基本只能靠祈祷维护。改一行措辞可能让整个流程输出崩掉加一个示例又可能让之前稳定的场景开始胡言乱语。开发时各种“妙手偶得”的小技巧在生产环境里全都变成了定时炸弹。几年前大家普遍以为Prompt Engineering的核心价值在于“把话说清楚”。但实际做久了就会发现真正的问题不是单条Prompt写得好不好而是当系统里存在几十条、上百条Prompt并且它们之间还有调用关系时整个体系根本无法预测、无法测试、无法演进。Agent的情况更麻烦。原本设计Agent是为了让模型自主决策调用工具、规划步骤但一旦任务复杂度上来模型在长链路里经常会“迷失自我”——忘了最初目标、重复执行同一个动作、在两个工具之间无限循环甚至自作聪明地把用户没要求的事情也做了。更致命的是整个执行过程对开发者来说是黑盒出了问题根本不知道应该改哪里。这些症状其实指向同一个根源我们一直把扩展问题的解法押在模型的文本理解能力上而没有建立一套结构化的能力封装机制。Anthropic把这个问题摊开来讲给出了一个专门针对扩展性设计的范式——Skills。理解它的思路比单纯跟风用某个功能重要得多。先说结论Skills本质上解决的是“能力如何被稳定、可控、可组合地提供给模型”的问题。它和Prompt、Agent最大的区别在于前两者是把能力和上下文混在一起而Skills是把能力做成独立单元并配了清晰的接口。2. 为什么Prompt天生就无法Scale——那些年我们踩过的“提示词凋零”2.1 Prompt的规模诅咒当年大家刚开始用Prompt时都觉得这东西太神奇了——不用写代码用自然语言就能调教模型。但实际项目里Prompt一多问题就暴露了。最典型的症状是提示词之间的互相污染。A场景的Prompt里写了一句“你是一个严谨的助手”这句话的本意是规范A场景的输出风格但如果在系统里被复用到B、C、D场景就可能让B场景的输出变得过于死板。很多团队最终把公共Prompt越加越长就是因为不确定哪些话会对哪些场景产生影响只能“宁可错杀不可放过”。这种脆弱性在业内被称为“提示词凋零”Prompt Decay。我见过不止一次一个在测试集上表现极好的Prompt过了一个月再跑效果明显退化。原因不一定是模型版本更新了也可能是上游数据分布变了、用户提问方式变了或者仅仅是上下文里多了一段与任务无关的文本。Prompt的正确性依赖太多隐含假设而这些假设没有任何机制被固化下来。2.2 上下文窗口的物理天花板Prompt扩展困难的另一个硬约束是上下文窗口。现在的模型虽然动辄支持百万token但只要稍微用密集检索增强RAG的应用很快就会发现上下文根本不够用。一个典型的知识库问答机器人如果用户的问题比较复杂需要检索的片段可能有二十到三十段。每段按300 token计算就是6000到9000 token的上下文。如果再算上历史对话、当前任务指令、各种few-shot示例一次请求轻轻松松突破两万token。这还只是单个请求如果要支撑高并发推理成本会呈线性甚至超线性上涨主要是计算attention矩阵的算力开销。很多人用“把Prompt写得短一点”来应对但效果有限。因为Prompt的核心功能是传递任务意图和知识这两者都天然需要空间。而且一旦上下文过长模型会很难聚焦关键信息甚至出现“大海捞针”式的问题——明明信息都在上下文里但模型就是找不到。2.3 Prompt的不可测试性带来维护噩梦写代码可以有单元测试、集成测试、持续集成但Prompt很难有一套标准的测试体系。原因在于模型的输出是概率性的同一个Prompt同一份输入在不同时间可能给出不同答案。即使加了模型版本锁定采样参数调成temperature0也只能部分缓解随机性问题。这意味着Prompt的“回归测试”只能靠人工逐条检查。我以前在某个项目里维护过七十多个Prompt模板每次改版都要在几十个用例上逐一人工确认输出质量整个流程要耗费两天。更要命的是有些时候你改了一个Prompt想着只影响一个场景结果另一个看似不相关的场景却因为系统级的Prompt被间接影响输出风格全变了。这种“蝴蝶效应”会彻底摧毁团队对系统的信任感最后所有人都倾向于“能不动就不动”。当一套系统只能靠冻结变更来维持稳定时它在架构上就已经失败了。3. Agent的扩展困境编排逻辑的不可控与不可见3.1 Agent不是万能灵药如果说Prompt的问题是“静态指令不可控”那Agent的问题就是“动态过程不可控”。理想中的Agent应该像一个能干的下属接到任务、分析拆解、调用工具、逐步推进、最后交结果。现实中的Agent则经常像一个过度自信的新人口头答应得很好一上手就开始自由发挥。最常见的故障有几种。一是自我循环模型反复调用同一个查询工具拿回来的结果和上一轮几乎一样但它不觉得自己做完了。二是目标漂移长时间的多步推理中模型逐渐忘记了用户最初要什么开始在一个次级问题上深耕。三是幻觉性操作模型在不确定的情况下“编造”一个工具调用参数比如把一个不存在的文件名传给了读取函数。这些问题的共同点在于Agent的每一步决策都依赖模型的即时判断而没有一套机制去约束每一步的边界。你当然可以在系统Prompt里写“请务必先确认参数再调用工具”但这种依赖文本约束的方式本质上又回到了Prompt的老路上。3.2 调试Agent是在“给黑盒做心理分析”做过Agent开发的人都懂那种痛苦任务执行到第三轮时模型做了一个奇怪的决策然后整个流程就歪了。你回头看日志发现这个决策在当时的上下文里居然“有它的道理”——因为模型在上下文里看到了一些引导性的信息。这就是Agent调试的尴尬你无法简单地“修正一行代码”来纠正错误因为错误是模型在特定上下文中的概率性反应。你能做的只是调整Prompt、换模型版本、修改工具描述、增加约束……这些都是间接手段效果如何只能重新跑一遍再看。有一次排查一个Agent循环调用的问题我花了将近一天时间把上下文里每一段文本都过了一遍最后发现是某个工具的描述里写了“如果需要更多信息可以再次调用本工具”模型就把这句话理解成了“必须反复调用直到永远”。这种问题在数学上没法根治只能靠工程手段把可能性排除掉。这也是为什么我越来越觉得Agent的演进方向不应该是“让模型更自由地发挥”而是“把自由限制在结构化框架里”。Anthropic Skills的很多设计细节其实就是往这个方向努力的。4. Anthropic Skills的设计精髓把“能力”从“上下文”里解耦出来4.1 Skills到底是什么——一个管理“能力单元”的接口规范Anthropic提出的Skills不是又一个魔法提示词而是把“某项能力”打包成一个完整、独立的单元并定义了这套能力如何被发现、被加载、被执行。你可以把它理解成工具函数Function Calling的进阶形态。工具函数阶段我们只是告诉模型“有这么一个函数你可以调用”但函数的内部实现、依赖资源、运行环境等细节模型完全不知道也不需要知道。Skills沿用了这个“黑盒”思想但把黑盒做得更厚实了——它不仅描述函数长什么样还定义了函数需要哪些资源、在什么条件下运行、内部有哪些步骤。从API的角度看用户向模型发出请求后模型会根据任务判断需要哪些Skills。然后这些Skill被显式地注入到上下文中或者以特殊标记的形式作为可用项的“清单”提供给模型。关键在于Skill本身不是提示词。提示词是给模型“读”的文本Skill是给模型“用”的能力包。一个Skill内部可以包含执行代码、操作流程、参数校验规则、输出格式要求甚至还可以藏一些不适合让模型自由发挥的“私密指令”。这种隔离设计是从根上解决Prompt规模问题的关键。4.2 清单模式Manifest让模型“看到”能力而不是“读到”内容Anthropic文档里有一个让我印象很深的设计——Skills的清单Manifest机制。默认情况下系统里可能挂了上百个Skill但每一次请求不可能把所有Skill的全部内容都塞进上下文。那样上下文立刻爆炸。所以它采用了类似“能力注册表”的方式每个Skill对外暴露一份简短的清单列出名称、描述、用途、触发条件模型先浏览这份清单决定哪些Skill与当前任务相关然后按需获取具体内容。这就像你去一个大型图书馆入口处有一块总索引板上面写着各个书库的位置、开放时间、馆藏范围你先看了板子再决定去哪个书库而不是把全馆几十万本书都搬到阅览室。这个设计的价值是双重的。一是上下文瘦身模型只需要看到名字和摘要就能做出选择决策。二是解耦部署即使某个Skill内部的实现细节频繁更新只要清单描述不变上游流程就不需要任何改动。这给AI应用的架构演进留出了很大的灵活空间。4.3 能力边界与权限控制——防止模型“越界操作”Skills在设计上还有一个很值得借鉴的点把权限控制提升到了能力描述层。普通Agent在使用工具时只要模型生成了一个看起来合理的JSON格式工具调用系统往往就会执行它。至于这个调用是否在用户授权范围内大多数情况是没人在意的反正默认“模型说啥就是啥”。Skills把这个问题前置了每个Skill可以声明自己需要什么权限、访问什么资源、不允许做什么操作。模型只有在已有授权匹配的情况下才会触发这个Skill否则直接返回“无权限”或者引导用户授权。举个类比。传统方式相当于你把一个员工带到服务器机房门口告诉他“你需要什么自己拿”Skills的写法相当于你给员工办了一张门禁卡卡上写清楚了能进哪些房间、不能动哪些设备一旦员工试图进入无权区域门直接不开。这种机制表面上只是一个工程细节但它对扩展性的影响极其深远。因为一旦能力可以被权限描述清楚你就可以把不同的Skills分配给不同的用户角色、不同的项目、不同的环境而复用性由此产生。5. Skills面对的挑战与思考——它是不是终极方案5.1 我的第一个Skill从“文档搜索引擎”到“渐进式总结器”上个月我花了些时间实践了一阵建了一个小型的“文档搜索引擎”Skill后来又迭代出一个“渐进式总结器”。整个过程让我对Skills的实际运作有了更深的感觉。最初版本纯粹是为了验证清单机制做了一个能搜索本地文档库的Skill。它的清单是这样写的名称文档搜索引擎描述从本地文档库中根据关键词检索相关条目并按相关度排序触发条件当用户询问与本地文档库相关的问题参数query必填limit可选默认5结果发现模型对这个Skill的调用率并不高——在很多场景下模型会先自己对问题做各种猜测性回答而不是直接去检索。问题出在描述上因为模型“读了”描述但“理解”到的触发条件不够清晰。后来我改进了写法把描述改成“仅当用户明确要求查找本地文档时使用本工具不要将本工具用于常识性问题。”这一下调用准确率才上去。这个教训让我意识到Skills虽然把结构化边界建好了但Skill清单本身可不可用依然考验设计者对描述、触发条件、参数说明的把握能力。然后我在同一个Skill里叠加了一个“渐进式总结”能力当检索结果超过5条模型先归纳前5条再追加下一轮而不是一次性把所有结果硬塞给模型。这个步骤很像人类处理长文档的方式效果还挺稳。5.2 Skills的边界——哪些场景它解决不了Skills设计得再精巧也解决不了一个根本问题它依赖模型对清单的判断能力。如果模型本身对“该不该调用这个Skill”的判断不准确再好的封装也无济于事。我遇到过几个典型失败案例一是清单描述含糊导致模型无论如何都无法触发正确的Skill。这类问题只能靠大量试错来微调清单文案其难度和调Prompt没什么本质区别。二是多个Skill的触发条件高度重叠。系统里有“文档搜索”“网页检索”“数据库查询”三个Skill当用户提出一个可能涉及多个数据源的问题时模型可能会随机选择一个而不是综合判断。我在一次测试中让模型查询一个既存在于本地文档又存在于数据库的信息结果模型选择了本地文档搜索而实际上数据库里的那份才是最新版本。三是Skill内部步骤依然可能失控。Skills定义了能力单元的外围但单元内部如果是一系列多步操作模型在中间步骤的决策依然可能出错。这时就要靠内部设计足够简化甚至用确定性代码替代自由决策。综合来看Skills是对Prompt和Agent范式的一次重要修正但它不可能是终极方案。终极方案大概率是分层协作底层用确定性代码做“硬逻辑”中层用Skills做“能力封装”上层用模型做“意图理解与协调”。6. 工程化落地的几条实操建议——怎么开始用Skills改造现有系统6.1 从最痛的点切入不要全面重构如果你有一个已经跑起来的AI应用千万不要急着把所有功能都改造成Skills。这样做的风险极大因为现有系统的行为模式已经固化强行迁移很容易出现行为漂移。我建议找一个逻辑最清晰、边界最明确、失败率最高的功能点把它先抽出来做成一个Skill。这既能验证范式可行性也能在出现问题时把影响面控制到最小。我自己尝试过改造一个“邮件分类助手”它本身的功能很简单把收到的邮件按紧急程度和主题自动分类。但之前因为和多条Prompt混在一起每次调整都会误伤其他场景。改成Skill后因为边界独立只要Skill清单描述不变其他场景完全不受影响。6.2 描述与清单就是新“接口文档”——写清楚才能被正确使用Skills将Prompt里的描述与参数说明脱离了上下文后就变得非常像真正的接口文档。但接口文档写得好不好直接影响对接质量。写Skill清单时我总结出几条经验描述里写明“做什么”“不做什么”“什么时候用”“什么时候不用”。参数定义尽量详细写清楚类型、取值范围、默认值。触发条件要写“排除项”因为模型容易把“根据某些描述”理解为“有这样的情况就调用”但漏掉“哪些情况下不该调用”的约束。不要在清单里写具体业务数据清单只做能力索引。6.3 建立测试集让Skills可回归、可对比Skills的封装逻辑让测试比纯Prompt更加可行但依然需要用测试集来持续验证。我给自己的Skill建立了一个小规模回归集里面包含几十个典型输入每次调整Skill后都跑一遍核对输出是否符合预期。这里出现了一个不同类型的“单测”——不仅仅是断言模型的输出还要断言模型是否正确地触发了Skill、参数是否填写正确、返回结果是否被正确使用。这个测试体系一旦建起来你的系统就从“黑盒玄学”走向了“灰盒工程”至少在出问题时能快速定位是不是Skill环节的问题。6.4 别忽略成本与延迟——Skills的加载也是要花token的最后提醒一个很多人容易忽略的点Skills的加载和触发也会消耗token和推理时间。虽然清单模式已经大幅压缩了上下文但每个Skill的完整描述提示词内容在触发时还是要被注入到上下文中的。如果一个请求同时触发三四个重型Skill上下文长度依然会显著增加推理延迟也会上升。在架构设计时需要统筹考虑哪些Skill是高频、轻量的可以常驻上下文哪些Skill是低频、重型的应该做成按需加载。这个权衡逻辑和传统软件开发里的“缓存策略”很像需要机构对运行指标持续追踪、调整才能找到最优解。7. 从Prompt到Skills的范式迁移能给我们带来什么从整个AI应用开发的演进脉络来看Prompt时代解决的是“怎么让模型理解一句话”Agent时代解决的是“怎么让模型自主执行一串动作”而Skills阶段解决的是“怎么让模型在一个结构化的能力网络中安全、高效地工作”。对开发者来说这其实是一个非常明确的方向转变从“面向模型写提示词”转向“面向能力做封装”。前沿领域里很多人已经预判未来的AI应用会越来越像传统的软件系统——模块化、可测试、有边界、可运维。而Skills的设计恰恰提供了这样一套逻辑基础。当然它仍处于快速演进阶段工程实践还需要大量真实场景去验证。但方向本身值得重视现在开始思考如何用这种“能力单元”思维整理自己手头的工作是一个确定性很强的投入。我个人在实际操作中的体会是与其等生态成熟了再学不如现在就挑一个最小、最痛的点开始实践。把这个点做成Skill跑通之后你会自然理解这套范式的价值边界在哪里——清楚什么东西能给你带来扩展性哪些问题依旧要靠清晰的系统边界去解决。