面試官皺眉：“沒(méi)用過(guò) Claude Code 也敢來(lái)？” 我不屑：“但我能寫(xiě)一個(gè)！”，他愣了：等等我記一下…

　　大家好，我是程序員魚(yú)皮 ?。

　　堪稱全球最強(qiáng)的 AI 編程工具 Claude Code 的 50 多萬(wàn)行源碼泄露了！一家以 AI 安全著稱的公司，自己卻在代碼發(fā)布環(huán)節(jié)翻了車。

　　針對(duì)這件事，我只想說(shuō)兩個(gè)字：

　　感謝！

　　這份源碼對(duì)學(xué)技術(shù)的同學(xué)來(lái)說(shuō)簡(jiǎn)直是寶藏資源啊，過(guò)年了過(guò)年了！

　　那 Claude Code 源碼具體是怎么泄露的？源碼里有哪些精妙的設(shè)計(jì)？為什么它能做到 AI 編程工具的天花板？

　　下面我利用 AI 帶大家一起學(xué)習(xí)，學(xué)會(huì)它優(yōu)秀的設(shè)計(jì)后，你可以改進(jìn)自己的 AI 項(xiàng)目、或者面試的時(shí)候吊打一下面試官。

　　?? 本文對(duì)應(yīng)視頻版：https://bilibili.com/video/BV1ZB9EBmEAU

　　 完整源碼我存了一份，想要獲取完整源碼的同學(xué)可以點(diǎn)我頭像，私信「claude」獲取，隨時(shí)可能被下掉，速速速

　　到底是怎么泄露的

　　Claude Code 是通過(guò) npm 發(fā)布的，你可以把 npm 理解為程序員的「應(yīng)用商店」，開(kāi)發(fā)者把寫(xiě)好的工具打包上傳到這里，別人一行命令就能安裝。

　　正常情況下，代碼上線之前會(huì)經(jīng)過(guò)「壓縮混淆」處理，變成一坨人類看不懂的東西。

　　但在開(kāi)發(fā)的時(shí)候，為了方便定位 Bug，代碼打包工具會(huì)自動(dòng)生成一個(gè)叫Source Map的文件，它相當(dāng)于一張「翻譯對(duì)照表」，能把加密后的代碼還原成原始版本。但是這個(gè)文件只能在開(kāi)發(fā)環(huán)境用，上線時(shí)必須刪掉！

　　結(jié)果 Anthropic 的工程師在發(fā)布 Claude Code 2.1.88 版本的時(shí)候，打包工具 Bun 默認(rèn)生成了 Source Map 文件，而他們忘了在發(fā)布配置里把.map文件排除掉。于是一個(gè) 59.8 MB 的cli.js.map文件就這么被直接發(fā)到了公開(kāi)的 npm 倉(cāng)庫(kù)。

　　這個(gè) map 文件本質(zhì)上是一個(gè) JSON，里面有兩個(gè)關(guān)鍵數(shù)組，sources存著所有文件的路徑，sourcesContent存著每個(gè)文件的完整源碼，兩者一一對(duì)應(yīng)。只要寫(xiě)個(gè)腳本解析一下這個(gè) JSON，按路徑把內(nèi)容寫(xiě)出來(lái)，所有源碼就原樣還原了。

　　而且據(jù)說(shuō) map 文件里甚至還引用了一個(gè) Cloudflare R2 存儲(chǔ)桶的公開(kāi)地址，點(diǎn)進(jìn)去直接就能下載打包好的完整源碼目錄，連腳本都不用寫(xiě)。

　　安全研究員 Chaofan Shou 最先發(fā)現(xiàn)了這個(gè)問(wèn)題并發(fā)到了 X 上：

　　然后幾個(gè)小時(shí)之內(nèi) GitHub 上就冒出了好幾個(gè)鏡像倉(cāng)庫(kù)，源碼傳遍了整個(gè)互聯(lián)網(wǎng)，其中有個(gè)倉(cāng)庫(kù)不到 1 天就快 10w Star 了（而且倉(cāng)庫(kù)里早就沒(méi)有 Claude Code 源碼了）……

　　更搞笑的是，去年 2 月 Claude Code 剛發(fā)布的時(shí)候就出過(guò)一模一樣的事故，同樣的錯(cuò)誤犯了兩次！

　　怕不是 Claude Code 團(tuán)隊(duì)的開(kāi)發(fā)者 Vibe Coding 上癮，連基本操作都忘了？

　　源碼里都有什么

　　這次泄露的是 Claude Code 客戶端的源碼，包括 1906 個(gè) TypeScript 源文件、大約 51.2 萬(wàn)行代碼。涵蓋了 Agent 循環(huán)引擎、40 多個(gè)內(nèi)置工具的完整實(shí)現(xiàn)、系統(tǒng)提示詞的組裝邏輯、記憶系統(tǒng)、上下文壓縮、權(quán)限管控機(jī)制，還有一堆沒(méi)上線的隱藏功能。但是不包括服務(wù)端的模型訓(xùn)練代碼和 API 后端邏輯。

　　
Claude Code 完整架構(gòu)

　　整個(gè)項(xiàng)目用的是 React Ink 框架，簡(jiǎn)單說(shuō)就是用 React 來(lái)寫(xiě)命令行界面，你可以理解為「在終端里寫(xiě)網(wǎng)頁(yè)」。所以 Claude Code 的命令行交互才會(huì)比很多傳統(tǒng)工具絲滑。

　　我用 AI 把它的架構(gòu)從上到下梳理了一遍，大致分為 6 層：

　　1）最上面是 CLI 和界面層，你在終端里看到的所有交互都是這一層負(fù)責(zé)的

　　2）往下是 Agent 循環(huán)引擎，你可以把它理解為 Claude Code 的大腦，所有的決策都從這里發(fā)出

　　3）再往下是工具系統(tǒng)，40 多個(gè)內(nèi)置工具加上 MCP 擴(kuò)展

　　4）然后是記憶系統(tǒng)，解決 AI 聊著聊著就斷片兒的老毛病

　　5）上下文壓縮系統(tǒng)，解決 token 越來(lái)越貴、窗口越來(lái)越滿的問(wèn)題

　　6）最底層是權(quán)限和安全系統(tǒng)

　　
Claude Code 分層架構(gòu)圖

