企业官网建设流程全解析

横评 OpenAI / Claude / LangChain 三大官方 Skills：同一件事，三家各说各话

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills

2026 年初，"Skills"接棒 MCP，成为智能体生态最热的关键词。掘金、CSDN 上相关教程动辄上万阅读，GitHub Trending 上 Skills 类仓库批量涌现，腾讯 SkillHub、智源 SkillsBench 等配套生态也相继落地。但热度之下有一个被反复忽略的事实：OpenAI、Anthropic、LangChain 三家都在做"技能化封装"，却给出了三套不同的文件规范、触发机制与加载策略。

同样是把一个可复用的工作流打包给 Agent，为什么 OpenAI 把"上下文即公共品"写进规范，Claude 强调渐进式披露的三层架构，而 LangChain 走向代码级路由与状态管理？本文以本地 OpenAI 官方 skills 仓库源码为主线，结合社区对 Claude Skills 与 LangChain Skills 的一线实践情报，逐层拆解三家体系的设计差异，最后给出按项目类型的选型建议。

一、先对齐问题：Skills 到底在解决什么

社区里流传最广的一句总结是："MCP 负责数据从哪来，Skills 负责拿到数据后怎么走，模型在这条路径上推理"。三者各管一段，才构成完整执行链路。

这句话点出了 Skills 的本质：它既不是工具协议，也不是提示词模板，而是把"指令 + 脚本 + 资源"打包成可发现、可复用、按需加载的能力单元。仓库 README 的开篇定义与此完全一致：

Agent Skills are folders of instructions, scripts, and resources that AI agents can discover and use to perform at specific tasks. Write once, use everywhere.

（见 README.md）

"Write once, use everywhere"——三家都认同这个目标，但"everywhere"落在哪个层级，分道扬镳就此开始。

二、设计哲学与文件规范：同一份 SKILL.md，三家各说各话

OpenAI / Codex：上下文是公共品，极简 frontmatter

OpenAI 官方仓库把技能目录组织为三个层级：skills/.system（Codex 内置预装）、skills/.curated（精选，可按名安装）、skills/.experimental（实验）。而整套规范的"宪法"是系统内置的 skills/.system/skill-creator/SKILL.md，其核心设计原则非常鲜明：

The context window is a public good. Skills share the context window with everything else Codex needs.

基于这一哲学，OpenAI 把 SKILL.md 压缩到最小必要集：

• YAML frontmatter 只允许name与description两个字段——规范明确写道"Do not include any other fields"，因为"这两个字段是 Codex 判断何时触发技能的唯一依据"；
• Body 仅在触发后才加载，且要求压到 500 行以内，把变体细节拆进references/；
• 可选资源目录三分：scripts/（可执行代码，无需读入上下文即可运行）、references/（按需读入的文档）、assets/（输出用模板/图标，不进入上下文）。

规范中还给出三级加载模型：元数据（约 100 词，常驻上下文）→ SKILL.md 正文（<5k 词，触发后加载）→ 捆绑资源（按需无限加载）。这被 OpenAI 官方命名为"渐进式披露"（Progressive Disclosure），并在 skills/.system/skill-creator/SKILL.md 中给出了三种拆分模式：按引用拆、按领域拆、按条件细节拆。

另一个值得注意的细节：OpenAI 引入了产品化的 UI 元数据文件agents/openai.yaml，包含display_name、short_description、icon_small、default_prompt等字段（详见 skills/.system/skill-creator/references/openai_yaml.md），还支持声明 MCP 依赖。这是三家体系里唯一把"给模型看的规范"与"给人/UI 看的元数据"显式分离的做法。

Claude：L1/L2/L3 三层架构，元数据更"厚重"

社区对 Claude Skills 的拆解普遍采用三层架构（以 CSDN 上阅读量两千余的 《智能体 Skills 技术原理分析和应用》 为代表）：L1 索引层（YAML Frontmatter）、L2 指令层（SKILL.md 结构化指令）、L3 资源层（Scripts/References）。

与 OpenAI 的极简 frontmatter 相比，Claude 的元数据承载了更多"权限与控制"语义。本地仓库中 skills/.curated/migrate-to-codex/references/differences.md 以官方迁移工具的口吻逐条记录了 Claude Code 技能的独有字段，这几乎是一份现成的对比白皮书：

也就是说，Claude 的 Skill 元数据天然"管得更多"：它能声明允许调用的工具、是否允许模型隐式调用、甚至钉死模型档位。这份差异表的存在本身也说明一个残酷现实：两家"官方"之间并不互通，任何跨体系迁移都要经历语义降级——allowed-tools从硬边界降格为一句"仅供参考"的提示语，user-invocable从开关降格为待人工复核的注释。

LangChain：把 Skills 做成框架内的对象与路由

LangChain 的 Skills 不诞生于"编辑器 + 仓库"形态，而是作为 Agent 框架的一个抽象层。社区解析文章（《LangChain Skills框架核心解析》）梳理出几个关键机制：动态工具加载、状态管理与约束系统、渐进式技能披露，并称其在 Token 效率、推理准确率、响应速度、内存占用上有可量化的优化效果。

这种差异的本质是宿主不同：OpenAI 与 Claude 的 Skills 面向"一个对话客户端 + 一个模型"，生命周期由会话上下文驱动；LangChain 的 Skills 面向"一段程序代码"，生命周期由执行图驱动——触发不靠模型读 description 自行判断，而靠框架的路由器在代码里做确定性分发。同样的"同一件事"，在三家里分别被建模为：模型的按需记忆、模型的授权清单、框架的执行节点。

三、从安装、触发到上下文化的真实体验差异

安装：三级目录 vs 插件市场 vs pip 包

