設計原則
1. 原生能力優先
如果平台本身已經支援平行 Agent、worktree、Skills、權限或 Subagent，就先使用這些能力，再考慮增加新的抽象層。
任何新元件，都應該先回答：
它是否解決了現有 Runtime 無法可靠處理的問題？
如果沒有，就不應新增。
2. 複雜度必須由需求證明
這套架構刻意依照以下順序演進：
平台原生 Runtime
↓
共享工作區
↓
明確協調
↓
薄型 Broker
不要只因為「完整的分散式系統看起來比較像正式架構」，就直接跳到最複雜的階段。
只有出現明確需求時才增加元件，例如：
- 即時狀態；
- 可持久保存的失敗重試；
- Task lease（任務租約）；
- Heartbeat / Liveness（心跳／存活確認）；
- 跨主機排程；
- 共享工作區無法提供的失敗復原。
3. 依能力分工
不同 Runtime 不應預設都執行同一項工作。
任務分配應考慮：
- 工具是否可用；
- 是否能存取 Repository；
- 瀏覽器／Google 整合能力；
- 推理需求；
- 隱私分類；
- 預期成本與延遲；
- 是否需要獨立審查者。
目標不是：
「使用更多模型。」
而是：
「使用能完成任務的最低充分能力。」
4. 有限度委派
Runtime 內部使用多少 Subagent，是平台自己的事情。
跨 Runtime 再委派，則是架構層需要控制的事情。
收到工作的一方可以在內部展開更多 Agent，但跨 Runtime 委派應有：
- 明確 hop limit（轉交層數限制）；
- 明確的結果回傳路徑。
這讓成本、失敗位置與責任更容易判斷。
5. 共用方法，薄轉接層
可攜式知識應該放在可重複使用的 Skills 或共用指令中。
平台差異則放進小型 adapter（轉接層）。
避免：
- 把同一份 Skill 複製到多個互不相容的目錄；
- 把目前使用的模型名稱寫死在共用 Policy（政策）裡；
- 把某一個平台的私人設定，誤當成事實上的公開標準。
6. 多讀者、受控的寫入責任
平行分析通常便宜；互相衝突的寫入通常昂貴。
因此這套架構鼓勵：
- 多個 Agent 同時閱讀；
- 獨立審查；
- 以 Branch / worktree 隔離平行修改；
- 同一組衝突 write-set（會互相覆蓋的修改範圍）只有一個主要寫入負責人；
- 明確的 Merge / Finalization（合併／定稿）責任。
這不是分散式鎖的實作。
目前 Git 模式裡：
- 寫入責任是一項協作政策；
- Branch / worktree 負責隔離不同修改；
- Git 提供 optimistic concurrency（樂觀式併發控制）；
- PR / Review / Merge 是最後整合關卡。
只有未來 multi-host（多主機）真的需要更強的分散式寫入權管理時，才考慮由 Broker 提供 lease（租約）。
7. 隱私是路由條件
資料的隱私分類應直接影響任務可以在哪裡執行。
本地模型可以協助辨識組織內特有的敏感概念，但 LLM 不應成為唯一決定「資料可不可以離開本機」的機制。
仍然需要：
- Deterministic policy（確定性政策）；
- Secret detection（祕密／金鑰偵測）；
- Data classification（資料分類）；
- Local-only rules（僅限本地規則）。
8. 驗證比「全自動」宣稱重要
比起追求「fully autonomous（完全自主）」，本專案更偏好 low-friction（降低不必要操作摩擦）。
好的系統應該減少沒有價值的人工批准，同時保留清楚的 Gate（關卡），特別是：
- 破壞性操作；
- 對外發布；
- Credentials / Secrets（憑證／祕密）；
- 不可逆修改；
- 正式環境資料；
- 資安敏感動作。
9. Roadmap 不等於已完成
所有公開能力都應明確標示：
- Implemented（已實作）
- Partial（部分完成）
- Planned（已規劃）
- Exploratory（探索中）
架構圖可以顯示未來方向，但狀態表一定要把現在與未來分開。
10. 沒有產品級證據，就不要做產品級宣稱
在沒有相應的：
- 實作；
- Threat modeling（威脅模型）；
- Tests（測試）；
- 實際運作證據；
之前，不應把這個專案描述成：
- 企業級平台；
- 安全閘道；
- Zero-trust（零信任）解決方案；
- 完全自主的作業系統；
- Production-ready（可直接用於正式環境）；
- Seamless（無縫、毫無摩擦）。
這個專案最有價值的定位，是維持為：
務實的參考架構與實際案例。