　　接下來(lái)咱們結(jié)合源碼，看看每個(gè)模塊具體是怎么實(shí)現(xiàn)的，Claude Code 是怎么做到這么好用的？

　　一、Agent 循環(huán)

　　大家都知道現(xiàn)在的 AI 編程工具早已經(jīng)不是簡(jiǎn)單的「一問(wèn)一答」了，而是能連續(xù)執(zhí)行、自主完成任務(wù)的 AI Agent。

　　可能有同學(xué)會(huì)覺(jué)得，這背后一定是什么特別復(fù)雜的架構(gòu)，用了什么 AI Agent 開(kāi)發(fā)框架、什么多 Agent 協(xié)作之類的吧？

　　但我打開(kāi)負(fù)責(zé)核心對(duì)話循環(huán)的query.ts文件一看，好家伙，最核心的代碼其實(shí)就是一個(gè)while(true)無(wú)限循環(huán)！

　　// query.ts
asyncfunction*queryLoop(params: QueryParams, consumedCommandUuids:string[]){
letstate: State = {
messages: params.messages,
toolUseContext: params.toolUseContext,
autoCompactTracking:undefined,
maxOutputTokensRecoveryCount:0,
hasAttemptedReactiveCompact:false,
turnCount:1,
// ...
}

// eslint-disable-next-line no-constant-condition
while(true) {
// 1. 上下文壓縮（防止 token 爆炸）
// 2. 調(diào)用大模型，流式獲取響應(yīng)
// 3. 解析模型返回的工具調(diào)用
// 4. 執(zhí)行工具，獲取結(jié)果
// 5. 把結(jié)果追加到對(duì)話歷史
// 6. 如果沒(méi)有新的工具調(diào)用，結(jié)束；否則繼續(xù)循環(huán)
}
}


　　就是這么樸素的一個(gè)循環(huán)。每一輪迭代里，程序先做上下文壓縮、再調(diào)用大模型拿到響應(yīng)，如果模型說(shuō)「我要用某個(gè)工具」就去執(zhí)行，把結(jié)果追加到對(duì)話歷史里，然后進(jìn)入下一輪，一直循環(huán)工作直到活兒干完了才停下來(lái)。

　　這在 AI 領(lǐng)域叫ReAct 機(jī)制（推理 + 執(zhí)行），讓 AI 自己形成「思考 → 行動(dòng) → 觀察 → 再思考」的閉環(huán)。Claude Code 的源碼就是這個(gè)理論最接地氣的工程實(shí)現(xiàn)了。

　　每次循環(huán)中，程序會(huì)通過(guò)services/api/claude.ts里的queryModel函數(shù)來(lái)跟大模型溝通。這個(gè)函數(shù)負(fù)責(zé)發(fā)送請(qǐng)求、接收 SSE 流式輸出、累計(jì) token 用量這些事情。模型返回的結(jié)果里如果包含tool_use類型的內(nèi)容，說(shuō)明 AI 還想調(diào)用工具繼續(xù)干活，循環(huán)就接著轉(zhuǎn)；如果沒(méi)有tool_use了，說(shuō)明任務(wù)做完了，循環(huán)就結(jié)束。

　　// services/api/claude.ts — 模型調(diào)用核心函數(shù)
asyncfunction*queryModel(
messages: Message[],
systemPrompt: SystemPrompt,
thinkingConfig: ThinkingConfig,
tools: Tools,
signal: AbortSignal,
options: Options,
):AsyncGenerator{
// 解析模型（含 Bedrock inference profile）
// 合并 Beta headers
// 構(gòu)造 anthropic.beta.messages 流式請(qǐng)求
// 累計(jì) token 用量
// yield 流式事件
}


　　在這個(gè)循環(huán)定義的上方，還有一段 Anthropic 工程師留下的注釋，叫什么「巫師守則」：

　　// query.ts — queryLoop 函數(shù)上方
/**
* The rules of thinking are lengthy and fortuitous...
*
* The rules follow:
* 1. A message that contains a thinking block must be part of a query
* whose max_thinking_length > 0
* 2. A thinking block may not be the last message in a block
* 3. Thinking blocks must be preserved for the duration of an assistant
* trajectory
*
* Heed these rules well, young wizard. For they are the rules of thinking,
* and the rules of thinking are the rules of the universe. If ye does not
* heed these rules, ye will be punished with an entire day of debugging
* and hair pulling.
*/


　　這三條規(guī)則是關(guān)于模型思考過(guò)程（thinking block）的處理約束，大意就是「年輕的巫師啊，好好遵守這三條關(guān)于 thinking block 的規(guī)則，不然你將受到整整一天 debug 和拔頭發(fā)的懲罰」。

　　我一時(shí)間分不清，這是程序員的浪漫，還是 AI 的浪漫？

　　二、工具設(shè)計(jì)

　　Claude Code 內(nèi)置了 40 多個(gè)工具，在負(fù)責(zé)工具注冊(cè)和管理的tools.ts文件里，有個(gè)getAllBaseTools()函數(shù)列出了所有內(nèi)置工具：

　　// tools.ts — 工具注冊(cè)文件
/**
*NOTE:This MUST stay in sync with https://console.statsig.com/...
* in order to cache the system prompt across users.
*/
exportfunctiongetAllBaseTools():Tools{
return[
AgentTool, // 子 Agent 生成
TaskOutputTool, // 任務(wù)輸出
BashTool, // 執(zhí)行終端命令
...(hasEmbeddedSearchTools() ? [] : [GlobTool, GrepTool]),
FileReadTool, // 讀文件
FileEditTool, // 編輯文件
FileWriteTool, // 寫(xiě)文件
NotebookEditTool, // 編輯 Notebook
WebFetchTool, // 網(wǎng)絡(luò)請(qǐng)求
WebSearchTool, // 網(wǎng)絡(luò)搜索
TodoWriteTool, // 待辦事項(xiàng)
SkillTool, // 技能調(diào)用
EnterPlanModeTool,// 進(jìn)入規(guī)劃模式
...(process.env.USER_TYPE ==='ant'? [ConfigTool] : []),
// ... 還有幾十個(gè)，根據(jù)環(huán)境和 Feature Flag 動(dòng)態(tài)加載
...(isToolSearchEnabledOptimistic() ? [ToolSearchTool] : []),
]
}


