機器之心編輯部

2026 年以來，OpenAI、Anthropic、LangChain 等機構紛紛發布關于 Harness Engineering 的技術博客，OpenClaw、Hermes Agent 等項目的火爆更讓 Harness Engineering 成為業界熱詞。人們的共識正在形成：模型的能力釋放，依賴于一套精密的外部框架

Harness 的開發與優化是一個工程問題，需要結合模型能力、任務環境共同設計。然而，模型自身以月為單位進化，任務場景往長尾分布發展，Harness 的進化與迭代卻高度依賴人工經驗。 這引出了一個核心問題：在 Harness Engineering 的迭代循環中，哪些部分可以被自動化？如何讓 Harness 自動地從經驗中學習并改進？

來自復旦大學、北京大學、上海奇績智峰的團隊提出Agentic Harness Engineering (AHE)，這是一套可觀測性（Observability）驅動的 Harness 自動優化方法，端到端貫穿 Harness Engineering 的全流程，實現了模型能動性的最大程度釋放。

• 論文標題：Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses
• 論文鏈接：arxiv.org/abs/2604.25850
• 代碼倉庫：github.com/china-qijizhifeng/agentic-Harness-engineering
• 項目博客：https://dawning-road.github.io/blog/agentic-Harness-engineering

在實驗期間，使用 GPT?5.4，AHE 在 Terminal-Bench 2 上的分數從 69.7 迭代到 77.0。GPT-5.5發布后，AHE迅速迭代出與之適配的Harness，在 Leaderboard 上位列全球第三

并且，自動迭代得到的 Harness 展現出良好的模型間泛化以及任務間泛化能力，確保不是在 overfit 評測集。

目前論文在社交平臺 X 上收獲大量關注，已經有 10w + 瀏覽討論。

為什么要設計可觀測體系？

Harness Engineering 的三個視角

從形態上看，模型和 Harness 共同構成一個主體和環境進行交互。模型的所有行為都發生在概率空間中，是信息壓縮、智能發生、不確定性的來源，而 Harness 是包裹在外的確定性組件：system prompt、工具定義與實現、middleware/hook、skill 文檔、sub-agent 編排、長期記憶、日志與觀測。在 agent 邁向長程、生產力任務過程中，Harness 是讓模型行為穩定、一致、可控的重要保證。

從目的上看，Harness 的職能之一是在模型和環境之間管理一條雙向的上下文流：一側在合適的時機把任務、用戶意圖、環境狀態、外部信息傳進模型，另一側把模型的動作忠實地記錄、校驗后交回環境執行。

過去，開發者需要手動設計 prompt、復制 terminal 輸出、復制外部文檔內容給模型，上下文分布在互不相通的空間里，人類依據直覺和觀察來決定 context 的構成。因此，Harness 的設計目標之一，就是讓 context 的流動可以更加精準、更加自主。

基于以上的形態與目標，Harness Engineering 的方法論是什么？

最直觀的，是獨立優化各個組件代碼，或者稱之為 Agent Infra。開發者社區貢獻了大量有用的 Harness 組件，用于記憶、上下文管理、沙盒環境、軌跡管理，這依賴于扎實的工程開發與優化，讓各個部分的獨立地變得更加高效、安全、穩定。

進一步地，對于任意一個特定環境，若要找到最優的 Harness，這就成為了一個模型 x Harness x 環境的組合優化問題。不再能像開發單獨組件那樣有一個明確的規則，不再能利用人類開發者的先驗知識一步到位找出最優組合，而是要開發、觀測、迭代，根據模型的運行軌跡、評測分數，反復調整。

人類的注意力是稀缺的，因此，必須讓 agent 本身也參與到 Harness 優化的過程中來。只要把優化目標、動作空間、狀態空間都以一種 agent 可讀的方式呈現，那么就可以引入 agent 進行自主優化。這便是 AHE 設計可觀測體系的出發點。

可觀測體系：組件、經驗、決策

