你最好的 reviewer 是一個 Claude agent。你最快的草稿手是 Codex。你最便宜的摘要員跑在 Gemini 上。 今天它們各自活在三個 terminal 裡，共用一台筆電，彼此之間的交接全靠你。這篇文章要回答的問題是： 你要的是一個能呼叫很多模型的超強 agent，還是一個讓很多不同的 agent 一起工作的平台？
Kilo 是前者，Containarium 是後者。兩個答案都很好，只是回答的是不同的問題。
Kilo（仍常被叫做 Kilo Code）是一個 MIT 授權的開源 coding agent。它可以當作 VS Code 擴充套件、JetBrains 外掛、CLI， 或是你從瀏覽器啟動的託管 Cloud Agent 來使用。它的 CLI 是 OpenCode 的 fork。它非常擅長大多數開發者真正的工作型態： 一個人、一個 repo、一個在編輯器裡的 agent。
如果這就是你的工作方式，Kilo 是很好的選擇，你甚至可能不需要我們。若你的工作方式開始從「我的 agent」變成「我們的 agents」，請繼續讀下去。
Kilo 的多 agent 功能，是很多個 Kilo agent。它們可以呼叫不同的模型，但共用的是 Kilo 的 harness、工具與設定。 Kilo 的文件說明，Agent Manager 的 session 使用的是和側邊欄相同的登入、供應商設定、BYOK key、MCP server 與權限規則。 worktree 分開的是檔案和 git branch，而不是機器。在 Kilo 的 Cloud Agent 上，每位使用者擁有一個獨立的 Linux 容器，他所有的對話都共用這個容器。
Containarium 從另一端出發。基本單位不是對話 session，而是一個 box： 一個真實、持久的 Linux 環境（LXC 容器或 Kubernetes pod），跑在你自己擁有的基礎設施上，或我們的託管雲端。每個 agent 有自己的 box， 而 box 裡面的 agent 可以是不同的 runtime：
containarium code run 會在 box 裡以 detached run 的方式啟動 Claude Code、OpenAI 的 Codex CLI 或 pi。即使你的筆電斷線，run 仍會繼續，之後你可以從離開的那個位元組重新接上。claude（Claude Agent SDK）、codex（Codex SDK）或 gemini（Google Gen AI SDK）。執行時，你可以針對每個成員覆寫 engine 與模型。所以定位很簡單。Kilo 讓一個很強的 agent 存取很多模型。Containarium 讓很多不同的 agent，帶著不同的模型、runtime 與 skill，各自在自己的 box 裡，共同完成一件工作。
| 面向 | Kilo | Containarium |
|---|---|---|
| 基本工作單位 | 在編輯器、terminal 或瀏覽器中的 agent session | 一個 box（Linux 環境），加上在 box 裡執行的 skill、crew 與 task graph |
| Agent 與模型 | 一個 runtime（Kilo）；500+ 模型；subagent，以及最多 4 個用不同模型的平行版本 | 多個 runtime：box 裡的 Claude Code、Codex CLI 與 pi；skill 使用 claude、codex、gemini engine，可逐成員選擇 |
| 隔離 | 每個本機 session 一個 git worktree；Cloud Agent 每位使用者一個容器，由該使用者的對話共用 | 每個 agent 一個 box；task graph 的每個節點取得全新的 box；每個 box 有自己的網路政策 |
| 持久性 | 本機 worktree 會保留；Cloud Agent 容器是暫時的，beta 期間閒置 session 7 天後刪除 | box 跨 session 保留；skill 的 box 在多次執行間重複使用 |
| 治理與租戶 | 組織設定檔、管理員管控的設定、綁定沙盒的憑證替身 | 每個 skill 的 scoped token、強制執行的 allowed_peers、每次 run 一條 audit trace、多租戶控制平面 |
| 介面 | VS Code、JetBrains、CLI、網頁、Slack | CLI、平台 MCP server、REST/gRPC API，以及每個 box 內建的 MCP server |
| 授權 | MIT | Apache 2.0（開源）；託管雲端為選用 |
Kilo 的細節已於 2026 年 11 月對照 kilo.ai、其文件與 github.com/Kilo-Org/kilocode 查核。產品會變，決定前請查閱最新文件。
假設你希望在任何人動程式碼之前，從兩個角度審查一個變更。在你自己的 catalog 裡定義兩個 skill：一個用 Codex，一個用 Claude。 Containarium 會在啟動時從一個目錄載入外部 catalog，所以不需要重新建置任何東西。
# skills/reviewers.yaml (從 CONTAINARIUM_SKILLS_DIR 載入)
skills:
- id: security-review
name: Security Review
description: Reviews a change for security issues.
recipe_id: agent-runtime
system_prompt: You review code for security issues. Return JSON findings.
allowed_scopes:
- containers:read
allowed_peers: []
engine: codex
- id: api-review
name: API Review
description: Reviews a change for API compatibility.
recipe_id: agent-runtime
system_prompt: You review code for breaking API changes. Return JSON findings.
allowed_scopes:
- containers:read
allowed_peers: []
engine: claude
接著寫一個 task graph。兩個 review 之間沒有邊，所以同時執行，各自跑在全新的 box 裡。第三個節點等待兩者完成。
它使用內建的 diff-crew，
這是一個兩成員的 pipeline：一個 agent 草擬變更，第二個 agent 在同一個 commit 的獨立 checkout 上定稿。
# plan.yaml
goal: Review the change from two angles, then draft the fix
nodes:
- id: security
goal: Find security issues in the change
skill_id: security-review
- id: api
goal: Find breaking API changes
skill_id: api-review
- id: fix
goal: Address both sets of findings
crew_id: diff-crew
edges:
- { node_id: fix, depends_on: security }
- { node_id: fix, depends_on: api }
containarium crew run freeform-crew --plan plan.yaml --concurrency 5 \ --git-source https://github.com/<org>/<repo> --git-ref <commit-sha> \ --server <host>
daemon 會在建立任何 box 之前驗證整張 graph。每個成員都把同一個釘住的 commit checkout 到自己的 workspace， 所以它們透過 git 共享程式碼，而不是共用檔案系統。每個下游節點會收到它依賴節點的輸出（JSON）。 如果其中一個 review 失敗，fix 會被擋住，但另一個 review 仍會完成，最終狀態會保留每個節點的結果。
對於 issue 到 PR 的情境，有現成的 pipeline：engineer-crew
依序執行 implementer、reviewer 與 test runner。test runner 在它自己的 box 裡執行 repo 的測試並產生 proof pack，
而平台會拒絕 proof 來自 coder 自己 box 的 crew。在 Containarium Cloud 上，engineer crew 可以從已連接 repo 的 GitHub issue 啟動，並開一個 pull request。
當一個人只跑一個 agent 時，這個人就是安全邊界。當 agent 把工作交給其他 agent 時，就必須由別的東西擔任邊界。 Containarium 的答案是：邊界屬於平台，而不是 prompt。
containarium crew logs 追蹤。Kilo 在這方面也解決了一部分：它的 Cloud Agent 讓真實的 token 不進入沙盒。差別在於範圍。 Kilo 保護的是一位使用者的 agent session；Containarium 則是在同一個控制平面上，跨租戶治理一群不同的 agent。
混合 engine 的 crew 還很新。每個 skill 的 engine 路由已實作並有單元測試， 開源 catalog 也附上一個參考用的雙 engine crew（Claude 成員交給 Codex 成員）。會對兩家供應商實際執行它的 CI lane 已接好，但還沒有跑過。 Gemini 的結構化輸出目前只靠 prompt。
平行性存在於 task graph 裡。一般的 pipeline 會依序執行成員。 沒有 plan 的 orchestrator 或自由協作 crew，會把任務交給入口 agent。要讓獨立的工作同時進行，請如上所示給 crew 一張 task graph。
雲端與自架不同。task graph 的路徑在開源 daemon 裡。Containarium Cloud 的 catalog 目前列出 diff crew 與 engineer crew 這兩個參考 crew。 engineer crew 需要 Pro 方案，而雙 engine 的參考 crew 目前還不在 Cloud catalog 裡。
它不是編輯器。Containarium 沒有編輯器內的自動完成，也沒有 IDE 面板。 你的 agent 跑在 box 裡；你透過 CLI、MCP client 或 API 來驅動它們。
共用核心。box 是容器，不是 microVM。對於真正具有敵意的程式碼，這是較弱的邊界，我們在 另一篇文章（英文）中有說明。
↳ 一個開發者、一個 repo，在 IDE 裡用任意模型的 agent？Kilo。
↳ 同一任務的幾次平行嘗試，並排比較？Kilo 的 Agent Manager 在你自己的機器上做得很好。
↳ Claude、Codex 與 Gemini 的 agent 共同完成一件工作，各自有獨立的環境與憑證？Containarium。
↳ agent 要保有持久的 box、能 detached 執行，並跑在你自己擁有的基礎設施上？Containarium。
↳ 兩者都要？它們並不互斥。Kilo 支援 MCP server，而每個 Containarium box 都會提供一個 MCP server。
一套 Agent 真的會遵守的軟體品質管理流程，加上每個 Agent 一台獨立的 Linux box。
金鑰被撈走時，爆炸半徑有多大，以及加密邊界要怎麼設計。
「不可信」意味著三件事。對大多數團隊來說，真正的限制是 egress，而不是逃逸。