　　注意開(kāi)頭那段注釋，意思是這份工具清單必須和他們的 A/B 測(cè)試配置中心保持同步，否則全球用戶共享的系統(tǒng)提示詞緩存就廢了。看來(lái)工具注冊(cè)不只是功能問(wèn)題，還直接關(guān)系到成本和性能。

　　還有最后一行的ToolSearchTool，當(dāng)用戶接了很多 MCP 插件、工具數(shù)量特別多的時(shí)候，Claude Code 不會(huì)把所有工具的完整描述都塞進(jìn)系統(tǒng)提示詞里，而是先給模型一份「工具名 + 一句話介紹」的精簡(jiǎn)清單，讓模型自己選需要哪些，再按需加載完整定義，從而節(jié)省了大量 token。

　　代碼里還能看到process.env.USER_TYPE === 'ant'這個(gè)判斷，ant 是 Anthropic 內(nèi)部員工的代號(hào)（螞蟻），這說(shuō)明 Anthropic 自己也在重度用 Claude Code 來(lái)開(kāi)發(fā) Claude Code，怪不得這源碼一股 AI 味兒。

　　每個(gè)具體的工具都是通過(guò)Tool.ts里的buildTool工廠函數(shù)創(chuàng)建的，這個(gè)函數(shù)有個(gè)很巧妙的默認(rèn)值設(shè)計(jì)：

　　// Tool.ts — 工具類型定義和工廠函數(shù)
// Defaults (fail-closed where it matters):
// - isConcurrencySafe → false (assume not safe)
// - isReadOnly → false (assume writes)
// - isDestructive → false
// - toAutoClassifierInput → '' (skip classifier — security-relevant tools must override)
constTOOL_DEFAULTS = {
isEnabled:()=>true,
isConcurrencySafe:(_input?: unknown) =>false,
isReadOnly:(_input?: unknown) =>false,
isDestructive:(_input?: unknown) =>false,
toAutoClassifierInput:()=>'',
// ...
}


　　注釋里寫(xiě)的 「fail-closed where it matters」 是什么意思呢？

　　可以看到isConcurrencySafe和isReadOnly都默認(rèn)為false，也就是說(shuō)如果某個(gè)工具的開(kāi)發(fā)者忘了聲明「我只是讀個(gè)文件，不會(huì)改東西」，系統(tǒng)就自動(dòng)把它當(dāng)成危險(xiǎn)操作處理，不讓它并發(fā)執(zhí)行。

　　這種思路叫做fail-closed（失敗時(shí)關(guān)閉），打個(gè)比方就像公司的門(mén)禁系統(tǒng)，你沒(méi)刷卡默認(rèn)進(jìn)不去；跟它相反的 fail-open 就像小區(qū)大門(mén)，誰(shuí)來(lái)都讓進(jìn)。

　　對(duì)于 AI 應(yīng)用，你不知道它下一步會(huì)調(diào)用什么工具。在這種不確定性下，「默認(rèn)禁止」比「默認(rèn)允許」安全太多了。畢竟 Claude Code 直接操作你整個(gè)代碼庫(kù)，一旦出事兒可能是你半個(gè)月的代碼白寫(xiě)了。

　　還有toAutoClassifierInput默認(rèn)返回空字符串，意味著默認(rèn)跳過(guò)自動(dòng)分類器檢查，但注釋專門(mén)強(qiáng)調(diào)了安全相關(guān)的工具必須自己重寫(xiě)這個(gè)方法。這也是 fail-closed 的思路。

　　三、讀寫(xiě)分離的工具并發(fā)

　　假設(shè) AI 同時(shí)想讀 3 個(gè)文件、再改 1 個(gè)文件，這 4 個(gè)操作是一個(gè)一個(gè)排隊(duì)跑、還是一起并發(fā)執(zhí)行呢？

　　Claude Code 在負(fù)責(zé)工具執(zhí)行編排的toolOrchestration.ts里做了一套很聰明的讀寫(xiě)分離機(jī)制。

　　先看并發(fā)上限，默認(rèn)最多 10 個(gè)工具同時(shí)并發(fā)，還可以通過(guò)環(huán)境變量調(diào)整：

　　// services/tools/toolOrchestration.ts — 工具執(zhí)行編排
functiongetMaxToolUseConcurrency():number{
returnparseInt(process.env.CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY ||'',10) ||10
}


　　然后是核心的分批邏輯：

　　// services/tools/toolOrchestration.ts
functionpartitionToolCalls(toolUseMessages, toolUseContext):Batch[]{
returntoolUseMessages.reduce((acc, toolUse) =>{
consttool = findToolByName(toolUseContext.options.tools, toolUse.name)
constparsedInput = tool?.inputSchema.safeParse(toolUse.input)
constisConcurrencySafe = parsedInput?.success
?(() => {
try{
returnBoolean(tool?.isConcurrencySafe(parsedInput.data))
}catch{
returnfalse// 拋異常也當(dāng)不安全，又是 fail-closed
}
})()
:false // 解析失敗也當(dāng)不安全

if(isConcurrencySafe && acc[acc.length - 1]?.isConcurrencySafe) {
acc[acc.length- 1].blocks.push(toolUse) // 合并到并發(fā)批次
}else{
acc.push({ isConcurrencySafe, blocks: [toolUse] }) // 新開(kāi)一個(gè)批次
}
returnacc
}, [])
}


　　簡(jiǎn)單說(shuō)就是連續(xù)幾個(gè)只讀工具可以一起跑，但一旦遇到寫(xiě)操作，就得排隊(duì)等前面的都完成了才行。而且注意那個(gè) try-catch，如果判斷方法本身拋了異常（比如參數(shù)解析出錯(cuò)），也直接當(dāng)不安全處理。

　　并發(fā)執(zhí)行完之后，產(chǎn)生的上下文修改contextModifier也不會(huì)立刻生效，而是先排隊(duì)存著，等一個(gè)批次的所有工具都跑完了再按順序依次應(yīng)用。

　　在工具執(zhí)行編排文件的runTools函數(shù)里能看到這個(gè)邏輯：

