Anthropic 沒有開發布會。只在一篇十月的舊文章上，補了一行更新。九個月後，46 個 AI 工具讀同一種資料夾。
一句話結論：Agent Skills 是「一個資料夾裝一個 SKILL.md」的格式，2025 年 10 月 16 日由 Anthropic 推出、12 月 18 日開放成標準，目前 46 個工具支援。我把 OpenAI 與 Anthropic 官方倉庫共 64 個 SKILL.md 逐個拆開比對，必填欄位完全相同，所以寫一次確實搬得動。
本文所有數字都是我在 2026 年 9 月 9 日當天，用 GitHub API 和官方文件重新讀出來的，不引用二手轉述。星數這類會浮動的數字，我一律標讀取日期。
為什麼「Agent Skills 什麼時候發布」有三個答案？
因為它真的發生過三次，而且三次都是真的。中文圈的轉述常把三個日期混成一個，這是這個題目最容易寫錯的一格。
我原本手上的素材寫著「規格 2025 年 12 月 18 日由 Anthropic 發布」。但同一份素材又寫 openai/skills 倉庫建立於 2025 年 11 月 25 日。一個倉庫不可能比它遵循的規格早三個星期出生。兩個數字打架，就代表至少有一個要丟掉。
回官方原始頁面才拆得開。Anthropic 工程部落格那篇的日期戳是 Published Oct 16, 2025，文章開頭另有一行斜體更新：已把 Agent Skills 發布為開放標準，日期寫 December 18, 2025。兩件事，兩個日期，都印在同一頁上。
| 日期 | 發生什麼 | 我怎麼查到 |
|---|---|---|
| 2025-09-22 | anthropics/skills 倉庫建立 | GitHub API created_at |
| 2025-10-16 | Agent Skills 正式推出 | Anthropic 工程部落格日期戳 |
| 2025-11-25 | openai/skills 倉庫建立 | GitHub API created_at |
| 2025-12-16 | agentskills/agentskills 規格倉庫建立 | GitHub API created_at |
| 2025-12-18 | 發布為開放標準（agentskills.io） | 同一篇部落格的更新註記 |
| 2026-03-04 | openai/plugins 倉庫建立 | GitHub API created_at |
規格倉庫建立於 12 月 16 日，公告在 12 月 18 日。差兩天，方向合理，兩個獨立管道互相對得上。這比只信任何一邊都穩。
順帶把另一個常見錯誤釘死：不要寫「OpenAI 最近才開源 skills」。那個倉庫 2025 年 11 月 25 日就建好了，它只是最近很活躍。這兩件事在中文圈常常被講成同一件。
OpenAI 真的用同一套格式，還是只是撞名？
真的同一套。而且我沒有看 README 說明，README 想寫什麼都可以。我直接抓兩邊的檔案樹來數。
| 官方倉庫 | 檔案總數 | 叫 SKILL.md 的檔案 |
|---|---|---|
anthropics/skills | 419 | 20 |
openai/skills | 783 | 44 |
| 合計 | 1,202 | 64 |
檔名一樣只能算巧合，欄位一樣才算同一個格式。所以我再各抓兩個實際檔案，把最上面那段 YAML 拆出來比：
| 來源檔案 | YAML 欄位 |
|---|---|
anthropics/skills／canvas-design | name、description、license |
anthropics/skills／template | name、description |
openai/skills／cli-creator | name、description |
openai/skills／chatgpt-apps | name、description |
共用欄位是 name 和 description，只有 Anthropic 那個範例多一個 license。這個差異不是分歧，往下看規格就知道原因。
規格到底規定了什麼？
只規定兩個必填欄位，其餘全部選填。這是我在 agentskills.io 規格頁讀到的完整表格：
| 欄位 | 必填 | 限制 |
|---|---|---|
name | 是 | 最長 64 字元，只能用小寫英文、數字、連字號，頭尾不能是連字號 |
description | 是 | 最長 1024 字元，不可空白 |
license | 否 | 授權名稱或指向檔案 |
compatibility | 否 | 最長 500 字元，標環境需求 |
metadata | 否 | 字串對字串的自由鍵值 |
對回上一節：兩家都寫齊了必填的 name 和 description，Anthropic 多寫的 license 剛好在選填清單裡。實測結果和公開規格完全吻合，這條證據鏈才算閉合。
格式簡單到只有兩個必填欄位，正是它擴散得快的原因。要支援它，你不用改模型，只要肯讀一個資料夾。
你的 SKILL.md 合不合規？貼上來自己跑
下面這個檢查器直接照上面那張規格表寫成，完全在你自己的瀏覽器裡跑，不上傳任何內容。把你 SKILL.md 最上面那段 YAML（含兩行 ---）貼進去就會逐條告訴你哪裡不合規。
它只驗規格層面的欄位。內容寫得好不好、會不會被代理挑中，那是另一回事，我在裝了 215 個 skill 之後那篇寫過踩雷的部分。
到底有多少工具真的支援？
官方客戶名單上是 46 個。我把那份名單抓下來程式化數過，46 個名字沒有重複；其中 45 個附了自家說明文件連結，26 個有公開原始碼。
名單裡認得出的大廠陣容大致是這樣：
- 模型廠：Anthropic（Claude、Claude Code）、OpenAI（ChatGPT 與 Codex）、Google（Gemini CLI、AI Edge Gallery）、Mistral（Vibe）
- 編輯器與程式碼平台：VS Code、GitHub Copilot、Cursor、JetBrains Junie、Kiro、TRAE、Roo Code、Tabnine
- 資料與雲端：Databricks Genie Code、Snowflake Cortex Code、Pulumi Neo
- 開源代理：OpenHands、OpenCode、Goose、Letta、fast-agent、nanobot
這裡要老實講一件事：那份 46 家名單是標準官網自己公布的，屬於自我申報。我不會直接當成獨立事實。所以我隨機抽了 5 家，去它們自己的網域讀說明文件核對：GitHub Copilot、VS Code、Gemini CLI 三家在自家官方文件裡確認寫了 Agent Skills，其中兩家的頁面直接出現 SKILL.md。剩下 Cursor 和 OpenAI Codex 兩個文件站擋掉了我的抓取（回 308），抓不到不等於沒有，我只把它們記成未核實。
不過 OpenAI 這家用不著靠文件站證明。它官方倉庫裡躺著 44 個 SKILL.md，那比任何一頁說明文件都硬。
規模再往外看一層，GitHub 上掛 agent-skills 標籤的倉庫有 22,015 個，掛 claude-skills 的有 8,060 個（2026 年 9 月 9 日以搜尋 API 讀取）。規格倉庫本身是 Apache-2.0 授權，41 位貢獻者，75 個開放中的 issue，所以它不是一家公司關起門來改。
我只用 ChatGPT，這件事關我什麼事？
關係在於你花時間累積的東西，之後還在不在。
過去兩年，你把工作流程調教進某個聊天視窗裡：報價單怎麼排、客戶信怎麼寫、月報表哪幾欄要對。換一家工具，全部重來。這是很多人不敢換工具的真正原因，不是不好用，是搬不動。
把同一套流程寫成一個資料夾之後，情況反過來。它是純文字，可以進 Git、可以版本控制、可以寄給同事。你不是在餵某一家廠商的黑盒，是在累積自己帶得走的資產。46 個工具讀同一種格式，代表下次誰漲價、誰限流，你的搬遷成本接近零。
再往前一步就是變現。一個把公司報價流程寫清楚的資料夾，本身就是可以交付的東西。接案的把它當交付物，公司內部的把它變成新人上手包。我自己那套查核開源專案的清單就是這樣長出來的，先寫成流程，再變成能重複跑的資產。已經有人靠單一 skill 打進 77 個代理，這條路不是理論。
搬家前要檢查哪三件事？
格式相容不代表搬過去就會動。這三件是我實際會踩到的：
- 先驗必填欄位：把 frontmatter 貼進上面的檢查器，確認
name合法、description有寫「什麼時候該用」。名稱用了大寫或底線是最常見的死法。 - 再看有沒有綁死路徑和工具：skill 裡如果寫死
~/.claude/這種路徑，或呼叫只有某一家有的內建工具，換家就會斷。把路徑改成相對路徑，把工具依賴寫進選填的compatibility欄位。 - 最後確認執行環境：規格只管那份文字檔，不保證對方讓你跑腳本。附了 Python 腳本的 skill，搬到不給執行程式碼的工具就只剩說明書。搬之前先查對方文件支不支援執行。
不想學這套，有替代方案嗎？
有，而且不衝突：
| 做法 | 適合誰 | 代價 |
|---|---|---|
| Agent Skills | 流程會重複跑、要跨工具或跨同事共用 | 要學一點資料夾與 YAML |
| MCP | 要接外部系統、資料庫、即時 API | 要架伺服器，門檻高一截 |
| AGENTS.md | 只想給單一專案定規矩 | 不跟著你走，換專案要重寫 |
| 照舊貼提示詞 | 一次性任務 | 零累積，每次重來 |
官方文件自己也寫，Skills 和 MCP 是互補的：一個教流程，一個接外部工具。真的在用的人多半兩個都用。
新手行動清單
- 挑一件你這個月做過三次以上的事，先寫下步驟
- 開一個資料夾，裡面放一個
SKILL.md，只寫name和description兩行 - 把步驟貼在
---下面，先不要加腳本 - 用上面的檢查器驗一次欄位
- 在你現在用的工具裡跑一次，不順就改
description，那句決定它會不會被叫出來 - 順了之後丟進 Git，這份就搬得去另外 45 個工具
常見問題
Agent Skills 是 Anthropic 專有的嗎？
格式由 Anthropic 開發，2025 年 12 月 18 日發布為開放標準，規格倉庫用 Apache-2.0 授權、有 41 位貢獻者。目前 46 個工具支援，包含 OpenAI、Google、Microsoft 的產品。
寫一個 skill 至少要填什麼？
只有兩個必填欄位：name（最長 64 字元，小寫英文、數字、連字號）和 description（最長 1024 字元）。其餘 license、compatibility、metadata 都是選填。
Claude 寫的 skill 可以直接搬去 Codex 嗎？
欄位層面可以，兩家官方倉庫的 SKILL.md 必填欄位相同。但如果 skill 寫死了某家的路徑，或依賴對方沒有的執行環境與內建工具，仍然要手動調整。
Agent Skills 和 MCP 差在哪？
Skills 是教代理「這件事的步驟怎麼做」的文字資料夾，MCP 是讓代理連到外部系統與即時資料的協定。前者門檻低很多，兩者可以同時用。
我的判斷
一個只有兩個必填欄位的格式，九個月內讓互相競爭的幾家廠商讀同一個資料夾。它贏不是因為設計得多聰明，是因為簡單到大家懶得吵。
對散戶最實際的一句：從今天起，你調教工作流程花的時間，第一次真的存得下來。剩下要判斷的，是熱榜上那一大堆 skill 倉庫裡面，哪些值得你裝。那是另一個問題，而且答案多半是「不值得」。
延伸閱讀：Agent Skills 生態盤點：自述數字差 50%、換模型的隱藏成本：prompt cache 為什麼讓你多付錢。
資料與時效：本文數字於 2026 年 9 月 9 日以 GitHub API、agentskills.io 規格頁與各廠官方文件實地讀取。倉庫星數、標籤數量會隨時間變動，規格內容以官方頁面為準。46 家客戶名單為標準官網自我申報，本文抽查 5 家、3 家於自家網域確認，2 家因抓取受阻未核實。利益揭露：本文不含任何贊助或聯盟連結，提及的工具皆無商業合作。
發表迴響