本文要點
- Claude Code 與 Codex CLI 可同機，但禁止共用工作目錄；
git worktree硬隔離。 - 三層：目錄 → worktree → tmux；MCP 一份、路徑對齊。
- Claude Code 長會話多檔；Codex 腳本批處理或 OpenAI 棧。
- 16GB「1 長 + 1 短」；兩路長會話 → 24GB +
memory_pressure。 - 驗收：
tools/call≥95%、黃區 ≤2h、交叉寫入 0。
1. 為什麼需要雲 Mac 雙 AI Agent 架構？
kvmboot 工單已從「能否 SSH」變成「一台機跑幾個 Agent」。落地雙 AI Agent 架構時，常見是有人用 Claude Code Hooks 與 Anthropic 模型，有人用 Codex CLI 或 OpenAI 腳本；同一 sprint 跨模組 refactor 與 hotfix 並行——筆電合蓋即斷，雲 Mac 上本機只當遙控器。
租 Mac mini 24GB 的機器費常比筆電 7×24 更可控。脈絡：Claude Code 上雲 Mac、MCP 部署；雙 Agent 同機是第三層——兩個 CLI 不互害。
官方：Claude Code · Codex · worktree。
不熟悉 tmux / worktree / MCP？ 先只記一句：兩個 Agent = 兩個倉庫副本 + 兩個終端視窗 + 一個 MCP 服務。 下文再展開目錄配置、絕對路徑與量化驗收。
2. 五種翻車模式（工單最高頻）
「雙 Agent 配了但不工作」時，命中任意兩類就應先重做隔離，再繼續功能開發。
- 共目錄寫
.git/index：Claude Code 在main改檔，Codex 同時git checkout——「改動去哪了」是檔案系統競態，不是模型笨。 - MCP 路徑寫死本機：設定指向筆電，SSH 到雲 Mac 後讀不到——兩 Agent 以不同方式失敗，排障時間翻倍。
- tmux 會話混用：兩 Agent 共用 window，以為 Codex 在改 A，其實是 Claude 上一輪 shell。
- API Key / 配額混放：
~/.claude與 Codex 憑據被export污染——錯模型、錯帳單。 - 16GB 跑兩路長會話：
memory_pressure變黃後工具延遲飆升，被誤判成「MCP 壞了」。
共同解是邊界：倉庫、會話、配置——不是換更聰明的模型。
3. 分工矩陣
| 維度 | Claude Code | Codex CLI |
|---|---|---|
| 擅長 | 長會話、多檔 refactor、Hooks、MCP Git 深度聯動 | 快迭代小任務、腳本批處理、OpenAI 生態 |
| 不適合 | 與另一 Agent 共目錄並行寫 | 單獨扛 codesign / Xcode 全流程 |
| 典型槽位 | cc-main + feature/refactor | codex-hotfix + hotfix/config |
| 費用 | Token 計費；長會話設預算 | Token 計費；防腳本迴圈 |
兩路都做全倉大改 = 雙份 Token、單份吞吐。見 AI Coding 三件套、ECC。
4. 架構圖
5. 隔離 setup：目錄、worktree、tmux
5.1 目錄層：HOME 與配置分離
在雲 Mac 上為兩 Agent 各準備邏輯配置根（同一 Unix 使用者亦可，但啟動 env 分開）：
- Claude Code：
CLAUDE_CONFIG_DIR=/Users/agent/.claude-cc，Hooks 與 MCP stdio 放此。 - Codex CLI：憑據與
config.toml獨立目錄，勿與 Claudesettings.json混寫。
SSH 與鑰匙圈邊界見 租 Mac 開通驗收清單。
5.2 倉庫層：worktree 農場（硬隔離）
主倉庫只讀或僅 fetch；每個 Agent 綁定一個 worktree 絕對路徑——非協商項：
# On the cloud Mac — example paths
/opt/worktrees/my-app-cc-refactor # Claude Code only
/opt/worktrees/my-app-codex-hotfix # Codex CLI only
git worktree add /opt/worktrees/my-app-cc-refactor feature/refactor
git worktree add /opt/worktrees/my-app-codex-hotfix hotfix/config完整農場布局見 遠端 Mac worktree 短租。Agent 啟動前先 cd 進自己的 worktree，寫進 tmux 腳本。
5.3 會話層：tmux 一 Agent 一 window
tmux new-session -s agents -n cc -c /opt/worktrees/my-app-cc-refactor
tmux new-window -t agents -n codex -c /opt/worktrees/my-app-codex-hotfix本機 SSH 後 tmux attach -t agents；合蓋只斷 Client，雲 Mac 上雙 Agent 會話繼續。夜間 launchd 見 launchd + MCP FAQ，仍須獨立 worktree。
6. MCP 與雙 Agent：一份 Server，兩條 Client
雙 Agent ≠ 亂裝兩份 MCP。較穩做法：
- 在雲 Mac跑一份 MCP Git Server，
--repository指向 worktree 父目錄，或每 worktree 一埠——二選一並寫進文件。 - Claude 與 Codex 的 MCP 路徑必須是SSH 那台機的絕對路徑，與 MCP 部署專文「Server 與倉庫同機」一致。
- 禁止：Claude 連 VPS MCP、Codex 連本機 stdio。
驗收：兩個 tmux window 各問「最近三次提交」，日誌皆有 tools/call 且分支名與各自 worktree 一致。
7. 16GB vs 24GB：並行度與 memory pressure
雙 Agent 常低估 Apple Silicon 統一記憶體（含索引/語言服務時）：
- 16GB：「一路長 + 一路短」或一路 Agent + 唯讀 MCP；雙 Xcode/Docker 易頂滿。
- 24GB：兩路互動長會話，或一路 Agent + 模擬器/構建；配合 記憶體洪峰與 swap 治理。
第一天別鎖區域：用 亞太/美東 16GB/24GB 指南 測 RTT，日租窗口壓 memory_pressure。
8. Cloud Mac 雙 Agent 驗收標準（Checklist）
把 48 小時日租變成可複製驗收：時間軸管過程，下表管是否達標。建議在雲上保存可打碼日誌。
| 指標 | 合格線 | 怎麼測 |
|---|---|---|
| tools/call 成功率 | ≥ 95% | 48h 內兩路各 ≥20 次 MCP；回傳正確分支/提交 |
| memory_pressure 黃區 | 連續 ≤ 2h | while sleep 300; do memory_pressure; done |
| worktree 交叉寫入 | = 0 | 禁止 A/B 互 cd；git -C 審計 |
8.1 48 小時時間軸（可複製）
- 0–2h · Setup：SSH；worktree A/B；tmux 腳本寫死
cd；MCP 用雲 Mac 絕對路徑。 - 2–8h · Isolation：Claude 只在 A refactor；Codex 只在 B 小步提交；交叉
cd應為 0。 - 8–16h · MCP：雙 window 問「最近三次提交」；統計
tools/call成功率。 - 16–32h · Resilience：本機合蓋/斷網 ≥8h；回來
tmux attach確認進程仍在。 - 32–48h · Decision：匯總三項；僅 memory 超標 → 試 24GB 或 2×16GB；全過 → 升週/月租 Mac。
Pass：三項同時達標且 RTT 可接受。Fail 先查：共目錄、MCP 不在雲 Mac——再查模型。
9. FAQ
9.1 能共用一個 worktree 嗎？
僅當嚴格串行（一個完全退出再開另一個）。互動並行一律不要——資料遺失多來自「以為串行其實並行」。
9.2 雙 Agent 要兩台雲 Mac 嗎？
兩路皆長會話且各自 Xcode 構建：2×16GB 比 1×24GB 更省心。一路長一路短：一台 24GB 通常夠。
9.3 Codex 必須在 macOS 上嗎？
Codex 本身不強制 macOS；若交付含 codesign、notarization、Xcode，與 Claude Code 同機雲 Mac 仍比 Linux+Mac 分裂少一整類跨機問題。
10. 結論
雲 Mac 雙 AI Agent 架構 本質是小型多租戶：Claude Code + Codex CLI 各走 worktree 與 tmux，MCP Server 單一來源。用拓撲圖對齊團隊認知，用三項量化指標替代「感覺能跑」——達標後再鎖月租與記憶體檔位。