AAIF 納入代理開放專案：Skills、Responses、訓練環境與沙箱分別解決什麼？
AAIF 成為 Agent Skills 的中立治理機構，也收錄 Open Responses、OpenEnv 與 OpenSandbox。本文分清任務知識、模型介面、訓練環境和執行沙箱的責任，說明共同維護如何影響開發，以及團隊該從哪一層開始接入。
一個 AI 代理要完成工作，需要知道怎麼做、如何呼叫模型，也得有地方執行動作。這些問題很難只靠一份共通提示詞解決。
AAIF，也就是 Linux Foundation 旗下的 Agentic AI Foundation，正把不同層次的開放專案放進共同治理架構。
Anthropic 在十月二十二日宣布捐出 Agent Skills 的名稱、程式組織和網站。使用者不必加入基金會，也能繼續使用或參與標準。
AAIF 的專案裡還有 Open Responses、OpenEnv 和 OpenSandbox，處理模型通訊、訓練環境與執行環境，並非四種互相取代的代理。
我認為跨工具開發者最該先找出自己卡在哪一層，再挑一項標準測整合。共同治理提供參與維護的途徑，卻不保證每個實作表現相同。
先從這次治理移轉改變了什麼看起，才知道哪些能力早已存在，哪些工作接下來由社群共同決定。
AAIF 接下什麼？治理移轉和產品首發有何不同
Agent Skills 這次移轉的是標準的共同維護與資產，不是要求使用者改買一套新產品。
依Anthropic 的公告，捐出的內容包括名稱、標誌、GitHub 組織與網域。這些資產決定標準對外如何辨識、文件在哪裡維護，以及未來改動如何協作。
既有技能不會因為換了治理機構，就自動獲得新的執行能力。
時間也要分開理解，因為技能概念與開放規格在這次移轉前已存在，官方把二〇二五年十月的初始技能、同年十二月的開放標準，和今年十月的治理移轉分開說明。
因此，看到「加入基金會」時，不能把它寫成今天才第一次能使用技能。這次重要的變化，是標準日後由誰共同決定，而非一項過去不存在的功能突然上線。
維護者來自多家組織，並以個人身分參與。AAIF 的安排希望讓規格的發展不只依賴一家產品公司的需求。
對開發者而言，實際意義是能透過公開討論、問題回報與提案，把跨工具使用時遇到的差異帶進維護流程。
使用或貢獻標準不以加入基金會為前提，也不需要先取得會員身分才有資格寫技能。
官方提到的版本化發布、正式提案流程與安全指引等工作，仍有屬於未來規畫的部分。治理轉移提供了推動這些工作的架構，但不應直接當成每項制度都已完成的證明。
團隊若要依賴特定版本，還是需要查看實際規格與發布紀錄，而不是只根據加入基金會的消息做採用決定。
AAIF 的 Skills 說明則把焦點放在組織知識：熟悉工作的人可以整理流程、範例與完成條件，其他同事再沿用及修正。
這讓「怎麼做才符合團隊需求」有一個可共同維護的地方。但標準仍只是承載方法的格式，內容好不好，取決於作者是否理解工作，以及使用後有沒有持續修訂。
知道誰能維護之後，還要分清這些專案究竟處理代理工作的哪一部分。把所有開放工具都叫成代理標準，容易忽略它們其實位於不同的資料流位置。
Agent Skills 與 Open Responses：教任務和呼叫模型為何不同？
Skills 提供可重用的工作方法，Open Responses 則讓程式用共同介面和不同模型服務溝通。
前者回答「這項工作應該怎麼做」，後者回答「程式要用什麼格式把請求送出去、接回結果」。所以兩者可以在同一個代理裡並存，卻不能互相代替。
一份技能通常以資料夾組織，核心說明放在 SKILL.md，旁邊可以附腳本、參考資料與範例。代理在需要時載入相關內容，就不必每次由使用者重講整個流程。
譬如團隊對程式審查有固定要求，技能可以記下檢查順序與輸出格式。但若代理沒有讀取程式庫或執行測試的工具，這份說明也不會憑空替它補上權限。
這和 MCP 的工具連接層也有差別。技能偏向告訴代理何時及如何工作。工具介面則讓它能取得資料或執行動作。可以把技能想成工作手冊，工具想成手邊可用的設備。
所以工作手冊能教人使用設備，卻不是設備本身。同一份流程也可能因為各個環境的工具不同，需要少量調整。
Open Responses 的官方介紹描述的是另一種重工：不同模型供應商用不同欄位表示提示、工具呼叫與串流事件，開發者就得維護多套轉接程式。
因此，共同規格讓符合規格的端點接受一致的請求結構，開發者較能把端點與模型名稱放進設定，而不是在程式裡到處分支判斷。
共同格式不代表所有服務能力相同。某個端點可能支援額外的搜尋工具，另一個只支援基本對話。模型品質、價格、上下文限制與使用政策，也不會因為欄位一致就消失。
規格允許擴充功能，客戶端可以選擇支援哪些擴充，因此要驗證的是自己使用的功能是否完整對應，而不是只看一個簡單文字請求能否成功。
工作方法和模型通訊接好後，代理仍需要執行動作、觀察結果。這時才輪到訓練環境與執行沙箱，不能期待模型介面替整個電腦環境做管理。
OpenEnv 和 OpenSandbox：訓練情境與執行環境怎麼分工？
OpenEnv 讓任務的觀察、動作與回饋更容易共用，OpenSandbox 則管理代理執行工作的環境。前者關心的是如何把一項任務變成可互動、可訓練或評估的情境。
後者關心的是執行空間如何建立、啟動、使用與結束。它們可能搭配使用，但處理的責任不同。
以強化學習來說，系統會在環境裡採取動作、觀察結果，再取得回饋。回饋可以讓訓練流程知道這一步離目標更近或更遠。
OpenEnv 提供組織這類環境的框架，讓觀察內容、可用動作與回饋有較一致的介面。它不是一個已訓練好的大型語言模型，也不會只靠安裝就讓代理學會所有工作。
所以任務設計在這裡十分重要。假設目標是修好測試，回饋若只看某個指令是否成功結束，代理可能得到與使用者需求不一致的訊號。
環境格式能讓實驗更容易重做，卻不替設計者判斷目標是否合理。應該檢查哪些檔案、怎樣算完成，仍需要由任務本身定義。
OpenSandbox 則提供管理執行環境生命週期與程式執行的共同介面。生命週期就是從建立一個空間、執行工具，到保留或結束它的過程。
開發者可以透過介面操作不同基礎設施上的環境，而不必把每個後端的管理方式全部寫進代理的主要邏輯。
不過，相同介面不表示底層隔離方式完全一樣。實際使用的核心、網路設定、檔案保存及資源限制，仍取決於後端實作與部署設定。
共同介面可以降低更換後端時的程式改動，卻不是一張保證所有環境具有相同隔離程度的證書。AAIF 的專案治理，也不等於替每個部署提供服務等級承諾。
維護者的文章提供了一個很具體的評分陷阱：水彩訓練專案曾把渲染逾時或評分器不可用回傳為零分，等於把基礎設施失敗，誤當成作品畫得不好。
後來改成沒有有效評分，並排除那次嘗試，才不會讓模型學到錯誤訊號。這說明環境可以被重複呼叫，與回饋是否可信，仍是兩份需要處理的工作。
沙箱這一側也有具體的交接過程。依官方介紹，代理先透過開發套件要求建立環境，由生命週期服務把請求交給已設定的執行後端。
環境建立完成後，再由內部的執行程序接收指令與檔案操作。因為建立是非同步工作，送出請求不代表立刻能跑測試，客戶端還需要等到環境進入可用狀態。
這幾層可以互相配合，但一項標準接通，不代表整個代理任務已經完成。
若希望看懂不同環境如何隔離工作，可以對照Perplexity SPACE 開源：每個 AI 任務一台微型虛擬機，憑證與連線怎麼管？。
底層架構的選擇仍會影響上層工具能做什麼。
用一次程式修補看四層如何接在一起
同一個修補任務，可以同時用到程序知識、模型介面、可重做的測試情境與隔離電腦。
以下是一種理解架構的方式，並非官方已完成的四專案整合案例：使用者要求修復一項失敗測試，代理先讀取團隊的技能，再呼叫模型判斷下一步，接著到環境裡執行工具。
技能可以描述先重現錯誤、找出原因，再做最小修改的工作順序。共同模型介面負責把程式片段、工具描述與回傳結果送給選定的服務。執行沙箱提供讀檔、修改與跑測試的空間。
如果團隊要比較不同代理在同一批任務上的表現，訓練或評估環境則需把初始狀態與完成條件明確定義。
所以拆開後，出錯的位置比較容易辨認。代理沒有遵守團隊流程，可能需要改技能。換模型後工具呼叫遺漏欄位，可能需要檢查介面實作。
每次測試的起始檔案不同，則是環境可重做性的問題。若把所有錯誤都歸到模型能力，就很難知道哪個改動能改善結果。
版本也要跟著各層留下。技能內容、介面規格與執行映像可能各自更新。今天成功的流程，明天若換了其中一層，就需要確認任務仍能完成。
因此，記住這些版本的目的，是讓團隊能重現差異，而不是為了建立一份越長越好的設定清單。
但技能數量增加後，維護責任更值得注意。本站的skills.sh 破 100 萬個 Agent Skills：近 2.8 億次安裝代表什麼？數字、風險與入門已討論公開目錄的規模。
這次治理消息更進一步回答，當大家開始依賴共同格式，未來誰能參與規格的演進。目錄大，不等於團隊手上的每份技能都適用。
團隊從哪一層開始？先處理最常重做的整合
我會先挑目前最常造成重工的一層，而不一次把四個專案都塞進同一個流程。如果每次換代理都要重講相同要求，先整理一份技能。
如果主要負擔是維護多家模型的轉接程式，先測共同模型介面。如果比較結果總因環境不同而失真，就先把任務環境固定下來。
已有多種執行後端的團隊，則可以觀察共同沙箱介面是否減少部署分支。判斷方式應回到原任務：更換一個後端後，代理是否仍能取得需要的檔案、執行相同工具，並交回可核對的結果。
所以只讓建立環境的請求成功，還不足以證明遷移完成。
例如先保留一項已知能完成的修補任務，只換模型端點，檢查工具呼叫是否仍帶回完整參數。下一次才換執行後端，觀察測試結果是否相同。一次改一層，能讓差異比較容易歸因。
若同時更換流程、模型與環境，即使最後表現變好，也很難知道是哪個因素帶來改善。
採用時遇到的資訊遺失、欄位差異或流程例外，也正是值得回報標準社群的內容。AAIF 的共同治理提供讓實作者一起處理這些問題的地方。
能證明一層替換後仍完成原任務，開放標準才會從一個相容標誌，變成團隊可持續維護的工作能力。
AAIF 專案的共同規格也需要相容性範圍。團隊可以明確記錄自己依賴的是基本請求、串流事件，還是某個供應商擴充。技能則記下需要哪些工具與參考資料。
所以交給另一位同事時，他才知道哪些部分可以直接沿用，哪些需要先補上環境。
治理移轉降低的，是標準方向只由單一產品決定的疑慮。日常維護仍仰賴實作與回報。
能把一次具體的不相容說清楚，往往比抽象要求所有代理完全互通，更容易形成可以修正的規格問題。
想繼續追蹤這類工具的正式推出條件與後續更新，可以免費訂閱 AI 郵報。
AAIF 代理專案常見問題
使用 Agent Skills 必須加入 AAIF 嗎？
不需要。Anthropic 公告明確表示，使用及參與標準不以基金會會員身分為前提。
Open Responses 格式相同，就能隨意換所有模型嗎？
共同格式可減少轉接程式，但各端點的功能、限制、價格及政策仍不同。需要驗證自己用到的工具呼叫與擴充功能。
OpenEnv 是一個可以直接對話的模型嗎？
不是。它是組織代理互動環境的框架，讓觀察、動作與回饋較容易共用。模型與任務目標仍需另外提供。
OpenSandbox 等於 AAIF 的 Sandbox 專案階段嗎？
不等於。OpenSandbox 是執行環境專案名稱。基金會所稱的 Sandbox 階段，則是治理與專案發展流程中的用語。
