市面上講 Claude Code 的文章，多半停在「裝 CLI、曬 diff」。但把它放進真實團隊時，你會發現：頂級 AI 程式設計工具的核心架構，從來不是終端裡那一個 Agent 行程——而是 Cloud Mac AI Stack 裡，Diff、Fact、Context、Workflow 如何分工、如何閉環。
本篇是 L6-Q02 支柱地圖（L6-Q02）：以 Claude Code 為入口，畫出全站 Stack 總架構、五模組接入順序與系統閉環。操作手冊見 L6-Q01 完整手冊；權限門檻見 L3 決策首講——本篇只管地圖。
一句話架構
Claude Code 生產 Diff，GitHub Runner 生產 Fact。 MCP 擴展 Context，Ollama 可選 Inference，OpenHands 編排 Workflow——全部跑在 Cloud Mac（L0）之上。
Claude Code 本體：10% 拆解（其餘 90% 是 Stack）
先把 Claude Code自己說清楚，再談它坐在哪一層。它是一個終端編碼 Agent，不是 IDE 外掛：
單輪 Agent loop（可多次迭代） 讀 CLAUDE.md + 倉庫上下文 │ ▼ 規劃（改哪些檔案、跑哪些命令） │ ▼ 執行（Write / Edit / Bash / 可選 MCP Tool） │ ▼ 驗證（你指定的 test / lint） │ └──► 產出 Diff（git 可審計的改動）
- 邊界 —
CLAUDE.md與權限策略決定「能碰什麼」；見 手冊 · 專案邊界 - 延伸感官 — MCP 把 GitHub Issue、CodeGraph、API 接進 Context；見 MCP 三連通 Hub
- 與 Cursor 的分工 — 編輯器內補全 vs 跨檔案 + shell Agent；見 vs Cursor
到這裡為止，只是 L3。真正讓組織敢用的「核心架構」，是下面這張 Stack 總圖。
Cloud Mac AI Stack 總架構圖（職責層級）
下圖是本站 L0–L5 的統一模型——讀任何專題文時，都可回到這裡對照。重要：這是職責層級，不是執行時誰先呼叫誰。
Stack ≠ 呼叫順序
Claude Code 不必依賴 Ollama；MCP 在圖上高於 L3，指 Context 為編碼服務，不是說 MCP 一定比 CLI 先啟動。落地順序見 § 接入順序。
產出物：Inference · Diff · Fact · Context · Workflow
┌──────────────┐
│ OpenHands │ L5 · Workflow（整條需求跑完了嗎？）
└──────┬───────┘
│
┌──────▼───────┐
│ MCP │ L4 · Context（Agent 看得見什麼？）
└──────┬───────┘
│
┌──────▼───────┐
│ Claude Code │ L3 · Diff（這次改動是什麼？）← 本篇入口
└──────┬───────┘
│
┌──────▼───────┐
│ Ollama │ L2 · Inference（可選 · 本地私有算力）
└──────┬───────┘
│
┌──────▼───────┐
│ GitHub Runner│ L1 · Fact（組織敢不敢信？）
└──────┬───────┘
│
┌──────▼───────┐
│ Cloud Mac │ L0 · 基礎設施（24/7 macOS 節點）
└──────────────┘
L0 托住算力，L1 托住 Fact，其上才是 Diff、Context、Workflow。 Claude Code 再強，若沒有 L1，Diff 只是開發機上的自嗨。
五模組（+ 底座）職責與產出物
| 層 | 模組 | 產出物 | 回答的問題 | 深入閱讀 |
|---|---|---|---|---|
| L0 | Cloud Mac | 底座 | macOS / Apple Silicon 從哪來？ | 買還是租 |
| L1 | GitHub Runner | Fact | push 之後誰跑 xcodebuild / 測試？ | 執行引擎 |
| L2 | Ollama | Inference | 要不要本地 embedding / 小模型？ | 私有推理層 |
| L3 | Claude Code | Diff | 誰改程式、跑 shell、循環測試？ | 完整手冊 |
| L4 | MCP | Context | Issue / 圖譜 / API 怎麼進 Agent？ | 三連通 Hub |
| L5 | OpenHands | Workflow | 整條需求能否無人值守跑完？ | Agent 平台 |
Workflow（L5）與 Fact（L1）的關係：OpenHands 在任務週期內反覆消費 Context、產出 Diff、用 Fact 校驗——不是「Workflow 跑完才輪到 CI」。詳見 OpenHands · 產出物關係。
建議接入順序：先 Fact，再 Diff
熱搜順序往往是：先 Claude Code → 再 MCP → 最後才想起 CI。我們更推薦下面這條部署順序（與結構圖層級不同）：
① Cloud Mac（L0 底座）
│ 常駐 macOS · SSH · 出口 IP
▼
② GitHub Runner（L1 · Fact）
│ push → 綠/紅 可重複 · workspace 隔離
▼
③ Ollama（L2 · Inference，可選）
│ 本地 embedding / 小模型 · 注意與 L1/L3 排記憶體
▼
④ Claude Code（L3 · Diff）
│ CLAUDE.md · 權限 · 第一天試跑
▼
⑤ MCP（L4 · Context）
│ GitHub / CodeGraph / Fetch · 最小權限
▼
⑥ OpenHands（L5 · Workflow）
│ 多步 issue · agent loop · 與 L3 疊層
▼
⑦ 系統閉環
委託 → Diff → PR → Runner Fact → review → merge
- ① L0 — 沒有 24/7 macOS 節點，Runner 與 Agent 搶筆電記憶體；選型見 買還是租
- ② L1 — 先讓組織有可信的 Fact；隔離見 一 job 一 workspace
- ③ L2 — 可選；與 Claude Code、Runner 同機時注意 並行排班
- ④–⑥ — 在 Fact 穩定後再疊 AI；手冊見 L6-Q01
- ⑦ 閉環 — 見下一節
系統閉環：從 Claude Code 委託到 PR 綠燈
「核心架構」的最後一塊，是資料怎麼流回來——Agent 不能活在孤立終端裡：
人在場 · L3 開發者 ──委託──► Claude Code（+ MCP Context） │ │ Diff（commit） ▼ feature 分支 / PR │ 機器驗收 · L1 ▼ GitHub Runner（Fact） xcodebuild / test / lint │ ├── 紅 ──► 回饋給 Agent 再改（Diff ↔ Fact） │ └── 綠 ──► 人工 review ──► merge 可選 · L5 OpenHands 夜間清 issue 佇列 ──► 同樣走 PR + Runner 閉環
閉環成立的三條硬條件：Runner 與 Agent 環境隔離、PR 必過 CI、生產 secrets 不進 Agent shell。生產清單見 L6-Q01 · 生產級。
全站內鏈樞紐：按層跳轉
本篇是 Stack 專題的地圖頁。按你目前卡點選入口：
| 你想解決… | 去讀 |
|---|---|
| 要不要 Cloud Mac / 怎麼租 | L0 買還是租 · M4/M5 選型 |
| CI 排隊 / Runner 值不值 | L1 排隊與 TCO · L1 執行引擎 |
| Swap / Ollama 與 Agent 同機 | L2 並行排班 |
| 裝 Claude Code / 生產級工作流 | L6-Q01 完整手冊 · L3 權限決策 |
| 接 MCP / CodeGraph | L4 Hub · MCP 安裝教程 |
| 無人值守多步任務 | L5 OpenHands |
常見問題
Claude Code 的核心架構是什麼？ 終端 Agent loop 產出 Diff；生產級還要 CLAUDE.md、MCP Context、獨立 Runner Fact。
一定要先裝 Ollama 才能用 Claude Code 嗎？ 不必。L2 可選；結構圖表示職責層級，不是呼叫鏈。
本篇和 L6-Q01 手冊有什麼區別？ Q01 是操作主線（安裝→CI）；Q02 是 Stack 總地圖（本篇）。
OpenHands 能取代 Claude Code 嗎？ 不能。L5 編排 Workflow，L3 結對產 Diff；疊層使用。
ZavCloud
按地圖搭 Stack，從一台 Cloud Mac 開始
L0 底座 → L1 Runner → L3 Claude Code。原生 macOS，按接入順序試跑整條閉環。
查看 Cloud Mac 方案