前幾天晚上，我在 GitHub 上看到一個讓我眼睛發直的專案。
一個叫 shareAI‑lab 的團隊對 Claude Code 進行了徹底逆向，並把完整的研究資料、中間的分析過程全部 po 了出來。
Claude Code 可是 Anthropic 家的當紅炸子雞，是他們在 AI coding 這條路上最拿得出手的產品。
但現在，Claude Code 的底褲被一個民間逆向倉庫扒了，曝光了核心技術架構、實現機制和執行邏輯，相當於做了個開箱拆機，連怎麼聽懂人話、怎麼呼叫工具、怎麼記住上下文、怎麼防惡意指令，全都曝光了。
倉庫地址我放在這裡了：
https://github.com/shareAI-lab/analysis_claude_code
（PS：這個專案目前在 archive，作者佬在小紅書回應還在更新中）
先鋪個背景方便大家夥兒理解——
大家都知道 Claude Code 本身是閉源的，但為了讓 CLI 正常跑，他們還是得把程式碼隨安裝包發給使用者。所以 CLI 裡還打包了一份 50 k+ 行的混淆 JavaScript 程式碼，只是這份程式碼被 刻意“打亂、加密、改名”，目的就是把核心演算法和 Prompt 邏輯藏起來，讓人看不懂，避免別人抄襲了去。這就叫 JavaScript 混淆。
但是 JS 終究要跑在本地，再怎麼混淆，Node.js 終究要看到可執行的明文邏輯，這就給逆向者提供了入口。
那這位民間逆向者是咋做的呢？
他們是用 claude code 去分析 claude code（v1.0.33）本身的混淆後代碼** **，（哎？聽起來像套娃）
也就是對 5 萬行的混淆程式碼切片，藉助 Claude Code 的力量分析 15 個 chunks 檔案，再用人肉 + 除錯補洞，最後拼出來一份 95% 準確度的“推斷版架構”。
【友情提示】：下面的逆向筆記並非官方文件，README 裡寫得很直白——“非 100 % 準確，分析過程中 LLM 難免出現幻覺，僅供學習參考”。
先來看看這份逆向推斷版的 Claude Code 系統架構全景圖：
最核心的技術對映如下——
最頂層是使用者互動層。
無論你是在命令列裡敲 Claude、在 VSCode 用外掛，還是在 Web 頁面上跑，它們背後對接的其實是同一套排程系統。
這一層只負責接收你的指令，並把它們統一編碼為 Claude Agent 系統能理解的請求格式。也就是說，不管你從哪個入口發出指令，最終都會被轉化為統一的資料格式，由 “Claude 模型大腦”接收和處理。
而這個“大腦”在中間層——Agent 核心排程層。
中心是一個叫 nO 的主迴圈引擎（其實就是 AgentLoop），它負責管理一切智慧體行為的“總排程室”。流程圖是這樣的：
你每輸一句話，它就得判斷：
-
是不是新任務？ -
需要呼叫哪些工具？ -
哪些 Agent 該被喚醒？ -
哪些歷史資訊要壓縮？ -
有沒有地方出錯要補救？
這些決策的執行，要靠它左手的h2A 訊息佇列（負責非同步傳輸和流式反饋），右手的 wu 會話流生成器（即時生成文字輸出），加上一套名為wU2 的壓縮引擎來動態最佳化你用過的上下文。
注意，這裡沒有一個地方是模型在跑。模型本身只是排程結果中的一個工具，它只是整個流程中的一個“被呼叫者”。真正做判斷、做協調的，是這一整套排程引擎和執行時邏輯。
往下是工具執行與管理層，也是 Claude Code 最像“中臺”的地方。
它負責排程具體的子 Agent。比如你發一個“執行 shell 命令”的請求，它就會調出負責 bash 執行的 Agent；你要求讀取專案目錄，它就找出讀寫許可權最小的檔案管理 Agent。
這些 Agent 都受控於幾大核心部件：
-
MH1 工具引擎：發現工具、校驗引數、分配任務； -
UH1 併發排程器：限制併發量、防止資源爭搶； -
SubAgent 管理器：給每個子任務分配獨立 Agent，並做任務隔離； -
許可權驗證閘道器：判斷你這個 Agent 能不能執行某條命令、能不能訪問某個檔案、有沒有聯網許可權。
也就是說，Claude 不是一次性調一個“大助手”來幹活，而是每個任務都生成一個獨立的“子 Agent”，然後嚴格按照許可權、狀態、工具能力來分發執行。
繼續往下，是工具生態系統。
這就是 Claude Code 真正的“武器庫”。上百個分類明確、職責清晰的小工具，從檔案讀寫、命令執行，到網路搜尋、任務管理、MCP 整合、效能診斷應有盡有。
你以為 Claude 在思考，其實它只是在呼叫：
-
誰擅長這類問題？哪個 Agent 適合？ -
有沒有需要配合的兩個工具一起跑？
這種工具生態不是外掛，而是結構化地配置在系統裡。
工具的定義方式是檔案級別，每一個工具都是一個可管理、可審計、可熱載入的模組單元。你甚至可以自己寫一個 .yaml 檔案扔進目錄裡，Claude 立馬能發現它、載入它、賦許可權。
最底層，是儲存與持久化系統。
這是 Claude 記憶力的來源，整個記憶架構分三層。
它是按時間維度、壓縮策略、任務粒度分層處理記憶：
-
當前會話 → 放在 Messages 裡，支援即時互動； -
中期摘要 → 放進 Compressed 模組，由 wU2 壓縮器負責最佳化； -
永久偏好 → 寫入 CLAUDE.md，包括你常用語言、專案結構、喜好工具等； -
系統狀態 → 存在 StateCache 裡，比如某工具執行次數、是否曾報錯、是否因許可權受限被停用等。
每一次呼叫、每一個決策，其實都依賴於這些儲存結構的回憶。
Claude Code 並不依賴於雲端記憶，而是靠本地狀態檔案、上下文壓縮演算法、狀態快取系統構建出一個“類人記憶”的思維體系。
這就是 Claude Code 系統架構的全貌。
它把一套多 Agent 系統跑得像流水線一樣順滑。Claude Code 早就不是一個“智慧補全”的工具了，它是一套 AI 時代的“本地分散式 Agent 作業系統”。
說到這裡，很多人可能還是覺得，這不就是多加了幾個 Agent 和工具嘛，有啥真正厲害的地方？
錯了。
如果你真的開啟那份逆向分析文件，你會看到一個句子像電流一樣穿過程式碼註釋和排程日誌：Claude Code 的真正突破，不在於調了幾個工具，而在於它讓這些 Agent 之間的協作，變成了“即時的、穩態的、動態可控”的過程。
簡單說，它不僅能調，還能邊調邊改方向，邊跑邊讓不同 Agent 對齊節奏。這聽起來像廢話，但工程上能做到的幾乎沒有。
另外，專案作者還整理了這裡面的重要的技術創新，即時 Steering 技術和 智慧上下文壓縮演算法。
即時 Steering：從“觸發”到“引導”的躍遷
大多數 AI 工具的排程邏輯是觸發式的，也就是你下個請求，我執行一次；你換個指令，我再跑一遍。但 Claude Code 的 h2A 訊息佇列，不是“等你發完才處理”，而是能在指令剛輸入一半時就啟動流程，並邊接收、邊排程、邊調整。
我們在逆向文件裡看到它的核心機制用的是“雙緩衝佇列 + 條件觸發消費”，虛擬碼如下：
classh2AAsyncMessageQueue{ enqueue(message) { // 策略1: 零延遲路徑 - 直接傳遞給等待的讀取者 if (this.readResolve) { this.readResolve({ done: false, value: message }); this.readResolve = null; return; }// 策略2: 緩衝路徑 - 儲存到迴圈緩衝區 this.primaryBuffer.push(message); this.processBackpressure(); } } 簡單來說，它不是等訊息“堆滿”才動，而是只要有人等，它就立刻傳；沒人等，它就緩衝 + 限流。再加上流式寫回機制，這就保證了 Claude 可以邊生成文字、邊調整任務、邊響應新輸入。
這才是真正的“Steering”，你能在它做的時候，隨時發指令“換方向”，它立刻響應。
智慧上下文壓縮：用演算法判斷保留誰在說話
Claude 的第二個重大創新，是我們看到的 wU2 上下文壓縮系統。
很多 AI 產品都在解決一個問題：上下文太長，token 爆炸，要裁剪。但大多數產品是靠“歷史越久越刪”“內容越長越刪”，要麼全砍，要麼硬塞。
Claude 不一樣。它用了一種 “重要性加權 + 策略性摘要”的壓縮法。
比如這段觸發邏輯：
// 壓縮觸發邏輯 if (tokenUsage > CONTEXT_THRESHOLD * 0.92) { const compressedContext = await wU2Compressor.compress({ messages: currentContext, preserveRatio: 0.3, importanceScoring: true }); } 意思是，當 token 使用量超過閾值 92%，系統就會呼叫壓縮器進行上下文重構。但不是壓縮全部，而是按“重要性”打分，只保留 30% 的最關鍵段落，剩下的提煉成摘要。
這一設計讓 Claude 在執行任務時，可以更精準地維持上下文的“記憶完整度”。壓縮操作不以時間或長度為主維度，而是以內容關鍵性為準則，減少冗餘資訊對模型推理的干擾，同時維持對歷史任務、使用者偏好和中間變數的追蹤能力。
這也是為什麼使用者在與 Claude 進行長時間互動時，會感覺它記得住，並且記得的都是重點，不容易斷片。
從這次的逆向文件中，我們第一次清晰地看到了什麼是真正有工程厚度的 Agent 產品。
它並不追求一句話能做多少事，而是讓每一句話的背後，都能安全、高效、合理地排程十個 Agent。
而且關鍵是，它是真的跑起來了。
它讓我們看到一個事實：
未來的 AI 程式設計助手，不會是 ChatGPT 的一個功能分支，而是一個具備工程穩定性、安全性、組織能力的智慧體操作平臺。