　　// services/tools/toolOrchestration.ts — runTools 函數(shù)
if(isConcurrencySafe) {
constqueuedContextModifiers = {}
forawait(constupdate of runToolsConcurrently(blocks, ...)) {
if(update.contextModifier) {
// 先排隊(duì)，不立即應(yīng)用
queuedContextModifiers[toolUseID].push(modifyContext)
}
}
// 全部跑完后，按工具調(diào)用順序依次應(yīng)用
for(constblock of blocks) {
for(constmodifier of queuedContextModifiers[block.id]) {
currentContext = modifier(currentContext)
}
}
}


　　學(xué)過(guò)數(shù)據(jù)庫(kù)的同學(xué)肯定覺(jué)得眼熟，這不就是「讀讀并行、讀寫(xiě)互斥」的簡(jiǎn)化版嘛。很多計(jì)算機(jī)底層的設(shè)計(jì)思想，換個(gè)場(chǎng)景照樣管用，這就是基礎(chǔ)知識(shí)的魅力。

　　四、System Prompt 的緩存分裂

　　Anthropic 的 API 支持 Prompt Cache 提示詞緩存，如果你每次發(fā)給模型的系統(tǒng)提示詞前半部分都不變，API 就能緩存這部分內(nèi)容，后續(xù)請(qǐng)求直接復(fù)用，不用重新處理。

　　打開(kāi)負(fù)責(zé)系統(tǒng)提示詞組裝的constants/prompts.ts文件，你會(huì)看到提示詞被一個(gè)叫DYNAMIC_BOUNDARY的標(biāo)記分成了上下兩部分：

　　// constants/prompts.ts — 系統(tǒng)提示詞組裝
exportconstSYSTEM_PROMPT_DYNAMIC_BOUNDARY =
'__SYSTEM_PROMPT_DYNAMIC_BOUNDARY__'

sections = [
// ...靜態(tài)部分：角色定義、行為規(guī)范、工具說(shuō)明、語(yǔ)氣要求等
// === BOUNDARY MARKER - DO NOT MOVE OR REMOVE ===
...(shouldUseGlobalCacheScope() ? [SYSTEM_PROMPT_DYNAMIC_BOUNDARY] : []),
// --- Dynamic content (registry-managed) ---
...resolvedDynamicSections, // 動(dòng)態(tài)部分：當(dāng)前時(shí)間、git 狀態(tài)、CLAUDE.md 配置、MCP 工具等
]


　　Claude Code 用這條分界線精確地把提示詞切成兩半：上面是靜態(tài)部分，全球幾百萬(wàn)用戶共享同一份緩存；下面是動(dòng)態(tài)部分，比如你當(dāng)前的時(shí)間、你的 Git 倉(cāng)庫(kù)狀態(tài)、你自己配的 CLAUDE.md 規(guī)則等等，每個(gè)用戶各不相同，獨(dú)立加載。

　　源碼注釋里還專門(mén)警告，如果把動(dòng)態(tài)內(nèi)容不小心混到了靜態(tài)部分里，每個(gè)用戶的提示詞都不一樣了，緩存就全廢了。

　　// constants/prompts.ts
// WARNING: Do not remove or reorder this marker without updating cache logic in:
// - src/utils/api.ts (splitSysPromptPrefix)
// - src/services/api/claude.ts (buildSystemPromptBlocks)


　　如果你也在做 AI 應(yīng)用，調(diào)用量大的話，這個(gè)優(yōu)化技巧能幫你省不少錢(qián)。

　　五、內(nèi)容檢索策略

　　AI 模型本身沒(méi)有你項(xiàng)目的代碼記憶，所以需要一種方式讓它「看到」相關(guān)的代碼和文檔。

　　現(xiàn)在業(yè)界最流行的做法叫 RAG 檢索增強(qiáng)生成，簡(jiǎn)單說(shuō)就是先把項(xiàng)目數(shù)據(jù)做 Embedding 存到向量數(shù)據(jù)庫(kù)里，用戶提問(wèn)時(shí)先從數(shù)據(jù)庫(kù)里檢索出相關(guān)內(nèi)容，再連同問(wèn)題一起發(fā)給模型回答。

　　但沒(méi)想到，Claude Code 壓根不用這套！

　　不管是搜記憶文件還是搜歷史對(duì)話，它用的都是最樸素的 Grep 文本搜索。

　　在負(fù)責(zé)記憶系統(tǒng)的memdir/memdir.ts文件里有個(gè)buildSearchingPastContextSection函數(shù)，寫(xiě)得很明確：

　　// memdir/memdir.ts — 記憶搜索指令
constmemSearch =`grep -rn " " ${autoMemDir}--include="*.md"`
consttranscriptSearch =`grep -rn " " ${projectDir}/ --include="*.jsonl"`


　　Claude Code 的創(chuàng)始人 Boris Cherny 在播客里說(shuō)過(guò)：俺們?cè)囘^(guò) RAG，但發(fā)現(xiàn)讓 AI 自己決定搜什么、怎么搜，效果反而遠(yuǎn)遠(yuǎn)好于 RAG。

　　我的理解是這樣的，RAG 相當(dāng)于你幫實(shí)習(xí)生把相關(guān)資料都整理好了打包給他看；而 Agentic Search 是直接給他公司文檔庫(kù)的權(quán)限，讓他自己去找。模型能力越強(qiáng)，后者的優(yōu)勢(shì)就越大，因?yàn)?AI 比你更知道自己需要什么信息。而且 Grep 這種方案簡(jiǎn)單、沒(méi)有索引過(guò)期問(wèn)題、不用維護(hù)向量數(shù)據(jù)庫(kù)，工程復(fù)雜度直接降了一個(gè)量級(jí)。

　　所以做 AI 應(yīng)用的時(shí)候，哪些能力該交給工程系統(tǒng)、哪些該留給 AI 模型，這個(gè)邊界值得好好想想。模型越來(lái)越強(qiáng)，很多以前需要復(fù)雜工程方案解決的問(wèn)題，現(xiàn)在可能直接讓 AI 自己搞定就行了。

　　六、三層記憶架構(gòu)

　　這是我覺(jué)得整份源碼里設(shè)計(jì)最精妙的部分了，也是現(xiàn)在 Context Engineering 上下文工程領(lǐng)域最值得學(xué)的案例。

　　用過(guò) AI 編程工具的朋友應(yīng)該都體驗(yàn)過(guò)：同一個(gè)對(duì)話框里聊久了，AI 就斷片兒了，忘了之前說(shuō)過(guò)什么，甚至自相矛盾。

