Claude Code 架構深度解析：洩露原始碼揭示了什麼
Claude Code 洩露的原始碼揭露了 512K 行生產環境 TypeScript 代碼。本文提供完整架構分析——工具系統、查詢引擎、多代理模式與上下文壓縮。
大家好，我是 Dora。2026 年 3 月，我原本沒打算深入研究什麼。一則訊息出現在我的動態牆：「Claude Code 原始碼透過其 npm 套件中的 map 檔案遭到洩露。」
我關掉了手邊的分頁，沒有回頭。
接下來的下午，是我研究一款生產級 AI 工具如何實際構建以來，最真正令人著迷的幾個小時之一。並不是因為洩露事件的戲劇性——那種熱鬧很快就會退燒——而是因為這份程式碼實屬罕見：一個真實出貨、商業上佔主導地位的 agentic CLI，以 512,000 行的細節被攤開來審視。
以下是我的觀察。
為何洩露的原始碼是難得的架構研究機會
Claude Code 洩露後，原始碼隨即浮出水面——透過 Anthropic 自家 npm 套件中一個設定錯誤的 .map 檔案暴露——開發者很快意識到這不是對聊天 API 的簡單封裝。根據 cybersecuritynews.com 對此事件的分析，洩露內容涵蓋約 1,900 個檔案，超過 512,000 行嚴格的 TypeScript，僅主要進入點就重達 785KB。
技術堆疊本身已相當有趣：使用 Bun 作為執行環境（而非 Node.js）、搭配 Ink 的 React 用於終端 UI 渲染，以及全程使用 Zod v4 進行結構驗證。在 CLI 中採用 React 元件模式，意味著要在終端裡處理狀態管理、重新渲染與可組合的 UI 元件。這是一個刻意而大膽的選擇。
為何值得在梗圖之外深入研究：這裡的 Claude Code 架構模式適用於任何正在構建嚴肅 agentic 系統的團隊。
工具系統——40 餘個自包含的權限控管模組
第一個引起我注意的，是工具系統隔離得多麼乾淨。每個工具各自定義輸入結構、權限等級與執行邏輯——彼此獨立。工具之間沒有隱性的共享可變狀態在流竄。
BashTool 和 FileReadTool 同在一個登錄檔中，卻有著根本不同的風險特性。Bash 執行可以改變系統狀態；檔案讀取則是唯讀的。架構據此對待它們，讓每個工具背後有各自的權限等級，而非套用一刀切的政策。這種隔離在生產級 agentic 系統中至關重要——一個跨工具洩漏的權限模型，是安全性與可靠性上的潛在定時炸彈。
AgentTool 是其中最巧妙的一個。它讓系統能夠以普通工具呼叫的方式生成子代理——無需特殊的協調層，無需獨立的進程模型。子代理是同一個工具登錄檔中的一等公民。這個設計決策讓架構保持扁平且可預測。
光是基礎工具定義就跨越約 29,000 行 TypeScript。這不是冗贅——這才是嚴格的結構驗證、權限執行與錯誤處理在這種規模下的真實樣貌。Anthropic 官方 Claude Code 文件印證了這種以工具為核心的理念：工具才是讓系統具備 agentic 能力的根本所在。
46,000 行的查詢引擎——Claude Code 真正的大腦
QueryEngine.ts 有 46,000 行。先讓這個數字沉澱一下。
這個模組處理所有 LLM API 呼叫、串流、快取與協調工作，全部集中在單一檔案中。這聽起來或許是個警訊——依照你的程式碼慣例，質疑它是合理的——但背後的邏輯是連貫的：所有接觸模型 API 的邏輯都在同一個地方，意味著重試邏輯、速率限制處理、上下文預算管理與串流錯誤，都能被一起思考。
最讓我出乎意料的是自我修復查詢循環。當上下文預算接近上限時，引擎不會崩潰或求助，而是自動觸發壓縮，在到達上限前預留出緩衝空間，並生成一份關於對話內容的結構化摘要。這不是黑魔法——這是設計行為。對於任何正在構建長時間運行代理會話的人來說，這個模式直接值得研究。
多代理協調——協調者、工作者與信箱模式
多代理系統對危險操作使用了洩露原始碼中稱為信箱模式的機制。實際含義是：執行任務的工作者代理無法自主批准高風險操作。它會向協調者的信箱發送請求並等待。協調者評估後決定批准或拒絕。
原子性的認領機制防止兩個工作者同時處理同一個批准請求——這在任何具備平行執行能力的系統中，都是個微妙卻關鍵的細節。所有代理共享記憶空間，讓整個團隊維持連貫的上下文，無需重複重取。
這與那種每個代理都完全自主運作的幼稚多代理設計有著顯著的差異。帶有審批閘門的協調者／工作者拆分，正是在不引發混亂的前提下實現平行處理的方式。正在為自己的 agentic 系統設計協調層的團隊，不妨在動筆設計之前，先研讀 Anthropic 的 agentic 模式文件。
三層上下文壓縮——為長時間會話而工程化
對於任何正在構建生產級 AI 應用的人而言，這或許是整個程式碼庫中最直接有用的工程成果。
Claude Code 使用三種不同的壓縮策略，各自在不同時間點觸發：
MicroCompact 在本地編輯快取內容，零 API 呼叫。舊的工具輸出直接被裁剪。快速、低成本、透明。
AutoCompact 在對話接近上下文視窗上限時觸發。它預留 13,000 個 token 的緩衝，然後生成最多 20,000 個 token 的會話結構化摘要。內建斷路器——連續三次壓縮失敗後停止重試。不會無限循環。
Full Compact 壓縮整個對話，然後重新注入最近存取的檔案（每個檔案上限 5,000 個 token）、活躍計劃與相關的技能結構。壓縮後，工作預算重設為 50,000 個 token。
值得注意的是，這個架構對完全跳過壓縮的工具意味著什麼。不管理上下文預算的 agentic 工具，在規模化後將直接失敗——悄悄地退化或遭遇硬性錯誤。三層方式是從一開始就為會話持久性而設計的罕見範例，而非事後補貼。
功能旗標即架構——108 個在生產環境中不存在的模組
洩露原始碼中較少被討論的發現之一：108 個功能控管模組，透過 Bun 的編譯期死碼消除從外部構建中剝離。
KAIROS、VOICE_MODE、DAEMON——這些在你安裝的版本中並不存在。原始碼中有這些程式碼，但 Bun 在編譯期根據功能旗標設定將其消除。生產套件出貨時乾淨俐落。這就是在不觸動已交付功能的前提下，迭代新能力的方式。
其中一個頗具諷刺意味的細節已被廣泛記錄：潛行模式（Undercover Mode）——一個專門設計用來防止內部代號出現在 git 提交或輸出中的子系統——出現在洩露的原始碼裡。這個為防止洩露而構建的系統，卻無法阻止洩露本身發生。並非災難性的安全失敗，但對於風險在軟體交付管道中實際積累於何處，是個發人深省的教訓。
內嵌於核心循環的遙測
洩露原始碼中有兩個遙測訊號讓我一直在思考：
一個挫折感指標追蹤咒罵頻率作為使用者體驗訊號。如果使用者在對著工具罵人，說明某些地方出了問題——這是一個領先指標，而非滯後指標。
一個「continue」計數器追蹤使用者在會話中輸入「continue」這個詞的頻率。對於 agentic CLI 而言，這是停滯的代理指標——代理失去動能、需要人類輕推才能繼續的時刻。
兩者都不是虛榮指標。兩者都能浮現出標準分析工具會錯過的特定失效模式。如果你正在構建任何具備延伸互動會話的 AI 產品，以這種方式對代理行為進行埋點，是值得投入的工程時間。
這對構建者的技術選型有何啟示
研究這份 Claude Code 架構後，誠實的結論是：從零開始構建一個生產級 agentic CLI，是一項龐大的工程承諾。工具系統、查詢引擎、多代理協調、上下文壓縮與遙測，加在一起代表的是數年的迭代，而非數月。
這不是反對構建的論點。這是在清醒認識自己將面對什麼之前的提醒。信箱審批系統和三層壓縮等模式是可移植的——你不需要 512,000 行就能實現其核心理念。
構建與購買的權衡轉向的地方，在於模型存取與聚合。這個架構假設可以直接存取單一模型提供商。跨多個模型提供商工作，或需要保持模型無關性的產品團隊，面對的是一套完全不同的取捨。
這裡的模式值得借鑑。在決定複製之前，複雜性值得先行理解。
常見問題
Claude Code 的工具系統與標準函數呼叫有何不同？
標準函數呼叫將工具視為一個扁平列表。Claude Code 在每個邊界增加了逐工具的權限閘門、隔離的執行上下文以及結構驗證——防止跨工具的狀態洩漏，並執行最小權限存取。當 BashTool 能夠修改系統狀態時，這一點尤為重要。
什麼是信箱模式，構建者應在何時使用它？
它將危險操作從工作者代理路由至協調者進行審批，而非自主執行。任何時候當你有平行代理執行，且需要對高風險操作設置人機互動或層級審批機制時，都應使用它。吞吐量代價，安全性收益。
Claude Code 如何在規模化時處理上下文視窗限制？
三層壓縮：MicroCompact（本地編輯，無 API 成本）、AutoCompact（在接近限制時觸發，生成帶有預留 token 緩衝的結構化摘要）以及 Full Compact（完整對話壓縮並選擇性重新注入檔案）。專為長時間會話設計，無需人工介入。
什麼是編譯期功能旗標，為何生產級 AI 工具使用它們？
它們允許尚未發布功能的程式碼存在於原始碼中，而不出現在生產構建中。Bun 在編譯期消除已關閉旗標的程式碼，使外部使用者永遠不會遇到尚未準備好的功能——將出貨與就緒分離開來。
研究並參考洩露原始碼的架構靈感是否合法？
值得謹慎對待。洩露的原始碼是 Anthropic 的智慧財產。出於教育目的研究架構模式，與直接複製程式碼處於不同的法律範疇。Anthropic 官方文件仍是任何構建在其系統之上的事物的適當參考。如有疑問，請諮詢您自己的法律顧問。
我一直縈繞心頭的，是這個架構有多少設計是關於優雅地管理失敗的。壓縮上的斷路器、危險操作的信箱模式、工具之間的權限隔離——這些都不是樂觀的設計。它們是由親眼見過事情出錯、並決定圍繞此進行工程化的人所構建的。
這是一種不同於功能迭代速度的成熟度。
好了，今天的分享就到這裡。下次見。
