什麼是 Harness Engineering?AI 工程從 agent 轉向系統的 2026 趨勢
2026 年 7 月的 AI Engineer World's Fair 上,AutoGPT 等 2023 年指標性的自主代理人專案幾乎無人提及,取而代之的是 Claude Code、Codex、Gemini CLI、Cursor 等以系統可靠性為核心的工具。
目錄

重點摘要
- 2026 年 7 月的 AI Engineer World's Fair 上,AutoGPT 等 2023 年指標性的自主代理人專案幾乎無人提及,取而代之的是 Claude Code、Codex、Gemini CLI、Cursor 等以系統可靠性為核心的工具。
- Lilian Weng(Thinking Machines Lab 共同創辦人、前 OpenAI 安全與研究副總裁)在 2026 年新文章《Harness Engineering for Self-Improvement》中指出,圍繞模型運作的系統,包括工作流管理、脈絡控制、權限設計、基準評測、持久狀態與持續改進機制,其重要性已與模型本身相當。
- swyx 在 2023 年 6 月提出「AI 工程師」這個詞三年後,這個職位的核心技能正在轉向:從「讓模型輸出更好的答案」,移向「讓系統在各種條件下穩定且可被驗證地運作」。
2026 年 7 月 14 日,AI Engineer World's Fair(AIEWF 2026)落幕。回顧會場上的討論,有一件事格外清晰:AI 工程三年前在意的問題,和現在在意的問題,已經不是同一件事了。
AI 工程的重心已從追求單一模型與代理人的自主能力,轉向建構圍繞模型的可靠系統工程,系統的穩定性與基準評測能力成為核心競爭力。
swyx 在 2023 年 6 月提出「AI 工程師」這個詞時,整個圈子還在爭論提示詞工程算不算一個正式職業。那個時代最具代表性的示範作品是 AutoGPT 和 BabyAGI,它們讓人第一次親眼見到大型語言模型能夠自主規劃、循環執行、呼叫外部工具,一時之間成為 AI 自主性的最佳說明。到了 AIEWF 2026,AutoGPT 一次都沒被提到。替代它的討論焦點是 Claude Code、Codex、Gemini CLI、Cursor,這些工具的共同點不是「用了更強的模型」,而是「跑在更可靠的系統上」。
2023 年的代理人熱潮,為什麼到 2026 年沒人再提了?
Lilian Weng 在 2023 年發表的文章《LLM Powered Autonomous Agents》,把代理人的架構拆解成三個核心:規劃(Planning)、記憶(Memory)、工具使用(Tool use)。AutoGPT、BabyAGI、GPT-Engineer 都是她引用的例子,這些系統把大型語言模型的自主性推向了概念驗證的極限。
到了 2026 年,Lilian Weng 的新文章《Harness Engineering for Self-Improvement》切入角度完全不同了。問題不再是「代理人能做什麼」,而是「代理人要在什麼樣的系統裡運作才可靠」。她用「harness」描述的,是圍繞代理人運作的整套基礎設施:工作流管理、脈絡控制、權限設計、基準評測、持久狀態,以及讓代理人能從過去執行結果持續改進的機制。
這個轉變不是學術立場的轉移,而是三年部署經驗的積累。大型語言模型跑起來很容易,讓它在真實業務環境裡穩定運作、出了問題能被診斷、改進後能被驗證,這才是工程師在 2026 年真正面對的難點。這些難點,模型本身解決不了,所以問題的重心才整個移開了。
Harness 是什麼?它和代理人本身差在哪裡?
最直觀的理解方式是:代理人跑在 harness 裡,harness 不只是代理人的外殼,而是它整個工作環境的定義。
Harness 決定了代理人從哪裡取得執行任務的脈絡、能呼叫哪些工具、能改動哪些資源、任務執行到一半出狀況後狀態要怎麼保存、任務完成後輸出怎麼被驗證。把代理人比作一個工程師,harness 就是這個工程師的完整工作環境,包括存取權限、能讀到的文件、完成任務後別人怎麼確認成果品質。少掉其中任何一環,代理人就算模型再強,也很難穩定跑完一個完整的工作流程。
這說明 harness 工程有一個核心挑戰:系統各部件,包括說明文件、權限設定、工具介面,必須和系統的實際行為保持同步。這不是「一次設定好就能運作」的問題,而是一個需要持續維護的工程承諾。
脈絡管理和基準評測:harness 工程最難的兩道關是哪兩道?
脈絡管理是第一道。當代理人需要維護跨越多次對話、多個執行步驟的工作狀態,脈絡視窗的長度和成本就成了真實的工程限制。什麼資訊應該留在當前的脈絡?什麼要存到外部記憶系統再視情況檢索?多個代理人協同工作時,狀態怎麼同步,誰的版本算數?每個業務場景的最佳解都不一樣,沒有通用公式可以套。
基準評測的設計比脈絡管理更難,也更關鍵,因為沒有有效的基準評測,你根本無法判斷任何改進是否真的有效。傳統軟體測試針對確定性輸出:給定輸入 A 就必須輸出 B。代理人的輸出天生不確定,而且「正確」的定義往往需要業務脈絡或人類判斷才能確認。設計出一套能大規模、自動化驗證代理人行為的基準評測套件,技術只是其中一部分;整個組織對「什麼樣的輸出算好的」要有明確且一致的認識,才能設計出有實際意義的評測標準。
這個觀察帶出一個更長遠的競爭意涵。一家公司如果能把業務知識和品質標準有效編碼進基準評測套件和代理人的工作環境,這種積累理論上很難被純粹的資本規模或使用者數量複製,因為它代表的是整個組織對自己問題的深度理解。算力可以買,工程師可以僱,但「我們知道什麼算是好的輸出,而且能自動驗證它」這種判斷力,要靠時間和真實業務經驗慢慢建起來。在基準評測和環境設計上投入愈早的公司,累積出來的競爭優勢反而比單純擴大規模更難被追上,這個邏輯在 AIEWF 2026 的討論中一再浮現。
AI 工程師接下來三年,「調模型」和「造系統」哪條路比較值?
AIEWF 2026 的訊號對技能投資方向很具體:技能的時效在這兩條路上明顯不同。
2023 年那一波 AI 工程,很大程度是調整提示詞或微調模型的時代,主要瓶頸就是模型本身的能力。誰能繞過模型限制、讓輸出更準確,誰就更有競爭力。但底層模型進步很快,今天需要技巧才能繞過的限制,明天的新版模型原生就解決了。「調模型」這條路的技能半衰期極短,不是因為技能本身沒有價值,而是底層在快速變化,你的專業優勢很容易被下一版模型的更新直接覆蓋。
Harness 工程需要的技能不同:設計可靠的狀態管理機制、建立能實際驗證代理人行為的基準評測套件、設計最小權限的工具呼叫介面、讓系統能從每次執行結果累積改進訊號。這些技能在底層模型更新時,大部分仍然有用,因為系統的可靠性需求不會因為模型更好就消失。
這裡有一個誠實的補充:「造系統」這條路,門檻在於你需要真實的業務問題和真實的部署環境,才能積累出有效的基準評測設計和狀態管理判斷力。光靠閱讀文件學不來,這和調模型需要大量實驗是同一回事,只是失敗的代價和成功的樣子長得不太一樣。對沒有業務場景可以磨練的人,這條路比看起來更難進入。
三年前,swyx 給這個新職業取名「AI 工程師」的時候,「工程」兩個字更像是一種期望。到了 2026 年,這兩個字的分量變重了:它真的是指把系統造得穩、造得能被驗證、造得能持續改進。這個標準,比「讓大型語言模型寫出漂亮的答案」難得多,而 AIEWF 2026 上被熱烈討論的工具,全都是朝這個方向在走。
常見問題
Harness 和代理人框架是同一件事嗎?
不是。代理人框架通常提供代理人運作的基礎元件,如工具呼叫介面、記憶模組、鏈式呼叫等。Harness 的範圍更廣,指的是圍繞代理人的整套運作系統,包含基準評測機制、權限控制、持久狀態管理、以及讓代理人能從執行結果持續改進的機制。框架可以是 harness 實作的一部分,但 harness 本身是更高層的系統設計問題。
傳統軟體測試方法為什麼對代理人不夠用?
傳統測試針對確定性輸出:給定特定輸入,輸出必須是特定結果。代理人的輸出天生不確定,而且「正確」的定義往往需要業務脈絡或人類判斷才能確認。基準評測設計需要先回答「什麼叫做夠好」,並找到能大規模、自動化驗證這個標準的方法,這本身是一個需要領域知識的工程問題,不是套用現有測試框架就能解決的。
標籤


