如果你在 2026 年春天逛過 AI 工程圈，大概很難不撞見這個詞：Harness Engineering。

• AI Agent 會忘事
• 會跑偏
• 會提前宣告任務完成
• 會把局部修修補補變成全系統性事故

模型越強，這些問題不但沒有自然消失，反而被放大。因為當你不再拿它來回兩句話，而是讓它連續工作六小時、改完整個 codebase、自己開 PR、自己 review、自己部署時，真正決定成敗的，已經不是模型有多聰明，而是你給它的工作環境夠不夠穩。

Harness Engineering 就是在這個背景下浮上檯面的。

它要處理的，不是「怎麼把話講清楚」，也不是「怎麼把資料餵對」，而是更殘酷的問題：當 AI 開始真的做事，你要怎麼讓它不失控？怎麼讓它可驗證、可糾錯、可長時間推進，甚至可被其他代理接手。

這篇文章想做的，不是把它說成一個潮語，也不是替它寫一篇行銷稿。我要做的是把它放回時間軸，看看它到底從哪裡長出來；再把它放回今天的版圖，看看它到底在和什麼競爭、填補了什麼空白。

更重要的是，回答一個很多人其實都在問、但不太敢直接問的問題：Harness Engineering 究竟是不是一門新學科，還是只是把軟體工程老問題重新包裝之後，丟回 AI 時代的戰場？

以下以 2026 年 4 月為觀察時間點。

一、縱向分析：Harness Engineering 是怎麼被逼出來的

1. 在它被命名之前，問題其實已經存在很久了

如果只看名詞，Harness Engineering 像是 2026 年突然出現的新東西；但如果看它要解的問題，它其實是 2024 到 2025 年整個 agentic software engineering 自然演化出來的下一步。

最早大家談的是 Prompt Engineering。那是一個相信「說對話，模型就會做對事」的年代。系統提示詞、角色設定、few-shot、CoT，一切都圍繞著一句話：如何用更好的措辭，換到更好的單次輸出。這套做法在一次性任務上很好用，例如摘要、翻譯、格式轉換、簡單程式片段生成。

但只要任務一拉長，問題就來了。模型不是只要回答一次，它要讀專案、理解架構、修改多個檔案、調用工具、驗證結果、記住先前承諾、承接上一輪上下文。這時候，單一 prompt 立刻顯得太薄。

於是 2025 年開始，焦點往 Context Engineering 移動。這一波的核心轉向很明確：問題不只是你怎麼問，而是模型在每一個決策瞬間，到底看到了什麼。Anthropic 在 2025 年 9 月的文章把這件事說得很清楚：當 agent 要跨越多輪推理與更長時間尺度時，真正要管理的不是某一條提示詞，而是整個 context state，包含系統指令、工具、外部資料、訊息歷史、MCP 介面、檢索結果與執行產物。

這是一個很重要的躍遷，因為它第一次把「AI 工程」從文案雕刻，變成資訊流與狀態管理。

但 Context Engineering 再怎麼重要，還是有一個天然邊界：它主要處理的是「模型看到什麼」。它還沒真正處理以下這些問題：

• 「如果做錯了，怎麼讓它自我修正？」
• 「如果它工作了六小時中途斷線，下個代理怎麼接手？」
• 「如果它寫出來的東西在架構上慢慢腐化，誰來阻止熵增？」

這些問題，就是 Harness Engineering 真正要接手的部分。

2. 這個詞會在 2026 年爆紅，不是偶然，而是瓶頸真的換位置了

很多技術名詞的流行，來自敘事；Harness Engineering 的流行，更像來自工程現實的逼供。

原因其實很簡單：模型能力在 2025 年下半年到 2026 年初跨過了一條心理門檻。它們已經強到足以讓人停止爭論「能不能用」，開始爭論「為什麼還是不好用」。OpenAI、Anthropic、LangChain、Datadog 等團隊在這段時間，先後都透露出同一件事：長鏈任務裡最痛的，不再是模型不會寫，而是整個外圍系統沒有把它托住。

