很多企业找我做智能体落地咨询时都会问同一个问题模型能力已经够强了为什么我们接了 API、写了 prompt、配了几个工具智能体上线后还是像个一次性玩具换个部门换个场景就废了我的看法是他们缺的不是模型是「能力封装层」。prompt 是写给一次对话的工具是模型伸手去够的外部动作这两者之间还隔着一层东西一个能把「这个领域怎么干、用哪些脚本、查哪些文档、踩过哪些坑」整包打包、按需取用、还能跨团队复用的能力单元。Anthropic 把它叫 Agent Skills我更愿意把它理解成企业智能体的「能力资产」。这一篇不聊怎么调模型、不聊怎么画工作流就聊 Skill 这件事的本质。它到底是个什么结构运行时怎么被检索和触发它怎么同时解决了「上下文爆炸」和「能力可复用」这两件看起来矛盾的事它和工具调用、和 prompt 工程的边界在哪里以及企业怎么把散落各处的知识和流程沉淀成一个可以版本化、可授权、可编排的 Skill 资产库。先把最本质的一句话放在这Skill 就是一个被检索、被触发的「上下文与指令包」。它不是一个新的模型能力它是对上下文窗口的一次工程化治理。Skill 到底是什么一个文件系统里的目录抛开所有包装一个 Skill 在物理上就是一个目录。它里面至少有一份SKILL.md可能还带有scripts/子目录放可执行脚本和若干 markdown、schema、模板之类的参考文件。模型不是在「运行」这个 Skill而是在虚拟机的文件系统里用 bash 读它、用 bash 跑它里面的脚本。这和你看一个新同事入职时给他一份 onboarding 文档、让他自己按需翻阅参考手册、让他执行仓库里的工具脚本几乎没有区别。最关键的约定在SKILL.md的开头一段 YAML frontmatter。它只有两个必填字段但这两个字段决定了 Skill 的生死。name字段约束很死最长 64 字符只能小写字母、数字和连字符不能含 XML 标签不能用anthropic、claude这两个保留词。这不是强迫症是因为这个 name 会原样出现在系统提示里用来做检索匹配乱写就匹配不上了。description字段才是真正的「触发器」。规范的要求很明确必须同时说明「这个 Skill 做什么」和「什么时候该用它」。它会被注入系统提示Claude 靠它来判断「当前这个请求要不要把对应的 Skill 从文件系统里拽出来」。所以一个糟糕的 description 长这样「处理文档」。一个合格的来自官方示例的长这样「Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.」注意它用的是第三人称、列出了具体动作、还写了触发语境。这一步写不好后面全白搭。SKILL.md的正文是第二层内容是真正的过程性知识流程、最佳实践、调用示例。规范建议正文控制在 500 行以内超过就拆到单独文件里靠引用按需加载。至于scripts/和参考文件它们构成第三层。脚本是 Claude 通过 bash 执行的脚本本身的代码不会进上下文只有它的输出占 token。参考 markdown 是 Claude 真正用 read 读进上下文的读到才有成本。这一套「分层装载」的机制是 Skill 全部价值的地基下面专门展开。这里有个细节值得点破模型在启动期看到的不是 Skill 全文而是形如pdf-processing - Extract text and tables from PDF files...的一行摘要。它要做的是一次「请求语义」和「每行摘要」的匹配。所以description的质量直接决定了召回上限。写到位的 description模型在几百个 Skill 里也能精准命中写水的 description装得再多也是摆设。官方把description称为 Skill 的「发现面」本质上它是一段给模型用的检索索引不是给人看的说明。很多人花大量精力写 SKILL.md 正文却草草写一句 description等于把最该打磨的检索入口交给了运气。它解决的真实问题上下文窗口的工程化治理很多团队对智能体的痛苦归根到底都是上下文窗口的痛苦。一方面你希望模型掌握全公司所有的领域知识、流程规范、历史踩坑全堆进去上下文根本装不下装下了也因为噪声太多而用不好这是「上下文爆炸」。另一方面每次新对话你又得把这些知识重新交代一遍重复劳动、且每次质量不稳这是「能力不可复用」。Skill 的精妙之处是用一套渐进式披露progressive disclosure机制把这两个问题一起解了。它把 Skill 的内容切成三级每级在完全不同的时机进入上下文且成本天差地别。第一级是元数据。也就是name和description在系统启动那一刻就被预先加载到系统提示里。每个 Skill 大约只占 100 token。这意味着你可以装一百个 Skill在启动期几乎不付出上下文代价因为它们只有「名字 一句话介绍」在那儿待命。它不占地方但足以让模型在接到请求时判断「该请哪个 Skill 出山」。第二级是SKILL.md正文。只有当某个请求匹配到了 description模型才会用 bash 把这份文件读进上下文。它的体量被建议压在 5k token 以内是一次性的、按需的装载。第三级是脚本和参考文件。脚本被执行它的代码永远不进上下文只有 stdout 占 token参考文件被 read读哪份才占哪份的 token没读到的那份在文件系统上躺着零成本。一个 PDF 处理 Skill 可能带了几百页的 API 文档和一个验表单的脚本但只要你今天只是想提取文本那几百页文档和那段脚本就不会消耗你一个 token。这套机制的本质是把「上下文」从「启动时一次性全量灌入」变成了「运行时按路径增量取用」。上下文窗口不再是仓库而是变成了一个按需挂载的文件系统。我常跟团队说Skill 不是在给模型加知识是在给模型的上下文做「虚拟内存」常用内容在窗内不常用的放在「磁盘」上用到再 page in。理解到这一层你就不会再试图把所有知识写进一个超长 prompt 里了。还有一点容易被忽略脚本执行比让模型现场生成等价代码要可靠得多。模型临时写一个表单校验脚本可能每跑一次接口都变而 Skill 里预置的validate.py行为完全一致且代码本身不占上下文。这是把「确定性操作」从模型的随机性里剥离出来的关键手段。Skill 与 tool use、prompt 工程的边界讲到这必须把它和另外两个经常被混为一谈的概念划清prompt 工程和工具调用tool use / function calling。先说 prompt 工程。prompt 是写给「这一次对话」的指令它是会话级别的、一次性的。你今天给模型写一段「你是资深 Go 工程师遵循我们团队的错误处理规范」明天开新会话就丢了得重写。Skill 是「常驻的、可被检索的」指令集写一次装上文件系统之后任何会话只要相关就会被自动触发。一个朴素的区别prompt 是你说给模型听的话Skill 是模型自己会去找的说明书。当同一段领域知识要在成百上千次对话里反复生效把它固化成 Skill 比每次塞 prompt 强太多。但反过来Skill 也不能取代 prompt 里那些针对当下任务的具体约束。两者是常驻知识与临时约束的互补不是替代。再说 tool use。工具是模型可以调用的「动作接口」比如查数据库、发 HTTP 请求、读写文件。工具本身是能力但它不携带「什么时候用、怎么组合、踩过什么坑」的过程性知识。Skill 恰恰补的是这一层一个 Skill 内部可以指示模型去调用某个工具或 MCP server它用ServerName:tool_name这种全限定写法来避免工具找不到。换句话说工具是「手」Skill 是「知道什么时候该伸手、伸手之前要先看清路况的操作手册」。一个只配了工具没配 Skill 的智能体模型虽然「能做」但每次都得靠自己在对话里重新推演怎么做质量随缘。把流程沉淀进 Skill等于把「怎么做」从模型的临场发挥变成了可复用的确定性资产。边界可以这么记prompt 管当下这一次Skill 管常驻可复用的方法论tool 管伸手够得到的动作。三者叠加才是一个能稳定生产的企业级智能体。顺带澄清一个常见混淆Skill 和 RAG 不是一回事。RAG 是在每次查询时按相似度从知识库捞几段文本塞进上下文喂的是「碎片化的事实」Skill 是触发后整包载入的结构化方法论喂的是「成体系的过程性知识」。RAG 适合「这个字段什么含义」这类事实检索Skill 适合「这种报表怎么做才不翻车」这类流程性任务。两者可以共存一个 Skill 内部的参考文件完全可以用 grep 甚至 RAG 去定位具体章节。把 Skill 理解为「带流程意识的 RAG」是个好切入角度但别指望用 RAG 替代 Skill 去承载那些必须按特定顺序执行、带校验环的操作那是 Skill 的主场。企业怎么沉淀 Skill 资产库单看一个 Skill 是个工程技巧但企业真正吃到红利的是把散落各处的知识和流程沉淀成一个可治理的「Skill 资产库」。这件事做好了智能体就从一个项目的玩具变成组织的肌肉记忆。我见过太多样子一个核心工程师脑子里装着「我们系统上线前必须跑哪七个检查、找谁审批、哪个接口不能直连」他一离职这知识就随人走了或者某个团队的排障步骤写在三个月没人看的 Confluence 里新人根本不知道去看。这些隐性知识最该被固化成 Skill。具体来说沉淀的素材通常来自三类领域知识那些「只有老人懂」的表结构、字段含义、过滤规则比如「查营收永远要排除测试账号」放进reference/下的 markdown模型按需 grep。重复流程那些「每周都要做一次、步骤固定、容易漏」的操作固化成 SKILL.md 里的 workflow关键步骤用脚本兜底校验。踩坑经验那些「上次这么干翻车了」的反例写成 SKILL.md 里的 MUST / MUST NOT 规则比口头警告管用得多。企业治理有几个从官方最佳实践里提炼出来的要点值得照搬。先窄后宽。不要一上来就做一个「万能运营 Skill」。从一个具体、单一的工作流起步比如「格式化销售周报」等模式跑通了、评估也过了再考虑把相关的窄 Skill 合并成角色级的大包比如「销售运营」。合并的前提是评估证明合并后的效果不降而不是拍脑袋。比如把「格式化销售周报」「查询管线数据」「更新 CRM 记录」三个窄 Skill 合成「销售运营」大包只有当评估套件确认合成后在单个任务上的表现不弱于原来三者之和合并才站得住脚。建内部注册表。每一个 Skill 在库里都要有记录用途、Owner、当前版本、依赖MCP server、包、外部服务、最近一次评估时间和结果。没有注册表的 Skill 库半年后就是一堆没人敢动的目录。按角色组织。把 Skill 按组织角色打成束销售团队的 CRM 操作、管线报表工程团队的代码审查、部署流程、事故响应财务团队的报表生成、数据校验。每个角色的用户只加载和自己相关的那束既控制上下文占用又避免无关 Skill 抢触发。注意召回上限。这是很多人栽跟头的地方装太多 Skill每个的元数据都要在系统提示里竞争注意力装到一定数量模型的召回准确率就会掉。官方在 API 上单请求最多支持 20 个 Skill。所以当某个角色需要的 Skill 超过这个量该做的是合并窄 Skill或者按任务类型把请求路由到不同的 Skill 集合而不是无脑全装上。还有一个治理动作叫「评估驱动开发」先写三到五个典型查询的评估用例什么该触发、什么不该触发、模糊边界怎么处理再用最小指令去写 Skill 跑评估迭代到通过。这比「先把文档写一大篇」有效得多因为文档往往写的是想象出来的需求。沉淀时的信息架构也有讲究不是把所有 markdown 堆进一个目录就完事。官方推荐几种组织模式最实用的是「按领域切分参考文件」。比如一个大数据分析 Skill把reference/finance.md、reference/sales.md、reference/product.md分开用户问营收时模型只读 finance.md其余两份躺在磁盘上零成本。第二种是「条件细节」基础用法写进 SKILL.md高级特性链接到独立文件用到才读。第三种针对超长参考文件开头必须放目录否则模型用head -100预览时看不到全貌会漏掉后半部分的关键约束。无论哪种模式参考文件都要「从 SKILL.md 直接一层深链接出去」禁止 A 引 B、B 再引 C 的嵌套嵌套会让模型只读个头部就走人拿到残缺信息。对于有执行代码的 Skill还有一条铁律叫「solve, don’t defer」脚本要自己处理错误而不是把失败甩给模型去临场发挥。比如读文件失败就创建默认内容而非直接抛异常超时和重试次数要有注释说明依据而非丢一个魔法数字。更进一步对高风险的批量操作采用 plan-validate-execute 模式先生成一份changes.json计划用校验脚本审过再真正执行。校验脚本要输出具体错误信息「字段 signature_date 不存在可用字段有 customer_name、order_total」让模型能精准修正。这套机制把「确定性操作」从模型的随机性里彻底剥离是大批量、不可逆操作的保命绳。版本化、权限与组合编排当 Skill 进了生产它就不再是一份可以随便改的文档而是一件需要被管控的软件资产。这里有几条必须守住的线。版本必须钉死。在 API 上如果你不指定版本请求会用最新版。这意味着workspace 里任何一个人上传了新版生产上跑的智能体立刻就换了一套行为。正确做法是生产环境钉死到具体版本新版本上线前必须跑完整评估套件把它当成一次正式部署、走完整安全审查。保留上一个版本作为回滚兜底新版本评估挂了立刻回退。更高级的做法是算 reviewed Skill 的校验和部署时校验用签名提交保证来源可信。安全审查不能省。Skill 给了模型新能力也意味着一个恶意 Skill 能指挥模型干和声明无关的事。企业审查清单里最该盯的几条目录里有没有.py/.sh/.js脚本它们以环境完整权限运行、有没有教唆绕过安全规则或隐藏行为的指令、有没有引用 MCP server把访问面扩大到 Skill 之外、有没有网络访问fetch/curl/requests是数据外泄的常见通道、有没有硬编码的密钥、有没有越出 Skill 目录的文件系统访问。官方的 Skills API 上传通道不自动扫描所以靠的是这份人工审查清单加版本钉死。Claude Enterprise 在 claude.ai 和 Cowork 侧可以开启内容安全扫描但 API 侧不覆盖两边策略要分开想。组合编排靠引用而非复制。复杂的智能体不该把所有知识塞进一个超大 Skill而是让多个 Skill 各管一段由上层 graph 或 loop 把任务路由到对应 Skill。一个 Skill 内部也可以叫起另一个领域 Skill 的参考文件。组合的关键原则是「引用一层深」参考文件都直接从SKILL.md链接出去不要让 A 引用 B、B 再引用 C否则模型在嵌套引用里可能只读个head -100就走人拿到的是残缺信息。长参考文件在开头放目录让模型即使只预览也能看到全貌。落到工程管理Skill 目录天生适合用 Git 当单一事实源每个 Skill 目录天然对应仓库里的一个文件夹历史追踪、PR 审查、回滚都现成。但有个跨端陷阱要提醒自定义 Skill 不会跨端同步。上传到 claude.ai 的不会自动出现在 API 上Claude Code 的文件系统 Skill 又独立于前两者每个端都要单独上传和管理。如果同时在多个端部署得自己建同步流程保证一致否则会出现「本地能触发、线上触发不了」的诡异问题。API 侧单请求最多挂载 20 个 Skill超出就得靠合并窄 Skill 或按任务路由来收敛。讲到这Agent Skills 的本质已经很清楚了。它不是一个新模型能力它是对「如何让模型稳定地、可复用地、安全地获得领域能力」这个老问题的工程回答。三层渐进式披露解决了上下文窗口的有限性目录化结构让知识可沉淀、可审计、可版本化与工具和工作流的清晰边界让它成为智能体系统中承上启下的那一层。我的判断是未来企业智能体的竞争力不会来自谁接的模型更大而来自谁把组织的过程性知识沉淀成了高质量、成体系、可治理的 Skill 资产库。模型会趋于同质但一家公司的「怎么做才不会翻车」的私有知识是别人抄不走的。Skill 就是把这些知识变成机器可调用的形态的那把钥匙。从这个角度看投入精力经营 Skill 资产库远比追每一个新模型发布更值得。