最近看 AI agent 工具生態時，我一直有個感覺：大家很容易把「外掛」想得太像一個資料夾。看到某個 plugin 是 Git repo，就會直覺想問：那我是不是可以把它裝到另一個 agent 裡？答案通常是：檔案搬得過去，不代表能力跑得起來。
這件事乍聽有點掃興，但其實是很重要的架構觀念。外掛真正依賴的不是 repo，而是 host contract。
所謂 host contract，可以把它想成外掛和宿主程式之間的契約：manifest 怎麼宣告、command 怎麼註冊、生命週期怎麼啟動、設定值放哪裡、權限怎麼控、hook 什麼時候被呼叫、執行環境提供哪些 API、錯誤怎麼回報。這些東西只要有一層對不上，外掛就不是「稍微改一下路徑」那麼簡單，而是需要 adapter、wrapper，甚至整個重新包裝。
這其實不新。VS Code extension 不能直接丟進 Chrome 使用，Chrome extension 也不能拿去 Obsidian 當 plugin。它們都可能是 zip、資料夾、GitHub repo，也都可能用 JavaScript 寫，但宿主看得懂的宣告格式、提供的 runtime API、權限模型完全不同。AI agent 只是把同樣的問題搬到另一個還在快速演化的領域。
Repo 是載體，不是標準
工程團隊在評估 AI agent 生態時，很容易被「它也是一個 repo」誤導。Repo 只是交付方式，不是相容性保證。
一個 agent plugin repo 裡可能有 commands、agents、skills、hooks、MCP 設定、prompt 模板、甚至安裝腳本。但另一個 agent 能不能使用它，不是看它有沒有 README.md 或資料夾結構看起來像不像，而是看宿主是否知道：
- 哪個檔案是入口？
- manifest schema 是否一致？
- command 的 input / output contract 是什麼？
- 執行時能不能取得同樣的環境變數與憑證？
- 權限、確認、審計與錯誤處理由誰負責？
- 這個外掛預期的是互動式 session，還是背景工作？
如果這些問題沒有答案，直接安裝通常只是把未知風險搬進系統。
我現在比較傾向用「三層」來看這件事。
第一層是原生外掛層。這層最貼近宿主，使用體驗最好，可以直接吃到 host 提供的 UI、命令、權限、記憶與工具呼叫能力。缺點也很明顯：耦合最高，換一個 host 就不一定能用。
第二層是能力封裝層。例如把一段工作流程寫成 skill、script、prompt package，讓 agent 可以讀懂並執行。這層比原生外掛鬆一點，移植性較好，但仍然會受宿主的 skill 格式、工具呼叫方式與檔案規範影響。
第三層是協議服務層。像 MCP 這類做法，本質上是把能力抽到外部 server，用標準協議暴露 tool、resource 或 prompt。只要不同 host 都支援同一套協議，就比較有機會共用。代價是多了一個服務要部署、監控、除錯，也多了一層延遲與故障面。
跨 agent 共用，不一定要硬裝同一個外掛
如果目標是「同一份能力給多個 agent 用」，我不會第一時間追求「同一個 plugin 可以原生安裝到所有 host」。那通常會把 repo 搞成一團條件判斷：這邊一份 manifest、那邊一份 adapter、不同 host 各自一套 lifecycle。短期看起來很省，長期常變成維護地獄。
比較乾淨的做法是先判斷能力的核心在哪裡。
如果核心是某個 API、查詢、計算或資料存取，那就把它抽成 service 或 MCP server，讓不同 agent 透過協議呼叫。各自的 plugin 只做很薄的 adapter，負責把 host 的命令轉成標準呼叫。
如果核心是某套工作方法、操作流程或提示策略，那它更像 skill 或 playbook。這時候不一定需要 server，重點反而是文件夠清楚、步驟可驗證、失敗情境有寫出來。不同 agent 可以各自用自己的 skill 格式承載，但內容邏輯保持一致。
如果核心是 host-specific 的 UI 或互動體驗，例如某個 IDE 裡的 sidebar、特定聊天室的 slash command、某個 agent 的 hook 流程，那就老實承認它是原生外掛，不要假裝它可以無痛跨平台。跨平台可以做，但那是產品規劃，不是複製資料夾。
技術主管要看的不是「能不能裝」，而是責任邊界
從 CTO 或技術主管角度，我最在意的其實不是某個工具支不支援某個 plugin，而是責任邊界有沒有畫清楚。
外掛壞掉時，是 host 的問題、adapter 的問題、協議 server 的問題，還是背後 API 的問題？權限檢查在哪一層做？敏感操作要不要人類確認？log 記在哪裡？版本升級時誰負責相容性？
這些問題如果在導入前沒想清楚，AI agent 工具會很快從「很聰明的助理」變成「很難控的自動化黑盒」。尤其當 agent 開始能改檔案、打 API、發訊息、觸發工作流程時，外掛不再只是功能擴充，而是生產系統的一部分。
所以我現在看到新的 agent plugin 生態，會先問幾個問題：
- 這個能力是要給單一 host 用，還是多個 host 共用？
- 它依賴的是 host 的互動體驗，還是背後的通用服務？
- 能力核心能不能抽成協議層？
- adapter 能不能保持很薄？
- 權限、審計、錯誤處理在哪裡收斂？
如果答案是「只是想先試試看」，那原生外掛或 skill 很好，快、直接、回饋短。如果答案是「未來會有多個 agent、多人、多系統共用」，我會更早把核心能力抽出來，不讓它長死在單一 host 裡。
結語
AI agent 的工具生態接下來一定會越來越碎。每個平台都會有自己的 plugin、skill、command、workflow 格式，這很正常，因為大家都還在找最好的互動模型。
但身為工程團隊，我們不能只看「能不能安裝」。真正該看的，是這個能力和宿主之間簽了什麼契約。
外掛不是資料夾，repo 也不是標準。標準在 contract 裡，在 runtime 裡，在權限與生命週期裡。看懂這一點，跨 agent 整合就不會變成一場複製貼上的豪賭，而會變成有邊界、有抽象、有退路的架構設計。