簡介Anthropic 官方 Claude Code 命令行工具的完整源代碼壓縮包2026年4月1日版面向 AI 編程助手研發(fā)者、CLI 工具愛好者和希望深入理解 MCP 協(xié)議、Agent 工具鏈及終端交互設(shè)計的中高級開發(fā)者是一份適合源碼級拆解與二次開發(fā)的基礎(chǔ)參考。源碼在 src 目錄下按職責(zé)清晰分層commands 實現(xiàn)斜杠命令components 與 design-system 負(fù)責(zé)終端 UIservices 包含 API、MCP、分析、設(shè)置同步等核心服務(wù)tools 提供 Bash、文件讀寫、Grep、Glob、Task 等工具另含 hooks、schemas、ink 等基礎(chǔ)模塊模塊劃分完整類型定義清晰方便逐一研讀。壓縮包共 1903 個文件以 TypeScript 為主其中 1332 個 ts 與 552 個 tsx 分別承載純邏輯與 UI 組件另有少量 js 和 1 個 md 說明文件包體大小約 9.43MB。目前已有 707 人學(xué)習(xí)下載。通過通讀源碼可掌握 Claude Code 的命令調(diào)度機(jī)制、工具封裝方式、MCP 通信設(shè)計以及終端交互渲染邏輯對自研 AI 編程助手或二次開發(fā)腳手架具有直接參考價值尤其適合研究工具調(diào)用、上下文維護(hù)與權(quán)限控制等核心實現(xiàn)。1. 源碼泄露先看一眼日期再決定要不要激動“Claude Code源碼泄露”這個標(biāo)題真正值得先看的不是內(nèi)容而是日期。4月1日懂的都懂。這幾天確實有技術(shù)群里在轉(zhuǎn)一個幾百 MB 的壓縮包配文是“限時刪除”“錯過再無”這類話術(shù)。作為一個被各種假源碼坑過的人我的第一反應(yīng)不是下載而是問三個問題官方發(fā)布形態(tài)里到底有沒有“源碼”這個概念如果真泄露了普通開發(fā)者拿到能做什么如果是個釣魚包我能不能在五分鐘內(nèi)識別出來。這篇筆記就是圍繞這三個問題展開的。2. Claude Code 的發(fā)布形態(tài)與“源碼”的邊界npm包、打包產(chǎn)物、閉源推理層2.1 所謂的“源碼”在工程上其實分三層先說結(jié)論Claude Code 的發(fā)布形態(tài)是一個 npm 包安裝后本機(jī)跑的是打包壓縮過的 JavaScript 產(chǎn)物不是一份能直接閱讀、修改、重新構(gòu)建的 TypeScript 工程。所謂“源碼泄露”在工程上至少要拆成三個層次看待。第一層是 CLI 側(cè)邏輯包括命令行解析、會話管理、工具調(diào)用、權(quán)限確認(rèn)、日志輸出。這一層會以壓縮后的 dist 文件形式出現(xiàn)在你本機(jī)的 node_modules 里嚴(yán)格說它“可見”但變量名和函數(shù)名都被混淆過可讀性很差談不上“泄露”。第二層是 agent 循環(huán)的編排層官方術(shù)語里叫 harness。它負(fù)責(zé)把用戶的一句話目標(biāo)翻譯成多輪工具調(diào)用維護(hù)上下文狀態(tài)決定什么時候調(diào)用 read_file、什么時候執(zhí)行 bash、什么時候停下來問你要權(quán)限。這一層同樣打包在 npm 產(chǎn)物里。第三層是模型推理服務(wù)本身。真正的模型權(quán)重、推理邏輯、服務(wù)端調(diào)度都在遠(yuǎn)端CLI 進(jìn)程里只有一個 HTTP 客戶端。這一層是不可能通過一個“源碼壓縮包”泄露到你手里的因為它在任何本地分發(fā)鏈路中都不存在。所以當(dāng)你看到一個帖子聲稱“Claude Code 完整源碼泄露”先問它說的是哪一層。如果壓縮包里是幾千個 .ts 源文件且?guī)暾?.git 目錄反而說明它是別人重新整理過的二手工程如果聲稱包含模型服務(wù)端源碼那基本可以直接判斷為噱頭。2.2 從安裝到首次運行一條命令背后發(fā)生的事很多人搜“claude code安裝”“claude code下載安裝”以為裝完就能看到全套源碼其實安裝過程本身就說明了它的分發(fā)策略。最常見的安裝方式是全局 npm 安裝命令如下# 全局安裝 Claude Code 的官方 npm 包 npm install -g anthropic-ai/claude-code # 查看安裝后的可執(zhí)行文件 which claude # 常見輸出/usr/local/bin/claude - ../lib/node_modules/anthropic-ai/claude-code/cli.js安裝完成后npm 會在系統(tǒng)全局目錄下建立 bin 軟鏈把 cli.js 暴露成 claude 這個命令。你真正執(zhí)行的入口就是一個壓縮后的 JavaScript 文件它內(nèi)部再按需 require 同目錄下的一系列 chunk 文件。這里有幾個安裝時需要留神的參數(shù)和環(huán)境問題。Node.js 的版本要滿足官方要求太老的版本會在啟動時直接報語法錯誤因為打包產(chǎn)物使用了較新的 JS 語法。全局安裝目錄的寫權(quán)限也經(jīng)常出問題如果你之前改過 npm prefix或者用 sudo 裝過別的全局包后面會出現(xiàn) auto-update failed 一類的報錯這個我在第 4 章單獨講。網(wǎng)絡(luò)源方面npm registry 可以換成你網(wǎng)絡(luò)環(huán)境下訪問更快的鏡像節(jié)點但要注意鏡像節(jié)點的同步頻率官網(wǎng)已發(fā)布新版而你本地的鏡像還沒同步是很多“裝完還是舊版”的根源。第一次運行 claude 會要求完成登錄授權(quán)這是官方的賬號流程和源碼無關(guān)。在 VSCode 里配置 Claude Code本質(zhì)上也只是在集成終端里運行同一個 claude 命令不需要單獨的插件安裝很多教程把這件事復(fù)雜化了。2.3 真正值得研究的骨架harness、agent loop 與工具調(diào)用循環(huán)拋開“源碼”這個誘餌Claude Code 里真正有學(xué)習(xí)價值的是 harness 的工程設(shè)計而這些信息并不需要靠泄露包獲取。官方文檔中對 harness 的描述、CLI 自身的日志輸出、hook 機(jī)制、MCP 配置格式已經(jīng)把架構(gòu)輪廓暴露得很清楚。一個典型的 agent 循環(huán)是這樣運轉(zhuǎn)的用戶輸入目標(biāo) → 模型返回一個決策可能包含工具調(diào)用 → CLI 檢查該工具是否需要權(quán)限確認(rèn) → 執(zhí)行工具并把結(jié)果回填給模型 → 模型繼續(xù)決策 → 直到模型認(rèn)為任務(wù)完成。這個循環(huán)和很多開源 agent 框架的結(jié)構(gòu)一致差別在于實現(xiàn)細(xì)節(jié)工具結(jié)果如何截斷、上下文窗口滿了怎么辦、失敗的工具調(diào)用如何重試、權(quán)限確認(rèn)怎么不打斷用戶節(jié)奏。// 一個高度簡化的 agent loop 偽代碼 let messages [{ role: user, content: 把當(dāng)前目錄的 README 總結(jié)成 5 條要點 }] while (true) { const decision await model.chat(messages) // 調(diào)用模型 if (decision.tool_calls null) break // 不再要工具說明任務(wù)結(jié)束 for (const call of decision.tool_calls) { if (needPermission(call.name)) await confirm(call) // 關(guān)鍵交互點 const output await tools[call.name](call.arguments) // 執(zhí)行 messages.push({ role: tool, content: output }) // 回填結(jié)果 } if (messages.length 40) messages trimHistory(messages) // 控制窗口 }這段代碼里最值得品的是 needPermission 和 trimHistory 兩個點。前者是 agent 在真實工程環(huán)境中能落地的前提——工具權(quán)限不能全程自動放行否則一個錯誤指令就能刪庫后者決定了長任務(wù)的穩(wěn)定性窗口一滿簡單粗暴地丟棄早期消息會導(dǎo)致 agent 失去任務(wù)上下文這是很多自建 agent 翻車的常見原因。理解了 harness 與模型服務(wù)的關(guān)系就能回答一個常被問到的問題能不能把 Claude Code 的 harness 換成別的模型來跑。從架構(gòu)上看CLI 和模型服務(wù)之間是協(xié)議解耦的社區(qū)里也有人通過改環(huán)境變量里的接口地址和模型名把整個工具鏈指向兼容 OpenAI 協(xié)議的第三方服務(wù)。這件事和“源碼泄露”沒關(guān)系它恰恰說明協(xié)議層的研究價值高于追逐一個假泄露包。3. 判斷一個“Claude Code源碼包”的真?zhèn)嗡牟胶藢Ψ?.1 第一步核對包名、版本號與發(fā)布時間拿到一個號稱 Claude Code 源碼的壓縮包先別急著解壓。第一步是回到 npm registry核對官方真實的包名、版本號和發(fā)布時間。偽造者最容易犯的錯誤就是給一個根本不存在的版本號或者發(fā)布時間對不上。# 查官方包的最新版本號和各版本發(fā)布時間 npm view anthropic-ai/claude-code dist-tags --json npm view anthropic-ai/claude-code time --json # 查官方包名是否存在 npm view anthropic-ai/claude-code name versiondist-tags 里看 latest 字段這是當(dāng)前穩(wěn)定版的真實版本號。time 字段里能看到每一個版本的發(fā)布時間重點看 modified 時間它代表官方最近一次更新。如果壓縮包里的 README 聲稱自己是 5.x.x而 latest 明明是 2.x.x說明這個包要么是改名的翻版要么是故意夸大的噱頭。版本號相同也不能直接信任。很多釣魚包會把 README 改成和官方一模一樣但 package.json 里的 name、version、bin 字段被悄悄改過。所以下一步要做的不是讀 README而是對比 package.json 的完整字段和文件清單。3.2 第二步檢查文件清單和入口識別官方產(chǎn)物特征解壓之前可以先列清單。無論壓縮包是 tar.gz 還是 zip都可以在不解壓的情況下查看內(nèi)部文件列表這一步能暴露大量信息。# 查看 tar.gz 包內(nèi)的文件清單 tar -tzf claude-code-source.tar.gz | head -50 # 查看 zip 包內(nèi)的文件清單 unzip -l claude-code-source.zip | head -50官方 npm 包的文件結(jié)構(gòu)有兩個顯著特征根目錄一定有一個 package.jsonbin 字段指向一個 cli.js 入口主體代碼在 dist 或者 vendor 目錄下是一堆壓縮后的 js/chunk 文件。你可以看到 readme、license但不會看到一個完整的 src 目錄更不會有 .git 目錄。我見過把官方發(fā)布產(chǎn)物重打包成“源碼包”的例子也見過拿一個無關(guān)開源項目改標(biāo)題的例子兩種情況的文件清單截然不同。把常見特征整理成一份對比判斷時會快很多| 特征項 | 官方 npm 發(fā)布包 | 常見偽造“源碼包” | | 根目錄 | package.json README license | 一堆 src/、docs/ 目錄 | | 代碼位置 | dist/ 或 vendor/ 下壓縮產(chǎn)物 | 干凈整齊的 .ts/.js 源文件 | | .git 目錄 | 無 | 經(jīng)常出現(xiàn) | | 版本信息 | 和 registry 完全一致 | 常被改成更高的假版本 | | 文件體量 | 正常 CLI 的合理范圍 | 幾 KB 或明顯注水的大包 |這個表不能覆蓋所有情況但能幫你過濾掉八成以上的假包。真正需要繼續(xù)做硬核對的是那些文件結(jié)構(gòu)看起來很像官方產(chǎn)物的重打包包。3.3 第三步拉官方包做哈希與體積比對文件清單看著像還不夠第三步用哈希和體積做一次硬核對。npm 自帶 pack 命令可以把官方包完整下載成 tgz然后計算哈希和你的壓縮包對比。# 下載官方包到本地 npm pack anthropic-ai/claude-code # 生成類似 anthropic-ai-claude-code-2.x.x.tgz 的文件 # 計算官方包的哈希 shasum -a 256 anthropic-ai-claude-code-2.x.x.tgz # 計算你手上“泄露源碼包”的哈希 shasum -a 256 claude-code-source-4-1.tar.gz哈希完全一致的情況幾乎不存在因為兩個包的構(gòu)建時間和元數(shù)據(jù)不同但你可以看體積數(shù)量級。官方 CLI 打包出來是一個正常工具鏈該有的大小如果你手上的“完整源碼”只有 200KB那它連官方產(chǎn)物都未必是更別談源碼。反過來如果自稱源碼的包體積異常巨大里面大概率塞了一堆不相關(guān)的資源文件撐體積。這里有一個容易誤導(dǎo)人的點哈希不一致不能證明它是假的它可能是某一次構(gòu)建快照但哈希不一致加上文件結(jié)構(gòu)和版本對不上三個證據(jù)疊加基本可以下判斷。還有一個更直接的檢查方向打開壓縮包里的 JS 文件隨便抽幾段搜有沒有官方域名、官方 CLI 標(biāo)志性的提示語、以及產(chǎn)物混淆痕跡。一個聲稱“源碼”的包里沒有這些字符串說明它和真正的 Claude Code 關(guān)系不大。3.4 第四步斷網(wǎng)最小啟動盯住網(wǎng)絡(luò)行為文件和哈希都核對完還有一種情況需要實測包是別人重打包的官方產(chǎn)物但被注入了后門邏輯。這時候要做的不是直接在主力環(huán)境里登錄運行而是找一個隔離環(huán)境做一次啟動觀察。# 在隔離目錄里直接調(diào)用入口腳本先看它打印什么 cd /tmp/inspect-source node cli.js --help # Linux 上用 strace 觀察網(wǎng)絡(luò)相關(guān)系統(tǒng)調(diào)用 strace -f -e tracenetwork node cli.js --help 21 | head -50第一次運行建議加 --help 或者直接傳一個無害參數(shù)目的不是完成任務(wù)而是看它的啟動過程有沒有超出預(yù)期的行為。如果它突然開始請求一個陌生域名、往臨時目錄寫奇怪的文件、嘗試讀取 ~/.ssh 或 ~/.aws 下的密鑰那這就是一個帶后門的重打包包。需要特別強(qiáng)調(diào)的是不要在主力環(huán)境、不要用真實賬號去試運行一個來源不明的包。我見過拿到包就迫不及待登錄官方賬號跑 demo 的開發(fā)者結(jié)果賬號密鑰通過環(huán)境變量被腳本讀走幾分鐘后就看到了異地登錄提醒。所謂的“泄露源碼”驗證安全優(yōu)先級永遠(yuǎn)是第一位。4. 號稱泄露的源碼包避坑記錄五分鐘內(nèi)出現(xiàn)這些現(xiàn)象就該停手4.1 現(xiàn)象裝完CPU占用異常飆升現(xiàn)象描述解壓后照著 README 運行安裝腳本機(jī)器風(fēng)扇馬上狂轉(zhuǎn)CPU 占用率沖到 90% 以上而且沒有任何窗口顯示任務(wù)進(jìn)度。原因分析這類“源碼包”里通常帶一個安裝腳本腳本在后臺拉取并執(zhí)行了挖礦模塊。挖礦程序為了不被立刻察覺往往把自己寫成無界面守護(hù)進(jìn)程占用率又不做限流結(jié)果就是整機(jī)卡頓。解決思路立即斷開網(wǎng)絡(luò)用 htop 按 CPU 排序找出可疑進(jìn)程并 kill再去檢查 crontab、開機(jī)自啟目錄和 /tmp 下的臨時文件。然后把全局 node_modules 里那個可疑包徹底刪掉改回官方 npm 源重裝。這個處理順序很重要先斷網(wǎng)再做清理否則挖礦程序會從遠(yuǎn)端拉取新版繼續(xù)運行。4.2 現(xiàn)象一運行就要求安裝“Python依賴包”現(xiàn)象描述運行時腳本提示“缺少環(huán)境依賴需要執(zhí)行 python 安裝命令”給出的命令里含有一段你從沒見過的一大串 --index-url 參數(shù)。原因分析這是典型的供應(yīng)鏈注水手法。安裝腳本在安裝階段通過自定義 pip 源把惡意 Python 包混進(jìn)環(huán)境后續(xù)通過 Python 進(jìn)程執(zhí)行命令。偽造者預(yù)判了你的好奇心把“安裝依賴”包裝成常規(guī)初始化動作用戶很容易習(xí)慣性回車執(zhí)行。解決思路任何時候都不要直接執(zhí)行 README 或 install.sh 里給的安裝命令。先打開腳本讀一遍head -80 install.sh看里面有哪些外聯(lián)地址、有沒有 base64 解碼、有沒有把內(nèi)容重定向到某個 URL。一旦看到類似 curl xxx | bash 或 python -c “…” 的結(jié)構(gòu)果斷停手。如果已經(jīng)執(zhí)行了檢查 pip list 里是否多了和項目無關(guān)的包再看 ~/.bashrc 是否被追加了可疑行。4.3 現(xiàn)象配置目錄里藏著無法解釋的外聯(lián)地址現(xiàn)象描述包自帶的“激活腳本”往 ~/.claude 下寫入了 settings.json打開后里面多了一個你在官方文檔里沒見過的 apiBaseUrl 或 endpoint 字段指向某個陌生地址。原因分析這類配置把模型請求的流量轉(zhuǎn)發(fā)到第三方服務(wù)器。Claude Code 這類 CLI 是按協(xié)議和遠(yuǎn)端服務(wù)通信的配置文件里的接口地址、認(rèn)證密鑰就是流量入口。被篡改后你的授權(quán)信息會隨每次請求一并發(fā)送給攻擊者。解決思路檢查 ~/.claude 目錄下所有 json 配置對照官方文檔確認(rèn)哪些字段是合法的。出現(xiàn)不在官方文檔里的 apiBaseUrl、代理地址、自定義證書路徑直接刪除對應(yīng)字段或整份配置。修改配置后重啟 CLI再看日志輸出里的請求地址是否恢復(fù)為官方域名。4.4 現(xiàn)象auto-update failed: no write permission to npm prefix現(xiàn)象描述裝了某個來源不明的包之后啟動 claude 時報 auto-update failed: no write permission to npm prefix自更新一直失敗但命令行本體能跑。原因分析這個問題其實不一定是惡意包引起的更多是全局 npm 目錄權(quán)限不對。npm 的全局 prefix 指向 /usr/lib/node_modules 或 /usr/local/lib/node_modules如果之前用 sudo 裝過包目錄所有者被改成了 root后續(xù)以普通用戶運行 claude 時自更新就寫不進(jìn)去。所謂“破解版”經(jīng)常遇到這個報錯因為它的安裝方式改了目錄權(quán)限。解決思路先看 prefix 指向哪里再修正目錄所有者不要用 chmod 777 這種一刀切方式。npm prefix -g ls -ld $(npm prefix -g) sudo chown -R $(whoami) $(npm prefix -g)修正后再跑 claude 的自動更新確認(rèn)能順利拉到新版這本身也能驗證你裝的包是否還和官方更新通道連通。如果 chown 之后啟動仍然報錯說明這臺機(jī)器的 node 安裝路徑本身有問題可以考慮改用用戶級目錄重新安裝但不要因此輕易卸掉系統(tǒng) node容易造成其它全局命令同時失效。4.5 現(xiàn)象提示“源碼已加密”交錢才給解壓密碼現(xiàn)象描述壓縮包解壓到一半彈出提示說主目錄被 AES 加密聯(lián)系發(fā)布者付費才能拿到密碼。這是最直接的信號。原因分析這已經(jīng)不是“源碼泄露”問題了是拿泄露噱頭做引流或騙局。所謂“限時刪除”“交押金看源碼”本質(zhì)是利用白嫖心理讓人付費。真正的開源或泄露內(nèi)容不會用加密套娃的方式分發(fā)。解決思路不付款不聯(lián)系直接放棄這個包。也不要因為好奇去運行它附帶的主程序加密可能只是個幌子主程序一旦執(zhí)行就可能干別的事。對這類包的正確處置是記錄文件名和來源渠道然后刪除再回到官方 npm 渠道裝一遍正規(guī)產(chǎn)品。5. 不追泄露也能拆開學(xué)基于官方安裝產(chǎn)物的工程梳理與最小復(fù)刻5.1 從 package.json 和 dist 入口反推啟動鏈路不追偽造的泄露包官方安裝產(chǎn)物里的工程信息已經(jīng)足夠?qū)W一陣。安裝完成后先定位全局包目錄把 package.json 和文件結(jié)構(gòu)讀一遍。NODE_PATH$(npm root -g) ls -la $NODE_PATH/anthropic-ai/claude-code cat $NODE_PATH/anthropic-ai/claude-code/package.json # 用 node 直接讀取關(guān)鍵字段 node -e const prequire($NODE_PATH/anthropic-ai/claude-code/package.json); console.log(version:, p.version); console.log(bin:, JSON.stringify(p.bin)); console.log(main:, p.main)package.json 里的 bin 映射能告訴你 claude 命令實際指向哪個入口main 字段則標(biāo)記了庫模式下的入口。順著 cli.js 打開能看到它 require 了哪些模塊這個依賴關(guān)系就是啟動鏈路的地圖。讀這一層時重點不是讀懂每一行混淆代碼而是記錄模塊名和文件大小找出哪些 chunk 被入口直接依賴、哪些是懶加載。懶加載文件通常對應(yīng)按需功能比如某個特定工具或某種登錄方式啟動時不會被立即執(zhí)行。這種靜態(tài)分析習(xí)慣比追一個假泄露包能積累更扎實的工程判斷力。5.2 用字符串搜索定位 agent loop 的關(guān)鍵節(jié)點打包產(chǎn)物雖然被壓縮混淆但字符串常量不會被全部抹掉。工具名稱、權(quán)限提示語、錯誤信息、日志模板這些字符串會原樣留在產(chǎn)物文件里。用 grep 做一次字符串挖掘就能還原 agent loop 的大致地圖。NODE_PATH$(npm root -g) CLAUDE_DIR$NODE_PATH/anthropic-ai/claude-code # 列出所有工具相關(guān)的字符串 grep -roh read_file\|execute_command\|write_file\|notify $CLAUDE_DIR | sort | uniq -c | sort -rn | head -20 # 檢索權(quán)限確認(rèn)提示語 grep -roh permission\|allow\|deny $CLAUDE_DIR/dist | sort | uniq -c | sort -rn | head -20grep 結(jié)果里出現(xiàn)頻率高的工具名基本就是 agent 默認(rèn)開放的工具集權(quán)限相關(guān)字符串的密度能告訴你哪些操作默認(rèn)需要確認(rèn)。把這些字符串和一個實際的運行日志對照看你會發(fā)現(xiàn)模型的 tool_calls 參數(shù)名、CLI 內(nèi)部的事件名、日志里打印的字段名是一一對應(yīng)的。這個方法的妙處在于完全基于官方產(chǎn)物合法且可持續(xù)。每次官方更新版本重新跑一遍字符串挖掘還能看到新增工具和變更提示語相當(dāng)于一份自動生成的版本差異說明。如果你要寫自己的 agent這些字符串就是現(xiàn)成的兼容性參考。5.3 一份最小可運行的“harness”骨架前面分析了這么多最終價值應(yīng)該落在能動手。我經(jīng)常給同事看的一份最小 agent 骨架長這樣它只有一個 read_file 和一個 bash 工具通過一個循環(huán)把模型決策和工具執(zhí)行串起來。代碼刻意精簡目的是展示 harness 的核心機(jī)制不是復(fù)刻產(chǎn)品。import os import subprocess TOOLS { read_file: lambda path: open(path, encodingutf-8).read(), bash: lambda cmd: subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue ).stdout, } def call_model(messages: list[dict]) - dict: # 這里通過任意兼容 OpenAI 協(xié)議的端點調(diào)用模型 # 需要設(shè)置環(huán)境變量 LLM_ENDPOINT 和 LLM_MODEL endpoint os.getenv(LLM_ENDPOINT) model os.getenv(LLM_MODEL) # 省略 HTTP 請求細(xì)節(jié)返回模型的響應(yīng) JSON raise NotImplementedError(用你手頭的模型服務(wù)補(bǔ)全這段) def agent_loop(task: str, max_turns: int 5) - None: messages [{role: user, content: task}] for _ in range(max_turns): resp call_model(messages) tool_calls resp.get(tool_calls) if not tool_calls: print(resp[content]) return for call in tool_calls: name call[function][name] args call[function][arguments] result TOOLS[name](args) # 執(zhí)行工具 messages.append({role: tool, tool_call_id: call[id], content: result}) print(達(dá)到最大輪次停止。)這段骨架里的關(guān)鍵參數(shù)是 max_turns它決定了 agent 不會因為模型反復(fù)請求工具而進(jìn)入死循環(huán)。TOOLS 字典是工具白名單不加新工具模型就無法調(diào)用它。實際運行前應(yīng)該把環(huán)境變量配好并確認(rèn) TOOLS 里每個函數(shù)都能處理異常工具拋錯會直接中斷整個循環(huán)這是新手最容易翻車的地方。從這個骨架再往前邁一步就是權(quán)限確認(rèn)、消息歷史裁剪、工具結(jié)果截斷。每一步都是在解決真實場景里的一個問題而不是追逐一份來路不明的源碼。理解了這些再回頭看“源碼泄露”的標(biāo)題你會發(fā)現(xiàn)真正該學(xué)的部分從來不在那個壓縮包里。6. 一個具體習(xí)慣拿到任何代碼包先“三查三試”再動手把前面五章的思路濃縮成一條可執(zhí)行的習(xí)慣就是三查三試。三查一查包名和版本是否與官方 registry 對得上二查文件清單里有沒有不該在發(fā)布包里出現(xiàn)的東西比如源碼目錄、.git、加密提示、安裝腳本外聯(lián)三查解壓后的配置和腳本內(nèi)容重點看 api 地址、密鑰路徑、base64 解碼段。三試一試試在隔離目錄里不用主力工作目錄二試先斷網(wǎng)或最小權(quán)限跑 --help觀察有沒有意外外聯(lián)三試看日志和進(jìn)程列表確認(rèn)沒有多余的子進(jìn)程常駐。這個習(xí)慣在分析任何來源的第三方包時都通用不只是 Claude Code。源碼泄露的瓜每年都有但絕大多數(shù)最后都被證偽成引流工具或釣魚包真正值得投入時間的是理解一個成熟 CLI 的發(fā)布形態(tài)和 agent 循環(huán)的骨架設(shè)計。這些年我養(yǎng)成的習(xí)慣是任何來路不明的包都不直接進(jìn)工作目錄先解壓到 /tmp 看一眼腳本再決定。這個習(xí)慣幫我避開了很多麻煩不只是挖礦腳本還有各種偽裝成工具包的引流陷阱。希望這篇筆記能幫你在下次看到“完整源碼”標(biāo)題時先花五分鐘做三查三試而不是被 4 月 1 日的時間戳帶著走。希望幫到你。本文還有配套的精品資源點擊獲取