同一個模型的 API,有人做出的 Agent 穩定得像個資深同事,有人做出的連 demo 都撐不完。模型人人都叫得到,效果卻天差地遠。
差距不在模型。模型是別人訓練的,權重凍結,你動不了。有人會說:可以 fine-tune 啊。沒錯,但動權重是另一個領域,資料、算力、維運成本完全是另一個量級,不在這個系列的範圍。而且多數 production 問題,在動權重之前,模型外面就有更便宜的解。這個系列 30 天要講的就是這件事:從「一個模型」到「一個能在真實場景穩定運作的 AI 系統」之間,有四層不動權重就能動的工程槓桿。
拿 Claude Code 當例子。很多人以為它好用是因為模型強,但把同一個模型接上自己隨手包的 agent loop,效果就是差一截。決定表現的是模型外面那一整套東西:system prompt 怎麼寫、工具怎麼設計、權限怎麼把關、context 滿了怎麼壓縮、任務中斷了怎麼接續。
這套東西業界開始叫它 Harness(韁繩、套具)。同一匹馬,配不同的套具,能拉的車完全不同。API 上的模型人人一樣,能力差距來自你圍繞它蓋了什麼。
問題是「模型外面的工程」範圍太大,從改一行 prompt 到蓋一套自我改進的系統都算。所以我把它整理成四層地圖,這也是這 30 天的路線。

| 層 | 你在動什麼 | 典型手段 | 生效範圍 |
|---|---|---|---|
| L1 Prompt Engineering | 單次呼叫的輸入 | Prompt 設計、結構化輸出、快取 | 一次呼叫 |
| L2 Context Engineering | 窗口裡的所有內容 | RAG、記憶系統、壓縮 | 每次組窗口 |
| L3 Harness Engineering | 模型外的整個執行系統 | Session、Tool、Permission、Skills | 整個系統 |
| L4 Loop Engineering | 系統隨時間演化的方式 | 評估、可觀測性、自我改進 | 系統的一生 |
L1 Prompt Engineering 是最便宜的槓桿:改的是一次呼叫的輸入。它有效,而且有效的原因可以從 Transformer 的機制解釋,不是玄學。但它有天花板:prompt 調到極限,輸出還是不穩,因為問題常常不在指令怎麼下,而在模型根本沒看到該看的資訊。
L2 Context Engineering 往上一層:不只調指令,而是決定整個窗口裡放什麼。檢索(RAG)、記憶、壓縮,本質上都在回答同一個問題:這次呼叫,模型應該看到什麼?但 context 塞好塞滿,Agent 還是會跑歪,因為沒有系統在外面接住它的錯誤。
L3 Harness Engineering 再往上:動的是模型外面的整個執行系統。Session 怎麼設計、工具怎麼給、權限邊界畫在哪、能力怎麼模組化。這一層是「能 demo」和「能上線」的分水嶺。但 harness 蓋好了,系統也不會自己變好。
L4 Loop Engineering 是最大的槓桿:動的是系統隨時間演化的方式,讓每一次執行變成下一次的養分。評估和可觀測性在這一層不是附屬品,是前提:你能驗證系統有沒有變好,這個迴路才敢轉起來。
因為每一層都以下面那層為地基。沒想清楚 prompt 為什麼有效,RAG 只是把垃圾塞進窗口;不會管理 context,harness 跑十輪就爆掉;沒有 harness 收集執行軌跡,評估和自我改進根本無米可炊。
路線很簡單:由下而上,一層一層走。先把 Prompt 層的機制和成本講透,再往上進 Context、Harness,最後走到 Loop。每一層講到極限的時候,你自然會知道為什麼需要下一層
最後你會帶走什麼:
明天從最底層開始:你寫的 prompt 為什麼有效?「請一步一步思考」這句話為什麼真的有用?答案在 Transformer 的機制裡,明天拆開來看。