【2026 最新】Proliferate 教學：Claude Code、Codex、OpenCode 的可審查 Worktree 流程

你同時把登入 bug 丟給 Claude Code、文件修正丟給 Codex、測試補強丟給 OpenCode，三個視窗看起來都很忙；半小時後卻發現兩個 Agent 改到同一個檔案，另一個早已把 branch 推上遠端。這篇 Proliferate 教學要解的不是「怎麼多開幾個 AI」，而是怎麼讓每個任務有獨立 Worktree、可讀 diff、測試收據與明確的人類核准點。

本文適合已會基本 Git、第一次管理多個 Coding Agent 的讀者。你會從一個可隨時丟棄的小型 bug fix 開始，核對 Claude Code、Codex、OpenCode 的登入環境，再安全地增加兩個不重疊任務。流程依截至 2026 年 8 月 27 日的 Proliferate 官方 Quickstart、產品文件與原始碼整理；不把官方示範寫成 AlphaLab 本機實測。

Proliferate 教學先說結論：一任務一 Worktree，仍要兩道核准

• 先從一個小任務開始：限定檔案、禁止遠端寫入、寫清楚驗收指令；第一回合不要同時開三個 Agent。
• Worktree 只隔離工作目錄與 branch：它不是安全沙箱；同一台電腦的憑證、程序、連接埠與網路權限仍可能互相影響。
• 第一道核准管執行：Agent 跑 shell、MCP、連接器或網路命令時就可能產生外部副作用，不能等到 Publish 才開始防守。
• 第二道核准管 Git 發佈：在 Changes 檢查 diff、測試與 commit，再由人決定是否 Publish branch／PR。

可審查的多 Agent 工作流＝一任務一 Worktree＋原生權限核對＋Diff／測試收據＋人類 Publish。

把它想成四道相乘的門：任何一道是零，多開 Agent 只會更快放大混亂。本文另外把風險整理成「執行權限核對」與「Publish 前 Git 審查」兩個人類核對點；這是 AlphaLab 的操作模型，不是 Proliferate 官方 gate 名稱。

Proliferate 是什麼？先把 Worktree 當成獨立工作桌

Proliferate 是一個把原生 Coding Agent、任務工作區、Git Worktree、Changes 審查與 Publish 流程放在同一介面的 AI IDE。依 官方架構說明，桌面 client、control plane 與 AnyHarness runtime 各負責介面、協調和啟動 Agent；Claude Code、Codex、OpenCode 仍透過各自的原生 harness 工作。若「harness」還很陌生，可先讀 AI Agent Harness 是什麼。

Proliferate 的 Worktree 文件把界線說得很清楚：不同 Worktree 有自己的目錄、branch 與工作狀態，卻共享 Git 物件與歷史，也通常共享同一個使用者的全域設定、工具鏈、快取、程序、連接埠與憑證。白話說，Worktree 是「不同工作桌」，不是「不同上鎖房間」。

所以它真正減少的是誤改同一份 checkout，不是自動消除權限風險。你若只需要兩個終端與手動 Git，先看 Nodeterm 教學也合理；Proliferate 的增量在於把原生 Agent、工作區、審查與發佈接成一條整合流程。

Proliferate 教學步驟 0：準備一個可以失敗的測試 Repo

不要拿月底 release、資料庫 migration 或整站重構當第一題。選一個可逆、20 至 40 分鐘內能人工檢查的任務，例如「修正一個輸入驗證 bug，並補一個回歸測試」。開始前在原本 checkout 執行：

git status --short
git branch --show-current
git remote -v
# 再執行這個 repo 原本就有的測試指令

git status --short有輸出時先停下來，別讓未歸屬的改動混進新任務；基線測試不通過，也先記錄並修好基線。接著把任務寫成五格合約：目標、允許修改的檔案、禁止事項、驗收指令、交付格式。想看更完整的工作單位設計，可搭配 打造 AI Agent Harness。

步驟 1：安裝桌面版，連接 Repo 並選 New worktree

