當你的團隊裡有多個 AI 助手同時工作時,怎麼確保它們不會互相踩線?

一個負責寫代碼的 Claude 正在修改 main.py,同時另一個負責審計的 Codex 想要讀取同一個檔案。如果沒有好的協調機制,輕則工作互相覆蓋,重則重要資料被誤刪。這就是多 Agent 系統面臨的核心挑戰。

Google 最近開源了 Scion,一個專門為解決這個問題而生的實驗性 Agent 編排平台。根據 InfoQ 報導,Scion 被稱為「agents 的 hypervisor」,它能夠管理多個並發 Agent 在容器中運行,無論是在本機、遠端 VM 還是 Kubernetes 叢集上。

什麼是 Scion?

Scion 是一個實驗性的編排測試平台,讓開發者能夠運行一組專門化的 Agent,每個 Agent 都有獨立的身分認證、憑證和共享工作空間。簡單說,它就是一個「Agent 作業系統」,負責協調多個 AI 助手如何分工合作。

Google 把 Scion 稱為「agents 的 hypervisor」。虛擬機的 hypervisor 管理的是虛擬機的生命週期和資源分配,而 Scion 管理的是 AI Agent 的生命週期和任務協調。這個比喻很傳神 —— 它不是在限制 Agent 做什麼,而是為 Agent 創造安全的運作環境。

Scion 的核心設計哲學

Scion 有一個重要的設計原則:偏好隔離而非限制(isolation over constraints)。

傳統的 Agent 安全做法是定義各種規則,把這些規則嵌入 Agent 的語境中,試圖從內部限制 Agent 的行為。這種做法有明顯的問題:規則越多,靈活性越低;而且 Agent 很有可能找到繞過規則的方法。

Scion 走了另一條路:讓 Agent 在自己的容器裡隨意發揮去做它們需要做的事,但在外部設置邊界和防護網。Google 甚至建議讓 Agent 在「–yolo 模式」下運行,意思是 Agent 可以不受約束地工作,但被隔離在容器、git worktree 和有網路政策的節點上。

這種思路就像給每個 Agent 一個沙盒。它們在裡面怎麼跳都可以,但出不來。

Scion 的技術細節

Agent 隔離機制

每個 Scion 管理的 Agent 都會得到自己的容器、git worktree 和憑證。這意味著:

容器隔離的深入理解

在傳統的單 Agent 應用中,如果你的 AI 工具被攻擊或出現錯誤,它可能刪除專案檔案、修改系統配置、訪問不該訪問的資源。

但在 Scion 中,Agent 被限制在容器裡。即使它被攻擊或失控,最壞的情況也只是那個容器被影響,其他 Agent 和你的主系統是安全的。

這種隔離是在多個層次上實現的:檔案系統層次(每個容器有自己的根檔案系統)、網路層次(每個容器有自己的網路命名空間,可以配置規則控制通訊)、進程層次(容器內的進程在容器外不可見)。

Git Worktree 的實際應用

Git worktree 允許同一個倉庫有多個獨立的工作目錄。在 Scion 中,這意味著 Agent A 可以在 worktree-A/ 修改代碼,Agent B 可以在 worktree-B/ 修改代碼,它們都在同一個 git 倉庫上工作,但各自有自己的副本。

當 Agent A 完成任務,它可以在自己的 worktree 中提交或創建 PR。Agent B 不會看到 Agent A 未提交的修改,除非 Agent A 明確發起了 PR 或合併請求。這對於多 Agent 協作來說非常關鍵,避免了「一個 Agent 正在寫文件,另一個 Agent 也試圖寫同一個文件」這類衝突。

支援的 Agent 類型

Scion 通過「harness」支援多個熱門的 Agent。Harness 是一個介面層,負責管理 Agent 的生命週期、認證和配置。

根據 Google 的文件,目前支援的 Agent 包括:
– Gemini
– Claude Code
– OpenCode(部分支援)
– Codex(部分支援)

Google 提供了一個功能支援矩陣,詳細列出了每個 harness 支援哪些特性。開發者可以根據自己的需求選擇合適的 Agent。

容器化執行時期

Scion 支援多種容器化執行時期,包括:
– Docker
– Podman
– Apple containers
– Kubernetes(透過 named profiles)

這給了開發者很大的靈活性。如果你的團隊已經在用 Docker,可以直接繼續;如果你用 Kubernetes,Scion 也能整合進去。

容器技術簡介

容器技術(比如 Docker)是一種輕量級的虛擬化技術。與傳統虛擬機不同,容器共享宿主機的內核,但隔離了進程、檔案系統和網路。這帶來的好處是:啟動快速(秒級)、資源效率高、環境一致。