Anthropic 在 2024 年底談「effective agents」時，還強調先用簡單可組合模式，不要過度迷信框架。到 2025 年的 context engineering 與 long-running agents 系列文章時，語氣已經變得更具體：

• agent 會試圖一步到位，最後把上下文耗盡；
• 會在做到一半後，看到一點進度就提早宣布勝利；
• 會寫完代碼就說自己完成，卻沒真正做端到端驗證。

這些不是模型「不聰明」，而是系統沒有給出足夠強的節點控制、狀態切分、驗證回路與交接機制。

換句話說，當模型變強，瓶頸反而更清楚地暴露出來了。以前大家怪馬不會跑；現在馬會跑了，才發現問題是沒有鞍、沒有韁繩、沒有路標、沒有柵欄、也沒有剎車。

3. 名字是 Mitchell Hashimoto 先點破的，但把它推進主流的是 OpenAI

關於「誰發明了 Harness Engineering」這件事，最穩妥的說法不是「誰創造了這門學科」，而是「誰先把分散的工程痛點命名成一個可討論的物件」。

這個命名節點，通常會回到 Mitchell Hashimoto 在 2026 年 2 月 5 日發表的〈My AI Adoption Journey〉。那篇文章不是學術論文，也不是公司白皮書，而是一篇非常工程師、非常實作導向的工作流反思。

文章裡他講到自己使用 AI 編碼工具一路踩坑，最後走到「Engineer the Harness」這一步。它的核心想法非常直接：每當 agent 犯下一個反覆出現的錯，你不該只是在下一輪 prompt 裡多加一句提醒，而是應該花力氣把一個新的環境機制做出來，讓它未來不再犯同樣的錯。

這句話的重要性，在於它把改善 agent 表現的工作，從「臨時糾正輸出」提升成「設計外部系統」。也就是說，真正該工程化的，不是模型本身，而是模型外面的那層駕馭系統。

但如果沒有 OpenAI，這個概念大概還會停留在少數工程師的個人體感。真正把 Harness Engineering 推進主流的，是 OpenAI 在 2026 年 2 月 11 日發表的〈Harness engineering: leveraging Codex in an agent-first world〉。

那篇文章之所以震動圈內，不只是因為用了這個詞，而是因為它拿出了一個極端案例：OpenAI 團隊從 2025 年 8 月下旬的空 Git 倉庫開始，在五個月內做出一個有內部日活與外部 alpha 用戶的 beta 產品。整個代碼庫約一百萬行，約一千五百個 PR，起初由三位工程師驅動，之後擴到七位，並強調整個過程中人類沒有直接手寫任何代碼。

這個實驗真正有力的地方，不是「AI 寫了很多 code」，而是它公開承認：早期進展變慢，不是因為 Codex 不夠強，而是環境定義不夠清楚。於是工程師的工作不再是親自寫代碼，而是設計知識結構、設定架構邊界、讓 UI 與 observability 可被代理讀懂、把 AGENTS.md 從百科全書改成目錄、把 docs 做成唯一可信來源、用 linters 和 structural tests 強制約束、再用背景代理持續清理熵增。

那篇文章幾乎等於對外宣告：AI 時代的工程槓桿，正從 code authoring 轉向 environment authoring。

4. 從「一篇案例」變成「一套框架」，靠的是後來幾波補完

OpenAI 把概念推紅了，但它並沒有把概念講完。這也是為什麼 2026 年 2 月到 4 月之間，整個圈子出現了一波非常密集的補完工作。最值得注意的，是 Thoughtworks 與 Martin Fowler 網站上的一系列文章。

Birgitta Böckeler 在 2026 年 2 月 17 日的 memo 就先對 OpenAI 的敘事做出一個非常關鍵的提醒：OpenAI 的文章很強調 maintainability、architecture constraints、garbage collection，但對「功能與行為是否真的被正確驗證」談得還不夠。這個提醒很重要，因為它點出一個現實：如果 Harness Engineering 只是把 codebase 維持得整齊，那它還不夠成為一門完整的方法。真正難的是，你不只要讓代理寫得乾淨，還要讓它寫得對。

