Agent生態碎片化終結，.agents/skills統一所有工具
整理版優先睇
Agent工具各自為政嘅碎片化問題有望終結，.agents/skills統一標準正被推行
呢篇文係由AI編程知識分享者賈傑撰寫，佢長期觀察AI工具生態，發現目前Agent工具（如Codex、Cursor等）各自要求技能檔案放喺專屬目錄（.codex/skills、.cursor/skills），令開發者要重複複製、遷移，造成巨大麻煩。作者想解決嘅係呢種碎片化導致嘅vendor lock-in問題，核心結論係：推廣一個統一嘅標準目錄.agents/skills，畀所有Agent工具共用技能檔案，先可以打破壁壘，建立健康生態。
作者指出，問題本質係工具開發者嘅「地盤意識」，但受害者係用戶。佢引用前端模塊化從混戰到ES Module統一嘅歷史，說明標準嘅價值。技術實現好簡單：工具改讀取路徑，用戶移動文件就得。真正挑戰係要夠多人支持，形成網絡效應，好似TypeScript咁靠主流採用成為事實標準。
文章最後呼籲開發者、用戶同教程作者一齊推動，每個人都可以參與：工具開發者支援.agents/skills，用戶去提issue，教程作者推薦用呢個路徑。總結一句：好嘅標準唔係設計出嚟，係用出嚟。
- 目前Codex、Cursor等Agent工具各自用專屬目錄放技能文件，開發者要重複複製同遷移，效率極低。
- 解決方案簡單到令人發笑：所有工具統一由.agents/skills讀取技能文件，終結碎片化。
- 技術實現成本極低：工具只需改讀取路徑，用戶移動文件就得，兼容舊目錄可保留。
- 真正挑戰係共識：需要足夠多工具同用戶支持，形成網絡效應先可以成為標準。
- 每個人都可以推動：工具開發者加入支援、用戶提issue、教程作者推薦使用，匯聚力量改變生態。
Alexander原推文
提出.agents/skills標準嘅原始推文，呼籲社羣支持
Codex已支援
Codex已經率先支援.agents/skills，用戶而家就可以將技能文件搬過去
而家嘅蠢現狀：目錄碎片化
你用Codex，佢要求技能文件放喺.codex/skills。用Cursor，就係.cursor/skills。用其他Agent工具，又係另一個目錄。結果項目根目錄一堆.xxx/skills文件夾，每次寫新技能要複製粘貼三四份，改個bug要改三四個地方。
呢個唔係寫代碼，係做復讀機
更慘嘅係，你想換個Agent工具試試？對唔住，先將所有技能文件遷移一遍。
問題本質：地盤意識 vs 用戶便利
本質上係每個Agent工具都想搞自己嘅專屬目錄，好似動物撒尿劃地盤。.codex/skills係我地盤，.cursor/skills係你地盤，誰都唔好侵犯。聽落合理，但開發者就係犧牲品。
簡單到令人發笑嘅方案：.agents/skills
Alexander 提出嘅方案簡單直接：大家都從.agents/skills讀技能文件。唔係.codex/skills，唔係.cursor/skills，就係.agents/skills。所有Agent工具都從呢個地方讀。
Codex 已經支援咗，而家正呼籲其他工具跟進。呢個就好似當年前端模塊化混戰：AMD、CMD、UMD打唔停，最後ES Module出嚟，大家終於消停。標準嘅價值就係令大家唔使再瞎折騰。
點解件事咁重要？
你可能覺得只係改個目錄名，冇必要大張旗鼓。但佢關係到整個生態會唔會變成一盤散沙。如果每個工具都搞自己標準，開發者就被綁死：用Codex就要用佢目錄結構，想換工具？先遷移曬配置。
網絡效應係關鍵：越多人用，就越有價值；越有價值，就越多人用。呢個係正反饋循環。
我哋可以做啲咩？
如果你係Agent工具開發者，請支援.agents/skills。如果你係用戶，去提issue要求支援。如果你寫教程，推薦用.agents/skills。
- 工具開發者：改讀取路徑，優先讀標準目錄，兼容舊目錄
- 用戶：去GitHub提feature request，俾壓力
- 教程作者：喺教學入面用.agents/skills路徑
每個人都係一小步，加埋就係生態一大步。記住：好嘅標準唔係設計出嚟，係用出嚟。
一個好蠢嘅現狀
我哋先睇下而家係咩情況。
你用Codex，佢要求你將技能文件放喺.codex/skills。
你用Cursor，佢可能要求你放喺.cursor/skills。
你再用的Agent工具，又係另一個目錄。
結果就係你嘅項目根目錄入面一堆.xxx/skills資料夾。
每次寫個新技能，複製貼上三四份。改個bug，三四個地方都要改。
呢個唔係寫緊代碼，而係做復讀機。
仲差嘅係，你想換個Agent工具試下？對唔住，要將所有技能文件搬一次先。
問題出喺邊度
本質上呢個係個地盤問題。
每個Agent工具都想搞自己嘅專屬目錄，就好似動物尿尿畫地盤咁。
.codex/skills係我嘅地盤，.cursor/skills係你嘅地盤，邊個都唔好想侵犯邊個。
聽落好合理係咪？各自管各自嘅，井水不犯河水。
但開發者就慘啦。
我哋唔係Agent工具嘅附庸，我哋只係想用個順手嘅工具做嘢啫。
一個好簡單嘅方案
Alexander提出嘅方案簡單到令人想笑：
大家都從.agents/skills讀咪得囉？
冇錯，就係咁簡單。
不是.codex/skills，不是.cursor/skills，就是.agents/skills。
所有Agent工具都從呢一個地方讀技能文件。
Codex已經支持咗，而家正係呼籲其他工具跟進。
呢個就好似當年前端模塊化嘅混戰。AMD派、CMD派、UMD派打到不可開交，最後ES Module出嚟，大家終於停止咗。
標準嘅價值就係在於等大家唔使再亂咁搞。
點解呢件事咁重要
你可能覺得呢啲係小事。
改個目錄名啫，有冇必要咁大陣仗呀？
有必要。
呢件事關乎成個生態會唔會變成一盤散沙。
如果每個工具都搞自己嘅標準，開發者就被綁死咗。用咗Codex就要用佢嘅目錄結構，想換工具？要將配置全部搬一次先。
這種vendor lock-in（供應商鎖定）係生態嘅毒瘤。
佢會令開發者唔敢嘗試新工具，令新工具好難進入市場，令成個生態停滯不前。
反過來，如果大家都用.agents/skills：
你可以隨便換Agent工具，零成本。
技能文件可以喺社區共享，就好似npm package咁。
新工具唔需要令用戶重新組織項目，直接就可以用。
呢個先係健康嘅生態。
技術上唔係問題
實現呢個好簡單。
對Agent工具嚟講，就係改個讀取路徑：
// 先讀標準目錄
const skills = await readDir('.agents/skills')
// 找不到再讀舊目錄（兼容）
.catch(() => readDir('.codex/skills'));對用戶嚟講，就係鬱嚇個檔案：
mv .codex/skills .agents/skills技術從來都唔係問題，人心先係。
真正嘅挑戰
Alexander喺推文入面特別強調"like/tag/RT for momentum"。
呢個唔係求關注，而係因為標準需要夠多人支持先可以成為標準。
如果得Codex支持.agents/skills，咁佢就只係又一個專屬目錄。
但如果主流工具都支持，佢就係標準喇。
呢個令我想起TypeScript嘅故事。微軟啱推出時，好多人唔屑一顧。但Angular用咗，Vue用咗，React都用咗，最後TypeScript就成為咗事實標準。
網絡效應係標準形成嘅關鍵。
越多用，就越有價值。越有價值，就越多人用。
呢個係個正反饋循環。
我哋可以做啲咩
如果你喺開發Agent工具，支持.agents/skills。
如果你喺用Agent工具，去提issue要求支持。
如果你喺寫教程，推薦用.agents/skills。
每個人嘅一小步，匯聚起嚟就係生態嘅一大步。
總結
.agents/skills呢個提議睇落好細。
但佢解決嘅係生態碎片化呢個大問題。
技術實現好簡單，難嘅係令大家達成共識。
呢度需要社區嘅力量，需要每個人嘅參與。
好嘅標準唔係設計出嚟嘅，係用出嚟嘅。
P.S. 如果你喺用Codex，而家就可以將技能文件搬去.agents/skills了。
參考資料
原推文：https://x.com/OpenAIDevs/status/2018421900511433071
一個很蠢的現狀
我們先看看現在是什麼情況。
你用Codex，它要求你把技能文件放在.codex/skills。
你用Cursor，它可能要求你放在.cursor/skills。
你再用個別的Agent工具，又是另一個目錄。
結果就是你的項目根目錄裏一堆.xxx/skills文件夾。
每次寫個新技能，複製粘貼三四份。改個bug，三四個地方都得改。
這不是在寫代碼，這是在當復讀機。
更糟糕的是，你想換個Agent工具試試？對不起，先把所有技能文件遷移一遍吧。
問題出在哪兒
本質上這是個地盤問題。
每個Agent工具都想搞自己的專屬目錄，就像動物撒尿劃地盤一樣。
.codex/skills是我的地盤，.cursor/skills是你的地盤，誰也別想侵犯誰。
聽起來很合理對吧？各管各的，井水不犯河水。
但開發者遭殃了。
我們不是Agent工具的附庸，我們只是想用個順手的工具幹活而已。
一個很簡單的方案
Alexander提出的方案簡單到讓人想笑：
大家都從.agents/skills讀不就完了？
沒錯，就這麼簡單。
不是.codex/skills，不是.cursor/skills，就是.agents/skills。
所有Agent工具都從這一個地方讀技能文件。
Codex已經支持了，現在正在呼籲其他工具跟進。
這就像當年前端模塊化的混戰。AMD派、CMD派、UMD派打得不可開交，最後ES Module出來，大家終於消停了。
標準的價值就在於讓大家不用再瞎折騰。
為什麼這事兒重要
你可能覺得這是小事。
改個目錄名字而已，有必要這麼大張旗鼓嗎？
有必要。
這關係到整個生態會不會變成一盤散沙。
如果每個工具都搞自己的標準，開發者就被綁死了。用了Codex就得用它的目錄結構，想換工具？先把配置全遷移一遍。
這種vendor lock-in（供應商鎖定）是生態的毒瘤。
它會讓開發者不敢嘗試新工具，讓新工具很難進入市場，讓整個生態停滯不前。
反過來，如果大家都用.agents/skills：
你可以隨便換Agent工具，零成本。
技能文件可以在社區共享，就像npm包一樣。
新工具不需要讓用戶重新組織項目，直接就能用。
這才是健康的生態。
技術上不是問題
實現這個很簡單。
對Agent工具來說，就是改個讀取路徑：
// 先讀標準目錄
const skills = await readDir('.agents/skills')
// 找不到再讀舊目錄（兼容）
.catch(() => readDir('.codex/skills'));對用戶來說，就是移動一下文件：
mv .codex/skills .agents/skills技術從來不是問題，人心才是。
真正的挑戰
Alexander在推文裏特別強調"like/tag/RT for momentum"。
這不是在求關注，而是因為標準需要足夠多的人支持才能成為標準。
如果只有Codex支持.agents/skills，那它就只是又一個專屬目錄。
但如果主流工具都支持，它就是標準了。
這讓我想起TypeScript的故事。微軟剛推出時，很多人不屑一顧。但Angular用了，Vue用了，React也用了，最後TypeScript就成了事實標準。
網絡效應是標準形成的關鍵。
越多人用，就越有價值。越有價值，就越多人用。
這是個正反饋循環。
我們能做什麼
如果你在開發Agent工具，支持.agents/skills。
如果你在用Agent工具，去提issue要求支持。
如果你在寫教程，推薦用.agents/skills。
每個人的一小步，匯聚起來就是生態的一大步。
總結
.agents/skills這個提議看起來很小。
但它解決的是生態碎片化這個大問題。
技術實現很簡單，難的是讓大家達成共識。
這需要社區的力量，需要每個人的參與。
好的標準不是設計出來的，是用出來的。
P.S. 如果你在用Codex，現在就可以把技能文件移到.agents/skills了。
參考資料
原推文：https://x.com/OpenAIDevs/status/2018421900511433071