1. 這個專案是什麼？
你可以把它理解成一份「多個 AI 工作環境怎麼分工合作」的設計。這裡的 Agent（AI 代理），指的是能接收任務、使用工具、執行工作並回報結果的 AI 執行單位。
這不是新的 Agent 開發框架，也不是可以一鍵安裝的完整軟體套件。它目前最有價值的部分，是整理出一套可以實際運作、而且不過度複雜的合作方式。
2. 為什麼不直接再裝一個多 Agent 框架？
因為 Codex 與 Antigravity 本身就已經有各自的多 Agent、工具、權限與工作流程。如果只是為了讓它們互相合作，就再加一套新的大型中央調度系統，可能會增加設定、更新、除錯與維護成本。
先用原生能力
平台已經會做的事，不再重做一次。
依能力分工
不要每個 AI 都做同一件事，而是交給最適合的執行環境。
複雜度逐步增加
簡單合作先用現有工具；真正有需要才升級成更完整的協調機制。
3. 一個平台，不等於一個 Agent
這是整套架構最重要的觀念之一。Codex 或 Antigravity 本身都可以是一個完整的 Runtime（Agent 執行環境），裡面再包含主 Agent、專門工作者與平台原生的平行 Agent。
Codex 執行環境
- 主要協調角色
- 快速工作者／深度工作者
- Codex 原生平行 Agent
- 程式庫、測試、工作區操作
Antigravity 執行環境
- 主要 Agent
- 自訂角色 Agent
- 平台原生 Subagent（子 Agent）
- 瀏覽器與 Google 生態整合
本地模型執行環境
- 本機 AI 模型，例如 Qwen
- 私密資料或離線工作
- 未來可協助敏感內容分類
- 網路受限環境中的例行任務
4. 這些 Agent 怎麼合作？
平行處理
Codex 或 Antigravity 可以直接使用自己原生的多 Agent 功能，把工作拆開同時處理。
上下分工
主要協調者把工作交給不同角色，例如快速工作者或深度工作者。公開架構不要求使用特定角色名稱。
有限度委派
Codex 可以把適合的工作交給 Antigravity，反之亦然。但不允許平台之間一直「你丟給我、我再丟給別人、最後又繞回來」。
避免同時改壞同一份東西
多個 Agent 可以同時閱讀、分析、審查；真正要修改程式碼時，利用 Git 的 branch（分支）或 worktree（獨立工作區）隔離修改，最後再經過 review（審查）與 merge（合併）。
被委派的平台仍然可以使用自己的內部 Agent；限制的是「跨平台一直遞迴轉交」。
5. 跨 Runtime 的工作怎麼流動？
跨平台合作不只是「AI A 呼叫 AI B」。這套設計把通訊、交接格式、持久狀態與失控防護拆成不同責任，讓每一層都保持簡單。
限制的是外部轉交，不是平台內部分工
接收 Runtime 可以使用自己的 Subagent，但不應自動把同一任務再丟回另一個外部 Runtime。
Codex → Antigravity → Antigravity 內部 Subagents
Antigravity → Codex → Codex 內部 Agents
Codex → Antigravity → Codex → Antigravity → …
需要再次跨 Runtime 時，必須產生新的明確路由決策，而不是自動往外繼續轉交。
MCP Bridge
傳輸層：怎麼叫到另一個 Runtime。
Task / Result Packet
協作契約：交辦與回報應該包含什麼。
Shared Workspace
持久狀態：證據、文件、PR 與結果放在哪裡。
One-Hop Guard
失敗隔離：避免遞迴委派、Token 倍增與責任不清。
6. 為什麼要依能力分工？
不同平台的工具、權限與強項不同，因此沒有必要讓所有 AI 都重複做同一份工作。
Codex
程式碼、程式庫、測試、重構與工程執行。
Antigravity
瀏覽器、Google 生態與它原生整合較強的工作。
本地模型
不能離開本機的工作、離線處理、私密內容初步分析。
其他獨立 Agent
重要結果需要第二意見時，用不同模型或執行環境交叉審查。
這些是目前架構中的分工原則，不代表永遠固定綁定某一個平台。
7. 私密資料要怎麼處理？
這是未來規劃中的重要擴展方向。核心不是「所有資料都送到雲端」，而是先在本地判斷資料風險，再決定是否可以離開本機。
例如公開文件、公開程式碼、一般研究資料。可以直接交給雲端 AI。
先刪除不必要資訊、遮掉可識別內容，再依規則決定是否送出。
把真實名稱換成代號，只保留完成任務需要的內容；結果回到本機後再還原。
密碼、金鑰、禁止外傳內容或高度機密資料，維持本地處理，不送雲端。
技術文件中會把這種可還原的代號替換稱為 pseudonymization（假名化）。一般敏感資訊辨識可優先採用成熟工具，例如 Presidio；本地模型只作為額外的語意判斷來源，不應單獨決定資料是否允許外傳。
8. 跨平台、跨電腦，要不要一開始就做很複雜？
不需要。這個專案刻意採用「需求出現，再升級」的方式。
共享工作區
先用 GitHub、Google Drive 傳遞任務、文件、結果與審查資料。
明確的 Agent 溝通
真的需要跨執行環境直接傳遞任務時，再使用 MCP Bridge（MCP 橋接）或評估 A2A（Agent 對 Agent 通訊協定）。
分散式協調
只有大量跨主機任務真的需要排隊、租約、心跳、失敗重試時，才考慮很薄的 Broker（任務仲介服務）。
9. 目前實際做到哪裡？
這裡刻意把「已做完」與「未來方向」分開。
| 項目 | 白話說明 | 狀態 |
|---|---|---|
| Codex ↔ Antigravity 基本橋接 | 兩個執行環境可以進行基本任務／結果交換，核心只讀測試已通過。 | 已實作 |
| Task / Result Packet（任務／結果格式） | 用固定結構描述「要做什麼、限制是什麼、結果如何回報」。 | 已實作 |
| One-Hop Guard（單次跨平台轉交） | 限制跨平台遞迴轉交；接收端仍可使用平台內部 Agent 分工。 | 已實作 |
| 共享工作區 | GitHub / Drive 保存任務、結果、文件、PR 與審查紀錄。 | 已使用 |
| 唯讀雙方審查／辯論 | 重要決策可先讓不同 Agent 提出意見與反駁，再由單一執行者修改。 | 已實作 |
| 平台原生平行 Agent | 直接使用 Codex 與 Antigravity 自己的平行 Agent 功能，不另外重做。 | 原生能力 |
| Shared Skills（共用技能） | 方向已建立，但目前仍有同名 Skill 內容漂移需要重新確認唯一來源。 | 部分完成 |
| 本地模型隱私分流 | 讓本地模型處理私密／離線任務，並協助未來的敏感資料分類。 | 規劃中 |
| 跨電腦 Agent 協作 | 未來把同樣的分工延伸到多台電腦或本地 GPU 主機。 | 探索中 |
| Broker（任務仲介）／租約／心跳／失敗重試 | 只有規模真的需要時才考慮，不是目前必要元件。 | 探索中 |
10. 未來可以怎麼擴展？
未來的方向不是「加入更多工具」，而是看現有架構什麼時候真的遇到能力缺口。
先把現有雙平台整合收乾淨
Shared Skills 的唯一來源與同步差異重新驗證，避免把已知缺口包裝成完成。
再驗證本地隱私分流
先做很小的概念驗證：辨識、最小化、代號替換、雲端處理、本地還原與外洩檢查。
真的需要時再擴展到跨主機
優先評估現有標準與橋接方法，不自行發明另一套 Agent 通訊協定。
只有規模證明需要，才加入 Broker
排隊、租約、心跳、重試與分散式狀態都屬於後期需求，不預先建立。
11. 這個專案刻意不做什麼？
不重做平台已有功能
Codex、Antigravity 已經有的多 Agent 能力，直接使用。
不先建大型中央系統
沒有實際需求前，不額外導入資料庫、訊息佇列、向量資料庫或新的大型 Gateway（閘道服務）。
不宣稱全自動
高風險操作、公開發布、刪除與敏感資料仍需要清楚的權限與審查邊界。
不宣稱零風險隱私
本地去敏與假名化是降低暴露的方法，不是企業合規或絕對安全保證。
想看更完整的技術內容？
這一頁只負責把整體概念講清楚。以下四個閱讀頁面都以繁體中文說明；必要的產品名稱與技術名詞保留英文名稱方便對照。