　　Claude Code 為了解決這個(gè)問(wèn)題，搞了一套分層記憶系統(tǒng)，網(wǎng)上有人管它叫 Self-Healing Memory 自愈記憶。

　　
第一層、MEMORY.md（熱數(shù)據(jù)，常駐加載）

　　MEMORY.md 就像一本書(shū)的目錄，每次對(duì)話都會(huì)加載到上下文里。

　　看看memdir/memdir.ts文件里是怎么限制它的大小的：

　　// memdir/memdir.ts — 記憶索引文件
exportconstENTRYPOINT_NAME ='MEMORY.md'
exportconstMAX_ENTRYPOINT_LINES =200
// ~125 chars/line at 200 lines. At p97 today; catches long-line indexes that
// slip past the line cap (p100 observed: 197KB under 200 lines).
exportconstMAX_ENTRYPOINT_BYTES =25_000


　　最多 200 行、25KB，而且只存指針不存內(nèi)容，每行不超 150 字符。因?yàn)樗看味家忌舷挛拇翱诘奈恢茫绻缶蜁?huì)把有用的對(duì)話內(nèi)容擠掉。

　　注釋里提到，25KB 那個(gè)字節(jié)限制是后來(lái)加的。因?yàn)樗麄儼l(fā)現(xiàn)有用戶雖然沒(méi)超 200 行，但每行寫(xiě)了一大堆，200 行居然能寫(xiě)到 197KB。所以不得不加個(gè)字節(jié)數(shù)的兜底保護(hù)。

　　如果內(nèi)容超出限制了怎么辦？

　　在這個(gè)文件里，還有一段詳細(xì)的截?cái)噙壿嫞?/p>

　　// memdir/memdir.ts — 截?cái)噙壿?br/>exportfunctiontruncateEntrypointContent(raw:string):EntrypointTruncation{
// 先按行數(shù)截?cái)?br/>lettruncated = wasLineTruncated
? contentLines.slice(0, MAX_ENTRYPOINT_LINES).join('\n')
: trimmed
// 再按字節(jié)數(shù)截?cái)啵谧詈笠粋€(gè)換行符處切，避免截?cái)嗟揭话?br/>if(truncated.length > MAX_ENTRYPOINT_BYTES) {
constcutAt = truncated.lastIndexOf('\n', MAX_ENTRYPOINT_BYTES)
truncated = truncated.slice(0, cutAt >0? cutAt : MAX_ENTRYPOINT_BYTES)
}

// 截?cái)嗪笞芳?WARNING，讓 AI 知道這個(gè)文件沒(méi)加載完
return{
content: truncated +
`\n\n> WARNING:${ENTRYPOINT_NAME}is${reason}. Only part of it was loaded.`,
}
}


　　采用行數(shù)截?cái)?+ 字節(jié)截?cái)嚯p保險(xiǎn)，截?cái)鄷r(shí)還會(huì)在最后一個(gè)換行符處切開(kāi)，不會(huì)切到一行的中間。截?cái)嘀筮€追加了一條 WARNING，讓 AI 知道「這個(gè)索引沒(méi)加載完整」。這種細(xì)節(jié)才是 Claude Code 體驗(yàn)好的原因。

　　第二層、話題文件（溫?cái)?shù)據(jù)，按需加載）

　　你的編碼偏好、項(xiàng)目的架構(gòu)約定、之前踩過(guò)的坑這些細(xì)節(jié)信息，都存在單獨(dú)的話題文件里，比如user_role.md、feedback_testing.md。

　　新對(duì)話開(kāi)始時(shí)，Claude Code 會(huì)用 Sonnet 小模型來(lái)挑選最多 5 個(gè)跟當(dāng)前對(duì)話相關(guān)的文件加載進(jìn)來(lái)。在負(fù)責(zé)記憶召回的findRelevantMemories.ts文件中，可以看到它挑選記憶的提示詞：

　　// memdir/findRelevantMemories.ts — 記憶召回
constSELECT_MEMORIES_SYSTEM_PROMPT =`You are selecting memories that will be
useful to Claude Code as it processes a user's query.
Return a list of filenames for the memories that will clearly be useful (up to 5).
- If a list of recently-used tools is provided, do not select memories that are
usage reference or API documentation for those tools (Claude Code is already
exercising them). DO still select memories containing warnings, gotchas, or
known issues about those tools — active use is exactly when those matter.`


　　最后那條規(guī)則我覺(jué)得是 punchline：如果某個(gè)工具正在被使用，就不加載它的使用文檔（你都在用了說(shuō)明你會(huì)用），但一定要加載它的已知問(wèn)題和坑。想想也對(duì)，你正在用一個(gè)東西的時(shí)候，最怕的不就是不知道有什么坑嘛。

　　而且 Claude Code 的記憶不記代碼。因?yàn)榇a會(huì)發(fā)生變化，但記憶并不會(huì)自動(dòng)更新。舉個(gè)例子，如果記憶里說(shuō)「函數(shù) X 在第 30 行」，你后來(lái)重構(gòu)了，這條記憶就變成誤導(dǎo)了。所以它只記人的偏好和判斷，代碼的事實(shí)永遠(yuǎn)去源碼里實(shí)時(shí)讀取。

　　做過(guò)后端開(kāi)發(fā)的朋友都知道，緩存和數(shù)據(jù)庫(kù)不一致是最坑的 Bug 之一。Claude Code 的做法等于從根源上消滅了不一致的可能性。

　　第三層、歷史對(duì)話（冷數(shù)據(jù)，Grep 搜索）

　　更早之前的歷史對(duì)話會(huì)被存成.jsonl格式的文件，需要的時(shí)候用 Grep 搜關(guān)鍵詞就能找到。

　　總結(jié)一下，不同溫度的數(shù)據(jù)用不同方式管理。熱的常駐、溫的按需、冷的搜索。

　　如果你面試被問(wèn)到 “AI 應(yīng)用怎么做長(zhǎng)期記憶”，這套方案絕對(duì)能讓面試官眼前一亮，畢竟 Claude Code 這種級(jí)別的產(chǎn)品都在用。

　　七、五級(jí)上下文壓縮

