大家都在 SKILL.md:當 AI agent 的能力收斂成同一份說明書

一份檔案,值得單獨拿出來看

上一篇的結尾,我們停在一個沒展開的東西上:你把一個流程做一次給 Codex 看,它把這趟操作整理成一份可重用、可修改的「技能」。那一篇在意的是門檻的移動 — 從「會不會寫指令」滑到「會不會做這件事」;至於它整理出來的那份東西長什麼樣,只一句帶過。

這一篇想把那份東西拿出來,單獨看。

因為它不是隨手存的一個檔。它有名字,叫 SKILL.md;它有格式;而且 — 這才是真正耐想的地方 — 用這套寫法的,不只 Codex 一家。最近你會發現,好幾家做 agent 的產品,正往同一套開放格式靠攏,把「一個技能」寫成了同一種樣子。

這種事很容易被當成技術細節滑過去。但當不同陣營的產品,開始把同一個概念寫成同一份檔案,那通常不只是巧合,而是某種正在成形的共識。值得停下來,看清楚它在收斂的到底是什麼。

SKILL.md:寫給 agent 看的說明書

先把這份檔案講白。

SKILL.md 說穿了,就是一份「做某件事的說明書」,只是讀者不是人,是 AI agent。它用最樸素的純文字寫成,核心內容也很樸素:這個技能什麼時候該用、需要你給哪些輸入、分成哪些步驟、最後怎麼確認有沒有做對。 開頭通常還有一小段結構化的標頭,至少標明這個技能的名字和一句描述 — 讓 agent 一眼知道「這是做什麼用的」。

如果你覺得這聽起來和上一篇 Codex 整理出來的東西一模一樣,那就對了。Codex 的 Record & Replay 在「示範完之後」吐出來的,正是這樣一份檔案。它不是某家獨有的產物,而是一種共通的格式 — 你可以自己手寫,也可以讓 agent 看著你的操作幫你草擬,最後得到的都是同一種東西。

它刻意樸素,是有道理的。說明書要能被讀、被改、被交接,就不能寫成只有寫的人看得懂的黑盒。一份好的 SKILL.md,理想上你打開來就讀得懂它在做什麼,覺得哪步不對也能直接改 — 它更像一份組裝家具的圖解,而不是一段需要編譯才知道在幹嘛的程式。

為什麼「分層揭露」是關鍵

光是「把技能寫成檔案」還不夠有意思。真正讓這套設計站得住的,是一個叫 progressive disclosure(分層揭露) 的安排。

想像一個 agent 手上有幾十、甚至上百個技能。如果每次工作都得先把每一份 SKILL.md 的完整內容讀進「腦袋」,那它的注意力很快就被塞爆了 — 大半還是這次根本用不到的。

分層揭露換了個做法:平常,agent 只先載入每個技能的名字和一句簡述,薄薄一層,知道「有這些技能、各自大概做什麼」就好。等到某個任務真的需要某個技能,它才把那一份完整的 SKILL.md 讀進來,看細節。

這個設計之所以關鍵,是因為它正視了一個很現實的限制:agent 一次能放進注意力裡的東西是有限的。分層揭露讓「技能很多」和「注意力有限」這兩件事不再打架 — 你可以給它一整櫃的技能,而它每次只抽出當下要用的那一本。能力的「庫存」因此可以長大,而不會反過來拖垮它。

收斂這件事,不是各做各的

把鏡頭拉遠一點,真正的故事在這裡。

SKILL.md 這個格式,以及它背後那套叫 Agent Skills 的規範,並不是 Codex 發明的。據查證,這套寫法最早由 Anthropic 提出,並以開放標準的形式對外釋出 — 對應到一個公開的規格站點 agentskills.io。它的設計初衷,本來就帶著「跨產品通用」的意圖:技能不該被鎖死在某一家的工具裡。

Anthropic 的 Claude 與 Claude Code 較早就用上了這套 SKILL.md 寫法;這次 Codex 的做法,本質上是採用同一套開放標準,而不是另起爐灶搞一份自己的格式。換句話說,當你看到 Codex 把示範整理成一份 SKILL.md,你看到的不是「OpenAI 也做了一個類似的東西」,而是「OpenAI 也採用了同一套寫法」。

這種收斂,放在這個產業裡其實不太尋常。做 agent 的各家,平時在模型、在介面、在定位上各走各的;但在「一個技能該長什麼樣」這件最基礎的事上,卻開始往同一個點靠攏。當一個格式由一家提出、又被別家採用,它就從「某產品的功能」,慢慢變成了「這個領域共用的詞彙」。

值得提醒的是,這裡講的是就目前可查證的範圍:有一個公開的開放標準存在,且不只一家在用。至於每一家採用得多徹底、細節對齊到什麼程度,那是另一個更細的問題,不在這篇想斷言的範圍裡。

