横评 OpenAI / Claude / LangChain 三大官方 Skills同一件事三家各说各话【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年初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.mdWrite once, use everywhere——三家都认同这个目标但everywhere落在哪个层级分道扬镳就此开始。二、设计哲学与文件规范同一份 SKILL.md三家各说各话OpenAI / Codex上下文是公共品极简 frontmatterOpenAI 官方仓库把技能目录组织为三个层级skills/.systemCodex 内置预装、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 看的元数据显式分离的做法。ClaudeL1/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 Code 字段Codex 对应迁移行为allowed-tools无严格技能白名单仅转成提示语不构成权限边界user-invocablepolicy.allow_implicit_invocation语义类似但不等价model/effort无技能级模型钉死不支持argument-hint/context/hooks/paths/shell无直接对应需改写为提示语或配置也就是说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 供路由调用。同一件事三家对确定性与灵活性的配比给出了不同答案。五、按项目类型的选型矩阵基于上述对比与仓库实证给出如下选型建议项目/团队形态首选体系核心理由个人开发者在编辑器中用 AI 写代码、改 PR、做浏览器调试OpenAI / Codex三级目录即装即用CLI 型技能如 playwright、gh-address-comments开箱即用触发依赖模型语义判断上手成本最低需要严格工具权限治理、技能内声明工具白名单的企业Claudeallowed-tools、user-invocable等元数据天然是治理边界注意其与 OpenAI 体系不可直接迁移用 LangChain/LangGraph 构建程序化 Agent 应用客服、数据分析管线LangChain技能即代码对象路由与状态管理由框架保证适合必须确定性执行的生产链路团队既有 Claude Code 又计划迁移 CodexOpenAI经迁移工具本地仓库的 migrate-to-codex 附带完整差异表differences.md可预判哪些语义会降级为人工复核技能要被跨会话长期复用、且要控制上下文成本优先 OpenAI/Claude 的渐进式披露路线二者的 SKILL.md references 分层都能显著降低常驻上下文体积差异仅在权限层厚度需要提醒的两点其一Claude 的user-invocable与 OpenAI 的policy.allow_implicit_invocation类似但不等价迁移时若依赖该开关必须人工复核其二主路由框架通常不可叠加社区选型文《agent-skills 与 Superpowers、Pocock skills 怎么选》同样强调这一点建议按需 cherry-pick 单个技能而非堆叠体系。六、趋势生态在收敛官方在分叉一个容易被忽略的事实是本地这份 OpenAI 官方仓库的 README 首行已标注 deprecatedCodex 的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 横评 OpenAI / Claude / LangChain 三大官方 Skills：同一件事，三家各说各话
横评 OpenAI / Claude / LangChain 三大官方 Skills同一件事三家各说各话【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年初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.mdWrite once, use everywhere——三家都认同这个目标但everywhere落在哪个层级分道扬镳就此开始。二、设计哲学与文件规范同一份 SKILL.md三家各说各话OpenAI / Codex上下文是公共品极简 frontmatterOpenAI 官方仓库把技能目录组织为三个层级skills/.systemCodex 内置预装、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 看的元数据显式分离的做法。ClaudeL1/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 Code 字段Codex 对应迁移行为allowed-tools无严格技能白名单仅转成提示语不构成权限边界user-invocablepolicy.allow_implicit_invocation语义类似但不等价model/effort无技能级模型钉死不支持argument-hint/context/hooks/paths/shell无直接对应需改写为提示语或配置也就是说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 供路由调用。同一件事三家对确定性与灵活性的配比给出了不同答案。五、按项目类型的选型矩阵基于上述对比与仓库实证给出如下选型建议项目/团队形态首选体系核心理由个人开发者在编辑器中用 AI 写代码、改 PR、做浏览器调试OpenAI / Codex三级目录即装即用CLI 型技能如 playwright、gh-address-comments开箱即用触发依赖模型语义判断上手成本最低需要严格工具权限治理、技能内声明工具白名单的企业Claudeallowed-tools、user-invocable等元数据天然是治理边界注意其与 OpenAI 体系不可直接迁移用 LangChain/LangGraph 构建程序化 Agent 应用客服、数据分析管线LangChain技能即代码对象路由与状态管理由框架保证适合必须确定性执行的生产链路团队既有 Claude Code 又计划迁移 CodexOpenAI经迁移工具本地仓库的 migrate-to-codex 附带完整差异表differences.md可预判哪些语义会降级为人工复核技能要被跨会话长期复用、且要控制上下文成本优先 OpenAI/Claude 的渐进式披露路线二者的 SKILL.md references 分层都能显著降低常驻上下文体积差异仅在权限层厚度需要提醒的两点其一Claude 的user-invocable与 OpenAI 的policy.allow_implicit_invocation类似但不等价迁移时若依赖该开关必须人工复核其二主路由框架通常不可叠加社区选型文《agent-skills 与 Superpowers、Pocock skills 怎么选》同样强调这一点建议按需 cherry-pick 单个技能而非堆叠体系。六、趋势生态在收敛官方在分叉一个容易被忽略的事实是本地这份 OpenAI 官方仓库的 README 首行已标注 deprecatedCodex 的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考