　　上一節(jié)講的是記憶怎么存和取，這一節(jié)講的是上下文怎么「瘦身」。大模型的上下文窗口是有上限的，隨著對(duì)話越來(lái)越長(zhǎng)、工具調(diào)用結(jié)果越攢越多，token 用量會(huì)快速膨脹，不僅費(fèi)錢(qián)，還可能直接超出窗口限制導(dǎo)致請(qǐng)求失敗。

　　Claude Code 為了應(yīng)對(duì)這個(gè)問(wèn)題，設(shè)計(jì)了五級(jí)壓縮策略，像漏斗一樣層層過(guò)濾：

　　 Snip 剪裁：最輕的一刀，把舊的工具調(diào)用結(jié)果只保留結(jié)構(gòu)，不保留內(nèi)容

　　 Microcompact 微壓縮：把體積大的工具執(zhí)行結(jié)果卸載到緩存里。注意是卸載到緩存而不是直接丟掉，因?yàn)樽又悄荏w后續(xù)可能還需要這些結(jié)果

　　 Context Collapse 折疊：對(duì)中間的對(duì)話做折疊摘要，只保留關(guān)鍵信息

　　 Autocompact 自動(dòng)壓縮：當(dāng)上下文占用超過(guò)閾值時(shí)，觸發(fā)全量摘要壓縮

　　 Reactive Compact 應(yīng)急壓縮：最后的兜底，當(dāng) API 返回 413 “提示詞太長(zhǎng)” 錯(cuò)誤時(shí)緊急觸發(fā)

　　這五級(jí)從輕到重依次觸發(fā)，能裁掉的內(nèi)容先裁掉，實(shí)在不夠了再上更重的方案。

　　從query.ts文件的開(kāi)頭可以看到其中三級(jí)壓縮模塊通過(guò) Feature Flag 按需引入（另外兩級(jí)在其他文件里）：

　　// query.ts — 壓縮模塊按需加載
constreactiveCompact = feature('REACTIVE_COMPACT')
?require('./services/compact/reactiveCompact.js') :null
constcontextCollapse = feature('CONTEXT_COLLAPSE')
?require('./services/contextCollapse/index.js') :null
constsnipModule = feature('HISTORY_SNIP')
?require('./services/compact/snipCompact.js') :null


　　這里面還有個(gè)「斷路器」機(jī)制讓我印象深刻，在負(fù)責(zé)自動(dòng)壓縮的services/compact/autoCompact.ts文件里：

　　// services/compact/autoCompact.ts — 斷路器
// Stop trying autocompact after this many consecutive failures.
// BQ 2026-03-10: 1,279 sessions had 50+ consecutive failures
// (up to 3,272) in a single session, wasting ~250K API calls/day globally.
constMAX_CONSECUTIVE_AUTOCOMPACT_FAILURES =3


　　看到注釋中的那串?dāng)?shù)字了嗎？

　　2026 年 3 月 10 號(hào)他們統(tǒng)計(jì)發(fā)現(xiàn)有 1279 個(gè)會(huì)話連續(xù)壓縮失敗了 50 次以上，最夸張的一個(gè)會(huì)話連續(xù)失敗了 3272 次還在不停重試，全球每天浪費(fèi) 25 萬(wàn)次 API 調(diào)用！

　　要是讓我這種老倒霉蛋遇上了，光 token 費(fèi)就夠我吃一個(gè)月的了，這要是曝光出來(lái)公關(guān)團(tuán)隊(duì)怕是有的忙了……

　　所以他們加了這個(gè)斷路器，連續(xù)失敗 3 次就自動(dòng)停下來(lái)。

　　八、安全審查

　　用 Claude Code 的時(shí)候你可以開(kāi)啟--dangerously-skip-permissions模式（也叫 YOLO 模式），跳過(guò)所有權(quán)限確認(rèn)，讓 AI 自己干活。

　　我之前一直以為這模式就是完全不設(shè)防了，看了源碼才知道，其實(shí)背后還偷偷跑著一個(gè)「影子 AI」在幫你把關(guān)。

　　源碼里有個(gè)文件叫utils/permissions/yoloClassifier.ts，每次主 AI 要執(zhí)行操作，這個(gè)獨(dú)立的 AI 分類器都會(huì)過(guò)一遍：

　　// utils/permissions/yoloClassifier.ts — YOLO 安全分類器
exportasyncfunctionclassifyYoloAction(
toolName:string,
toolInput: Record,
// ...
):Promise<'allow' | 'soft_deny' | 'hard_deny'>{
// 用一個(gè)獨(dú)立的模型來(lái)判斷這個(gè)操作安不安全
// allow: 安全的，直接放行
// soft_deny: 有風(fēng)險(xiǎn)，降級(jí)成需要手動(dòng)確認(rèn)
// hard_deny: 直接攔截，沒(méi)得商量
}


　　而且權(quán)限系統(tǒng)不只有 YOLO Classifier 一個(gè)檢查點(diǎn)。一次工具調(diào)用要過(guò)的關(guān)卡至少包括：

　　 你當(dāng)前的運(yùn)行模式（Plan / Auto / Bypass）

　　 用戶在 hooks 里設(shè)的自定義規(guī)則

　　 YOLO Classifier 的模型分析

　　 Bash 命令危險(xiǎn)度分類（像 rm -rf 這種直接攔截）

　　 配置文件里的規(guī)則引擎

　　多個(gè)來(lái)源的權(quán)限結(jié)果還有競(jìng)爭(zhēng)關(guān)系，最終取最嚴(yán)格的那個(gè)。

　　其中第 4 點(diǎn) Bash 命令安全檢查的嚴(yán)格程度遠(yuǎn)超我的預(yù)期。在tools/BashTool/bashSecurity.ts這個(gè)文件里，定義了23 種安全檢查規(guī)則：