先從官方 Quickstart 檢查桌面版下載。macOS 依 DMG 流程安裝；截至 2026 年 8 月 27 日，官方 Windows 文件仍把 Windows x64 標為 beta，並說未簽章 installer 可能觸發 SmartScreen。不過本次 現行 updater 清單只獨立驗證到 Apple Silicon macOS 檔案，未驗證 Windows installer 當下可下載；Windows 使用者先確認官方按鈕確實取得安裝檔，再進入後續步驟。

開啟 Proliferate 後連接剛才的本地 repo。建立第一個 workspace 時選 New worktree，確認基準 branch 是你剛檢查過的乾淨 branch；不要選正在修改的主要 checkout。官方的 target picker 如下：

若 repo 需要安裝依賴或啟動開發伺服器，到 Repo Configuration 填入現有的 setup／run command，例如專案本來就使用的 pnpm install與 pnpm dev。官方建議讓 setup script 可重複、無互動；不要把一次性密碼、token 或個人環境變數寫進命令。

步驟 2：驗證原生登入，不要只看 Agent 名稱

Proliferate 官方認證文件提供原生登入、BYOK（自備 API key）與 Proliferate Gateway 等路線，但每個 Agent 可用的組合不同。選到「Claude Code」或「Codex」只代表 harness 名稱正確，不保證它使用你預期的帳號、方案或計費路徑。

先在 Proliferate 外完成各 CLI 的登入，並在同一個 OS 使用者的原生 CLI 端記錄登入方式／provider 狀態：

claude auth status --text
codex login status
opencode auth list

Claude Code與 Codex都可能因 OS 使用者、設定目錄、keyring 或注入的環境憑證而切換身分；OpenCode則有自己的 provider 認證儲存。上面三個指令分別確認 auth status、login method 或已儲存 provider，不一定能證明特定人類帳號與計費身分。接著在 Proliferate 的 Settings → Agents，替 Claude Code／Codex 選明 CLI login、API key 或 Gateway；OpenCode 則核對 Providers 與自己的 CLI login。啟動一個無寫入任務，確認畫面顯示的 provider 與 model，必要時再到供應商帳號頁核對計費路線；不一致就停止。不要打開、截圖或貼出任何 auth 檔。Claude Code 與 Codex 本身怎麼選，可接著讀 Claude Code vs Codex。

步驟 3：只派一個有界 Bug Fix，先守執行權限

把下面模板貼進第一個 workspace，再換成你的真實檔名與測試命令：

目標：修正空白 email 被視為有效輸入的 bug。
允許：src/validation/email.ts、對應 test 檔。
禁止：改依賴、改設定、讀取 secrets、git push、建立 PR、呼叫外部服務。
驗收：既有測試通過；新增空白與只有空格的回歸案例。
交付：列出改動檔案、測試指令、測試結果與仍未處理的邊界。

這段 prompt 是任務合約，不是權限系統。真正的第一道核准，是先替每個 chat 選最保守、仍能完成任務的原生 permission mode；檔案、命令、sandbox 與工具限制仍要分別在 Claude Code、Codex、OpenCode 或 OS／容器層設定，並另行停用不需要的 MCP 與連接器。Proliferate 目前提供的是 per-chat 原生模式，不要把 prompt 的檔案清單誤認成強制 allowlist。遇到要求升級成 Codex Full Access 或 Claude Code Bypass 時，先看清楚原因再決定。Proliferate 安全文件也明確指出，review gate 只保護合併路徑，Agent 的命令與整合仍可能有其他外部副作用。

若當下 Agent 與 permission mode 提供 plan checkpoint，先看計畫是否越界；沒有時就直接盯緊實際命令。完成後不要立刻 Publish；先核對：

1. 檔案範圍：diff 只出現在允許清單；多出 lockfile、設定或格式化全專案就是越界。
2. 行為正確：新增測試能先重現 bug，修正後才通過；不能只相信 Agent 的「已完成」。
3. 測試收據：本文把你人工記下的實際命令、exit code 與失敗數稱為收據；「看起來沒問題」不算。
4. 外部副作用：確認沒有 push、PR、留言或呼叫不在範圍內的第三方服務。