Harness 的開發也分為幾個階段：編寫組件、運行 agent、收集反饋。這個過程反復迭代，持續運行。如果要想讓 agent 接手人類的工作，就需要在此過程中所產生的 context 可觀測，并且做好 context 結構化、層次化。

在此過程中，并不限制 agent 的自主決策空間，只依賴評測結果，以及更多分層信息來輔助它精準修改、準確歸因。

AHE 方法由三個角色構成：Coding Agent 負責運行測試，Agent Debugger 負責整理軌跡，Evolve Agent 負責修改 Coding Agent 的 Harness 實現進化。

整個可觀測體系分三部分：

1. NexAU 提供各部分解耦的 Harness，提供 Harness 組件的可觀測性；
2. Agent Debugger 把 10M token 量級的 raw trace 提煉成分層的、可溯源的多維反饋意見，實現經驗的可觀測性；
3. Evolve Agent 基于 git 溯源的組件歷史、反饋結果，構建證據驅動的完整修改鏈路，對相應組件進行修改，實現優化行為的可觀測性。

（1）組件可觀測性：解耦的 “聲明式 Harness”

Coding Agent 基于 NexAU 框架運行。AHE 把 Harness 拆成了七種正交的文件級組件：System Prompt、Tool Description、Tool Implementation、Middleware、Skill、Sub-agent Config、Long-term Memory。每個組件都是一個獨立的文件，有明確的掛載點，彼此之間結構解耦。

這種設計的巧妙之處在于：它讓 “失敗模式 - 單一組件” 的映射關系變得極其清晰。 所有修改通過 Git 進行版本管理，每次變更都是一次可追溯、可審計、可回滾的 commit。

目標 Coding Agent 則故意從一個 “零先驗” 的極簡形態起步：只有一個 run_shell_command 工具，沒有任何 Middleware、Skill 或 Sub-agent。這樣做是為了確保后續每一次新增組件、每一次 Prompt 改寫，都能被干凈地歸因。

（2）經驗可觀測性：Agent Debugger 把軌跡變成可消費資產

一次完整評測所產生的原始軌跡動輒數千萬 Token，如果把它們直接丟給 Evolve Agent，其上下文窗口將瞬間被淹沒，什么代碼都改不了。

AHE 開發了一套名為 Agent Debugger 的分層提煉流水線：底層完整記錄所有原始軌跡；中層由 Cleaner 去除重復的工具輸出；上層則通過一個 QA Sub-agent，針對每道題的多次 rollout 結果，自動切換提問策略。最后，所有單題分析匯聚成一份約 10K Token 的概覽報告，交給 Evolve Agent 消費。

本質上，這是一種漸進式披露的設計。Evolve Agent 默認只需閱讀概覽，但隨時可以查看單題細節，在需要核實結論時回溯原始軌跡。10M 級別的數據由此變成了可并發、可消費、可審計的經驗資產。

（3）決策可觀測性：Evolve Agent 的 “證據驅動修改”

Evolve Agent 的設計原則極其克制，目的是為了實現穩定進化：

• 只能修改 workspace 內的 Harness 組件文件，評測框架、LLM 配置、原始 System Prompt 均為只讀，杜絕任何繞過評測的 hacking 行為。
• 每次修改必須附帶一份 “變更清單”，包括：失敗的證據（具體哪些任務失敗了）、推斷的根因、針對性的修改方案，以及自我聲明的預測（預計修復哪些任務、可能破壞哪些任務）。每一輪修改后，由下一輪評測充當驗證者：預測正確的修改保留，預測錯誤的修改自主決定回滾。

如此一來，每一次 Harness 變動都不再是工程師的直覺、抽象經驗，而是一條可被下一輪實驗所證偽的假說。Harness 進化由此從藝術走向工程，從經驗走向科學。

實驗結果：超越人類專家，跨模型泛化

在主實驗上，AHE 將 GPT-5.4 驅動的 Coding Agent 在 Terminal-Bench 2 上的 pass@1 分數從最初的 69.7% 提升到了 77.0%，絕對提升 7.3 個百分點，相對提升 10.5%。這一成績不僅超過了同樣使用 GPT-5.4 的 OpenAI 官方 Codex-CLI（71.9%），也顯著優于 ACE 和 Training Free-GRPO 等主流基線。

