Context Engineering（這系列的 L2）走了七天：窗口經濟學、檢索、記憶三部曲、壓縮。照 Day 7（Prompt 的極限）的慣例，離開一層之前，先誠實面對它的極限：窗口內容全部管理到位，為什麼還是做不出能上線的系統？

先承認 L2 偷偷欠下的債

回頭看這一週，每一天其實都預設了一個沒被討論的角色存在：

• Day 9 說「讓 agent 用工具迭代地搜」，工具是誰定義的？誰執行？
• Day 10 說「agent 主動呼叫 mem_save」「compaction 前搶救」，觸發時機誰在盯？
• Day 12 說「session 開始時凍結快照」，session 的邊界是誰劃的？
• Day 13 說「壓縮層插在 agent 和 provider 之間」，這一層本身住在哪裡？

L2 的每一個策略，都需要窗口外面的某個系統去執行。我們講了七天的「選什麼資訊」，把「怎麼做到」全部記在帳上。這筆債有名字：Harness。策略和執行的邊界值得畫清楚，因為它們需要的能力完全不同 — 前者是資訊的判斷，後者是系統的工程。

三類 L2 解不了的問題

第一類：模型看到了，還是做不了。 窗口內容只能給模型「知道」，不能給它「做到」。它知道要跑測試，但誰提供執行環境？它知道該查資料庫，但連線在誰手上？資訊的供給再完美，行動的能力是另一回事。Claude Code 的創始人 Boris Cherny 在訪談中把這件事叫做 un-hobbling（解開束縛）：現在模型的能力超前於產品，很多模型做得到的事還沒被產品化，缺的往往是把手腳接上去的那層工程。

第二類：模型做錯了，沒人接得住。 Day 9 講過檢索污染：檢回錯的文件，模型拿著錯的事實一路推。但更危險的版本在行動端：agent 拿著錯的認知去刪檔案、發 API、改設定，誰擋？信任邊界（什麼動作可以直接做、什麼要先問人）畫在窗口裡是沒有用的，Day 7 講過用 prompt 寫「不要亂刪檔案」的可靠性天花板。邊界必須畫在系統層，用權限機制強制，而這個機制本身在窗口外面。

第三類：呼叫之間的一切。 對話中斷了怎麼接續？多個 agent 同時跑怎麼不打架？工具執行失敗算誰的？這些問題發生在兩次 LLM 呼叫之間，那裡沒有窗口、沒有 prompt、沒有 context，只有你的系統。L2 的視角天生看不到這個地帶，因為它的整個世界就是「一次呼叫的窗口內容」。

兩個問題，判斷你該進 L3 了沒

延續 Day 7 的分流做法，這次只需要兩個問題：

「這個問題出在模型看到什麼嗎？」 是的話，留在 L2，檢索、記憶、壓縮的工具箱夠你用；改 prompt 之前先想想是哪個供給環節壞了。不是的話，往下看。

「這個問題出在呼叫與呼叫之間、或模型與世界之間嗎？」 是的話，那是執行系統的問題。session 管理、工具供給、權限邊界、錯誤接手，這些統稱 Harness，L2 的任何策略都替代不了它。

一個對照可以把邊界說得更白：Day 12 講 HermesAgent 的 frozen snapshot 時，我們關注的是「記憶凍結」這個資訊策略；但讓這個策略成立的，是它的 session 資料庫、系統提示組裝器、cache 斷點管理，全部是 harness 元件。同一個功能，L2 負責決定，Harness Engineering（這系列的 L3）負責讓它成立。

下一層的預告

Day 1 的地圖上，L3 Harness Engineering 是「能 demo」和「能上線」的分水嶺，現在你知道為什麼了：demo 只需要模型看對東西，上線需要一整套系統在模型外面持續運轉，session 怎麼設計、工具怎麼給、權限畫在哪、能力怎麼模組化，每一題都要有答案。

這一層也是整個系列我最想寫的一層。過去一年最有影響力的 AI 產品（Claude Code 是最好的例子）真正的護城河都不在模型，在 harness。明天進 L3：Harness Engineering，AI 工程師的第三個維度。