Claude Code 源碼解剖：98.4% 基礎設施 vs 1.6% AI 意味著什麼？

你以為 Claude Code 最值錢嘅部分係 AI 模型？VILA Lab 剛發表嘅論文用一個數字顛覆咗呢個假設：在 Claude Code v2.1.88 嘅 ~512,000 行 TypeScript 原始碼入面，真正屬於 AI 決策邏輯嘅只有 1.6%，其餘 98.4% 係權限系統、上下文壓縮管道、工具路由、錯誤恢復呢啲 deterministic 基礎設施。個 agent loop 核心就係一個 while-loop——call model、run tools、repeat，簡單到可以寫喺幾行 code 入面。真正複雜嘅，係圍住個 loop 起嘅成個工程系統。

1.6% 唔係疏忽，係 conscious design choice

好多人聽到「得 1.6% AI」會以為係 codebase 太臃腫或者技術債，但實際上係刻意嘅架構取態。Claude Code 嘅設計哲學叫「Model reasons; harness enforces」——模型負責諗嘢，框架負責執行。模型永遠唔可以直接 access filesystem、run shell command、或者做 network request。佢唯一嘅對外介面係結構化嘅 tool_use protocol，由 harness parse、check permissions、dispatch 去 tool implementations、再 collect results。

呢個 separation 有直接嘅安全後果：因為 reasoning 同 enforcement 行兩條分開嘅 code path，就算模型被人攻陷或者 prompt inject，都無辦法 bypass 個 sandbox、permission checks、同 deny-first rules。模型嘅「諗」同系統嘅「做」之間隔咗成個 permission system——七個 mode、一個 ML classifier、deny 永遠 override allow。

論文作者將呢個取態對比咗其他系統：LangGraph 用 explicit state graphs 嚟 constrain 模型嘅思維路徑，Devin 用 multi-step planners 去 maintain 顯式計劃結構。Claude Code 揀嘅路係「trust the model’s local reasoning, constrain only execution」，呢個 choice 直接決定咗 98.4% 嘅 code 要用喺邊。

Context 係綁死一切嘅稀缺資源

如果你覺得 context window 只係一個技術規格（200K tokens / 1M tokens），Claude Code 嘅架構會教識你件事遠遠唔係咁簡單。Context 係呢個系統嘅 binding resource constraint——成個 architecture 嘅每一個 major decision 都係為咗 manage context scarcity。

每次 model call 之前，system 會行一個五層嘅 compaction pipeline：Budget reduction（逐條 message 減 size）→ Snip（剪走舊歷史）→ Microcompact（cache-aware 壓縮）→ Context Collapse（read-time projection，唔會破壞原 data）→ Auto-Compact（最後手段，call model 自己 summary）。每一層都 trade off 唔同嘢，最平嘅行先。呢個「graduated laziness」嘅 pattern 唔止出現喺 context management——permission system 嘅七個 mode、extensibility 嘅四個機制（hooks、skills、plugins、MCP）全部用同一種 stacked independent stages 嘅設計語言。

對開發者嚟講，呢個 messages 好清楚：如果你喺度 build AI agent，context 唔係一個可以遲啲先諗嘅 optimisation problem——佢係會 shape 晒你成個 architecture 嘅 first-order constraint。由 tool schema 要 lazy load、到 subagent 嘅 return 限死係單一 summary message、到每條 tool result 要計 budget，全部係為咗慳 context。

安全架構：Deny-first 同 approval fatigue 嘅矛盾

Claude Code 嘅 permission system 有七個 mode，由最保守嘅 plan mode（每個動作都要 user approve）到最開放嘅 bypassPermissions。Deny-first 嘅邏輯係：broad deny 永遠 override narrow allow，strictest rule wins。七層獨立安全機制由 tool pre-filtering 玩到 shell sandboxing 再到 hook interception。

但論文揭露咗一個 uncomfortable finding：大約 93% 嘅 permission prompts 係俾 user 直接 approved 嘅。當你見到個 popup 出現第九十次嘅時候，你都會就咁撳 Allow。Approval fatigue 係真實存在嘅 human factor——你加更多 warnings 只會令用戶更加麻木。Claude Code 嘅應對唔係加更多 prompts，而係 restructuring boundaries：auto-mode 嘅 ML classifier、shell sandboxing、non-restoration on resume（每次新 session 都要重新 establish trust），呢啲係 deterministic 嘅 guardrail 而唔係依賴 user vigilance。

仲有一個叫「pre-trust execution window」嘅 structural vulnerability：hooks 同 MCP servers 喺 initialization 嘅時候會行，而個 trust dialog 未出現——呢個時間窗口係 structural 嘅攻擊面，已經有兩個 CVE 係呢個 root cause。七層安全機制有一個 shared failure mode：佢哋全部受限於同一段 context window 嘅 token budget。例如超過 50 個 subcommands 嘅時候，security analysis 會被 bypass，因為行唔晒。Defense-in-depth 只係喺 layers 有 independent failure modes 嘅時候先成立。

對創業者同開發者嘅實質啟示

論文嘅核心 thesis 係一句好 direct 嘅 claim：「as models converge in capability, the scaffolding becomes the differentiator。」Frontier models 嘅能力差距喺收窄（top 3 喺 SWE-bench 上相差少過 1%），咁意味住你揀邊個模型嘅重要性會越來越低，而你嘅 architecture——context management、safety system、tool routing、recovery logic——先係真正嘅 moat。

對香港同繁體中文圈嘅開發者嚟講，呢篇論文俾到一個明確嘅信號：AI agent 嘅競爭優勢唔係嚟自 training run，係嚟自 TypeScript。Anthropic 嘅真正 lead 唔係 Claude 模型本身——Claude Code 係任何人都可以 reverse engineer 同 reimplement 嘅 deterministic systems。論文仲發現咗 44 個 unreleased features 喺 compile-time feature flags 後面，包括一個叫 KAIROS 嘅 autonomous daemon mode 同 ULTRAPLAN 嘅 background planning system——即係你安裝嘅版本只係冰山一角。

如果你係 build AI agent 嘅 startup，應該睇清楚呢個 pattern：98.4% 嘅工程投資係基礎設施。Invest 喺 context compaction pipeline、permission architecture、recovery mechanisms、同 tool routing infrastructure 嘅回報，可能遠高過喺 prompting tricks 或者 model selection 上面糾結。模型會 commodity 化，但你嘅 harness 唔會。

最後，論文作者用 OpenClaw 做 comparison 嘅做法值得我哋反思：同一 set 設計問題（reasoning 喺邊、safety posture、context management、extensibility、subagents、persistence），喺唔同 deployment context 下會得出完全唔同嘅 architecture answers。分清楚咩係 recurring design question、咩係你嘅 specific constraint，可能係成篇 paper 俾到最有用嘅框架。