到了 2026 年 4 月 2 日，Böckeler 在 Martin Fowler 網站發表完整文章〈Harness engineering for coding agent users〉，整個概念才開始變得有可操作性。她提出一個非常有用的心智模型：

• Guides（前饋控制）： Guides 是前饋控制，在代理採取行動前就先引導它，例如 AGENTS.md、架構文件、技能、工具說明、可讀規範。
• Sensors（回饋控制）： Sensors 是回饋控制，在代理行動後產生糾錯訊號，例如 linter、型別檢查、測試、AI code review、監控訊號。

這個分法的價值很高，因為它讓「harness」不再只是一個含糊的大袋子，而是能拆成具體的控制機制。更進一步，Böckeler 還把 regulation category 擴成三層：可維護性、架構適配度、功能／行為。這幾乎等於補上 OpenAI 那篇文章最缺的一塊：你不是只要讓代理遵守格式與分層，你還要能衡量它交出的結果，在真實行為上是不是符合預期。

同一時間，LangChain 在 2026 年 2 月與 3 月把 Harness Engineering 轉譯成平台語言。他們一方面用〈Improving Deep Agents with harness engineering〉展示：同一個模型不變，只改 harness，在 Terminal Bench 2.0 上就能從 52.8% 提升到 66.5%，從榜單前 30 名外躍升到前 5；另一方面又在〈The Anatomy of an Agent Harness〉把 Harness 定義成模型之外的一切，包含 system prompts、tools、skills、MCP、filesystem、sandbox、orchestration、hooks、middleware、state、feedback loops。這一步很關鍵，因為它讓 Harness Engineering 從大型企業的內部案例，變成開發框架與 agent platform 可以直接販售、封裝、模組化的東西。

Datadog 則把另一條支線補上了：verification 與 observability。它在 2026 年 3 月的文章裡明確主張「harness-first engineering」，核心論點是：AI 可以比任何團隊更快產生軟體，但驗證速度成了新瓶頸。真正可擴張的方法，不是人類去讀每一行 agent 生成的 code，而是投資自動化驗證、模擬測試、形式規格、shadow evaluation、觀測回授，讓 harness 先替人類完成大部分不信任檢查。這讓 Harness Engineering 又往前走了一步：它不只是 software delivery 的方法，也開始往 reliability engineering、observability、SRE 的邊界靠攏。

5. 它真正改變的，不只是技術棧，而是工程師的位置

回頭看這條演進路徑，你會發現 Harness Engineering 最深的變化，可能不在工具，而在人。OpenAI 的文章裡最醒目的一句，不是「我們做出了一百萬行 code」，而是「工程團隊的主要工作不再是寫 code，而是設計環境、明確意圖、建立回饋迴路」。這句話在過去幾年很容易被當作誇張說法，但到了 2026 年，它開始變得具體。

因為當你真正讓 agent 在長鏈任務中持續工作，人類最有價值的地方，確實不再是逐行輸入，而是：

1. 定義什麼叫做完成；
2. 定義哪些邊界不可以碰；
3. 建立哪些訊號能判斷它偏了；
4. 決定哪種知識要進 repo、哪種必須被版本化；
5. 持續把失敗案例轉譯成新的 guardrail。

這其實很像把工程師的工作，往架構師、平台工程師、測試設計者、品質機制設計者方向拉。不是說人不再寫 code，而是「寫 code」這個動作不再是唯一、也未必是最高槓桿的行為。

6. 到 2026 年 4 月，它仍不是定型理論，而是一場快速凝固中的共識

說到這裡，還是得給一個冷靜的判斷：Harness Engineering 到 2026 年 4 月為止，仍然不是一個有清晰邊界、統一教材、統一架構、統一最佳實踐的成熟學科。它更像是一個剛剛凝固的共識：大家都已經意識到，agent 的真正戰場在模型外面；但對於這個「外面」到底應該如何拆模組、如何量測、如何標準化、如何和 context engineering、workflow orchestration、agent platform、MCP、observability、policy engine 分工，業界還在形成中。