對使用者來說,收斂意味著什麼

退一步,從用的人這邊看,「大家都用同一套寫法」帶來的,是一個過去不太敢想的可能:能力,有機會變得可攜 — 前提是目標 agent 支援相同格式,而且它落地的環境具備技能所需的工具與權限。

在各家格式互不相通的世界裡,你為某個工具養出來的一套操作知識,就只屬於那個工具。換了一家,等於從頭再來 — 你累積的那些「怎麼把這件事做對」的心得,沒辦法跟著你走。能力是綁定的,綁在產品上。

而當技能被寫成一種共通的、可讀可改的檔案,情況就鬆動了。一份你(或某個 agent 幫你)整理好的 SKILL.md,理論上不再只屬於某個產品。它是一份你能讀、能存、能改、能交給別人的東西。你在某處沉澱下來的做事方法,價值不必再鎖死在當初那個產品的圍牆裡。

這對個人和團隊都有意義。一份月結流程、一套報表整理的步驟,一旦落成 SKILL.md,它就更像一份資產,而不是某個工具的內建設定。資產的特性是:你擁有它、它能被盤點、能被傳遞、原則上也不那麼怕你哪天想換個地方用。上一篇講「隱性知識被沉澱成可交接的東西」,共通格式把這件事又往前推了一格 — 沉澱下來的東西,連能去的地方都變多了。

但別把「同格式」讀成「完全互通」

講到這裡,得踩一下煞車。因為最容易出錯的誤讀,往往就藏在最順的推論裡。

「大家都用 SKILL.md」很容易被讀成「那一份 Claude 的技能,應該能原封不動丟進 Codex 跑」。這一步要很小心。 共用同一種格式,讓技能在「讀得懂」這一層相通了 — 不同 agent 都認得這份檔案的結構,看得懂裡面在說什麼。但技能真正跑起來,靠的不只是讀得懂。

一份技能執行時,還要看它落地的環境:這個 agent 當下能用哪些工具?有沒有對應的權限?跑在什麼系統上?上一篇就提過 Codex 那套有它自己的硬限制 — 限某類系統、要開特定權限、要訂閱方案。同一份 SKILL.md,搬到一個工具不一樣、權限不一樣的環境裡,很可能就不是照著跑就會成。格式互通,和執行互通,是兩件不同的事。 把前者直接當成後者,往往會高估了「可攜」實際能走多遠。

更值得冷靜想的,是再往上一層的問題。當一個詞 — 「技能」、「SKILL.md」、「開放標準」 — 被大家同時掛在嘴上,真正的角力,常常不在「要不要用這個詞」,而在「誰來定義這個詞」。一個由某家提出、再被各家採用的標準,要保持名實相符,得靠後續持續對齊;否則,有可能慢慢走到一種看似開放、實則各自表述的局面:檔案都叫 SKILL.md,標準名稱也都掛著「開放」,但實際能跑、跑得對的範圍,各家悄悄不同。

這不是要往陰謀論去想。多半時候,差異來自各家工具與環境本來就不一樣,是務實的結果,而非誰有意設下的牆。但正因為它來得自然、不張揚,使用者反而更需要留意:「長得一樣」這件事,本身不保證「用起來一樣」。 看到同一個名字,先別急著假設背後是同一件事。

互通,還是只是長得像

所以回到最初那份檔案。

SKILL.md 收斂成一種跨家通用的寫法,這件事是真的,而且方向上多半是好的 — 一個讓能力可讀、可改、可攜的共同格式,比各家把技能鎖在自己院子裡,對使用者顯然更友善。把能力從「綁在產品上」往「屬於使用者」挪,光是這個方向,就值得重視。只是「開放標準」這四個字,仍應按目前公開的規格與各家實作的相容程度來理解 — 格式同源,不等於每一家的實作都已對齊到完全一致。

但「同一份格式」承諾的互通,究竟兌現到哪一步,目前還是個開放的問題。它可能真的長成一套人人能帶著走的能力標準;也可能停在「大家都用同一個詞,但各自跑各自的」這種看似互通的狀態。這兩者從外面看,有時長得幾乎一樣 — 而分辨它們,往往要等到你真的試著把一份技能,從一個地方搬到另一個地方,才會知道。

留給你想的,大概就是這個分辨:下次再看到某樣東西號稱「開放、通用、可攜」,值得多問一句 — 它是真的能互通,還是只是,長得很像。

至於「做一次它就會」這個夢,其實一點都不新 — 自動化的舊夢做了幾十年,這一輪到底新在哪、又有哪些地方只是換了層皮,下一篇想冷靜地接著盤一盤。