架構報告 ① · Claude Code / Codex CLI 模式

Claude Code 架構把「編排器」放在使用者本機的客戶端代理

Claude Code 是一個常駐終端機程式:整個代理迴圈(編排器)、工具執行、情境組裝、權限把關與擴充機制全部跑在使用者自己的機器上;唯一的雲端依賴,是每一回合送到 Anthropic 模型 API 的「推論」。

編排器位置:本機 / 客戶端 核心迴圈:QueryEngine.ts 唯一外部依賴:模型推論 API 資料落地:程式碼不出本機

01核心事實

來源:xuanyuancode.com《Claude Code 源码学习》教學,共 8 大主題、20+ 章,分主題平行擷取後彙整。

100%編排在本機
1雲端外呼(模型推論)
25+模型可呼叫工具(Bash/File/…)
5層權限把關

main.tsx 組裝者

啟動時平行預熱、載入設定/政策/環境、認證與功能旗標、收集指令與工具、組裝情境、初始化 MCP/LSP/Skills/外掛,再進入 REPL。

QueryEngine.ts 大腦

會話級任務編排器,每段對話一個實例;常駐有狀態(訊息、用量、檔案狀態)。跑「決策→權限→執行→回流」主迴圈直到任務完成。

tools.ts 能力閘

統一工具註冊與過濾:filterToolsByDenyRules() 在模型看到工具前先篩掉——被隱藏的工具模型根本無法呼叫(能力暴露層的安全)。

02架構圖

幾乎所有方塊都在「使用者本機」內;只有模型推論那一條線連到雲端。

🖥 使用者本機 / DGX Spark(編排器在此) CLI / 入口層 main.tsx 組裝 · commands.ts 斜線指令 · 終端 UI(React Ink) · 設定/MDM ⚙ 編排器 · QueryEngine 主迴圈 組裝情境 → 呼叫模型 → 權限把關 → 本機執行工具 → 結果回流 決策 → 權限 → 執行 → 回流(迴圈) 情境 / 狀態 context.ts(Git/CLAUDE.md) AppStateStore 狀態匯流排 動態 prompt 組裝 + 快取 工具系統(統一協定) BashTool · FileRead/Edit/Write Glob/Grep · 全部在本機檔案系統執行 ToolUseContext + 差異核可 UI 權限 / 安全(本機強制) 5 層:模式 · allow/deny/ask · 工具隱藏 checkPermissions / requiresUserInteraction Plan Mode 人工核可節點 擴充機制 MCP client · LSP · 外掛 Plugins Skills(SKILL.md,平台/政策層) → admin 可集中下發 skill 子代理 / 任務 AgentTool · SendMessageTool Task*/Team* 生命週期工具 由本機 leadership thread 協調 (選用)遠端執行橋接 REPL bridge 終端在本地 ≠ 執行一定在本地:可把「工具執行」搬到遠端容器,決策仍留本機。 ⚠ cc17 未解:橋接後「權限判斷在本地還是遠端」? ☁ 雲端:模型 API Anthropic Claude 推論 唯一外部依賴;只「決定呼叫哪個工具」 本身不做編排、不能自行動作 在 DGX 上本機部署 → 這條變 loopback 每回合:情境+工具定義 → ← 文字答覆 / 工具呼叫請求 👤 使用者 就坐在這台機器前 指令與資料皆在本機
本機 / 客戶端 編排器 / 主迴圈 雲端(僅模型推論) 權限 / 安全 選用 / 未解

03分層解構

9 個層級,每一層的「執行位置」標記:本機 雲端 兩者皆可

04一次請求的生命週期

注意第 4 步是「唯一」離開本機的動作。

    05安全模型與「Admin 下發 Skill」

    🔒 五層權限,全在本機強制

    哲學是「可控的自動化」而非完全自治。① 權限模式(default/acceptEdits/plan/bypassPermissions)② ToolPermissionContext 的 allow/deny/ask 規則 ③ 在 tools.ts 直接把某些工具對模型隱藏(比執行期攔截更強)④ 情境式自動拒絕 ⑤ 危險規則剝除。

    Plan Mode 是系統級核可節點:ExitPlanModeV2Tool(shouldDefer)會強制「Exit plan mode?」人工核可,requiresUserInteraction() 對一般使用者回 true、對 teammate 回 false。

    🧩 Skill 分層目錄 = 天然的集中治理鉤子

    Skills 由 loadSkillsDir.ts平台/政策層 → 使用者層 → 專案層掃描。Admin 只要把治理過的 SKILL.md(用 allowedTools / model / context / hooks 限縮爆炸半徑)放到平台層,每位使用者開機即自動獲得,同時仍可自加專案 skill。

    再加上 settings/政策與開機時的 MDM 讀取,就有了「組織級權限預設 + 功能旗標」的受管裝置通道——不需要信任任何遠端控制平面

    06對「賣 DGX Spark + 管理 Skill」的意義

    這對應決策的「選項 A:codex 式 — skill 存在 user 裝置」

    把這套客戶端編排器模式套到「賣 Spark + 管理 skill」的產品上,意思是:每位 user 裝一個 codex 式 client、skill 同步到各自裝置、編排在裝置端跑,模型推論再呼叫 Spark。它的架構長處(本機編排、能力暴露層安全、分層 skill 目錄)依然成立。

    但對你的首要目標(最快上手、最少維運)這不是最佳解:要逐機佈署 client + 把 skill 同步到每台裝置(MDM),且因為模型本來就在 Spark,「資料落地/離線」的好處被抵消,反而讓 skill IP 散落到裝置。它真正佔優的是「裝置端分擔算力、在地 UX」。完整對照見 ③ 決策報告——本案建議改採選項 B:skill 集中在 Spark(見 報告 ②)。下方仍列出此客戶端架構本身的優勢與限制。

    優勢

      限制 / 待解