這也是它最值得研究的地方。因為很多概念在成為教條之前，才最能看見它真正處理的問題。

二、橫向分析：Harness Engineering 在今天和誰競爭？

1. 先判斷賽道：它其實沒有「直接競品」

如果把研究對象視為一門方法論，而不是一個產品，那麼 Harness Engineering 比較接近「場景 A：無直接競品」。原因很簡單：它不是某一家公司推出的軟體，不是一個單獨框架，也不是某個 SDK 的品牌名稱。它更像是一個新的總括性視角，用來統整那些原本分散在 prompt、context、tooling、sandbox、verification、observability、CI、policy、memory、review、entropy management 裡的工程工作。

也正因如此，它沒有一個可以一對一對打的「同類產品」。你很難說 Prompt Engineering 是它的競品，因為它更像它的下層；你也很難說 LangGraph、CrewAI、AutoGen 是它的競品，因為那些更像它可能會使用的框架或執行器；你甚至不能說「強模型」是它的競品，因為模型變強通常只會讓 Harness 的瓶頸暴露得更明顯，而不是把它替代掉。

所以，更合理的分析方式，是看哪些路徑在試圖解決同一個核心問題：**如何讓 AI Agent 可靠地完成真實世界任務。**從這個角度看，Harness Engineering 今天面對的主要不是直接競品，而是幾種不同的替代性工程路線。

2. 第一條替代路線：Context Engineering 派

如果說 Harness Engineering 是在回答「怎麼讓 agent 可靠做事」，那 Context Engineering 派回答的問題會更窄一點：怎麼讓模型在做事時，看到正確且足夠的資訊。

這一派最大的優點，是入門門檻低、成效立竿見影。你不需要重做整個工作流，只要改善檢索、記憶、工具描述、上下文壓縮、動態注入與 token 佈局，模型表現就可能明顯變好。Anthropic 對這條路線的系統化整理，讓很多團隊第一次意識到：context 不是一個附屬品，而是每一輪推理時模型真正活著的資訊環境。

對使用者來說，這派做法的口碑通常是「最好懂，也最先見效」。尤其在問答、知識檢索、客服、研究助理、文件生成這類偏資訊工作中，Context Engineering 幾乎已經成為必要基本功。很多產品表面上看是在比模型，實際上比的是誰的 context 組裝更乾淨。

但它的問題也很明顯：只靠上下文管理，還不足以支撐真正長鏈、可執行、低容錯的任務。你可以讓 agent 更知道該做什麼，卻未必能保證它真的會做完、做對、做到不偏。當任務進入多步驟執行、跨 session 狀態延續、工具副作用管理、驗證回授、權限控制這些層次時，Context Engineering 會開始顯得像地基，重要，但不夠。

換句話說，**Context Engineering 最像 Harness Engineering 的前一站，而不是對手本身。**它填的是資訊供給的空白，Harness 則接手執行可靠性的空白。

3. 第二條替代路線：Workflow／Agent Framework 派

另一條常被誤認為和 Harness Engineering 同義的路線，是各種 agent framework 與 workflow orchestration 工具。最典型的代表包括 LangGraph、CrewAI、AutoGen 以及後續大量冒出的 multi-agent 編排系統。

這一派的核心魅力很實用：它讓人可以比較快地把「多步驟任務」拆成圖、節點、角色與流轉邏輯。對很多團隊來說，這比從頭設計一整套 agent runtime 容易得多。你可以先有 planner、executor、reviewer，也可以先有 researcher、writer、critic，透過圖狀結構讓多代理協作看起來更清楚。使用者喜歡它的理由，通常是真正能動起來。你不用先建立一個龐大的平台，就能做出 prototype，這對產品團隊非常有吸引力。從 demo 到 POC 的速度，往往很亮眼。

