代理技能是可重複使用的指令、腳本和資源包。Codex等人工智慧代理可以自動加載，高效穩定地完成特定任務。
無需重複輸入相同的指導方針，並且技能可以在一次寫入時間內在全球範圍內重複使用，節省時間並減少錯誤。您可以自動安裝預製技能，或根據組織需求定製專屬技能並在團隊之間共享。
這種模塊化方法將一般人工智慧助理轉變為領域專家，使他們能夠可靠地處理複雜的專業工作流程，而不必在每次對話中重複發出指令。
當許多人第一次看到這個項目（openai/skills）時，他們認為它只是一個「工具調用示例庫」。「但如果你仔細觀察，你會發現它實際上在做一些更基本的事情：它正在重新定義大模型到底是否是一個『系統』。
過去，當我們使用人工智慧時，大部分時間我們都在「對話」。你問，它就會回答。最多寫代碼、翻譯文本和解釋概念。這個模型本質上停留在「語言層面」。
但技能正在開始將人工智慧推向另一個層面--執行層面。
您可以這樣解讀：
大模型本身只是一個「思考和說話的大腦」，但它沒有手腳。技能是連接它的「外部器官」。
例如，技能可以是：
- 調用GitHub API讀取代碼
- 檢查資料庫
- 發送電子郵件
- 執行Python的一個段落
- 調整您自己的伺服器界面
當這些能力被標準化後，AI不再只是「建議你做什麼」，而是可以真正「做」。
這裡最重要的變化不是功能，而是結構。
以前我們做自動化的時候，邏輯是這樣的：
手動編寫過程-調優API-拼寫結果
現在它開始變成：
人工智慧自行決定流程|自動選擇工具|執行|繼續決策
這就是技能的意義。
它不是工具庫，而是「能力協議」。
您會發現它的設計很像您熟悉的東西：有點像OpenAPI，有點像函數調用，但更進一步。因為不是讓人打電話，而是讓模特「理解和選擇」。"
換句話說：
您不是在編寫代碼來調用工具
相反，「作為工具，我可以教人工智慧什麼？"
然後它使用自己。
一旦建立起來，整個開發範式就發生了變化。
你不再需要編寫死流程，而是建立一個人工智慧可以自由組合的「能力空間」。
接受一個簡單的請求：
「幫我分析這個GitHub項目並寫一個摘要」
在傳統程式中，您會寫：
- GitHub API拉代碼
- 文本解析
- 調整模式摘要
- 輸出格式化
但在技能+代理模型中：
人工智慧將自動執行此操作：
- 發現您需要GitHub數據|調整GitHub技能
- 獲取代碼→分析技能
- 生成摘要|輸出
在整個過程中，您不再寫「流程」，而是提供「能力」。
這就是為什麼現在你看到：
- OpenClaw
- Langstra
- 各種Agent框架
正在做類似的事情。
它們本質上都在解決同一個問題：
如何將人工智慧從「聊天工具」變成「任務執行系統」
技能是這個環節中非常核心的一環。
坦率地說：
過去，軟體是由人類編寫並由機器執行的
今天的軟體需要機器本身生成邏輯，然後調用執行邏輯的能力。
這是一個非常大的變化。
正因為如此，儘管這個項目看起來很簡單，但它實際上指向了一個更大的趨勢：
人工智慧正在成為「作業系統」。"
技能是該作業系統中的「應用程式界面」。
就像你手機上的應用程式一樣，你不需要關心底層如何實現。您只需點擊它即可完成一件事。未來的人工智慧也是如此--它會根據您的需求自動調用一組技能來幫助您完成任務。
你甚至不需要知道它做了什麼。
此時，「能否寫提示」不再重要。
更重要的是：
你能設計一套好的功能讓人工智慧有用武之地嗎？
如果您現在正在這樣做：
- 自動化流程
- Telegram機器人
- 多agent系統
- AI +電商/內容
嗯，這個想法實際上離你很近。
您製作的每個界面和每個功能本質上都可以抽象為一個技能。
當你整理這些功能並要求人工智慧調用它們時，你實際上是在做一件事：
構建自己的人工智慧作業系統
這是openai/skills項目中真正有趣的部分。
Github：https://github.com/openai/skills
輸油管：