代理技能需要套件管理器

代理技能如今出現了和JavaScript在鎖定檔普及前一樣的失敗模式：每個人都把有用的檔案複製到本機設定，接著每一份副本都開始偏移。

同一週內，訊號從多個方向傳來。Microsoft的Agent Package Manager文件把代理上下文描述成一種團隊應該在清單中宣告、解析成鎖定檔，並發佈到各個AI客戶端既有讀取目錄的內容。¹ Sx則從另一個角度描述同一類別：它是AI程式碼助理的套件管理器，可以在團隊與工具之間共享技能、規則、代理、命令、掛鉤、MCP伺服器與外掛組合。²

這個類別之所以重要，是因為Codex、Claude、Cursor、Copilot、Gemini、OpenCode與類似工具，已經不再只靠提示運作。它們依賴流程檔案、技能定義、命令檔案、MCP伺服器宣告、掛鉤腳本、政策檔案與外掛清單。這些檔案會在任務專屬工作的第一個token出現之前，就先塑造代理的行為。

重點摘要

代理技能需要套件管理器，因為代理上下文已經成為軟體供應鏈的一部分。有用的技能不只是文字。它可能帶入腳本、MCP伺服器、掛鉤、命令、代理與安裝範圍。團隊需要清單、鎖定檔、內容掃描、來源政策、審查關口，以及這些資產的回復機制。

正確的問題不再是「我要把這個技能貼到哪裡？」而是「我們安裝了哪個版本？它來自哪裡？誰核准了它？哪些客戶端收到它？它能執行什麼？我們要如何復原？」

套件管理器本身無法讓代理工作變得安全。它們能做的，是讓相依關係圖夠清楚，足以治理。

重點整理

給工程團隊： - 將代理技能、MCP伺服器、掛鉤、命令、提示與外掛視為相依套件。 - 提交鎖定檔、審查更新，並在新套件進入共享專案前執行安裝與稽核檢查。

給安全審查者： - 區分建置期間的套件完整性與執行期間的安全性。安裝乾淨，不代表掛鉤或MCP伺服器在代理讀取後仍會安全行事。 - 在信任共享代理上下文之前，要求來源允許清單、固定commit、隱藏字元掃描與祕密間接引用規則。

給代理工具建置者： - 封裝最小且完整的能力，而不是整套私人工作流程。 - 從第一次公開發佈開始，就為限定範圍的安裝、更新審查與回復而設計。

發生了什麼變化？

OpenAI的Codex Academy頁面現在給出清楚區分：外掛會把Codex連接到外部工具與資訊來源，技能則教Codex團隊的特定流程。³ Anthropic的外掛文件使用更廣的封裝框架：外掛會把MCP連接器、技能、slash command與sub-agent包成可重複使用的能力套件。⁴

這些定義帶來一個營運問題。團隊安裝的已經不是「建議」。團隊安裝的是一批檔案，這些檔案可能改變代理看見哪些工具、使用者叫用哪些工作流程、背景檢查如何執行，以及哪些指令載入上下文。

Claude Code的外掛參考文件直接展示了這個形狀。外掛可以包含技能、命令、代理、掛鉤、MCP伺服器宣告、監控器、二進位檔、設定與清單。⁵ 它的CLI支援user、project與local等安裝範圍；版本解析可以來自外掛中繼資料、市集中繼資料或git commit SHA。⁶

這看起來像相依系統，因為它就是相依系統。

為什麼複製貼上會失效

複製貼上適合一位開發者試用一個技能。放到團隊就會失效。

第一個失敗點是偏移。某個repo有昨天的技能。另一個repo有branch版本。第三位開發者因為一句話干擾了模型，就編輯了本機副本。沒有人知道上週那個好結果到底是哪個版本產生的。

第二個失敗點是範圍。設計審查技能適合設計密集的儲存庫。資料庫遷移技能可能只屬於後端服務。祕密掃描掛鉤幾乎到處都需要。全域安裝會膨脹上下文，也提高誤觸機率。逐專案複製貼上則會把有用成果埋起來。

