問題：同一套做法，換工具就要重包裝
很多中小企業不是沒有 AI，而是同一套做法散在不同地方：一份提示詞在聊天工具裡，一個資料查詢腳本在開發環境裡，人工核准規則則放在某位同事的腦袋裡。當團隊想把這套做法交給另一個 AI 工具，真正卡住的常常不是技能本身，而是每個工具要求的資料夾結構、設定檔格式與工具連接方式都不一樣。
Google 在 2026 年 8 月 6 日的公告，把這個問題直接稱為「包裝」問題：元件可以重複使用，但外層包裝常常得重做，最後形成多份容易漂移的副本。〔S1〕
7Pyramid 觀點
我會把 Agent Plugin 想成一個貼好標籤的小型工作箱：外面寫清楚這箱子要做什麼，裡面放工作步驟和需要的工具，敏感的那一步則由人簽名確認。工作箱比較容易搬，不代表它自動變成安全檢查站；這是協助理解的比喻，不是產品安全保證。
後果：工具越多，交接與稽核越難
Agent Plugins 1.0.0 的方向，是用一個開放、供不同工具採用的格式，把 Agent Skills 與 MCP 伺服器放進可攜式外掛。Google 宣布加入核心維護團隊，也表示 Agents CLI 與 Data Agent Kit 開始支援這個格式。〔S1〕這是產品與生態系公告，不應直接解讀成所有工具都已支援、流程一定可靠，或企業一定會得到投資報酬。
官方規格目前是 1.0.0，狀態標示為 Working Draft。它把外掛根目錄與元件位置固定下來，讓客戶端可以依約尋找支援的內容，而不是每次猜設定檔放在哪裡。〔S2〕
| 工作包位置 | 用途 | 今天要檢查 |
|---|---|---|
plugin.json | 說明外掛身分與目標格式版本 | 名稱、版本與 schema 是否清楚 |
skills/ | 放可重複的工作步驟與 SKILL.md | 指令是否能讓另一位同事照著跑 |
mcp.json | 放 MCP 伺服器設定 | 是否真的需要外部工具，以及工具能碰到什麼 |
第 1 版定義的核心元件是 skills 與 MCP servers；客戶端自己的特殊功能，則應放在 extension namespace。這讓可攜的核心和各工具的差異分開，但也代表客戶端仍要自行決定安裝、載入、授權與執行細節。〔S2〕
解法：先做一個可攜工作包，不要先做全公司自動化
今天可以挑一個低風險、重複發生的任務，例如每週整理名單摘要、分類客服問題、準備內容 brief，或檢查行銷活動素材。先寫一頁工作包簡報，只回答四件事：
- 輸入：AI 會收到哪些資料？哪些資料只能用假資料測試？
- 輸出：完成後要產出摘要、分類表、草稿，還是待辦清單？
- 核准：哪一步一定要由人檢查？誰負責按下最後的送出？
- 失敗處理：欄位缺漏、工具連不上或答案不確定時，要停下來還是交回人工？
接著建立最小結構：用 plugin.json 說明身分，把可重複步驟放進 skills/；只有真的需要外部工具時，才加入 mcp.json。這些固定位置來自官方規格，不代表每個客戶端都支援所有元件，也不代表安裝後就能直接執行。〔S1〕〔S2〕
可攜不等於安全：把兩件事分開驗證
最容易誤會的地方是：格式可攜，和外掛安全，是兩個不同的檢查。Agent Plugins v1 不定義安裝機制、散布方式、權限模型、沙盒要求、信任或來源驗證；官方規格也把客戶端的執行責任留在各工具手上。〔S1〕〔S2〕
Visual Studio Code 的官方文件提醒，外掛可以包含 hooks 與 MCP 伺服器，而這些元件可能在使用者電腦上執行程式；安裝前應檢查發布者與內容，企業也可以管理可用的市集與外掛。〔S3〕因此，台灣中小企業在測試時要把兩條線分開：
- 可攜性檢查：客戶端是否認得 schema？技能是否載入？輸出格式是否符合預期？換到另一個支援的工具後，哪些內容仍然可以重用？
- 安全檢查：外掛從哪裡來？要求哪些工具與權限？hooks 或 MCP 會執行什麼？是否含有祕密？付款、刪除資料、對外發訊息與發布內容前，人工能不能停下來？
Working Draft 也代表規格、客戶端支援與實作細節可能變動。要進入正式環境前，請重新核對版本、客戶端文件與公司的權限政策。
今天就做：用假資料跑一次低風險任務
請不要一開始把 API 金鑰、客戶個資、付款資訊、健康資料或私人帳號脈絡放進工作包。先用虛構商家、合成詢問與刻意缺少一個欄位的資料，跑完下面這個小測試：
- 記錄客戶端是否認得宣告的 Agent Plugins 版本。
- 確認輸入、輸出與失敗狀態都看得見。
- 在外部動作前保留一個明確的人工核准點。
- 讓第二位同事照著工作包重跑，記下哪裡仍需要口頭補充。
先把一個人的經驗整理成別人能接手的工作包，再談跨工具、跨團隊或全自動化。模型會換、介面會換，但清楚的任務邊界、可追蹤的資料來源，以及最後一道人工確認，才是公司真正留下來的自動化資產。
結論：留下來的不是包裝，而是可交接的流程
Agent Plugins 1.0.0 值得注意，不是因為它保證所有 AI 工具從此無痛互通，而是它把「如何把技能與工具放進工作包」變成一個可以共同討論的格式。對中小企業來說，最穩的順序仍然是：先選低風險任務，寫清楚輸入、輸出、核准與失敗路徑，再用假資料測試可攜性與安全性。
常見問題
Agent Plugins 1.0 代表所有 AI 工具都能直接使用嗎？
不代表。格式的目標是提高可攜性，但每個客戶端仍要自行支援、載入與執行元件。請以實際客戶端文件和測試結果為準。〔S1〕〔S2〕
可攜式外掛就等於安全嗎？
不等於。v1 沒有定義安裝、權限、沙盒、信任或來源驗證；外掛內的 hooks 與 MCP 也可能在本機執行程式。安裝前先看發布者、內容、工具權限和人工停損點。〔S1〕〔S2〕〔S3〕
第一個工作包應該拿什麼任務來試？
選擇重複、低風險、輸出可以人工檢查的任務，例如摘要、分類、內容 brief 或 QA 清單。付款、刪除資料、對外聯絡與發布內容，先保留人工核准，不要拿來做第一個 demo。