你寫的 Agent Harness 代碼，正在變成技術債
整理版優先睇
Agent Harness 正被模型迭代清空，精簡 harness 並將精力放喺 skills 先係長遠之計
呢篇文章出自技術博客作者 Lee Hanchung，佢觀察到好多團隊喺開發 AI Agent 嗰陣，寫咗大量系統提示詞、工具封裝、planner-executor 循環、記憶層呢類「harness」代碼，但佢認為呢啲代碼正變成技術債，因為模型能力愈嚟愈強，直接「食咗」呢啲腳手架。作者引用 Hyung Won Chung 嘅「為當前算力添加結構，然後刪掉」、Rich Sutton 嘅「苦澀教訓」，指出每一代模型都會令上一代嘅 harness 變得多餘。
作者回顧咗 2023 年嘅 RAG 流水線、2024 年嘅工作流，到 2025-2026 年模型原生支援交錯推理同工具調用，結論係 harness 唔係永久嘅，而家嘅工程投入好快就會被淘汰。佢特別舉咗五個正在消失嘅工程案例：no-code 工作流、工具封裝、planner-executor 腳手架、記憶層、多 Agent 拓撲，每個都因為模型進步而變得唔再必要。
文章最後提出明確策略：保持 harness 精簡（thin harness），將領域專業知識放入 skills（fat skills），因為 skills 可以快速迭代，而模型層由實驗室主導。判斷 harness 係咪技術債嘅方法係問：「如果下季模型變得更聰明，呢個部分仲有冇用？刪除佢要幾耐？」作者強調，應用層腳手架應該當係 90 日嘅製品對待，要組織好 codebase 方便隨時丟棄。
- 模型迭代會食咗舊有 harness，將腳手架當架構係最大嘅技術債
- 2023-2024 年嘅 RAG、工作流、planner-executor 正被模型原生能力取代
- 第一方 harness 通常優於第三方，但第三方如果針對性投資（如 Letta Code）可以反超
- 生產 harness 要窄（安全限制），訓練 harness 要寬（探索空間），兩者之間嘅差距要刻意設計
- 最佳策略係「Thin Harness, Fat Skills」：精簡 harness，將領域知識放喺快速迭代嘅 skills 度
乜嘢係 Agent Harness？
Agent Harness 即係模型同世界之間嘅編排層，包括系統提示、工具集、上下文管理、多 Agent 拓撲、記憶層、驗證器、可觀測性等等。你可以想象模型係 CPU，harness 就係操作系統——佢提供中斷同接口，管理進程，畀用戶覺得「內存無限、資源無限」嘅幻覺。
一個 Agent = 模型 + Harness，冇 harness 嘅模型就好似冇配套軟件嘅芯片，毫無用處。
但問題係：唔係所有 harness 都平等，更緊要係，唔係所有 harness 都應該係永久嘅。好多團隊將 harness 當成永久架構，但模型進步會令佢哋變成開銷。
點解 Harness 會變成技術債？
作者用時間軸說明：2023 年做 RAG 流水線，因為模型上下文窗口細；2024 年做工作流，因為工具調用唔可靠；2025-2026 年模型已經原生支援交錯推理同工具調用，循環喺模型內部運行，唔再靠我哋嘅 Python 代碼。
模型不斷「食咗」舊有 harness，例如：tool calling 可靠後就唔再需要複雜封裝；長 context 出現後就唔再需要向量數據庫記憶層。呢啲例子證明，而家寫嘅 harness 可能好快就過時。
正在消失嘅工程案例
以下五種常見 harness 結構正被模型能力取代：
- 1 No-code 工作流構建器（如 n8n）：到 2026 年，單個長時域 Agent 做到嘅事超過幾十個節點拼出嚟嘅工作流，而且複合誤差更少。
- 2 工具封裝：模型已經可以直接讀 OpenAPI 規範，Browser Use 嘅工程師甚至畀 Agent 自己編輯 helpers.py 來加函數。
- 3 Planner-Executor 腳手架：2026 年單個 agentic-thinking 模型喺自己推理軌跡中完成計劃、行動同反思，唔再需要分拆 LLM。
- 4 記憶層：Anthropic 嘅長時域 Agent 只用一個 JSON 特性列表、一個進度文件同 git log，因為模型好擅長讀寫純文本。
- 5 多 Agent 拓撲：Cognition 同 Anthropic 都話多 Agent 架構喺底層限制緩解後變成開銷。
每一個弱點都買來一類 harness 操作，而呢啲弱點而家幾乎都解決咗。
第一方 Harness vs 第三方 Harness
Anthropic 喺 Claude Code 用自己嘅 harness（1ph）做後訓練，所以模型喺呢個表面表現最好。研究顯示同一模型喺 1ph 同 3ph 評估差距顯著（GPT-5.1 Codex 20.2% vs 7.7%）。
但 Letta Code 係反例：喺 Opus 4.5 上以 59.1% 擊敗 Claude Code 嘅 41.6%，因為佢專注記憶基底，而基準測試獎勵記憶。
結論唔係第一方一定贏，而係 harness 係承重嘅，喺第一方忽略嘅維度上刻意投資嘅第三方 harness 可以反超。另一個關鍵：生產 harness 同訓練 harness 嘅目的相反，好多團隊搞錯咗。
正確策略：Thin Harness, Fat Skills
作者提出分層框架：模型 + Harness = Agent，Agent + Skills = 產品。優化預算應該放喺最平嘅表面——Skills 迭代最快，Harness 要精簡，模型層由實驗室主導。
Keep the harness thin——一套細嘅刻意欠規格原語，鏡像實驗室後訓練表面。
判斷 harness 係咪技術債嘅思想實驗：對每塊 harness 問「下季模型變聰明會點？」同埋「過時後刪除要幾耐？」如果答案係「一個鐘」就好辦，如果係「一星期」就係債。
- Skills / 提示詞：迭代快，出錯成本係一次文本編輯
- Harness：中速，隨二進制發佈，每週到每日
- 模型層：每季度由實驗室主導，算力擊敗聰明才智
你最近一年做緊 AI Agent，有冇寫過呢啲代碼：
系統提示詞、工具調用封裝、planner-executor 循環、重試策略、上下文壓縮、多 Agent 編排圖、停止條件判斷……
如果有，恭喜你——你正在積累一筆冇人話畀你知要預算嘅技術債。
唔係話你啲代碼寫得差。而係話：「你將腳手架當咗做架構。」
乜嘢係 Agent Harness？
喺深入之前，先搞清楚一個概念：「Agent Harness（編排層）」。
簡單講，佢係模型同世界之間嘅嗰一層。系統提示、可調用嘅工具集、上下文管理策略、多 Agent 拓撲、記憶層、驗證器、可觀測性……呢啲加埋，就係 harness。
一個 Agent = 模型 + Harness。
你可以將模型理解成 CPU，harness 係操作系統——佢提供中斷同接口，管理進程，畀用戶製造「內存無限、資源無限」嘅幻覺。
冇 harness，模型係一塊冇配套軟件嘅芯片，毫無用處。
但問題嚟咗：「唔係所有 harness 都係平等嘅，更加重要嘅係，唔係所有 harness 都應該係永久嘅。」
你嘅 harness，正被下一個模型版本清零
我哋嚟做一道時間軸題。
「2023 年，我哋做緊乜嘢？」
RAG 流水線。因為模型上下文窗口好細，檢索能力好弱，工程師要親手搭建整個記憶層——分塊器、嵌入模型、向量數據庫、重排序器、查詢改寫器、引用檢查器。模型只係呢條流水線末端嘅被動消費者。絕大多數工程精力，花咗喺流水線上面。
「2024 年，我哋做緊乜嘢？」
工作流。因為模型唔能夠可靠咁喺循環中調用工具，工程師構建咗顯式嘅 orchestrator-worker 結構——一個 LLM 分解任務，多個 worker 並行執行，最後拼接輸出。冇工具調用，因為嗰陣時工具調用唔可靠。呢個結構本質上係喺用 2024 年嘅模型做一件有用嘅事，方法係「繞開佢嘅 2024 年侷限」。
「2025 年末到 2026 年呢？」
模型可以可靠咁調用工具喇。Claude 模型，已經將交錯推理+工具使用變成咗原生行為。單個長時域 Agent 而家可以做2024年需要幾十個節點先拼得出來嘅嘢，循環喺模型內部運行，唔再係我哋嘅 Python 代碼。
Meta AI 嘅 Hyung Won Chung 用一句話總結咗呢個模式：
❝「為你當前嘅算力水平添加結構，然後將佢刪掉——因為結構會成為下一個算力級別嘅瓶頸。」
❞
2023 年嘅分塊檢索對於 2023 年嘅上下文窗口係正確嘅。2024 年嘅 orchestrator-worker 工作流對於 2024 年嘅工具調用可靠性係正確嘅。「每一代模型，都將上一代嘅結構暴露為開銷。」
呢個就係所謂嘅「苦澀教訓」（Bitter Lesson）——Rich Sutton 七十年前就講清楚咗：利用通用計算嘅方法，最終總係擊敗將人類聰明才智硬編碼入去嘅方法。SIFT 輸咗畀 ConvNet。規則解析器輸咗畀神經網絡。國際象棋嘅手工啓發式輸咗畀 AlphaZero。
而家，呢件事正喺發生喺 Agent Harness 身上。
正在消失嘅嗰啲工程
幾個正被模型「食咗」嘅具體案例：
「No-code 工作流構建器正在消失。」 n8n 等工具畀非工程師提供咗「可視、可版本、可重跑」嘅幻覺。但只要任何一個節點包含 LLM，確定性流程就唔等於確定性輸出。複合誤差喺超過幾個節點之後會變得好難睇。到 2026 年，一個單一嘅長時域 Agent 做嘅嘢，超過咗嗰啲畫布上幾十個節點拼出來嘅工作流。
「工具封裝正在消失。」 2024 年每個團隊都喺將原始 API 封裝成「更 LLM 友好」嘅工具 schema。但到 2025 年末，模型已經可以直接讀 OpenAPI 規範喇。Browser Use 嘅工程師走得更遠：佢哋嘅 ~600 行 harness 裏面，大部分係 Agent 喺運行時「自己可以編輯」的 helpers.py。當 upload_file() 呢個函數唔存在時，Agent 會讀 helpers.py，自己寫一個，然後繼續。Harness 縮細咗，模型填補咗空缺。
「Planner-Executor 腳手架正在消失。」 2024 年嘅標準模式係顯式嘅 planner LLM → executor LLM → reflection LLM 三步拆分。到 2026 年，單個 agentic-thinking 模型喺自己嘅推理軌跡中完成咗計劃、行動同反思嘅交錯。分解發生喺模型內部，唔再發生喺我哋嘅 Python 裏面。
「記憶層正在消失。」 長時域 Agent 記憶曾經係一個複雜嘅向量數據庫 + 摘要 + 選擇性檢索嘅技術棧。Anthropic 自己嘅長時域 Agent harness 用的是：一個 JSON 特性列表、一個進度文件、同 git log。明文文本，放喺工作目錄裏面。呢個係刻意嘅選擇——模型已經非常熟悉點樣讀寫同推理純文本，而任何自定義記憶抽象都需要喺每次發佈後重新教畀佢。
「多 Agent 拓撲正在消失。」 Cognition 同 Anthropic 都指向同一個方向：我哋為咗彌補短上下文窗口同弱工具調用而構建嘅多 Agent 架構，喺底層限制已經緩解之後，睇起嚟越來越似開銷。
第一方 Harness vs 第三方 Harness：一場被忽視嘅競爭
呢度有一個反直覺嘅數據點值得關注。
點解 Claude 喺 Claude Code 裏面用起上嚟，同喺一個通用 ReAct wrapper 裏面用起上嚟，感覺完全唔一樣？
原因在於：當 Anthropic 對模型進行後訓練時，佢係喺「自己嘅」 harness 裏面做——自己嘅工具 schema、自己嘅 rollout 協議、自己嘅系統提示約定、自己嘅上下文佈局、自己嘅停止條件。策略係針對嗰個特定表面被塑造嘅。
將同一個模型放入一個工具描述唔同、循環形狀唔同、記憶佈局唔同嘅第三方 harness，你就喺分佈之外運行佢——模型被要求通過一個佢從未被優化過嘅接口嚟行動。
實證研究顯示：喺第一方 harness（1ph）同現成第三方 harness（3ph）中評估同一個模型，第一方 harness 喺基準測試上持續領先。GPT-5.1 Codex 喺第一方 harness 中得分 20.2%，第三方 harness 7.7%。差距顯著。
但呢個唔係鐵律。
「Letta Code 係最乾淨嘅反例。」 喺 Opus 4.5 上，Letta Code 得分 59.1%，而 Claude Code 係 41.6%——一個第三方 harness 喺自己模型上擊敗咗第一方，而且差距好大。機制正係不對稱性論證所預測嘅：Claude Code 喺持久記憶上刻意做薄，Letta 圍繞記憶基底構建，基準測試獎勵記憶能力。
「結論唔係第一方總贏或總輸——而係 harness 係承重嘅，一個喺第一方 harness 所忽視嘅維度上進行刻意投資嘅第三方 harness，可以反超。」
一個冇人講得清楚嘅關鍵不對稱
大多數團隊犯嘅最大錯誤：「將生產 harness 當成訓練 harness，或者反過嚟。」
生產 harness 係「約束表面」。Agent 喺真實系統上代表真實用戶行動，有真實後果。你需要：嚴格嘅工具白名單、範圍受限嘅憑據、寫操作嘅審批層級、提示注入過濾器、冪等重試策略、最大運行時間、審計日誌、緊急停止開關。
訓練 harness 係「探索表面」。模型喺生成軌跡，優化器將用佢嚟塑造策略。如果你加白名單，你就喺預先決定模型被允許學習使用乜嘢。如果你約束行動空間，你就喺剝奪優化器發現更好策略所需嘅信號。「訓練 harness 應該喺生產 harness 收窄嘅地方放寬。」
兩種常見失敗模式：
「訓練過度束縛。」 一個團隊將生產白名單導入訓練「為咗安全」，運行 RL，結果產出嘅模型喺嗰個白名單內表現良好，喺之外毫無用處。模型從未學會從工具錯誤中恢復，因為生產 harness 替佢重試咗。佢從未學會喺兩個競爭工具之間選擇，因為生產 harness 替佢路由咗。生產護欄喺替 Agent 做思考，而策略從未需要發展出嗰種思考。
「生產過度放開。」 相反嘅團隊訓練咗一個開放式 Agent，見到佢喺開發環境中解決咗令人印象深刻嘅任務，然後直接用同樣嘅開放式 harness 部署佢對抗真實系統。第一次提示注入載荷流過工具輸出，Agent 盡職盡責咁泄露咗秘密，因為 harness 中沒有任何嘢話畀佢知唔應該咁做。
正確嘅形狀，作為一條規則：「harness 應該喺模型被訓練嘅地方最闊，喺模型被部署嘅地方最窄，而兩者之間嘅差距應該係一個刻意嘅、經過審計嘅工程製品，而唔係意外。」
優化預算應該花喺邊度？
如果 harness 係 2026 年嘅製品，下一個問題係：優化預算應該花喺邊度？
有一個分層框架經受住咗時間考驗：「模型 + Harness = Agent，Agent + Skills = 產品」。
核心原則：「將工作推到最平嘅優化表面上。」
Keep the harness thin（保持 harness 精簡）——一套細嘅、刻意欠規格嘅原語，鏡像實驗室後訓練所針對嘅表面。
Put domain expertise into skills（將領域專業知識放入 skills）——迭代快，製品可讀，出錯成本係一次文本編輯而唔係一次發佈。
Let the lab own the model layer（讓實驗室擁有模型層）——呢個係佢哋獨特擅長嘅工作，亦係算力最能擊敗聰明才智嘅層次。
「Thin harness, fat skills。」
點樣判斷你嘅 harness 係咪技術債？
做一個有用嘅思想實驗：對你係統中嘅每一塊 harness，問——「如果下季度模型變得好明顯更聰明，會發生乜嘢？」
嗰條寫住「始終一步步思考」嘅系統提示——如果模型已經咁樣做咗，仲有乜用？ 嗰個將整潔 API 轉換成「更 LLM 友好」接口嘅工具封裝——模型而家係唔係直接用原始 API 更好？ 嗰個分解任務嘅 orchestrator-router-judge 圖——下一個模型係唔係直接喺一次推理中完成？ 嗰個有嵌入同重排序嘅記憶抽象——而家 progress.md加git log夠唔夠用？嗰個捕獲格式錯誤 JSON 嘅輸出驗證器——新模型係唔係直接輸出有效 JSON？
對每個部分，再問一個問題：「當呢個部分過時嘅時候，刪除佢有幾難？如果答案係「一個鐘」，你有一個選項。如果答案係「一個禮拜」，你有一筆債。」
寫喺最後
我哋曾經有非常臃腫嘅 harness，因為模型喺好多方面好弱：唔能夠可靠咁使用工具、上下文窗口好細、推理能力有限、冇交錯規劃、視野好短。每一個弱點都買來咗一類 harness 操作：封裝、工作流、記憶棧、planner-executor 圖。呢啲而家幾乎都解決咗。
「模型食咗 harness。」
而且佢仲會繼續食。多 Agent 工作流同系統好快就會好似工作流咁被訓練入模型本身。持久嘅唔係任何特定嘅生產腳手架。持久嘅係訓練同評估數據、環境、任務同基礎設施——嗰個令你喺模型改變時重建 harness 嘅持久基底。
將應用層腳手架當成 90 日嘅製品嚟對待，組織好代碼庫，咁樣你就可以喺模型發佈時毫不猶豫咁將佢掉咗。
「你嘅軟件工程技巧將被下一個模型淘汰。你嘅判斷力唔會。」
❝視頻連結：https://leehanchung.github.io/blogs/2026/05/08/hidden-technical-debt-agent-harness/
❞
你最近一年在做 AI Agent，有沒有寫過這些代碼：
系統提示詞、工具調用封裝、planner-executor 循環、重試策略、上下文壓縮、多 Agent 編排圖、停止條件判斷……
如果有，恭喜你——你正在積累一筆沒有人告訴你要預算的技術債。
不是說你的代碼寫得差。而是說：「你把腳手架當成了架構。」
什麼是 Agent Harness？
在深入之前，先搞清楚一個概念：「Agent Harness（編排層）」。
簡單說，它是模型和世界之間的那一層。系統提示、可調用的工具集、上下文管理策略、多 Agent 拓撲、記憶層、驗證器、可觀測性……這些加起來，就是 harness。
一個 Agent = 模型 + Harness。
你可以把模型理解成 CPU，harness 是操作系統——它提供中斷和接口，管理進程，給用戶製造「內存無限、資源無限」的幻覺。
沒有 harness，模型是一塊沒有配套軟件的芯片，毫無用處。
但問題來了：「不是所有的 harness 都是平等的，更重要的是，不是所有的 harness 都應該是永久的。」
你的 harness，正在被下一個模型版本清零
我們來做一道時間軸題。
「2023 年，我們在做什麼？」
RAG 流水線。因為模型上下文窗口很小，檢索能力很弱，工程師要親手搭建整個記憶層——分塊器、嵌入模型、向量數據庫、重排序器、查詢改寫器、引用檢查器。模型只是這條流水線末端的被動消費者。絕大多數工程精力，花在了流水線上。
「2024 年，我們在做什麼？」
工作流。因為模型不能可靠地在循環中調用工具，工程師構建了顯式的 orchestrator-worker 結構——一個 LLM 分解任務，多個 worker 並行執行，最後拼接輸出。沒有工具調用，因為那時候工具調用不可靠。這個結構本質上是在用 2024 年的模型做一件有用的事，方法是「繞開它的 2024 年侷限」。
「2025 年末到 2026 年呢？」
模型可以可靠地調用工具了。Claude 模型，已經把交錯推理+工具使用變成了原生行為。單個長時域 Agent 現在能做 2024 年需要幾十個節點才能拼出來的事，循環在模型內部運行，不再是我們的 Python 代碼。
Meta AI 的 Hyung Won Chung 用一句話總結了這個模式：
❝「"為你當前的算力水平添加結構，然後把它刪掉——因為結構會成為下一個算力級別的瓶頸。"」
❞
2023 年的分塊檢索對於 2023 年的上下文窗口是正確的。2024 年的 orchestrator-worker 工作流對於 2024 年的工具調用可靠性是正確的。「每一代模型，都把上一代的結構暴露為開銷。」
這就是所謂的「苦澀教訓」（Bitter Lesson）——Rich Sutton 七十年前就說清楚了：利用通用計算的方法，最終總是擊敗把人類聰明才智硬編碼進去的方法。SIFT 輸給了 ConvNet。規則解析器輸給了神經網絡。國際象棋的手工啓發式輸給了 AlphaZero。
現在，這件事正在發生在 Agent Harness 身上。
正在消失的那些工程
幾個正在被模型「吃掉」的具體案例：
「No-code 工作流構建器正在消失。」 n8n 等工具給非工程師提供了「可視、可版本、可重跑」的幻覺。但只要任何一個節點包含 LLM，確定性流程就不等於確定性輸出。複合誤差在超過幾個節點後會變得很難看。到 2026 年，一個單一的長時域 Agent 做的事情，超過那些畫布上幾十個節點拼出來的工作流。
「工具封裝正在消失。」 2024 年每個團隊都在把原始 API 封裝成「更 LLM 友好」的工具 schema。但到 2025 年末，模型已經可以直接讀 OpenAPI 規範了。Browser Use 的工程師走得更遠：他們的 ~600 行 harness 裏，大部分是 Agent 在運行時「自己可以編輯」的 helpers.py。當 upload_file() 這個函數不存在時，Agent 會讀 helpers.py，自己寫一個，然後繼續。Harness 縮小了，模型填補了空缺。
「Planner-Executor 腳手架正在消失。」 2024 年的標準模式是顯式的 planner LLM → executor LLM → reflection LLM 三步拆分。到 2026 年，單個 agentic-thinking 模型在自己的推理軌跡中完成了計劃、行動和反思的交錯。分解發生在模型內部，不再發生在我們的 Python 裏。
「記憶層正在消失。」 長時域 Agent 記憶曾經是一個複雜的向量數據庫 + 摘要 + 選擇性檢索的技術棧。Anthropic 自己的長時域 Agent harness 用的是：一個 JSON 特性列表、一個進度文件、和 git log。明文文本，放在工作目錄裏。這是刻意的選擇——模型已經非常熟悉如何讀寫和推理純文本，而任何自定義記憶抽象都需要在每次發佈後重新教給它。
「多 Agent 拓撲正在消失。」 Cognition 和 Anthropic 都指向同一個方向：我們為了彌補短上下文窗口和弱工具調用而構建的多 Agent 架構，在底層限制已經緩解之後，看起來越來越像開銷。
第一方 Harness vs 第三方 Harness：一場被忽視的競爭
這裏有一個反直覺的數據點值得關注。
為什麼 Claude 在 Claude Code 裏用起來，和在一個通用 ReAct wrapper 裏用起來，感覺完全不一樣？
原因在於：當 Anthropic 對模型進行後訓練時，它是在「自己的」 harness 裏做的——自己的工具 schema、自己的 rollout 協議、自己的系統提示約定、自己的上下文佈局、自己的停止條件。策略是針對那個特定表面被塑造的。
把同一個模型放進一個工具描述不同、循環形狀不同、記憶佈局不同的第三方 harness，你就在分佈之外運行它——模型被要求通過一個它從未被優化過的接口來行動。
實證研究顯示：在第一方 harness（1ph）和現成第三方 harness（3ph）中評估同一個模型，第一方 harness 在基準測試上持續領先。GPT-5.1 Codex 在第一方 harness 中得分 20.2%，第三方 harness 7.7%。差距顯著。
但這不是鐵律。
「Letta Code 是最乾淨的反例。」 在 Opus 4.5 上，Letta Code 得分 59.1%，而 Claude Code 是 41.6%——一個第三方 harness 在自己模型上擊敗了第一方，而且差距很大。機制正是不對稱性論證所預測的：Claude Code 在持久記憶上刻意做薄，Letta 圍繞記憶基底構建，基準測試獎勵記憶能力。
「結論不是第一方總贏或總輸——而是 harness 是承重的，一個在第一方 harness 所忽視的維度上進行刻意投資的第三方 harness，可以反超。」
一個沒人說清楚的關鍵不對稱
大多數團隊犯的最大錯誤：「把生產 harness 當成訓練 harness，或者反過來。」
生產 harness 是「約束表面」。Agent 在真實系統上代表真實用戶行動，有真實後果。你需要：嚴格的工具白名單、範圍受限的憑據、寫操作的審批層級、提示注入過濾器、冪等重試策略、最大運行時間、審計日誌、緊急停止開關。
訓練 harness 是「探索表面」。模型在生成軌跡，優化器將用它來塑造策略。如果你加白名單，你就在預先決定模型被允許學習使用什麼。如果你約束行動空間，你就在剝奪優化器發現更好策略所需的信號。「訓練 harness 應該在生產 harness 收窄的地方放寬。」
兩種常見失敗模式：
「訓練過度束縛。」 一個團隊把生產白名單導入訓練「為了安全」，運行 RL，結果產出的模型在那個白名單內表現良好，在之外毫無用處。模型從未學會從工具錯誤中恢復，因為生產 harness 替它重試了。它從未學會在兩個競爭工具之間選擇，因為生產 harness 替它路由了。生產護欄在替 Agent 做思考，而策略從未需要發展出那種思考。
「生產過度放開。」 相反的團隊訓練了一個開放式 Agent，看到它在開發環境中解決了令人印象深刻的任務，然後直接用同樣的開放式 harness 部署它對抗真實系統。第一次提示注入載荷流過工具輸出，Agent 盡職盡責地泄露了秘密，因為 harness 中沒有任何東西告訴它不該這樣做。
正確的形狀，作為一條規則：「harness 應該在模型被訓練的地方最寬，在模型被部署的地方最窄，而兩者之間的差距應該是一個刻意的、經過審計的工程製品，而不是意外。」
優化預算應該花在哪裏？
如果 harness 是 2026 年的製品，下一個問題是：優化預算應該花在哪裏？
有一個分層框架經受住了時間考驗：「模型 + Harness = Agent，Agent + Skills = 產品」。
核心原則：「把工作推到最便宜的優化表面上。」
Keep the harness thin（保持 harness 精簡）——一套小的、刻意欠規格的原語，鏡像實驗室後訓練所針對的表面。
Put domain expertise into skills（把領域專業知識放進 skills）——迭代快，製品可讀，出錯成本是一次文本編輯而不是一次發佈。
Let the lab own the model layer（讓實驗室擁有模型層）——這是他們獨特擅長的工作，也是算力最能擊敗聰明才智的層次。
「Thin harness, fat skills。」
如何判斷你的 harness 是不是技術債？
做一個有用的思想實驗：對你係統中的每一塊 harness，問——「如果下季度模型變得明顯更聰明，會發生什麼？」
那條寫着「始終一步步思考」的系統提示——如果模型已經這樣做了，還有什麼用？ 那個把整潔 API 轉換成「更 LLM 友好」接口的工具封裝——模型現在是不是直接用原始 API 更好？ 那個分解任務的 orchestrator-router-judge 圖——下一個模型是不是直接在一次推理中完成？ 那個有嵌入和重排序的記憶抽象——現在 progress.md加git log夠不夠用？那個捕獲格式錯誤 JSON 的輸出驗證器——新模型是不是直接輸出有效 JSON？
對每個部分，再問一個問題：「當這個部分過時的時候，刪除它有多難？如果答案是「一個小時」，你有一個選項。如果答案是「一週」，你有一筆債。」
寫在最後
我們曾經有非常臃腫的 harness，因為模型在很多方面很弱：不能可靠地使用工具、上下文窗口很小、推理能力有限、沒有交錯規劃、視野很短。每一個弱點都買來了一類 harness 操作：封裝、工作流、記憶棧、planner-executor 圖。這些現在幾乎都解決了。
「模型吃掉了 harness。」
而且它還會繼續吃。多 Agent 工作流和系統很快就會像工作流一樣被訓練進模型本身。持久的不是任何特定的生產腳手架。持久的是訓練和評估數據、環境、任務和基礎設施——那個讓你在模型改變時重建 harness 的持久基底。
把應用層腳手架當成 90 天的製品來對待，組織好代碼庫，這樣你就可以在模型發佈時毫不猶豫地把它扔掉。
「你的軟件工程技巧將被下一個模型淘汰。你的判斷力不會。」
❝視頻連結：https://leehanchung.github.io/blogs/2026/05/08/hidden-technical-debt-agent-harness/
❞