OpenAI 的安装体验高度"声明式"：.system里的技能（imagegen、plugin-creator、skill-creator、skill-installer）随 Codex 预装；精选技能在 Codex 内通过$skill-installer按名安装，实验技能则按路径安装。底层逻辑藏在 skills/.system/skill-installer/SKILL.md 与配套脚本中：默认直连 GitHub 下载，失败自动回退 git sparse checkout，装入$CODEX_HOME/skills/<name>，且"目标目录已存在即中止"——安装是幂等、可预期的。

Claude 侧走插件/市场路线，migrate-to-codex差异表显示其存在.claude/plugins/、.claude/plugin-marketplaces.json等一整套市场元数据，Skill 只是插件包内的一个组成部分；LangChain 则遵循 Python 生态惯例，技能以包与注册表的形式出现在依赖图里。三者的共同点是都在"对抗碎片化"，但对抗方式不同：OpenAI 用目录分级，Claude 用市场封装，LangChain 用代码抽象。

触发：一段 description 的"权力"差异

在 OpenAI 体系里，触发是模型侧的语义判断。skill-creator规范反复强调：description 是"primary triggering mechanism"，所有"何时使用"信息必须写进 description 而非正文——因为正文在触发前根本不会被读。这也是为什么 skills/.curated/gh-address-comments/SKILL.md 的 description 会写得如此具体："处理当前分支对应 PR 上的 review/issue 评论，使用 gh CLI，先校验 gh 认证"。

Claude 体系在语义触发之上叠加了调用权限层（user-invocable、allowed-tools），决定"能触发但能不能调用工具"是两回事；LangChain 则把触发权交给代码路由，确定性最强，代价是灵活性与自然语言意图理解最弱。

上下文化：渐进式披露的三条路线

这是三家最微妙的分歧点。看两个仓库内的真实样本：

• skills/.curated/playwright/SKILL.md 把浏览器自动化做成 CLI-first：先查npx是否存在，再定义PWCLI包装脚本，把 open/snapshot/click/type 等原语命令列全，深挖细节全部下沉到references/cli.md与references/workflows.md，并明确"按需打开，只开你需要的"。
• skills/.curated/notion-spec-to-implementation/SKILL.md 则展示了一条与 MCP 协作的复杂链路：技能正文几乎是一份 SOP，而规格解析、任务模板、进度节奏全部外置到reference/目录，连"如果 Notion MCP 未连接怎么办"都写成了可执行的重置步骤。

两条路线对应 OpenAI 规范里的两种披露模式：CLI 型技能把"可执行代码"与"指导文档"分离，MCP 型技能把"指令骨架"与"按阶段读取的参考"分离。Claude 的 L1/L2/L3 分层在结构上与此高度相似，但多出allowed-tools这类运行时约束；LangChain 的"渐进式披露"则更接近惰性加载——技能内容按执行需要注入，由框架保证而非模型自觉。

四、同一件事的工程实证：处理 GitHub PR 评论

拿"处理 PR 评论"这个高频开发任务做横切对比。OpenAI 仓库中的 skills/.curated/gh-address-comments/SKILL.md 把流程拆成三步：先跑脚本拉取全部评论与 review 线程，再给用户编号摘要并询问处理范围，最后逐条修复。其中真正干活的是脚本：

skills/.curated/gh-address-comments/scripts/fetch_comments.py 是一份完整的 GraphQL 查询实现——一次查询同时拉取 conversation comments、review submissions、inline review threads 三类数据，并为每个分页游标独立做翻页，直到全部拉完。它把"模型每次都要重新发明"的 GitHub API 分页逻辑固化成了确定性的 Python 代码，SKILL.md 只负责流程编排与人工确认环节。

这个样本揭示了 OpenAI 技能哲学的关键：凡是反复重写且需要确定性的代码，都应该沉淀为脚本（规范原文：scripts 是"token efficient, deterministic, may be executed without loading into context"）。而 Claude 侧的同任务技能往往保留更多"由模型现写命令"的自由度（得益于allowed-tools声明的 Bash 权限），LangChain 侧则倾向于把评论获取封装成预注册的 Tool 供路由调用。同一件事，三家对"确定性与灵活性的配比"给出了不同答案。

五、按项目类型的选型矩阵

基于上述对比与仓库实证，给出如下选型建议：

需要提醒的两点：其一，Claude 的user-invocable与 OpenAI 的policy.allow_implicit_invocation"类似但不等价"，迁移时若依赖该开关必须人工复核；其二，主路由框架通常不可叠加（社区选型文《agent-skills 与 Superpowers、Pocock skills 怎么选》同样强调这一点），建议按需 cherry-pick 单个技能而非堆叠体系。

六、趋势：生态在收敛，官方在分叉

一个容易被忽略的事实是，本地这份 OpenAI 官方仓库的 README 首行已标注 deprecated：Codex 的 skill 与插件示例已迁移至 OpenAI Plugins 仓库，社区贡献入口也转向"skill-only plugin"。Skill 正在从独立目录形态被重新包装进插件清单——这是生态收敛的明确信号。

但收敛的是"技能打包成文件夹 + SKILL.md"这一共识，分叉的仍是宿主与元数据语义：OpenAI 用纯 description 驱动 + UI 元数据分离，Claude 用权限字段包裹技能，LangChain 用框架对象托管技能。对开发者而言，与其纠结"哪家标准最终胜出"，不如把三家的差异当作同一问题空间的三种约束答案：上下文稀缺时如何披露（OpenAI）、能力越权时如何约束（Claude）、执行复杂时如何编排（LangChain）。

Skill 的标准答案可能像 MCP 一样走向开放标准（agentskills.io 已在社区流传），但"同一件事，三家各说各话"的现状不会立刻消失——理解这背后的设计哲学差异，比记住某个具体字段更经得起版本迭代。

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills