大家好，我是 PaperAgent，不是 Agent！
昨天，Anthropic 的 Claude Code 原始碼意外公開了，想必大家都注意到了。已經獲得 76k star。
從 cli.js.map 還原出 4756 個原始檔後，我連續幾週泡在這堆程式碼裡，像考古一樣把它的系統提示詞、Agent 排程鏈、工具執行流程、權限模型、Hook 機制、Skill 生態……一塊塊拆開來看。
說實話，拆解之前我預想過它很強。但拆解完之後，我的感受遠不只是「強」——我看到的是一個設計理念上的代際差。
很多人以為 Claude Code 強在模型本身，或者強在某一段「神秘的 system prompt」。但真正拆開原始碼後你會發現：這些都不對。
它的強，來自一套被精心設計、工程化落地的 Agentic Harness。
這個概念不是我自己編的。Anthropic 官方文件裡寫得清清楚楚：
翻譯過來就是：Claude Code 整個系統，就是套在 Claude 外面的那個 Harness。
它提供的不只是一個聊天介面，而是一整套「讓模型變成可執行 Agent」的執行時期框架：工具怎麼呼叫、權限怎麼控制、上下文怎麼管理、子任務怎麼編排、Hook 怎麼攔截……全都在這層 harness 裡被制度化、產品化了。
很多人複刻 coding agent 時，只拿走了一個 system prompt + 檔案編輯工具 + Bash + CLI 殼。但拆解完 Claude Code 的原始碼後我意識到：真正拉開差距的，根本不是這幾樣東西。
今天這篇文章，我就把自己在原始碼裡看到的那些「真正的差距」，掰開揉碎了講給你聽。
https://x.com/ScarlettWeb3/status/2038940065523552263/photo/1
01 它不是一段 Prompt，而是一個 Operating Model
先看一個最容易被誤解的問題：Claude Code 的 system prompt 到底有多神秘？
我一開始也以為，打開 prompts.ts 就能看到一篇「神諭」。但實際打開之後，我看到的是一套 Prompt Assembly Architecture。
getSystemPrompt() 根本不是回傳一段靜態文字，它做的事情遠比這複雜：
先拼靜態前綴：身份定位、系統規範、任務哲學、風險動作規範、工具使用規範……
再注入動態後綴：session guidance、memory、MCP instructions、scratchpad、token budget、output style……
而且原始碼裡明確存在 SYSTEM_PROMPT_DYNAMIC_BOUNDARY，註解直接寫明：邊界前盡量可快取，邊界後是會話特定內容，不能亂改，否則破壞快取邏輯。
這意味著什麼？
意味著 Anthropic 連 system prompt 的 Token 成本與快取命中率都做了工程化最佳化。他們不是把「能想到的都塞進 prompt」，而是把 prompt 當作可編排的執行時期資源來管理。
靜態部分適合快取，動態部分按需注入。這種做法在成本控制上，比「一股腦全部塞進」的提示詞高出不止一個維度。
但這只是冰山一角。
https://x.com/jungeAGI/status/2039007004333932929
02 它把良好行為制度化
再看一個讓我印象深刻的細節：getSimpleDoingTasksSection() 這一段，基本可以看作 Anthropic 對 AI 工程師行為規範的制度化表達。
它非常明確地約束模型：
這一段的意義，遠不止「prompt 寫得細」。它揭示了一個本質：Claude Code 不把「好習慣」交給模型即興發揮，而是寫進規則裡，強制執行。
很多 coding agent 不穩定，不是因為模型不會寫程式，而是因為行為發散。同一個需求，今天能跑通，明天可能就給你來一輪「過度重構 + 加一堆註解 + 順便改個無關檔案」的取巧作法。
Claude Code 用這套制度化的約束，把行為方差壓到了最低。
同樣制度化的，還有風險動作規範：destructive operations、hard-to-reverse operations、修改共享狀態、上傳第三方工具……全部被標記為「需要確認」。原始碼裡明確要求：發現陌生狀態先調查，merge conflict/lockfile 不要粗暴刪。
這是一種 blast radius 思維——把「破壞範圍」寫進模型的行為準則裡。
03 它深知上下文是稀缺資源
拆解原始碼的過程中，另一個讓我反覆感嘆的點是：Anthropic 對上下文的珍惜程度，遠超大多數人的想像。
大量設計都在圍繞上下文做最佳化：
system prompt 的動靜邊界 + cache boundary
fork path 共享父執行緒的 prompt cache
skill 按需注入，不塞進全域 prompt
MCP instructions 按連線狀態動態注入
function result clearing、summarize tool results
compact / transcript / resume 機制
其中 fork path 的設計尤其精妙。
當模型決定 fork 一個子 agent 時，原始碼裡會走一條專門最佳化過的路徑：繼承父執行緒的 system prompt 和 tool defs，保持 API request prefix byte-identical，從而提高 prompt cache 命中率。
註解裡寫得很直白：fork 很便宜，因為共享 prompt cache。
這是什麼層級的最佳化？
普通人只想著「子任務能跑就行」，Claude Code 想的是「子任務能跑，而且盡量複用主執行緒快取，不白燒 token」。
這是產品級系統思維，不是展示級實作。
04 Agent 分工：不是萬能 Worker，而是 Specialist
很多人以為 Claude Code 的 Agent 就是一個「萬能 worker」——給個任務，它自己去拆、去執行、去驗證。
但拆開 built-in agents 後我發現：完全不是這樣。
原始碼裡至少定義了這幾個內建 Agent：
Explore Agent：純讀模式，專門做程式碼探索。它的 system prompt 明確規定——不能建立檔案、不能修改、不能刪除、不能移動、不能用重導向寫檔案，Bash 只允許 ls、git status、git log、git diff、find、grep、cat、head、tail 這些讀取操作。
Plan Agent：純規劃，不做編輯。它的職責是先理解需求、探索程式碼庫、輸出 step-by-step implementation plan，最後必須列出 Critical Files for Implementation。
Verification Agent：這是我最驚豔的一個。它的 system prompt 開頭就點明——你的工作是 try to break it。不是「確認實作看起來沒問題」，而是主動找茬。它強制要求：跑 build、跑 test suite、跑 linter/type-check、做專項驗證、跑瀏覽器自動化或 curl 實測、輸出每個 check 的 command 和 observed，最後必須輸出 VERDICT: PASS / FAIL / PARTIAL。
這套設計解決了一個很多系統長期存在的問題：一個 agent 既研究、又規劃、又實作、又驗收，最終哪件事都不夠穩定。
Claude Code 的選擇是：明確分工。Explore 只管讀，Plan 只管規劃，Verification 只管破壞性驗證，通用任務交給 General Purpose Agent。
這不是「多了三個 agent」的問題，而是架構上的 specialization 思維。
05 排程鏈：AgentTool → runAgent → query
拆解完 Agent 排程鏈後，我對「Agentic Harness」這個詞的理解又深了一層。
整個鏈路可以抽象成：
AgentTool.call() 的職責遠超「轉發到子 agent」——它本質上是 agent orchestration controller，要處理權限過濾、MCP 依賴、worktree isolation、foreground/async 任務註冊等一堆事情。
而 runAgent() 則是一個完整的子 agent runtime constructor：初始化 agent-specific MCP、過濾 context messages、處理 read-only agent 的 claudeMd slimming、建構 permission mode、執行 SubagentStart hooks、預載入 frontmatter skills、合併 agent MCP tools、最後呼叫 query() 進入主迴圈。
最讓我感慨的是，原始碼裡還有大量產品級細節：recordSidechainTranscript、writeAgentMetadata、registerPerfettoAgent、cleanupAgentTracking、killShellTasksForAgent、清理 cloned file state、清理 todos entry……
Anthropic 不是只讓 subagent「跑起來」，而是把 transcript、telemetry、cleanup、resume 都納入正式生命週期。
這才是產品級的 runtime。
06 Skill、Plugin、Hook、MCP：不只是可安裝，而是模型可感知
很多系統也有外掛、有工具、有外部協定，但模型本身不知道：有哪些擴充、什麼時候該用、怎麼用。
Claude Code 不一樣。
透過 skills 列表、agent 列表、MCP instructions、session-specific guidance、command integration，它讓模型知道自己的擴充能力是什麼。
Skill 不是說明文件，而是一個 prompt-native workflow package：markdown prompt bundle + frontmatter metadata + 可宣告 allowed-tools，按需注入當前上下文。
Plugin 不只是外掛，而是 prompt + metadata + runtime constraints 的擴充機制。
Hook 是 runtime governance layer：PreToolUse 可以改寫輸入、直接給 allow/ask/deny、甚至 preventContinuation；PostToolUse 還能追加 message、注入 additional context。
MCP 不只是工具橋，還能同時注入工具 + 如何使用這些工具的說明——getMcpInstructionsSection() 會把這些 instructions 拼進 system prompt。
這意味著 MCP 的價值遠高於簡單 tool registry，它同時是 behavior specification channel。
07 工具執行鏈：不是直接呼叫，而是 Pipeline
最後一個讓我印象深刻的部分，是 toolExecution.ts 裡的工具執行鏈路。
它不是「模型決定 → 直接跑函式」。實際鏈路大致是：
這是一條標準的 runtime pipeline，不是直連函式呼叫。
其中 PreToolUse hooks 的攔截能力非常強：hook 可以改寫輸入（updatedInput）、直接給出 permissionBehavior（allow/ask/deny）、甚至 preventContinuation——即使沒 deny，也能阻止流程繼續。
而 resolveHookPermissionDecision() 這層邏輯確保了：hook 的 allow 不自動繞過 settings 規則，如果需要 user interaction 而 hook 沒提供 updatedInput，仍要走統一 permission flow。
Hook 很強，但沒有繞開核心安全模型。
尾聲：Agentic Harness 設計的盡頭
拆解完這 4756 個檔案後，我一直在想一個問題：Agentic Harness 設計的盡頭到底是什麼？
如果讓我用一句話回答，我會說：
是把 prompt architecture、tool runtime、permission model、agent orchestration、skill packaging、plugin system、hooks governance、MCP integration、context hygiene 和 product engineering 全部統一起來的那個系統。
很多人複刻 coding agent 時，只會拿走：
一個 system prompt
一個檔案編輯工具
一個 bash 工具
一個 CLI 殼
但 Claude Code 真正的護城河，是那層把它們全部制度化、工程化、產品化的 Harness。
少一個環節，體驗都會掉一檔。而把它們全部做對、做深、做到能大規模穩定執行，需要的遠不止「寫 prompt」的能力，而是一整套系統架構思維。
這也許就是 Agentic Harness 設計的盡頭：不是更聰明的模型，而是更完整的系統。