把共用規則搬到中央 Repository 之後，問題沒有結束。

2026-10-03 核對時，共用平台的執行前檢查與驗證 Skill 已宣告為 0.3.0、0.5.0；其中一個實際 consumer Repository 保存的版本卻是 0.2.0、0.4.0。直接叫 Agent「讀最新版」，會讓它繞過採用共用能力的專案（consumer）已提交、正在使用的規則快照。

這個版本差異本身不代表 consumer 出錯，也不代表應該立刻升級。它先指出一件事：中央能力的演進，和使用這些能力的專案狀態，必須分開治理。

Shared Agent Platform 應共用穩定的治理責任，同時讓各專案保有本地規則、採用版本與修改授權。

Day 9 已談 Skill 的版本與跨專案升級。這一篇問的是：當驗證、比對、同步與發布都圍繞共用能力反覆出現，平台應該擁有哪些責任，又有哪些事不能收走？

我先看到的是差異，不是抽象需求

這個 consumer 在自己的 agent.yaml 宣告版本與檔案位置，並把 Skill 內容提交到自己的 Repository。普通 clone 就能取得那份快照，不必依賴另一個工作目錄或執行時下載中央最新版。

回查該 consumer 的兩份 Skill，其 Git 內容物件（blob）與共用平台一個既有 commit 完全一致。這能證明本地保存的是可定位的共用內容，不只是兩個名稱相同的文件。

但還有一個不能跳過的缺口：consumer 宣告的來源版本標記是 v0.7.0，這次透過 GitHub 查詢無法解析到該 tag。既有 commit 的內容相符，不等於發布標籤（release tag）的對應已被證明；也不能猜它一定只存在本機。

這個落差改變了下一步。先把「快照內容一致」與「發布來源可解析」分開記錄，再查缺少的來源證據，不能為了對齊中央最新版本就直接同步。

什麼適合上收

目前共用平台已集中幾種可重用責任：

consumer 的宣告檔仍列自己的測試、lint、build；產品特定的登入、唯讀檢視與遠端執行環境行為則列為人工或外部驗證。共用 Skill 沒有替產品決定這些命令，也沒有把本機檢查包裝成 Production 驗證。

這裡的抽取單位是穩定責任。若把某個產品的身份規則直接寫進 shared Skill，下次升級就得同時考慮所有 consumer 是否理解那套業務，中央化反而增加耦合。

官方 GPT‑6 指南對 Skill 的建議也提醒了一個相同方向：Skill 的入口描述應先說清楚「何時使用」，輔助細節再按需載入。對 Shared Platform 而言，這讓中央層更像可重用能力與路由，而不是把所有 consumer 的完整操作手冊都塞進同一份 Skill。這是架構旁證，不代表目前平台已量到 token 或維護成本下降。

Platform 不應拿走 Consumer Authority

平台的工作契約明確排除 consumer 應用程式、部署、憑證與專案特定流程。consumer 也規定，本地政策不能塞進上游管理的 Skill 目錄，否則下一次同步可能覆蓋它。

因此，共用不等於所有專案都由同一份規則直接控制。可以把責任分成三層：

• 平台維護可重用能力與相容性
• Consumer 宣告採用的內容與產品界線
• 當次任務決定這次是否有權同步、提交或部署

這比「中央最新版永遠正確」多一點管理成本，卻保留了升級前的檢查點。即使兩份內容不同，也要先分辨是舊版、合法的本地增強，還是意外漂移，不能立即用中央版本覆蓋。

本地政策放錯地方，下一次升級就會衝突

這個 consumer 有一個具體例子：一套舊執行層已退出 Production。進行現行後端的 schema 遷移與歷史匯入時，舊執行層專用的行為測試不列必要關卡；但歷史匯入仍須驗證舊資料來源的解析。任務若明確修改舊執行層行為，才重新納入相關執行測試。

這條政策留在 consumer 自己的 AGENTS.md，而且明文禁止把它寫進上游管理的 Skill 目錄。若直接修改共用 verification Skill，下次同步會面臨兩難：覆蓋後丟失產品政策，保留後又形成一份中央無法管理的分支。

平台的比對、同步、驗證工具可固定機械步驟；完整 lifecycle 已在 Day 9 說明。此處只保留權限界線：工具能處理快照，不代表它能決定產品政策是否過期，更不能自行批准 consumer 升級。本輪只讀實作，未執行同步，也未把無法解析的來源標記視為驗證通過。

Centralization 也會製造新的風險

共用規則出錯，可能影響所有採用該版本的專案；但本輪沒有完整的跨專案採用清單，不能從範例資料夾名稱推算使用規模。

現有證據只足以展示一個真實 consumer 如何保持可獨立 clone 的快照，以及中央如何提供升級工具。還沒有量到平台省了多少維護時間，也不能把「有平台」當成效率成果。

實務上，新增共用層前可以先留下一張責任表：哪個問題已在不同任務反覆出現、哪些內容必須一致、哪些內容必須留在產品內。若只有一個短任務，或規則仍高度依賴業務，本地文件往往更直接。

參考資料

• OpenAI｜GPT‑6 系列模型指南（2026-10-02；Skills / repository instructions）

下一篇會處理另一種容易過早固定的東西：與其把工作綁在模型名字上，先把規劃、執行與評估各自該交付什麼說清楚。