橫評 OpenAI / Claude / LangChain 三大官方 Skills同一件事三家各說各話【免費下載鏈接】skillsSkills Catalog for Codex項目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年初Skills接棒 MCP成為智能體生態(tài)最熱的關鍵詞。掘金、CSDN 上相關教程動輒上萬閱讀GitHub Trending 上 Skills 類倉庫批量涌現(xiàn)騰訊 SkillHub、智源 SkillsBench 等配套生態(tài)也相繼落地。但熱度之下有一個被反復忽略的事實OpenAI、Anthropic、LangChain 三家都在做技能化封裝卻給出了三套不同的文件規(guī)范、觸發(fā)機制與加載策略。同樣是把一個可復用的工作流打包給 Agent為什么 OpenAI 把上下文即公共品寫進規(guī)范Claude 強調(diào)漸進式披露的三層架構而 LangChain 走向代碼級路由與狀態(tài)管理本文以本地 OpenAI 官方 skills 倉庫源碼為主線結合社區(qū)對 Claude Skills 與 LangChain Skills 的一線實踐情報逐層拆解三家體系的設計差異最后給出按項目類型的選型建議。一、先對齊問題Skills 到底在解決什么社區(qū)里流傳最廣的一句總結是MCP 負責數(shù)據(jù)從哪來Skills 負責拿到數(shù)據(jù)后怎么走模型在這條路徑上推理。三者各管一段才構成完整執(zhí)行鏈路。這句話點出了 Skills 的本質(zhì)它既不是工具協(xié)議也不是提示詞模板而是把指令 腳本 資源打包成可發(fā)現(xiàn)、可復用、按需加載的能力單元。倉庫 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落在哪個層級分道揚鑣就此開始。二、設計哲學與文件規(guī)范同一份 SKILL.md三家各說各話OpenAI / Codex上下文是公共品極簡 frontmatterOpenAI 官方倉庫把技能目錄組織為三個層級skills/.systemCodex 內(nèi)置預裝、skills/.curated精選可按名安裝、skills/.experimental實驗。而整套規(guī)范的憲法是系統(tǒng)內(nèi)置的 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兩個字段——規(guī)范明確寫道Do not include any other fields因為這兩個字段是 Codex 判斷何時觸發(fā)技能的唯一依據(jù)Body 僅在觸發(fā)后才加載且要求壓到 500 行以內(nèi)把變體細節(jié)拆進references/可選資源目錄三分scripts/可執(zhí)行代碼無需讀入上下文即可運行、references/按需讀入的文檔、assets/輸出用模板/圖標不進入上下文。規(guī)范中還給出三級加載模型元數(shù)據(jù)約 100 詞常駐上下文→ SKILL.md 正文5k 詞觸發(fā)后加載→ 捆綁資源按需無限加載。這被 OpenAI 官方命名為漸進式披露Progressive Disclosure并在 skills/.system/skill-creator/SKILL.md 中給出了三種拆分模式按引用拆、按領域拆、按條件細節(jié)拆。另一個值得注意的細節(jié)OpenAI 引入了產(chǎn)品化的 UI 元數(shù)據(jù)文件agents/openai.yaml包含display_name、short_description、icon_small、default_prompt等字段詳見 skills/.system/skill-creator/references/openai_yaml.md還支持聲明 MCP 依賴。這是三家體系里唯一把給模型看的規(guī)范與給人/UI 看的元數(shù)據(jù)顯式分離的做法。ClaudeL1/L2/L3 三層架構元數(shù)據(jù)更厚重社區(qū)對 Claude Skills 的拆解普遍采用三層架構以 CSDN 上閱讀量兩千余的 《智能體 Skills 技術原理分析和應用》 為代表L1 索引層YAML Frontmatter、L2 指令層SKILL.md 結構化指令、L3 資源層Scripts/References。與 OpenAI 的極簡 frontmatter 相比Claude 的元數(shù)據(jù)承載了更多權限與控制語義。本地倉庫中 skills/.curated/migrate-to-codex/references/differences.md 以官方遷移工具的口吻逐條記錄了 Claude Code 技能的獨有字段這幾乎是一份現(xiàn)成的對比白皮書Claude Code 字段Codex 對應遷移行為allowed-tools無嚴格技能白名單僅轉(zhuǎn)成提示語不構成權限邊界user-invocablepolicy.allow_implicit_invocation語義類似但不等價model/effort無技能級模型釘死不支持argument-hint/context/hooks/paths/shell無直接對應需改寫為提示語或配置也就是說Claude 的 Skill 元數(shù)據(jù)天然管得更多它能聲明允許調(diào)用的工具、是否允許模型隱式調(diào)用、甚至釘死模型檔位。這份差異表的存在本身也說明一個殘酷現(xiàn)實兩家官方之間并不互通任何跨體系遷移都要經(jīng)歷語義降級——allowed-tools從硬邊界降格為一句僅供參考的提示語user-invocable從開關降格為待人工復核的注釋。LangChain把 Skills 做成框架內(nèi)的對象與路由LangChain 的 Skills 不誕生于編輯器 倉庫形態(tài)而是作為 Agent 框架的一個抽象層。社區(qū)解析文章《LangChain Skills框架核心解析》梳理出幾個關鍵機制動態(tài)工具加載、狀態(tài)管理與約束系統(tǒng)、漸進式技能披露并稱其在 Token 效率、推理準確率、響應速度、內(nèi)存占用上有可量化的優(yōu)化效果。這種差異的本質(zhì)是宿主不同OpenAI 與 Claude 的 Skills 面向一個對話客戶端 一個模型生命周期由會話上下文驅(qū)動LangChain 的 Skills 面向一段程序代碼生命周期由執(zhí)行圖驅(qū)動——觸發(fā)不靠模型讀 description 自行判斷而靠框架的路由器在代碼里做確定性分發(fā)。同樣的同一件事在三家里分別被建模為模型的按需記憶、模型的授權清單、框架的執(zhí)行節(jié)點。三、從安裝、觸發(fā)到上下文化的真實體驗差異安裝三級目錄 vs 插件市場 vs pip 包OpenAI 的安裝體驗高度聲明式.system里的技能imagegen、plugin-creator、skill-creator、skill-installer隨 Codex 預裝精選技能在 Codex 內(nèi)通過$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等一整套市場元數(shù)據(jù)Skill 只是插件包內(nèi)的一個組成部分LangChain 則遵循 Python 生態(tài)慣例技能以包與注冊表的形式出現(xiàn)在依賴圖里。三者的共同點是都在對抗碎片化但對抗方式不同OpenAI 用目錄分級Claude 用市場封裝LangChain 用代碼抽象。觸發(fā)一段 description 的權力差異在 OpenAI 體系里觸發(fā)是模型側的語義判斷。skill-creator規(guī)范反復強調(diào)description 是primary triggering mechanism所有何時使用信息必須寫進 description 而非正文——因為正文在觸發(fā)前根本不會被讀。這也是為什么 skills/.curated/gh-address-comments/SKILL.md 的 description 會寫得如此具體處理當前分支對應 PR 上的 review/issue 評論使用 gh CLI先校驗 gh 認證。Claude 體系在語義觸發(fā)之上疊加了調(diào)用權限層user-invocable、allowed-tools決定能觸發(fā)但能不能調(diào)用工具是兩回事LangChain 則把觸發(fā)權交給代碼路由確定性最強代價是靈活性與自然語言意圖理解最弱。上下文化漸進式披露的三條路線這是三家最微妙的分歧點。看兩個倉庫內(nèi)的真實樣本skills/.curated/playwright/SKILL.md 把瀏覽器自動化做成 CLI-first先查npx是否存在再定義PWCLI包裝腳本把 open/snapshot/click/type 等原語命令列全深挖細節(jié)全部下沉到references/cli.md與references/workflows.md并明確按需打開只開你需要的。skills/.curated/notion-spec-to-implementation/SKILL.md 則展示了一條與 MCP 協(xié)作的復雜鏈路技能正文幾乎是一份 SOP而規(guī)格解析、任務模板、進度節(jié)奏全部外置到reference/目錄連如果 Notion MCP 未連接怎么辦都寫成了可執(zhí)行的重置步驟。兩條路線對應 OpenAI 規(guī)范里的兩種披露模式CLI 型技能把可執(zhí)行代碼與指導文檔分離MCP 型技能把指令骨架與按階段讀取的參考分離。Claude 的 L1/L2/L3 分層在結構上與此高度相似但多出allowed-tools這類運行時約束LangChain 的漸進式披露則更接近惰性加載——技能內(nèi)容按執(zhí)行需要注入由框架保證而非模型自覺。四、同一件事的工程實證處理 GitHub PR 評論拿處理 PR 評論這個高頻開發(fā)任務做橫切對比。OpenAI 倉庫中的 skills/.curated/gh-address-comments/SKILL.md 把流程拆成三步先跑腳本拉取全部評論與 review 線程再給用戶編號摘要并詢問處理范圍最后逐條修復。其中真正干活的是腳本skills/.curated/gh-address-comments/scripts/fetch_comments.py 是一份完整的 GraphQL 查詢實現(xiàn)——一次查詢同時拉取 conversation comments、review submissions、inline review threads 三類數(shù)據(jù)并為每個分頁游標獨立做翻頁直到全部拉完。它把模型每次都要重新發(fā)明的 GitHub API 分頁邏輯固化成了確定性的 Python 代碼SKILL.md 只負責流程編排與人工確認環(huán)節(jié)。這個樣本揭示了 OpenAI 技能哲學的關鍵凡是反復重寫且需要確定性的代碼都應該沉淀為腳本規(guī)范原文scripts 是token efficient, deterministic, may be executed without loading into context。而 Claude 側的同任務技能往往保留更多由模型現(xiàn)寫命令的自由度得益于allowed-tools聲明的 Bash 權限LangChain 側則傾向于把評論獲取封裝成預注冊的 Tool 供路由調(diào)用。同一件事三家對確定性與靈活性的配比給出了不同答案。五、按項目類型的選型矩陣基于上述對比與倉庫實證給出如下選型建議項目/團隊形態(tài)首選體系核心理由個人開發(fā)者在編輯器中用 AI 寫代碼、改 PR、做瀏覽器調(diào)試OpenAI / Codex三級目錄即裝即用CLI 型技能如 playwright、gh-address-comments開箱即用觸發(fā)依賴模型語義判斷上手成本最低需要嚴格工具權限治理、技能內(nèi)聲明工具白名單的企業(yè)Claudeallowed-tools、user-invocable等元數(shù)據(jù)天然是治理邊界注意其與 OpenAI 體系不可直接遷移用 LangChain/LangGraph 構建程序化 Agent 應用客服、數(shù)據(jù)分析管線LangChain技能即代碼對象路由與狀態(tài)管理由框架保證適合必須確定性執(zhí)行的生產(chǎn)鏈路團隊既有 Claude Code 又計劃遷移 CodexOpenAI經(jīng)遷移工具本地倉庫的 migrate-to-codex 附帶完整差異表differences.md可預判哪些語義會降級為人工復核技能要被跨會話長期復用、且要控制上下文成本優(yōu)先 OpenAI/Claude 的漸進式披露路線二者的 SKILL.md references 分層都能顯著降低常駐上下文體積差異僅在權限層厚度需要提醒的兩點其一Claude 的user-invocable與 OpenAI 的policy.allow_implicit_invocation類似但不等價遷移時若依賴該開關必須人工復核其二主路由框架通常不可疊加社區(qū)選型文《agent-skills 與 Superpowers、Pocock skills 怎么選》同樣強調(diào)這一點建議按需 cherry-pick 單個技能而非堆疊體系。六、趨勢生態(tài)在收斂官方在分叉一個容易被忽略的事實是本地這份 OpenAI 官方倉庫的 README 首行已標注 deprecatedCodex 的 skill 與插件示例已遷移至 OpenAI Plugins 倉庫社區(qū)貢獻入口也轉(zhuǎn)向skill-only plugin。Skill 正在從獨立目錄形態(tài)被重新包裝進插件清單——這是生態(tài)收斂的明確信號。但收斂的是技能打包成文件夾 SKILL.md這一共識分叉的仍是宿主與元數(shù)據(jù)語義OpenAI 用純 description 驅(qū)動 UI 元數(shù)據(jù)分離Claude 用權限字段包裹技能LangChain 用框架對象托管技能。對開發(fā)者而言與其糾結哪家標準最終勝出不如把三家的差異當作同一問題空間的三種約束答案上下文稀缺時如何披露OpenAI、能力越權時如何約束Claude、執(zhí)行復雜時如何編排LangChain。Skill 的標準答案可能像 MCP 一樣走向開放標準agentskills.io 已在社區(qū)流傳但同一件事三家各說各話的現(xiàn)狀不會立刻消失——理解這背后的設計哲學差異比記住某個具體字段更經(jīng)得起版本迭代?！久赓M下載鏈接】skillsSkills Catalog for Codex項目地址: https://gitcode.com/GitHub_Trending/skills4/skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 橫評 OpenAI / Claude / LangChain 三大官方 Skills：同一件事，三家各說各話
橫評 OpenAI / Claude / LangChain 三大官方 Skills同一件事三家各說各話【免費下載鏈接】skillsSkills Catalog for Codex項目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年初Skills接棒 MCP成為智能體生態(tài)最熱的關鍵詞。掘金、CSDN 上相關教程動輒上萬閱讀GitHub Trending 上 Skills 類倉庫批量涌現(xiàn)騰訊 SkillHub、智源 SkillsBench 等配套生態(tài)也相繼落地。但熱度之下有一個被反復忽略的事實OpenAI、Anthropic、LangChain 三家都在做技能化封裝卻給出了三套不同的文件規(guī)范、觸發(fā)機制與加載策略。同樣是把一個可復用的工作流打包給 Agent為什么 OpenAI 把上下文即公共品寫進規(guī)范Claude 強調(diào)漸進式披露的三層架構而 LangChain 走向代碼級路由與狀態(tài)管理本文以本地 OpenAI 官方 skills 倉庫源碼為主線結合社區(qū)對 Claude Skills 與 LangChain Skills 的一線實踐情報逐層拆解三家體系的設計差異最后給出按項目類型的選型建議。一、先對齊問題Skills 到底在解決什么社區(qū)里流傳最廣的一句總結是MCP 負責數(shù)據(jù)從哪來Skills 負責拿到數(shù)據(jù)后怎么走模型在這條路徑上推理。三者各管一段才構成完整執(zhí)行鏈路。這句話點出了 Skills 的本質(zhì)它既不是工具協(xié)議也不是提示詞模板而是把指令 腳本 資源打包成可發(fā)現(xiàn)、可復用、按需加載的能力單元。倉庫 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落在哪個層級分道揚鑣就此開始。二、設計哲學與文件規(guī)范同一份 SKILL.md三家各說各話OpenAI / Codex上下文是公共品極簡 frontmatterOpenAI 官方倉庫把技能目錄組織為三個層級skills/.systemCodex 內(nèi)置預裝、skills/.curated精選可按名安裝、skills/.experimental實驗。而整套規(guī)范的憲法是系統(tǒng)內(nèi)置的 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兩個字段——規(guī)范明確寫道Do not include any other fields因為這兩個字段是 Codex 判斷何時觸發(fā)技能的唯一依據(jù)Body 僅在觸發(fā)后才加載且要求壓到 500 行以內(nèi)把變體細節(jié)拆進references/可選資源目錄三分scripts/可執(zhí)行代碼無需讀入上下文即可運行、references/按需讀入的文檔、assets/輸出用模板/圖標不進入上下文。規(guī)范中還給出三級加載模型元數(shù)據(jù)約 100 詞常駐上下文→ SKILL.md 正文5k 詞觸發(fā)后加載→ 捆綁資源按需無限加載。這被 OpenAI 官方命名為漸進式披露Progressive Disclosure并在 skills/.system/skill-creator/SKILL.md 中給出了三種拆分模式按引用拆、按領域拆、按條件細節(jié)拆。另一個值得注意的細節(jié)OpenAI 引入了產(chǎn)品化的 UI 元數(shù)據(jù)文件agents/openai.yaml包含display_name、short_description、icon_small、default_prompt等字段詳見 skills/.system/skill-creator/references/openai_yaml.md還支持聲明 MCP 依賴。這是三家體系里唯一把給模型看的規(guī)范與給人/UI 看的元數(shù)據(jù)顯式分離的做法。ClaudeL1/L2/L3 三層架構元數(shù)據(jù)更厚重社區(qū)對 Claude Skills 的拆解普遍采用三層架構以 CSDN 上閱讀量兩千余的 《智能體 Skills 技術原理分析和應用》 為代表L1 索引層YAML Frontmatter、L2 指令層SKILL.md 結構化指令、L3 資源層Scripts/References。與 OpenAI 的極簡 frontmatter 相比Claude 的元數(shù)據(jù)承載了更多權限與控制語義。本地倉庫中 skills/.curated/migrate-to-codex/references/differences.md 以官方遷移工具的口吻逐條記錄了 Claude Code 技能的獨有字段這幾乎是一份現(xiàn)成的對比白皮書Claude Code 字段Codex 對應遷移行為allowed-tools無嚴格技能白名單僅轉(zhuǎn)成提示語不構成權限邊界user-invocablepolicy.allow_implicit_invocation語義類似但不等價model/effort無技能級模型釘死不支持argument-hint/context/hooks/paths/shell無直接對應需改寫為提示語或配置也就是說Claude 的 Skill 元數(shù)據(jù)天然管得更多它能聲明允許調(diào)用的工具、是否允許模型隱式調(diào)用、甚至釘死模型檔位。這份差異表的存在本身也說明一個殘酷現(xiàn)實兩家官方之間并不互通任何跨體系遷移都要經(jīng)歷語義降級——allowed-tools從硬邊界降格為一句僅供參考的提示語user-invocable從開關降格為待人工復核的注釋。LangChain把 Skills 做成框架內(nèi)的對象與路由LangChain 的 Skills 不誕生于編輯器 倉庫形態(tài)而是作為 Agent 框架的一個抽象層。社區(qū)解析文章《LangChain Skills框架核心解析》梳理出幾個關鍵機制動態(tài)工具加載、狀態(tài)管理與約束系統(tǒng)、漸進式技能披露并稱其在 Token 效率、推理準確率、響應速度、內(nèi)存占用上有可量化的優(yōu)化效果。這種差異的本質(zhì)是宿主不同OpenAI 與 Claude 的 Skills 面向一個對話客戶端 一個模型生命周期由會話上下文驅(qū)動LangChain 的 Skills 面向一段程序代碼生命周期由執(zhí)行圖驅(qū)動——觸發(fā)不靠模型讀 description 自行判斷而靠框架的路由器在代碼里做確定性分發(fā)。同樣的同一件事在三家里分別被建模為模型的按需記憶、模型的授權清單、框架的執(zhí)行節(jié)點。三、從安裝、觸發(fā)到上下文化的真實體驗差異安裝三級目錄 vs 插件市場 vs pip 包OpenAI 的安裝體驗高度聲明式.system里的技能imagegen、plugin-creator、skill-creator、skill-installer隨 Codex 預裝精選技能在 Codex 內(nèi)通過$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等一整套市場元數(shù)據(jù)Skill 只是插件包內(nèi)的一個組成部分LangChain 則遵循 Python 生態(tài)慣例技能以包與注冊表的形式出現(xiàn)在依賴圖里。三者的共同點是都在對抗碎片化但對抗方式不同OpenAI 用目錄分級Claude 用市場封裝LangChain 用代碼抽象。觸發(fā)一段 description 的權力差異在 OpenAI 體系里觸發(fā)是模型側的語義判斷。skill-creator規(guī)范反復強調(diào)description 是primary triggering mechanism所有何時使用信息必須寫進 description 而非正文——因為正文在觸發(fā)前根本不會被讀。這也是為什么 skills/.curated/gh-address-comments/SKILL.md 的 description 會寫得如此具體處理當前分支對應 PR 上的 review/issue 評論使用 gh CLI先校驗 gh 認證。Claude 體系在語義觸發(fā)之上疊加了調(diào)用權限層user-invocable、allowed-tools決定能觸發(fā)但能不能調(diào)用工具是兩回事LangChain 則把觸發(fā)權交給代碼路由確定性最強代價是靈活性與自然語言意圖理解最弱。上下文化漸進式披露的三條路線這是三家最微妙的分歧點。看兩個倉庫內(nèi)的真實樣本skills/.curated/playwright/SKILL.md 把瀏覽器自動化做成 CLI-first先查npx是否存在再定義PWCLI包裝腳本把 open/snapshot/click/type 等原語命令列全深挖細節(jié)全部下沉到references/cli.md與references/workflows.md并明確按需打開只開你需要的。skills/.curated/notion-spec-to-implementation/SKILL.md 則展示了一條與 MCP 協(xié)作的復雜鏈路技能正文幾乎是一份 SOP而規(guī)格解析、任務模板、進度節(jié)奏全部外置到reference/目錄連如果 Notion MCP 未連接怎么辦都寫成了可執(zhí)行的重置步驟。兩條路線對應 OpenAI 規(guī)范里的兩種披露模式CLI 型技能把可執(zhí)行代碼與指導文檔分離MCP 型技能把指令骨架與按階段讀取的參考分離。Claude 的 L1/L2/L3 分層在結構上與此高度相似但多出allowed-tools這類運行時約束LangChain 的漸進式披露則更接近惰性加載——技能內(nèi)容按執(zhí)行需要注入由框架保證而非模型自覺。四、同一件事的工程實證處理 GitHub PR 評論拿處理 PR 評論這個高頻開發(fā)任務做橫切對比。OpenAI 倉庫中的 skills/.curated/gh-address-comments/SKILL.md 把流程拆成三步先跑腳本拉取全部評論與 review 線程再給用戶編號摘要并詢問處理范圍最后逐條修復。其中真正干活的是腳本skills/.curated/gh-address-comments/scripts/fetch_comments.py 是一份完整的 GraphQL 查詢實現(xiàn)——一次查詢同時拉取 conversation comments、review submissions、inline review threads 三類數(shù)據(jù)并為每個分頁游標獨立做翻頁直到全部拉完。它把模型每次都要重新發(fā)明的 GitHub API 分頁邏輯固化成了確定性的 Python 代碼SKILL.md 只負責流程編排與人工確認環(huán)節(jié)。這個樣本揭示了 OpenAI 技能哲學的關鍵凡是反復重寫且需要確定性的代碼都應該沉淀為腳本規(guī)范原文scripts 是token efficient, deterministic, may be executed without loading into context。而 Claude 側的同任務技能往往保留更多由模型現(xiàn)寫命令的自由度得益于allowed-tools聲明的 Bash 權限LangChain 側則傾向于把評論獲取封裝成預注冊的 Tool 供路由調(diào)用。同一件事三家對確定性與靈活性的配比給出了不同答案。五、按項目類型的選型矩陣基于上述對比與倉庫實證給出如下選型建議項目/團隊形態(tài)首選體系核心理由個人開發(fā)者在編輯器中用 AI 寫代碼、改 PR、做瀏覽器調(diào)試OpenAI / Codex三級目錄即裝即用CLI 型技能如 playwright、gh-address-comments開箱即用觸發(fā)依賴模型語義判斷上手成本最低需要嚴格工具權限治理、技能內(nèi)聲明工具白名單的企業(yè)Claudeallowed-tools、user-invocable等元數(shù)據(jù)天然是治理邊界注意其與 OpenAI 體系不可直接遷移用 LangChain/LangGraph 構建程序化 Agent 應用客服、數(shù)據(jù)分析管線LangChain技能即代碼對象路由與狀態(tài)管理由框架保證適合必須確定性執(zhí)行的生產(chǎn)鏈路團隊既有 Claude Code 又計劃遷移 CodexOpenAI經(jīng)遷移工具本地倉庫的 migrate-to-codex 附帶完整差異表differences.md可預判哪些語義會降級為人工復核技能要被跨會話長期復用、且要控制上下文成本優(yōu)先 OpenAI/Claude 的漸進式披露路線二者的 SKILL.md references 分層都能顯著降低常駐上下文體積差異僅在權限層厚度需要提醒的兩點其一Claude 的user-invocable與 OpenAI 的policy.allow_implicit_invocation類似但不等價遷移時若依賴該開關必須人工復核其二主路由框架通常不可疊加社區(qū)選型文《agent-skills 與 Superpowers、Pocock skills 怎么選》同樣強調(diào)這一點建議按需 cherry-pick 單個技能而非堆疊體系。六、趨勢生態(tài)在收斂官方在分叉一個容易被忽略的事實是本地這份 OpenAI 官方倉庫的 README 首行已標注 deprecatedCodex 的 skill 與插件示例已遷移至 OpenAI Plugins 倉庫社區(qū)貢獻入口也轉(zhuǎn)向skill-only plugin。Skill 正在從獨立目錄形態(tài)被重新包裝進插件清單——這是生態(tài)收斂的明確信號。但收斂的是技能打包成文件夾 SKILL.md這一共識分叉的仍是宿主與元數(shù)據(jù)語義OpenAI 用純 description 驅(qū)動 UI 元數(shù)據(jù)分離Claude 用權限字段包裹技能LangChain 用框架對象托管技能。對開發(fā)者而言與其糾結哪家標準最終勝出不如把三家的差異當作同一問題空間的三種約束答案上下文稀缺時如何披露OpenAI、能力越權時如何約束Claude、執(zhí)行復雜時如何編排LangChain。Skill 的標準答案可能像 MCP 一樣走向開放標準agentskills.io 已在社區(qū)流傳但同一件事三家各說各話的現(xiàn)狀不會立刻消失——理解這背后的設計哲學差異比記住某個具體字段更經(jīng)得起版本迭代?！久赓M下載鏈接】skillsSkills Catalog for Codex項目地址: https://gitcode.com/GitHub_Trending/skills4/skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考