但這條路線的問題，是它很容易把「有流程」誤當成「有可靠性」。Framework 可以幫你把節點串起來，卻不一定幫你處理文件系統、上下文腐敗、sandbox 安全、工具回傳品質、驗證訊號、錯誤恢復、長時程狀態續接、架構約束與熵管理。Anthropic 在 2024 年談 effective agents 時其實就提醒過：框架有助於快速起步，但也常帶來額外抽象層，讓 prompt、response 與真實失敗模式更難 debug。

這就是 Workflow 派和 Harness 派的本質差異。**前者比較像交通路線圖，告訴你工作如何流動；後者更像整套交通系統，包含路、護欄、號誌、事故處理、違規偵測、車輛保養與道路維運。**兩者不是誰取代誰，而是成熟系統終究會發現，光有流程圖不夠。

4. 第三條替代路線：模型優先派，或說「更強模型會吃掉一部分 harness」

這條路線通常不會正式寫成一套理論，但在業界很常見。它的直覺是：既然模型越來越會推理、越來越會自我修正、越來越懂工具，那很多原本需要外部 harness 做的事，也許會被模型內生化。最早大家用 Sequential Thinking 一類外掛工具來逼模型一步一步想；後來 reasoning model 變強後，很多人開始覺得某些外掛控制件會過時。

這種想法不是沒有道理。歷史上很多工程外掛，最後確實會被平台內建能力吃掉。模型如果真的更懂長程規劃、懂代碼編輯、懂錯誤修復、懂壓縮上下文，那麼一些粗糙的外層繞法確實會變得多餘。

但這派最大的誤判，是把「能力更強」等同於「系統更可靠」。模型內生化掉某些技巧，不代表權限、安全邊界、跨 session 狀態、一致性驗證、審計追蹤、與真實世界工具的契約設計會自動消失。你可以讓馬更聰明，但你還是得決定哪裡有懸崖、哪裡要設柵欄、哪裡可以上高速、哪裡要限速。

因此，比較合理的判斷不是「更強模型會取代 harness」，而是**「更強模型會吃掉部分低階 harness，逼 harness 往更高層移動」**。這也是為什麼很多人說，Prompt Engineering 沒有死，只是被包含進 Context；Context 沒有死，只是被包含進 Harness。工程嚴謹性不是消失，而是不斷搬家。

5. 第四條替代路線：驗證優先派，也就是 Datadog 式的 harness-first

如果前幾條路線的焦點分別是資訊、流程或模型能力，那 Datadog 這類路線最鮮明的特徵，就是把「驗證」放在最前面。它其實很接近 Harness Engineering，但風格上比 OpenAI 式的 coding-agent workflow 更偏向 reliability engineering。

這一派的信念很明確：AI 生成速度已經超過人類驗證速度，所以擴張的關鍵不在讓 agent 再多寫一點，而在讓系統能快速自動說出「這裡錯了」。因此它會特別強調 deterministic simulation、formal specification、shadow evaluation、telemetry-driven feedback、production validation，讓觀測資料本身成為 agent 的感測器。這種做法在高可靠、高合規、分散式系統、平台型產品上特別有吸引力。因為對這些場景來說，最貴的不是生成，而是錯誤落地。

但它的門檻也高。不是每個團隊都具備完整 observability、評測設計、formal-ish contracts 與 production shadowing 的能力。對早期團隊或需求變動很快的產品團隊來說，這條路會被嫌重、嫌慢、嫌像在還沒開工前先蓋半座品管工廠。所以從生態位來看，Datadog 式方法不是面向所有人，而是代表 Harness Engineering 往「成熟企業級方法」演進時，很可能出現的一個高配版本。

6. 從使用者視角看，大家真正買單或抱怨的是什麼

如果把官方文章的語氣拿掉，回到開發者的真實感受，對 Harness Engineering 的評價其實非常一致：喜歡它的人，通常不是因為覺得這個詞很新，而是因為終於有人把自己每天撞到的牆說清楚了。

被提到最多的痛點：

• agent 反覆犯同樣的錯。
• agent 容易做到一半失憶。
• agent 常以為自己完成了，其實沒完成。
• agent 會把 codebase 裡本來就不夠好的模式快速複製放大。
• 當模型可以連續工作數小時後，人類 review 反而成了新瓶頸。