第三個失敗點是信任。技能檔案可以包含程序性指令。外掛可以包含掛鉤。MCP伺服器可以連接資料與工具。slash command可以觸發多步驟工作流程。套件管理器無法判斷該工作流程是否值得信任，但它能迫使安裝者回答檔案來自哪裡，以及哪個版本進入了檔案樹。

第四個失敗點是回復。當新的技能削弱代理的判斷力，團隊需要的是一次可回復的相依變更。手動複製會讓回復變成考古。

套件管理器帶來什麼

Microsoft APM明確採用套件管理器的形狀。apm.yml宣告相依套件。apm.lock.yaml固定解析後的套件，讓兩位開發者能安裝位元組完全一致的上下文。APM會寫入既有客戶端目錄，例如.github/、.claude/、.cursor/、.codex/、AGENTS.md、.gemini/、.opencode/與.windsurf/；它沒有發明新的執行環境。¹

它的快速入門展示了實際資產組合：apm.yml、apm.lock.yaml、已加入gitignore的apm_modules/快取、與客戶端無關的技能，以及目標專屬輸出檔案。同一頁也說明，APM會解析遞移相依套件、掃描套件內容中的隱藏Unicode，並在鎖定檔記錄精確commit與內容hash。⁷

相依套件工作流程看起來很熟悉：

Microsoft文件也清楚說明鎖定檔紀律：提交產生的鎖定檔、絕不手動編輯，並透過檢查它來回答團隊實際執行的是哪個版本。⁸

對代理而言，這套紀律比許多早期設定檔更重要。代理上下文會以機率方式改變行為。一行指令就可能改變模型拒絕什麼、偏好哪個工具、是否停下來要求證據，或是否把發佈視為已完成。

Sx顯示出同樣壓力

Sx從不同的產品表面出發，最後落在同一類別。它的README稱sx是AI程式碼助理的套件管理器，並表示它管理技能、MCP設定、命令與相關資產。² 它支援跨組織、儲存庫、路徑、團隊、使用者與bot身分的安裝範圍。⁹

範圍細節很重要。好的代理上下文不應該到處載入。套件管理器應該能回答：誰會收到這個資產？在哪個repo？哪個路徑之下？對哪個bot或真人身分？

Sx也把稽核與使用狀況視為一級介面。它的README列出sx stats用於採用資料，sx audit用於近期團隊或安裝變更。⁹ 這指向下一層：代理套件不只需要發佈，也需要使用證據。沒有人叫用的技能是負擔。每個人都叫用但反覆修補的技能需要修訂。會阻擋有用工作的掛鉤，需要的是變更請求，而不是悄悄刪除。

Sx最強的想法不是市集。最強的想法是限定範圍的發佈，加上可觀察的採用狀況。

套件管理器無法證明什麼

套件管理器可以讓相依關係圖變得可見。它不能讓每個套件都值得存在。

Microsoft的安全文件清楚說明邊界。APM防護的是提示、指令、技能、掛鉤與MCP伺服器宣告的建置期間供應鏈。它的目標是可重現性、完整性、來源追溯與部署前內容安全。¹⁰ 同一頁也說，APM不會在執行期間沙箱化MCP伺服器、不會對相依程式碼做惡意軟體分析、不會簽署套件，也不會檢查代理讀取上下文後做了什麼。¹¹

這個邊界應該形塑採用方式。

不要把安裝成功當成信任決策。應該把安裝成功視為繼續審查的理由。審查仍然需要檢查可見指令、可執行掛鉤、MCP傳輸方式、環境變數處理、更新政策，以及該套件宣稱要完成的實際工作。

規則很簡單：套件管理器讓代理上下文可治理，但不會讓它天生優良。

最低標準

團隊不必等待單一生態系勝出，才開始改善流程。可以先從6條規則做起。

1. 盤點每一項代理資產。 列出技能、命令、掛鉤、MCP伺服器、代理、外掛組合、提示檔案與專案指令。團隊若無法盤點資產，就無法治理資產。

2. 分開個人、專案與組織範圍。 個人實驗不該變成專案預設。專案標準不該變成全域上下文。組織套件應該明確標示所有權。

3. 共享前固定版本。 對共享套件使用tag或commit SHA。浮動branch屬於實驗，不屬於發佈工作流程。