官方 Review and Publish 文件說明 Changes 可切換 Unstaged、Staged、Branch 與 Last turn，也可逐 hunk stage、unstage 或 revert。這才是第二道核准：只在 diff 與測試收據都合理時，才讓 Publish 推送 branch 並視設定建立 PR。

步驟 4：再開兩個不重疊任務，安排合併順序

第一題完整通過後，再從同一個已知乾淨基線開兩個 workspace。任務 A 可以是「修登入驗證器與對應測試」，任務 B 則是「修 README 的使用範例與連結檢查」；兩者要有不同檔案所有權，也都禁止修改共用設定。官方 Parallel Agents 指南也不建議把同檔編輯、沒有計畫的廣泛重構、migration 或 release 直接平行化。

兩個任務都完成後，各自留下 diff 與測試收據。以下把 A 當成依賴較少的示範：先審查並 Publish A 的 branch／PR，再依 repo 規則合併 A；接著讓 B 從已合併的最新基線更新、處理差異並重跑測試，重新審查後才 Publish／更新 B 的 PR，最後再依規則合併。若出現同檔衝突、測試退化或越界改動，就停止 Publish，交回人類決定保留哪一側；不要用破壞性的硬重設把證據一起清掉。

Terminal、Nodeterm、Agent Workspace、Proliferate 怎麼選？

真正的選型問題不是誰的畫面最漂亮，而是你現在最常發生哪種失敗：Git 操作太手動、終端太多找不到狀態、跨任務交接失焦，還是原生 Agent、Worktree、diff 與核准關卡散在不同工具。先用同一個小任務做 A/B 驗收，再看下圖：

• 選 Terminal＋Git：你只有一兩個任務、熟悉 git worktree、願意自己管 session、diff、測試與 push。這條路不新增上述工作台，遠端與總覽工具則要自己配置。
• 選 Nodeterm：主要痛點是終端太多、狀態和通知藏在不同視窗；它把真實終端放到畫布與 Worktree 群組中。
• 選 Agent Workspace：你更在意跨任務狀態、產物、成本與接管總覽。這是一類介面，不是單一標準；不同產品的 auth、沙箱、遠端與 approval 能力要逐一核對。可先讀 Agent Workspace 完整解析。
• 選 Proliferate：你想在一個整合式工作台中使用多種原生 harness，讓每個獨立任務選用 Worktree，並在同一介面完成 Changes 審查、Publish 與可重用流程。若你其實在比較 harness，而非工作台，可看 Pi、OpenCode、DeepSeek Harness 比較。

何時值得 Self-host？先算控制平面維運，不只看 AGPL

Proliferate 目前原始碼授權採 AGPL-3.0；但「可以自架」不等於「現在就該自架」。官方 Self-host 指南把 hosted service 列為多數團隊的起點，合規、資料落地或網路邊界才是典型自架理由。控制平面還包含 server、Postgres、migration、Caddy／TLS、帳號與整合憑證；因為資料庫與 secrets 由你管理，本文把備份還原、更新、監控與 rotation 視為自架前必須自行承擔的維運工作。

更重要的是，除非你另外配置本機模型或自架 inference gateway，單純自架控制平面不會把模型推論自動留在機房。Claude Code、Codex、OpenCode 的 prompt 與 context 仍會依你選的原生登入、API key 或 gateway 路線送往相應服務。若目標是打造自己的隔離控制面，可先參考 Cloudflare OS Agent Workspace，再決定你要的是現成產品還是自建系統。

AlphaLab 採用較保守的門檻：只有下面四題都能回答「是」，才進入自架：

1. 有明確的合規、資料落地或網路邊界需求，而不是「開源看起來比較安心」。
2. 有人負責資料庫、TLS、備份還原、版本升級與事故處理。
3. 已畫出模型、Git remote、MCP、連接器與使用者裝置的資料路徑。
4. 有退出條件：還原演練失敗、維護時間過高或核准邊界無法證明時，回到 hosted／Terminal。

