2026.08 Key Point：Agent = Model × Harness。harness 有兩種，有一種會被下一代模型吃掉
2026 年 8 月 13 日，DeepSeek 在 GitHub 上公開了 DeepSeek Harness。它不是新模型，在上線幾個小時後，star 數就衝上數萬，值得注意的不是每天都在變的星星數，而是命名。
harness 不是軟體工程裡的新詞。test harness 用了幾十年，意指「把待測物接上、讓它跑得起來看得到結果」；連 CI/CD 領域都早有一家公司就叫 Harness。
而現在它突然被推到 Agent 產品與架構的正中央。
不只 DeepSeek。OpenAI 在二月直接把這套做法叫做 harness engineering，而且是放在官方工程文章的標題上（【Harness engineering: leveraging Codex in an agent-first world】）；Anthropic 在四月把它變成架構層級的名詞；Meta 八月推出的 Muse Code，整個差異化也都在 harness 層。
一個實作細節被推上主場，通常表示底下有東西流動了起來。
關於公式：Agent = Model × Harness
harness 的定義可以簡單有力：模型權重以外的一切。舉凡工具介面、context 管理、agent loop、memory、權限邊界、驗證迴路都可以算。模型去推理，harness 來落地；而落地後能被審查。
而公式裡用乘號而不是加號是刻意的。加號的意思「兩個都重要」，那是當然。而乘號想表達的是：兩者互相限制對方能發揮到什麼程度：再強的模型放進糟糕的執行環境，能力也發揮不出來；而再完善的 harness，也變不出底層模型沒有的推理能力。
而乘號的另一層意思：相互限制的比例，會跟著下一代模型的出現而改變。這個公式最容易被誤用的地方，我後面會寫到；先來看看目前的實證。
同一個模型換了 harness，變成不同產品
Epoch AI 在檢視 SWE-bench Verified 究竟測到什麼的時候，留下了一組很乾淨的對照：同一個模型，只換 scaffold，分數從 62.3% 走到 70.2%。
結論更直接：一個好的 scaffold 可帶出上限 20% 的提升。而這結論出自一個獨立評測機構，而不是在賣 harness 的公司。
但我們在看 benchmark 的時候，留下來的往往只剩「哪個模型、幾分」。所以如果你是工程主管，該帶走的不只是那些數字，而是一套新的追問：「這個數字是在哪個 harness 下跑的？幾次 retry？context 的策略是？廠商自己報的還是獨立評測？」
這延續了 prompt → context → harness 的同一條軌跡：工程師的主控範圍，正在從「怎麼 prompt、包 context」，擴大到「怎麼為組織、團隊設好合適 agent 的作業環境」。
模型變強之後就沒用了？
Anthropic 在 2026 年 4 月的【Scaling Managed Agents】裡，講了一個對他們自己不太有利的故事。
Claude Sonnet 4.5 有個毛病：接近 context 上限時會焦慮性地提早收尾。於是他們在 harness 裡加了 context reset 機制去補救。後來換到 Opus 4.5，那個行為消失了。(原文是：The resets had become dead weight)
同一份文件中引用了 Rich Sutton 的【Bitter Lesson】。意思很清楚：你為了補償某一代模型特定缺陷而加進 harness 的東西，可能在下一代模型出來時變成負債。
這問題很實際：如果你現在正在練的 harness，下一代模型就讓它變成贅肉，那還值得做嗎？
不是所有 harness 都會過期
只是 Anthropic 那個案例，被引用的方式可能太粗糙。仔細看它說的：那個 reset 機制，是為了補償某一代模型的特定缺陷而存在的。 缺陷消失，補償就變成贅肉。這很合理，但那只涵蓋了 harness 的一半。
因此我們可以用「存在的理由」把 harness 分拆成兩種：
補償型的：因為模型目前還做不好某件事而存在。context reset、為了壓住某個壞習慣而越寫越長的 system prompt、針對特定失敗模式設計的 retry 規則。這類東西的價值和模型能力反向連動，模型每變強一代，它就變爛一輪。
承載型的：因為我們的系統和組織本要求這件事而存在。發 PR 前後的流程是什麼、build 跟 test 到底怎麼下、哪些邊界不能碰、哪些東西必須通過指定的驗證才進 git 的 main branch。
承載型存在的理由不是模型不夠聰明，而是組織、產品與工程本身都有自己的邊界、流程與正確性定義。
而這正是模型追不上、或根本不知道自己要追的地方。更新的模型，可能更容易讀懂我們 payment 邏輯裡那三個歷史包袱；但它無法憑空知道哪一個到今天仍是公司的商業邏輯、哪一個早就可以刪掉。組織與團隊情境下的判斷與決定，可能藉由提供更多的營運資料與 human in the loop 來進一步處理，卻難以單靠模型的能力成長。
所以當模型變強，第一種會被吃掉；第二種不但不會，反而更吃重。agent 能承擔更多工作、做得更快時，「界定它該做什麼、讓它能做得對、並且能審查它是不是有做對、可重現、能改善未來做錯的機會」的那層就更關鍵了。
那麼，軟體工程主管能從這個公式裡帶走什麼？
我的解讀是：對直接使用第一線最先進模型的大多數工程團隊來說，model 首先就是一個外部依賴。今天最好的那一個，六個月後未必還是；而你的競爭對手也能取得同一級的 model capability。你不會因為早一兩年在用當年的 frontier model，你的 model 就比別人的厲害。
不禁回憶起早期一兩年花在跟還不是那麼會寫 code 的 model 共同開發的時光，有趣好玩；但就產出來看，不好說是很明顯的投資；也許說團隊與自己的成長更實在一些。
而承載型的 harness 是我們寫得進 git 的那一層：AGENTS.md、skills、evals、權限邊界、CI gate，是「我們公司的東西要怎麼跑起來」的關鍵知識。即便 IaC 和 policy-as-code 早就在做這件事；harness 真正新增的，是把「怎麼讓 AI 做工程」這件原本高度隱性的東西，拉到變成第一線的工程資產。
而這就接了一個更值得問的問題，它跟 AI 其實沒直接關係：
你的組織過去一年在 AI 上累積下來的東西，有多少存在 repo 裡，有多少只存在某幾個工程師的操作習慣裡？
如果答案偏向後者，那麼你們請到的不是工程能力的提升，而是一個新的、更難察覺的 bus factor，因為它甚至沒有留下程式碼。
以前資深工程師離職，至少還留下他寫的東西。現在他可能只是帶走了「怎麼讓 agent 做對事情」的那套隱性手感，而你連他帶走了什麼都說不出來。
模型會換代。工具會換代。人會離職。問題永遠是同一個：
換完之後，留下的是什麼？
本文為系列第一篇。下一篇會拿這把尺去量幾個我實際跑過的東西：cmux、herdr、Hermes，看哪些是補償型、哪些是承載型，以及分類在哪裡開始不夠用。之後還想談：怎麼讀一份 agent benchmark，以及為什麼「寫更多 context 檔案」不一定讓 agent 表現更好。
資料來源
- DeepSeek Harness on GitHub 開源，2026-08-13
- OpenAI，【Harness engineering: leveraging Codex in an agent-first world】，2026-02
- Anthropic，【Scaling Managed Agents】，2026-04-08
- Epoch AI，【What skills does SWE-bench Verified evaluate?】
- Andrej Karpathy，context engineering 定義，2025-06
- Meta Muse Code 產品發布，2026-08