企业官网建设流程全解析

很多企业找我做智能体落地咨询时，都会问同一个问题：模型能力已经够强了，为什么我们接了 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 资产库，远比追每一个新模型发布更值得。