這些抱怨，在 Anthropic 的 long-running agent 文章、OpenAI 的實驗回顧、LangChain 的 trace analysis、Datadog 的 observability 驗證敘事裡，其實彼此對得上。

而支持者最常說的優點：

• 當 guardrails 做對後，吞吐量上升非常明顯。
• 把錯誤轉譯成機械約束後，很多 review toil 會消失。
• 把知識放進 repo、把規範做成可驗證資產後，agent 表現會更穩。
• 好的 harness 對弱模型尤其有放大效應，有時比升級模型更有用。

當然，懷疑也不少。最大的質疑通常有三類：

1. 可重現性質疑： OpenAI 的案例很震撼，但外界很自然會問：這能否被一般公司複製？是否過度依賴 OpenAI 自己的內部條件？
2. 長期品質質疑： Böckeler 的提醒就很典型：你現在證明了 maintainability 與 architecture 的一部分，但跨年尺度的行為正確性、產品一致性與技術債衍生會怎麼演化，還沒有人真正知道。
3. 成本質疑： Harness 很好，但不是免費。你得寫 docs、設 lint、做測試、建 sandbox、接 observability、做 agent-readable tooling，這本身就是一筆工程投資。

也就是說，大家並不懷疑這個方向的重要性；真正懷疑的是，值不值得現在就全力押注，以及誰有能力把它做好。

7. 它在整個賽道中的生態位：不是功能模組，而是價值聚集層

如果把 AI 應用層想成一條鏈，最底下是模型，中間是 context、tools、memory、workflow，最上面是產品與使用者體驗，那 Harness Engineering 的位置，其實不是某個模組，而是把這些模組串成可交付系統的中介層。它填補的不是「模型不夠聰明」，而是「模型很聰明，但不夠可信、不夠穩、不夠可延續」的空白。

也正因如此，未來真正可能從它身上長出來的競爭者，不會是一個單點替代品，而是幾種不同類型的平台：

• 一種來自模型供應商，把更多 harness 內建進 IDE、CLI、App Server 與 agent runtime。
• 一種來自框架公司，把 sandbox、memory、permissions、subagents、hooks、human-in-the-loop 做成可組合平台。
• 一種來自 observability 與 devtools 公司，把驗證與回授做成 agent-friendly 的標準配備。
• 還有一種來自企業內部平台團隊，乾脆把自己的軟體交付規範、審核流程、架構治理，重寫成 agent-first 的工程制度。

從這個角度看，Harness Engineering 不是在和某個工具爭功能，而是在爭奪「誰來定義 AI 時代的工程默認層」。

8. 趨勢判斷：它短期會分化，長期會沉到底層

基於目前橫向比較，我的判斷是：**Harness Engineering 短期內不會收斂成一套統一框架，反而會快速分化。**原因是不同團隊的痛點不一樣。

• 做 coding agent 的，會先卡在 code editing、repo docs、review loops、architecture constraints。
• 做企業流程代理的，會先卡在工具契約、權限邊界、審計與長時程記憶。
• 做高可靠系統的，會先卡在驗證速度與 production feedback loops。
• 做產品化平台的，則會先卡在如何把這些能力封裝成可重複部署的能力層。

但中長期來看，它很可能會像今天的 CI/CD、observability、feature flags、policy-as-code 一樣，慢慢沉到底層，不再被高頻喊名字，卻變成所有認真做 agent 的團隊都逃不掉的基建。這類東西最終通常不會以「一個大詞」存在，而是拆成多個具體能力被產品化。等到那時候，也許大家不再一直說 Harness Engineering，但你會發現你每天都在做它。

三、橫縱交匯：真正改變競爭格局的，可能不是模型，而是誰先把環境寫成系統

把時間軸與競爭版圖放在一起看，Harness Engineering 最值得記住的一點，不是它有沒有資格被叫做「新學科」，而是它揭露了一個很不舒服但很真實的事實：AI 工程的主要瓶頸，正在從 intelligence problem 轉成 systems problem。