對於 Scion 來說,容器的快速啟動特別重要。如果系統需要動態創建和銷毀 Agent,容器能夠快速響應這些需求。

Kubernetes 整合

Kubernetes(簡稱 K8s)是一個容器編排平台,能夠管理多個容器節點,自動調度容器到合適的節點上,處理容器的擴縮容、故障恢復等。

Scion 支援 Kubernetes 這一點意味著你可以在多台機器上運行 Scion,系統可以自動平衡負載,如果某個節點出現問題,容器可以遷移到其他節點。

這對於需要大量算力的多 Agent 系統來說非常重要。如果你的任務需要很多 Agent 同時工作,Kubernetes 能夠自動地把它們分發到不同的機器上。對於中小團隊來說,一開始可能只需要在本機或幾台機器上運行 Docker,但當任務規模擴大,你可以平滑地遷移到 Kubernetes,而不需要重新設計你的整個系統。

Scion 的獨特術語

Scion 引入了一些新的術語來描述它的概念:

這些術語乍看有點抽象,但熟悉之後會發現它們都很貼切。Grove 就像樹林,裡面有多棵樹(agents);Hub 是樹林的中樞;Runtime broker 是樹林所在的土地。

一個具體案例:Relics of the Athenaeum

為了展示 Scion 的能力,Google 發布了一個遊戲的程式碼庫:Relics of the Athenaeum

這個遊戲展示了多個 Agent 如何協作解決計算謎題。不同 Agent 運行在不同的 harness 上,扮演不同的角色。一個遊戲運行器負責生成新角色/Agent,這些 Agent 又會動態生成 worker Agent 和專門化 Agent。

讓我們更深入地理解這個遊戲的機制:

遊戲的架構

Relics of the Athenaeum 不是單一程式,而是一個由多個 Agent 組成的系統。遊戲的核心在於「角色扮演」——每個 Agent 都有自己的人格和專業能力。

遊戲運行器是整個系統的「導演」,負責創建新的角色 Agent、分配角色、控制遊戲進度、協調不同 Agent 之間的交互。角色 Agent 是「演員」,有獨特的語氣和風格、自己的專長和知識範圍,能夠主動提供建議和解答。Worker Agent 和專門化 Agent 是「配角」,負責特定的計算任務、資料處理或特定操作。

協作的具體機制

在 Relics of the Athenaeum 中,協作是一個動態的、基於情境的過程。

共享工作空間是核心。這是一個所有 Agent 都能存取的存儲區域,裡面存放著遊戲的當前狀態、已發現的線索、待解決的謎題,以及每個 Agent 的觀察和推論。這就像是一個「共同記憶」,所有 Agent 都可以向其中寫入資料,也可以從中讀取資料。

直接訊息讓 Agent 之間能夠精確地溝通。比如「偵探」角色 Agent 可以直接問「技術專家」Agent 某個設備的技術細節,「學者」角色 Agent 可以分享歷史線索給其他 Agent。

全員廣播則用於重要信息。當某個 Agent 發現了關鍵線索,它可以廣播給所有 Agent。

為什麼這個案例很重要

Relics of the Athenaeum 的價值不在於遊戲本身,而在於它展示了一個完整的、可運行的多 Agent 系統。

很多關於多 Agent 的討論都停留在概念層面,但這個遊戲是實實在在的代碼。你可以:
– 直接運行遊戲,看到 Agent 如何工作
– 觀察它們如何協作解決謎題
– 研究代碼,學習如何設計類似的系統

更重要的是,這個案例展示了 Scion 的幾個核心能力:
動態創建 Agent:遊戲運行器可以在執行時創建新的 Agent
不同 Harness 的整合:不同的 Agent 可以運行在不同的底層系統上
複雜的協作模式:不只是簡單的任務分配,而是基於情境的協作

這些能力正是未來 AI 應用所需要的。

Scion 的任務圖管理

Scion 讓開發者管理一個動態演變的任務圖。這些任務並行執行,追求不同的目標,比如編寫代碼、審計和測試。

與其依賴一組固定的 Agent,Scion 支援不同的 Agent 生命週期:
專門化且長命的 Agent:長期存在,專注於某個領域,比如一個永遠負責代碼審查的 Agent
短暫且綁定單一任務的 Agent:為特定任務而生,任務完成就銷毀,比如為某個 bug 排查生成的臨時 Agent

這種靈活性讓系統能夠根據實際需求動態調整 Agent 的數量和類型。

Scion 的局限性和注意事項

作為一個實驗性專案,Scion 有一些需要注意的地方:

支援度不完整

根據 Google 的文件,OpenCode 和 Codex 的支援目前是部分的。功能支援矩陣顯示,某些 harness 可能不支援所有特性。

學習曲線