七個常見坑：Worktree 不是權限系統

1. 把 Worktree 當沙箱：它隔離 checkout，不隔離同一使用者的 secrets、程序、socket 與網路。
2. 看到 Agent 名稱就相信登入：先查 claude auth status --text、codex login status或 opencode auth list，再核對 Proliferate route、provider／model；單一指令不一定能證明帳號與計費身分。
3. 只在 prompt 寫「不要 push」：prompt 是合約；各 harness 的 permission、sandbox、工具規則、整合設定與人工核准才共同決定實際權限。
4. 把 Publish 當唯一外部寫入：shell、MCP、PR 留言或第三方服務 API 都可能更早寫到遠端。
5. 平行修改同一檔案：不同 Worktree 仍可能在整合時出現文字或語意衝突；先切檔案所有權與驗收條件。
6. 只看 Agent 摘要，不看 Last turn：摘要可能漏掉順手格式化、lockfile 與設定變動；逐段看實際 diff。
7. 太早清理工作區：先保留 branch、commit、測試收據與人類決策，再依官方 cleanup 流程處理；不要把唯一證據和工作目錄一起丟掉。

Proliferate 教學 FAQ

1. 完全不會 Git 也能用 Proliferate 嗎？

可以操作，但不適合直接平行。至少先學會 branch、diff、commit、merge／conflict 與 git status，否則你無法判斷 Changes 是否合理。

2. Worktree 會保護 API key 和環境變數嗎？

不會。Worktree 是 Git 工作目錄隔離，不是憑證或程序隔離；Agent 仍可能繼承同一使用者可讀的環境與全域設定。

3. Claude Code、Codex、OpenCode 能在同一個 Repo 一起跑嗎？

可以，甚至能在同一 workspace 開多個 chat。但它們會共享檔案；要平行處理獨立任務時，應使用不同 workspace／Worktree，再切開檔案所有權並由人安排合併順序。

4. 三個 Agent 可以同時改同一個檔案嗎？

技術上可能，第一輪不要。它把衝突風險推遲到整合階段；就算 Git 自動合併，也可能留下語意錯誤，讓責任與測試結果變得難追。

5. 按 Publish 前都不會寫到遠端嗎？

不能這樣假設。Publish 是 Git branch／PR 的明確發佈點；但核准過的 shell、MCP、連接器與第三方服務 API 可能更早產生外部副作用。

6. 原本的 Claude／ChatGPT 訂閱登入可以沿用嗎？

只有在選對原生認證路線、且 workspace 保留相同憑證環境時才成立。BYOK 或 Gateway 是不同路線；每次都在同一 workspace／runtime context 核對 Proliferate route、provider／model 與 CLI status。

7. Windows 現在可以用嗎？

官方文件列出 Windows x64 beta，但本次未驗證 installer 當下可下載。文件也寫明未簽章 installer 可能觸發 SmartScreen；先確認官方下載可用，再用非關鍵 repo 驗收。

8. 一開始就該 Self-host 嗎？

多數個人與小團隊先不要。只有合規、資料落地或網路邊界確實需要，而且有人能維護資料庫、TLS、備份與升級時，自架才比 hosted 更有意義。

給新手的七個重點

1. 第一題只做一個可逆、小範圍、能人工核對的 bug fix。
2. 一任務一 Worktree；Worktree 是防碰撞，不是安全沙箱。
3. 在同一 workspace context 核對登入路線與 provider／model；介面能顯示時再核對帳號。
4. prompt 寫任務合約；permission、sandbox、工具與整合設定共同決定實際權限。
5. 每個任務都要留下檔案範圍、diff、測試指令與結果。
6. 先管執行中的外部副作用，再管 Publish 的 Git 發佈。
7. 平行任務先切責任，再決定合併順序；衝突時停下交回人類。