4. 提交鎖定檔。 可重現性需要解析後的樹，而不只是清單意圖。

5. 分開審查執行期間表面。 掛鉤、二進位檔、shell command與MCP伺服器，比純指令式技能更需要嚴格審查。它們能執行或連接，因此風險更高。

6. 讓回復變得平淡無奇。 壞的套件更新應該透過一次相依變更加上一個重新安裝命令即可回復。若回復需要回想複製過哪些檔案，系統就還沒準備好。

實務採用路線圖

從小處開始。

先封裝一個無害的技能：寫作評分規準、測試清單或審查格式。把它安裝到一個repo。確認正確的客戶端看得見它。確認鎖定檔固定它。確認解除安裝可行。

接著，封裝一個大家已經手動叫用的命令。在團隊理解安裝與回復路徑之前，先避開掛鉤與MCP伺服器。

然後封裝一個MCP伺服器宣告，但不要把憑證放進套件。使用環境變數引用與獨立的祕密儲存區。套件應該描述執行期間相依，而不是攜帶祕密。

掛鉤最後再來。掛鉤可以在正確時機強制品質，但也可能阻擋工作、隱藏脆弱假設，或在錯誤信任模型下執行腳本。只有在團隊已具備來源政策、審查所有權與回復方式後，才發佈掛鉤。

這個順序尊重風險梯度：

審查包

共享代理套件進入專案前，要求一份審查包。保持樸實。

這份審查包可以避免最糟的失敗：團隊說「我們安裝了一個技能」，實際上卻安裝了一個外掛、一台MCP伺服器、兩個掛鉤，以及一個沒人審查過的命令。

品味層仍然重要

代理套件會招來數量誘惑。因為安裝感覺便宜，團隊可能安裝40個技能。便宜的上下文仍有成本。

每增加一個技能，都會爭奪注意力。每增加一個命令，都多一個選項。每增加一個掛鉤，都多一個可能的阻擋點。每增加一台MCP伺服器，都擴大動作表面。套件管理器解決的是發佈，不是判斷力。

正確標準仍然要小而鋒利：安裝能改善工作的東西，移除讓代理臃腫的東西，固定通過審查的東西，並觀察人們實際使用什麼。

這就是代理套件的Steve Test。不要發佈最大包。要發佈 coherent 的那一包。

快速總結

代理技能需要套件管理器，因為代理上下文現在的行為已經像相依程式碼。技能可以攜帶流程。外掛可以攜帶命令、掛鉤、MCP伺服器與代理。套件可以改變每位開發者的代理設定行為。

套件管理器的工作不是讓這些資產變好。它的工作是宣告、固定、發佈、稽核它們，並讓回復成為可能。團隊的工作仍然更難：決定哪些資產值得存在。

FAQ

代理技能真的算相依套件嗎？

是。共享技能會改變代理執行任務的方式。外掛也可以加入命令、掛鉤、MCP伺服器與代理定義。這些檔案會跨機器影響行為，因此團隊應該用對待程式碼相依套件的嚴肅程度來追蹤它們。

套件管理器會取代外掛審查嗎？

不會。套件管理器會記錄來源、版本、hash、範圍與已安裝檔案。審查仍然需要檢查套件說了什麼、它能執行什麼、宣告了哪些MCP伺服器，以及這項能力是否屬於專案。

團隊應該封裝私人工作流程嗎？

團隊應該封裝可重複完成的任務，而不是私人營運細節。公開套件可以提供一般審查關口、遷移清單或文件工作流程。它不該帶出私人提示、敏感檔案路徑、憑證、內部來源地圖或專有評分內部邏輯。

團隊第一個該封裝什麼？

從低風險、且已經能手動運作的技能開始。在團隊具備清單、鎖定檔、來源政策、安裝審查與回復路徑之前，先避開MCP伺服器與掛鉤。

對代理工作而言，套件管理器最好的功能是什麼？

鎖定檔是承重功能。探索有幫助，安裝命令用起來也順手，但可重現的代理上下文需要精確來源參照、內容hash與已部署檔案的紀錄。

參考資料