更讓人驚喜的是泛化能力。

跨任務泛化： 將在 Terminal-Bench 2 上演化得到的 Harness 凍結后，直接遷移到 SWE-Bench Verified 上，AHE 以更少的 Token 消耗實現了比 ACE 和 TF-GRPO 更高的成功率。這表明演化學到的不是 “如何刷 Terminal-Bench 2” 的特化知識，而是可遷移的通用工程經驗。

跨模型泛化： 同樣一份由 GPT-5.4 演化得到的 Harness，分別配到 Qwen-3.6-Plus、Gemini-3.1-Flash 和 DeepSeek-V4 上，不做任何再演化直接評測。結果是三種模型均獲得 +5.1 到 +10.1 個百分點的顯著提升，且模型越弱，提升越大。這套 Harness 并非為某個特定模型量身定制，而是學到了一些真正普適的結構性原則。

價值到底沉淀在哪里？

事實比策略更可遷移

在博客中，作者還提到了一些前期的失敗探索。為了快速迭代，團隊最初只在 Terminal-Bench 2 的 30 道 hard 難度的題目上做 10 輪演化。結果題目通過數在 16-20 間反復震蕩，基本修一個壞一個。分析最終版本的 Harness 發現，Evolve Agent 對特定任務寫了針對性的 hack：Golden Gate 的 splice-offset 檢測、Caffe 的完整工作流模板等等。這表明，過小的題集讓單一題目的信號過強，抑制不住 agent 的 hack 傾向

團隊將題集擴到 89 題的全集，并在 Evolve Agent 的 System Prompt 中加入顯式的方法論指導，比如 “Safety/Creativity/Generality” 原則和 “Middleware > Tool Desc > Skill > Prompt” 的約束層級排序。結果 overfit 確實緩解了，但訓練曲線在 75.3% 就早早觸頂不再上升，78% 的修改都落在 Middleware 層。人工引入的行為先驗，恰恰成了進化的僵化之源

最終版本做了兩個關鍵改動：一是在評測時每題跑兩次，通過 partial-pass 的 diff 定位最精準的診斷信號；二是刪掉所有行為指導，只保留證據驅動過程要求和回滾規則。

結果上，不僅分數上穩步提升至 77.0%，修改分布也變得更加健康：middleware 37% + tool 48% + prompt 10%，沒有任何層級單獨占比超過一半，不同階段靈活調整。

一個來自社區的慣性思維是 “先調整 Prompt”。然而，把 AHE 演化得到的四類組件（Memory、Tools、Middleware、System Prompt）逐一單獨放回最初的 Harness 上進行消融實驗時，結果卻截然相反：Memory 單獨就能恢復全局增幅的 95% 以上，Tool 在中等難度題目上提升顯著，而 System Prompt 單獨遷移反而導致性能下降。

一個可能的原因是：Prompt 的語義是策略性的（你應該這樣做），而 Memory 和 Tool 的語義是事實性的（這里有一段可復用代碼）。事實比策略遷移性好，它們保留了信息，同時維持了泛化性。這或許也解釋了為什么人類試圖通過注入方法論來指導 Evolve Agent 時會遭遇失?。洪_發者習慣于教策略，而模型更擅長學事實。

結語：可觀測的進化循環會讓 AGI 加速到來

AHE 帶來的最大啟示或許在于：當模型足夠強，搭建一個結構化的、可觀測的演化環境，比直接開發 Harness 更重要。搭建好觀測體系（讓 Evolve Agent 能訪問組件、軌跡、反饋），然后在全量數據上運行測試，就足夠演化出有競爭力的 Harness。無需替 Agent 思考任何方法論，只是給它一個清晰的 workspace、明確的修改接口和高質量的反饋信號，Evolve Agent 的行為便自動向真實工程師收斂。

是時候邁出第一步，讓 Harness 也開始進化了。