　　// tools/BashTool/bashSecurity.ts — Bash 安全檢查 ID
constBASH_SECURITY_CHECK_IDS = {
INCOMPLETE_COMMANDS:1, // 殘缺命令（以 tab 或 - 開(kāi)頭）
JQ_SYSTEM_FUNCTION:2, // jq 的 system() 函數(shù)調(diào)用
OBFUSCATED_FLAGS:4, // 混淆的命令行參數(shù)
SHELL_METACHARACTERS:5, // 危險(xiǎn)的 shell 元字符
DANGEROUS_VARIABLES:6, // 危險(xiǎn)環(huán)境變量注入
IFS_INJECTION:11, // IFS 變量注入
PROC_ENVIRON_ACCESS:13, // /proc/environ 訪問(wèn)
CONTROL_CHARACTERS:17, // 控制字符
UNICODE_WHITESPACE:18, // Unicode 空白字符欺騙
ZSH_DANGEROUS_COMMANDS:20, // Zsh 危險(xiǎn)命令（zmodload 等）
COMMENT_QUOTE_DESYNC:22, // 注釋與引號(hào)狀態(tài)不同步
QUOTED_NEWLINE:23, // 引號(hào)內(nèi)換行
// ... 共 23 種
}


　　比如第 18 條的UNICODE_WHITESPACE，說(shuō)明 Anthropic 的安全團(tuán)隊(duì)考慮過(guò)用 Unicode 零寬空格來(lái)混淆命令的攻擊手法，讓安全檢查器看到的和 shell 實(shí)際執(zhí)行的不是同一條命令。還有第 20 條針對(duì) Zsh 的zmodload命令，這個(gè)命令能加載模塊繞過(guò)常規(guī)的文件和網(wǎng)絡(luò)檢查，總之防護(hù)做的還是很周到的。

　　怪不得我開(kāi)著全部放行模式用了這么久，從來(lái)沒(méi)出過(guò)什么嚴(yán)重事故，原來(lái)是有一套多層機(jī)制在背后替我負(fù)重前行。

　　九、Feature Flag 和未來(lái)功能

　　在 Claude Code 的源碼中，你會(huì)經(jīng)常看到feature('XXX')的判斷：

　　// tools.ts — Feature Flag 條件加載
constSleepTool = feature('PROACTIVE') || feature('KAIROS')
?require('./tools/SleepTool/SleepTool.js').SleepTool :null

constWebBrowserTool = feature('WEB_BROWSER_TOOL')
?require('./tools/WebBrowserTool/WebBrowserTool.js').WebBrowserTool :null


　　這就是 Feature Flag 功能開(kāi)關(guān)，做開(kāi)發(fā)的同學(xué)應(yīng)該都不陌生。每個(gè)實(shí)驗(yàn)功能都藏在開(kāi)關(guān)后面，可以按用戶、按環(huán)境灰度發(fā)布。這樣萬(wàn)一出了問(wèn)題，就不用回滾代碼，直接關(guān)掉開(kāi)關(guān)就行。通過(guò)條件require，關(guān)掉的功能在打包時(shí)還能被 tree-shaking 掉，不增加體積。

　　有趣的是，這些 Feature Flag 等于無(wú)意中泄露了 Claude Code 的產(chǎn)品路線圖：

　　1）KAIROS：長(zhǎng)期助手模式，AI 可以 24 小時(shí)持續(xù)運(yùn)行不結(jié)束。里面還有個(gè) AutoDream 自動(dòng)做夢(mèng)功能，名字起得很是浪漫，說(shuō)白了就是 AI 白天干活記筆記，晚上自動(dòng)整理記憶。

　　2）COORDINATOR_MODE：多 Agent 協(xié)作，一個(gè) AI 指揮多個(gè) AI 干活。

　　從coordinatorMode.ts能看到，它的工作流分四個(gè)階段：

　　// coordinator/coordinatorMode.ts — 協(xié)調(diào)者工作流定義
| Phase | Who | Purpose |
|----------------|--------------------|---------------------------------------------------------|
| Research | Workers (parallel) | Investigate codebase, find files, understand problem |
| Synthesis | You (coordinator) | Read findings, craft implementation specs |
| Implementation | Workers | Make targeted changes per spec, commit |
| Verification | Workers | Test changes work |


　　子智能體之間通過(guò)utils/mailbox.ts里的 Mailbox（一個(gè)基于文件的消息隊(duì)列）來(lái)通信。

　　還有 VOICE_MODE 語(yǔ)音模式、WEB_BROWSER_TOOL 瀏覽器操作工具等等。

　　十、反蒸餾和臥底模式

　　Anthropic 為了防止競(jìng)爭(zhēng)對(duì)手竊取 Claude Code 的能力、以及防止內(nèi)部信息通過(guò)開(kāi)源貢獻(xiàn)泄露，在源碼里埋了兩套防御機(jī)制。（但沒(méi)想到這波泄露了個(gè)大的 ）

　　先說(shuō)反蒸餾。有些競(jìng)爭(zhēng)對(duì)手可能會(huì)通過(guò)錄制 Claude Code 的 API 流量來(lái)「蒸餾」它的能力，就是把大模型的輸入輸出錄下來(lái)，用來(lái)訓(xùn)練自己的小模型。

　　Anthropic 的應(yīng)對(duì)策略簡(jiǎn)直絕了，直接往 API 請(qǐng)求里注入假工具定義：

　　// services/api/claude.ts — 負(fù)責(zé)模型 API 調(diào)用
// Anti-distillation: send fake_tools opt-in for 1P CLI only
if(feature('ANTI_DISTILLATION_CC')
&& process.env.CLAUDE_CODE_ENTRYPOINT ==='cli'
&& shouldIncludeFirstPartyOnlyBetas()
) {
result.anti_distillation = ['fake_tools']
}


　　做防御不是單純加密或者限速，而是主動(dòng)給你喂假數(shù)據(jù)，讓你拿去訓(xùn)練的模型越訓(xùn)越差，有點(diǎn)兒反間計(jì)的意思。

　　而且它只在 Anthropic 官方的命令行客戶端，也就是你在終端里直接用claude命令的場(chǎng)景中才生效，通過(guò) SDK 或其他方式接入的不受影響。

　　再說(shuō)臥底模式，Anthropic 內(nèi)部員工用 Claude Code 往開(kāi)源項(xiàng)目提交代碼時(shí)，會(huì)自動(dòng)啟用這個(gè)模式：

　　// utils/undercover.ts — 負(fù)責(zé)隱藏 AI 貢獻(xiàn)痕跡
/**
* Undercover mode — safety utilities for contributing to public repos.
* When active, Claude Code strips all attribution to avoid leaking internal
* model codenames, project names, or other Anthropic-internal information.
* The model is not told what model it is.
*
* There is NO force-OFF. This guards against model codename leaks.
*/

