市面上讲 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 方案