Scion 引入了很多新概念和術語,初學者需要花時間熟悉。Grove、Hub、Runtime broker 這些詞需要理解它們的含義和關係。

實驗性質

Google 明確將 Scion 標記為「實驗性」(experimental)。這意味著 API 可能會變更,功能可能不穩定,不建議直接用於生產環境。

開發者應該如何使用 Scion?

開始之前

在使用 Scion 之前,開發者應該:
1. 熟悉 Docker 或 Kubernetes
2. 了解至少一個支援的 Agent(比如 Claude Code 或 Gemini)
3. 理解 Scion 的術語和概念

基本使用流程

根據 Google 的文件,基本使用流程包括:
1. 定義一個 Grove(專案)
2. 配置 Hub(控制平面)
3. 選擇 Runtime broker(運行環境)
4. 編寫任務定義(任務圖)
5. 選擇合適的 harness 和 Agent
6. 啟動系統並監控執行

最佳實踐

從 Scion 的設計哲學出發,建議:
– 優先使用容器隔離,不要依賴 Agent 內部限制
– 根據任務需求選擇合適的 Agent 生命週期
– 利用共享工作空間和訊息機制來協調 Agent
– 監控 Agent 的執行狀態和資源使用

Scion 對 AI 發展的意義

Scion 的開源反映了一個重要趨勢:AI 正在從單一工具走向協作系統。

過去,AI 主要被當作獨立的工具 —— 你打開 ChatGPT,問一個問題,得到一個答案。但未來的 AI 應用更可能是多個專門化 AI 互相協作,共同完成複雜任務。

Scion 提供了一個框架,讓這種協作變得可能。它解決的技術挑戰包括:
– 如何隔離多個 AI 的運作環境
– 如何協調它們的工作流程
– 如何在它們之間傳遞資料和狀態
– 如何管理它們的生命週期

這些都是未來 AI 系統的核心需求。

對開發者的實際價值

對於開發者來說,Scion 解決了一個真實的痛點:如何讓多個 AI 工具協作而不互相干擾。

想像一個場景:你在開發一個大型專案,希望:
– 一個 AI 負責寫新功能的代碼
– 另一個 AI 負責做安全審計
– 第三個 AI 負責寫測試
– 還有一個 AI 負責生成文件

如果沒有像 Scion 這樣的工具,你只能手動協調它們的工作,或者忍受它們可能互相覆蓋檔案的風險。Scion 讓這種多 Agent 工作流自動化且安全。

如何開始嘗試 Scion

如果你想嘗試 Scion,可以:
1. 訪問 Scion 的 GitHub 專案:https://github.com/GoogleCloudPlatform/scion
2. 閱讀官方文件,了解概念和安裝步驟
3. 運行官方提供的範例,比如 Relics of the Athenaeum 遊戲
4. 嘗試在自己的專案中定義簡單的多 Agent 工作流

記住,這是實驗性專案,不建議直接用於生產環境。但對於探索多 Agent 系統的開發者來說,這是一個很好的學習資源。

具體行動步驟

如果你對 Scion 感興趣,可以按以下步驟開始探索:

1. 前置準備
– 確保你已經安裝 Docker 或 Kubernetes
– 選擇一個你想用的 Agent(建議從 Claude Code 或 Gemini 開始)
– 確保你的機器有足夠的資源來運行多個容器

2. 安裝 Scion

git clone https://github.com/GoogleCloudPlatform/scion.git
cd scion
# 閱讀 README 中的安裝說明

3. 運行範例專案

# 嘗試運行 Relics of the Athenaeum
git clone https://github.com/ptone/scion-athenaeum.git
cd scion-athenaeum
# 閱讀專案的 README 並運行

4. 觀察並學習
– 注意觀察 Agent 是如何隔離的
– 理解它們之間如何協作
– 分析任務圖是如何定義和執行的

5. 嘗試自己的工作流
– 定義一個簡單的 Grove
– 配置至少兩個 Agent
– 讓它們協作完成一個簡單任務

6. 記錄你的發現
– 記錄哪些地方好用,哪些地方不夠直觀
– 思考你自己的專案是否需要多 Agent 協作
– 如果你找到有趣的用例,可以回饋給 Scion 社群

總結

Scion 是一個有趣的實驗,它把 AI 的應用從單一工具推進到多 Agent 協作系統。雖然目前還是實驗性質,但它解決的問題是未來 AI 應用的核心挑戰。

對於開發者來說,Scion 提供了一個框架來思考和管理多 AI 助手的協作。如果你在思考如何讓多個 AI 工具一起工作,Scion 值得你花時間探索。

未來的 AI 不再只是你問它答的工具,而是能夠自主協作、共同解決問題的智能系統。Scion 是朝這個方向邁出的一步。