這裡的 systems，不只是傳統意義上的分散式系統或平台系統，而是更廣義的「控制系統」：你如何定義目標、如何提供資訊、如何授予能力、如何限制邊界、如何回收錯誤、如何保存狀態、如何讓代理交接、如何驗證結果、如何壓制熵增。

• Prompt Engineering 時代，勝負手是誰比較懂模型脾氣。
• Context Engineering 時代，勝負手是誰比較會安排模型看到的世界。
• Harness Engineering 時代，勝負手開始變成誰有能力把整個工作環境設計成可累積、可驗證、可繼承的工程系統。

這就是為什麼它雖然沒有直接競品，卻反而很重要。因為它不是一個功能點，而是一個重新劃分價值的邊界。模型越商品化，這條邊界越值錢。

從縱向看，它不是憑空誕生，而是 Prompt 與 Context 在長鏈任務上撞牆後的自然後果。 從橫向看，它之所以暫時沒有直接競品，不是因為它無敵，而是因為它本質上是一個上位概念，正在吞併周邊一整圈原本分散的工程實踐。

我對它的最終判斷是這樣：

**Harness Engineering 不是一場短期術語狂熱，也不是靠幾篇文章吹起來的風口。**它更像 AI Agent 真正開始承擔生產責任之後，軟體工程對自己做出的防禦性重組。它會持續變形，很多低階部分會被模型與平台內建吃掉；但它不會消失，因為只要代理仍然活在真實世界裡，仍然要碰工具、碰資料、碰權限、碰風險、碰時間尺度、碰人類有限注意力，那麼「如何為它打造可被信任的外部環境」就永遠不會變成一個可以跳過的問題。

真正的護城河，不一定在模型裡。很多時候，它在模型外面那一整套你平常嫌麻煩、但一旦沒有就會立刻翻車的東西裡。而 Harness Engineering，就是這些東西第一次被集體承認、被命名、被當成主角的那一刻。

資料來源

• Mitchell Hashimoto，〈My AI Adoption Journey〉，2026 年 2 月 5 日
• OpenAI，Ryan Lopopolo，〈Harness engineering: leveraging Codex in an agent-first world〉，2026 年 2 月 11 日
• OpenAI，Celia Chen，〈Unlocking the Codex harness: how we built the App Server〉，2026 年 2 月 4 日
• Anthropic，〈Building effective agents〉，2024 年 12 月 19 日
• Anthropic，〈Effective context engineering for AI agents〉，2025 年 9 月 29 日
• Anthropic，〈Effective harnesses for long-running agents〉，2025 年 11 月 26 日
• Anthropic，〈Writing effective tools for agents — with agents〉，2025 年 9 月 11 日
• Martin Fowler 網站，Birgitta Böckeler，〈Harness Engineering - first thoughts〉，2026 年 2 月 17 日
• Martin Fowler 網站，Birgitta Böckeler，〈Harness engineering for coding agent users〉，2026 年 4 月 2 日
• Martin Fowler 網站，Birgitta Böckeler，〈Context Engineering for Coding Agents〉，2026 年 2 月 5 日
• LangChain，Vivek Trivedy，〈Improving Deep Agents with harness engineering〉，2026 年 2 月 17 日
• LangChain，Vivek Trivedy，〈The Anatomy of an Agent Harness〉，2026 年 3 月 10 日
• LangChain 官方文件，〈Harness capabilities〉，2026 年
• Datadog，〈Closing the verification loop: Observability-driven harnesses for building with agents〉，2026 年 3 月 9 日
• Datadog，〈Closing the verification loop, Part 2: Fully autonomous optimization〉，2026 年 3 月 9 日
• Datadog，〈Observability in the AI age: Datadog's approach〉，2025 年 12 月 2 日
• Can Bölük，〈I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed.〉，2026 年 2 月 12 日
• BASHCAT，〈Harness Engineering 完全解析：當 AI Agent 的護城河不再是模型，而是環境〉，2026 年 4 月 12 日