昨天欠下的債今天開始還。Context Engineering（這系列的 L2）的每個策略都需要窗口外面的系統去執行，那套系統有名字：Harness。從今天起的九天都在這一層，它也是 Day 1 說過的「能 demo」和「能上線」的分水嶺。

Harness 是什麼

這個詞來自馬術，是韁繩、馬鞍、轡頭的總稱。這套裝備不改變馬的能力，但決定馬能往哪走、走多快、出了問題怎麼拉回來。對 AI 系統來說，模型是馬，harness 是讓牠能被安全騎乘的整套裝備：圍繞模型建立的執行基礎設施。

跟前兩層的分工用一張表就能對齊：

為什麼會有這一層：模型從文字工具變成執行代理

模型只輸出文字的年代，最壞的情況是答案不好，重問一次就行，L1 就夠應付。但當模型開始執行操作（讀寫檔案、呼叫 API、改資料庫），有四件事同時發生，而且每一件都輪不到 prompt 解決：

• 操作有副作用，不可逆。 刪掉的檔案、送出的請求、提交的 commit，改 prompt 救不回來。你需要機制在操作前判斷、出事時攔截
• 任務有狀態，跨越幾十輪。 模型每一輪都是無記憶的（Day 7 講過的前向計算），狀態要靠系統帶過去
• 資源有限。 窗口有上限、呼叫有費用，長任務會失控累積，需要預算和熔斷
• 複雜任務需要分工。 單一模型的注意力有上限，並行探索、分工驗證，需要有東西協調

對應下來，harness 有五個維度：資源管理、狀態持久化、資訊流控制、安全邊界、任務編排。資訊流控制上週已經講了（L2 的策略，L3 的執行），剩下的就是接下來的路線：session、工具、執行迴圈（agentic loop）、權限、能力模組化、多 agent 協作、對外介面，最後把所有零件組回一台完整的機器。

這一層的心法：解開束縛，而不是加上限制

直覺上 harness 聽起來像「給模型上枷鎖」，但做得好的 harness 方向相反。Boris Cherny（Claude Code 創始人）在訪談中分享過兩個觀點，可以當這一層的心法。

第一個叫 product overhang：模型的能力超前於產品，很多模型做得到的事還沒被產品化。開發者最常犯的錯是把步驟寫死（第一步做 A、第二步做 B），這反而束縛了模型；更好的做法是給高層次的任務、明確的出口條件、還有驗證工具，讓模型自己找路。Harness 的工作是把模型已有的能力接上手腳，這也是 un-hobbling（解開束縛）這個說法的由來。

第二個是實驗心態：他形容打造 AI 產品不像傳統的工程設計，更像在了解一種有機生物，要靠不斷實驗和觀察來調整外殼。這句話聽起來玄，工程上的含義很實際：harness 的設計沒辦法在白板上一次想對，你要觀察模型在哪裡卡住，再針對性地補環境。

工程師的角色跟著變了

這一層改變的不只是系統架構，還有你的工作型態。Agent 卡住的時候，值錢的問題從「Agent 出了什麼問題」變成「環境缺少了什麼，讓它無法繼續」— 缺工具？缺資訊？缺約束？焦點從實作轉向賦能。

Cloudflare 工程師 Boris Tane 分享過他的第一原則：永遠不要讓 agent 在你審查並批准書面計劃之前寫程式碼，規劃與執行的分離是最重要的一件事。理由很工程：agent 一旦開跑，中途糾偏的成本比人寫程式時高得多，它可能已經改了多個檔案、疊了好幾層錯誤前提。

角色轉變的另一面是管理：同時盯著多個 agent 並行工作，分配任務、觀察進度、偏了就拉回來。這種工作有兩個成熟度階段 — 有人值守（主動監管、即時重定向）和無人值守（發完任務離開，agent 自主跑到 PR）。判斷一個團隊在哪個階段，看的是 harness 的成熟度，不是模型的能力。同一個模型，harness 完整的團隊敢放手，harness 陽春的團隊只能盯著。

明天從地基開始

五個維度裡，最底層的是一個看起來最不起眼的問題：session。模型是無狀態的函數，但使用者感受到的是一段有頭有尾、可以中斷再續的「對話」。這個從無狀態到有狀態的橋，就是 session 設計。它決定了狀態存在哪、斷線怎麼恢復、多裝置怎麼同步，而且一旦選定就很難改。明天講 Session 設計：Stateless 與 Durable 兩條路線。