exportfunctionisUndercover():boolean{
if(process.env.USER_TYPE ==='ant') {
if(isEnvTruthy(process.env.CLAUDE_CODE_UNDERCOVER))returntrue
// Auto: active unless we've confirmed we're in an internal repo.
returngetRepoClassCached() !=='internal'
}
returnfalse
}


　　注釋里寫(xiě)得很明確：「There is NO force-OFF」，不能強(qiáng)制關(guān)閉。而且從代碼邏輯看，默認(rèn)就是開(kāi)啟的，只有當(dāng)倉(cāng)庫(kù)被確認(rèn)為內(nèi)部倉(cāng)庫(kù)時(shí)才會(huì)關(guān)掉。說(shuō)明 Anthropic 非常擔(dān)心內(nèi)部模型代號(hào)通過(guò)開(kāi)源貢獻(xiàn)泄露出去。

　　十一、其他細(xì)節(jié)

　　最后分享幾個(gè)源碼里藏著的有趣細(xì)節(jié)。

　　1）在buddy/目錄下，Anthropic 的工程師居然偷偷藏了一套數(shù)字寵物系統(tǒng)！

　　一共 18 種物種，從鴨子到仙人掌應(yīng)有盡有：

　　// buddy/types.ts — 虛擬寵物物種定義
exportconstSPECIES = [
duck, goose, blob, cat, dragon, octopus, owl, penguin,
turtle, snail, ghost, axolotl, capybara, cactus, robot,
rabbit, mushroom, chonk,
]asconst


　　這個(gè)功能原本計(jì)劃 4 月份作為彩蛋預(yù)熱、5 月正式上線，結(jié)果源碼泄露了提前被大家發(fā)現(xiàn)了。AI 寫(xiě)代碼寫(xiě)累了，然后擼擼 AI 寵物，Anthropic 的工程師也太會(huì)整活了。

　　2）還有個(gè)小細(xì)節(jié)，因?yàn)?Claude 之前老是浪費(fèi)一輪對(duì)話去執(zhí)行mkdir檢查目錄存不存在，工程師們直接在memdir/memdir.ts里硬編碼了一行提示，告訴 AI “這個(gè)目錄已經(jīng)存在了，直接用 Write 工具往里寫(xiě)就行，不要再跑 mkdir 或者檢查目錄是否存在了！”

　　// memdir/memdir.ts
// Shipped because Claude was burning turns on `ls`/`mkdir -p` before writing.
exportconstDIR_EXISTS_GUIDANCE =
'This directory already exists — write to it directly with the Write tool
(do not run mkdir or check for its existence).'


　　3）Claude Code 對(duì)啟動(dòng)速度有一種近乎偏執(zhí)的追求。

　　比如在入口文件cli.tsx里，--version這種最簡(jiǎn)單的請(qǐng)求一個(gè)模塊都不加載，直接返回；其他路徑全部用await import()動(dòng)態(tài)加載，按需引入。

　　更絕的是，在加載主模塊的這幾百毫秒里，它會(huì)同時(shí)啟動(dòng)一個(gè)「早期輸入捕獲器」（utils/earlyInput.ts），把你在等待時(shí)敲的鍵都緩存起來(lái)，模塊加載完之后再回放，讓你感覺(jué) “剛敲完就有反應(yīng)了”。

　　初始化階段還會(huì)偷偷發(fā)一個(gè) TCP 預(yù)連接（utils/apiPreconnect.ts），讓 TCP+TLS 握手和初始化工作并行跑，省掉 100ms 左右的等待時(shí)間。

　　// utils/apiPreconnect.ts — TCP 預(yù)連接
/**
* Preconnect to the Anthropic API to overlap TCP+TLS handshake with startup.
* The TCP+TLS handshake is ~100-200ms that normally blocks inside the first
* API call. Kicking a fire-and-forget fetch during init lets the handshake
* happen in parallel with action-handler work.
*/
最后聊幾句

　　看完這份源碼，你會(huì)發(fā)現(xiàn) Claude Code 里其實(shí)沒(méi)什么驚天動(dòng)地的新算法，用的基本上都是程序員接觸過(guò)的基礎(chǔ)知識(shí)，比如并發(fā)控制、讀寫(xiě)分離、分層緩存、斷路器、功能開(kāi)關(guān)等等……

　　但是 Claude Code 團(tuán)隊(duì)把這些東西組合到了 AI 場(chǎng)景里，打造出了一個(gè)極其優(yōu)秀的產(chǎn)品，所以說(shuō)計(jì)算機(jī)的基礎(chǔ)知識(shí)和設(shè)計(jì)思想很重要。

　　這份源碼也是目前最好的 AI 應(yīng)用架構(gòu)教材了。像 Agent 循環(huán)怎么寫(xiě)、工具系統(tǒng)怎么設(shè)計(jì)、記憶怎么管理、安全怎么做，答案全在里面。簡(jiǎn)歷上如果能寫(xiě)上 “深度閱讀了 Claude Code 源碼并應(yīng)用于自己的項(xiàng)目”，那絕對(duì)是加分項(xiàng)。

　　至于說(shuō)這次泄露對(duì) Claude Code 有多大影響嘛…… 我覺(jué)得其他做 AI 編程工具的競(jìng)爭(zhēng)對(duì)手們肯定開(kāi)心壞了，大家也學(xué)到知識(shí)（吃到瓜）了，我也有流量了，用 Claude Code 的人更多了，可以說(shuō)是皆大歡喜。

　　而且就算有人家的源碼，也很難跟人家這種有資源的專業(yè)團(tuán)隊(duì)去競(jìng)爭(zhēng)呀，你就像我開(kāi)源出來(lái)一個(gè) yupi-code 估計(jì)也沒(méi)人用吧？

　　話說(shuō)我最近正好在自己的 魚(yú)皮 AI 導(dǎo)航網(wǎng)站 上更新 Claude Code 相關(guān)的教程，萬(wàn)萬(wàn)沒(méi)想到竟然從源碼開(kāi)始講起了。如果你想更系統(tǒng)地學(xué)習(xí) AI 編程工具的使用方法、項(xiàng)目實(shí)戰(zhàn)、經(jīng)驗(yàn)技巧和原理，可以關(guān)注一波，后續(xù)持續(xù)更新。