這項由北京航空航天大學未來區塊鏈與隱私計算高精尖創新中心人工智能學院與清華大學聯合開展的研究，于2026年6月1日以預印本形式發布，編號為arXiv:2606.01779，研究成果被命名為HarnessForge框架。有興趣深入了解的讀者可以通過該編號在arXiv平臺查閱完整論文。

**一個讓AI干活的難題**

假設你雇了一位助手，你給他一本操作手冊（告訴他該按照什么步驟工作），然后讓他去完成各種任務。問題來了：當任務越來越復雜、越來越多樣時，手冊里的步驟可能根本跟不上需要，而助手本身的能力也未必能完全執行手冊里要求的那些復雜操作。更糟糕的是，手冊和助手之間可能存在"代溝"——手冊寫得很好，但助手根本沒辦法照著做；或者助手很聰明，但手冊太簡陋，導致他發揮不出來。

這正是當今AI助手（也就是"大語言模型智能體"，簡單理解成能執行復雜任務的AI程序）面臨的核心困境。北航和清華的研究團隊發現，以往的方法要么只改進"手冊"（專業上叫"外部執行框架"或"harness"），要么只訓練"助手"（專業上叫"策略"或"policy"），從沒有人認真考慮過把這兩者**一起**進化——讓手冊和助手相互磨合、彼此適應。HarnessForge就是為了解決這個問題而生的。

**一、AI助手為什么總是"換個場景就不行了"**

回到那個雇員的比喻。當你的助手只需要在一家公司做固定工作時，一本寫好的操作手冊就夠了。但現代AI助手面對的挑戰遠不止于此——它既要搜索網頁查資料，又要調用各種工具和API接口，還要記住上下文、分解復雜任務、與多個系統交互。每換一個場景，對"手冊"的格式要求就完全不同。

研究團隊把這種困境概括為三種典型失敗模式。第一種是"動作說明書寫錯了"，也就是手冊規定的工具調用格式和步驟根本不對，AI按照手冊操作只會不斷出錯。第二種是"任務拆解方式不對"，手冊沒有教AI如何把一個復雜問題拆成可以逐步解決的小問題，導致AI在面對多步驟任務時束手無策。第三種是"記憶沒被正確利用"，手冊沒有告訴AI什么時候該記住什么、該回憶什么，導致AI在執行過程中遺忘了關鍵信息。

以往的解決方案就像在修一輛車時，有人專門負責換引擎，有人專門負責調方向盤，但從來沒有人把整臺車放在一起統籌考慮——引擎換了，方向盤還是舊的，兩者不配套，跑起來照樣出問題。

**二、HarnessForge的核心思路：讓手冊和助手一起進化**

HarnessForge的核心洞察非常直接：與其分別優化手冊或助手，不如把"手冊+助手"這個組合作為一個整體來優化。研究團隊把這個組合正式定義為一個"智能體系統"，用公式表達就是：智能體系統 = （執行手冊，推理助手）。

執行手冊由三個部分組成。第一部分是"規劃模塊"，負責任務分解、重新規劃和何時停止；第二部分是"動作模塊"，負責工具調用的格式規范、角色分配和協作規則；第三部分是"記憶模塊"，負責什么信息該被存儲、什么時候該被調取、如何被整理后呈現給AI。推理助手則是在手冊定義的框架內實際執行推理的AI模型，它有一個可以微調的"適配器"，可以在不改變基礎模型的情況下學習新技能。

整個HarnessForge框架分成多輪進化，每一輪都像是給這對"搭檔"進行一次深度磨合訓練。具體來說，每輪進化包含兩個互相促進的階段：先改進手冊，再讓助手適應改進后的手冊。兩者不斷螺旋上升，直到這對搭檔越來越默契。

**三、"故障診斷+檔案參考"：手冊是怎么被改進的**

手冊的改進過程有點像醫院的會診制度。當AI在執行任務時出了問題，HarnessForge不會籠統地說"這個AI出錯了"，而是會仔細分析：到底是手冊的哪個部分導致了失敗？是規劃模塊沒有正確分解任務？是動作模塊的工具調用格式出了問題？還是記憶模塊沒有及時提供關鍵信息？

這個診斷工作由一個專門的"元智能體"（可以理解成一個專門負責分析和改進的高級AI，本研究中使用的是GPT-5.5）來完成。元智能體會同時查看當前手冊的設計、失敗軌跡的具體過程以及整體表現數據，然后輸出一份詳細的"故障報告"，明確指出是規劃、動作還是記憶出了問題。

診斷完成后，系統并不會從零開始重新寫一本手冊，而是會先查閱一個"歷史檔案庫"。這個檔案庫存儲了之前所有版本的手冊及其表現數據。元智能體會從中找出那些在類似故障情況下表現良好的歷史手冊，提煉出可復用的改進方向，形成一份"改進建議書"。

有了改進建議書，系統才開始生成新版本的手冊候選方案。每一輪會生成8個候選手冊，然后通過一個"半淘汰賽"機制逐步篩選：先用200個任務測試，淘汰一半；再用200個任務測試，再淘汰一半，最終留下2個最優手冊進入下一階段。這種分階段篩選的好處是節省計算資源，不需要把所有候選手冊都在全量數據上跑一遍。

篩選標準并不只看任務完成率，而是同時考慮三個維度：任務完成質量、消耗的token數量（相當于AI的"思考成本"）以及響應延遲。這種多目標權衡的方式，保證了最終留下來的手冊不只是"能完成任務"，還要"高效地完成任務"。

**四、"量身定制的訓練"：助手是怎么適應新手冊的**

手冊升級之后，老助手可能一時半會兒適應不了新的操作流程。這就好比公司換了一套全新的工作規范，老員工還在用舊習慣干活——手冊再好，執行起來也會打折扣。HarnessForge的解決方案是為每一本手冊專門訓練一個配套的"適配器"。

這里的"適配器"是一種輕量級的微調技術（學名叫LoRA，低秩自適應），可以在不改動基礎AI模型的前提下，給模型附加一層專門針對特定手冊的行為習慣。這樣做的好處是靈活——基礎模型只有一個，但可以搭配不同的手冊配上不同的適配器，就像同一個人可以根據不同崗位的操作規范調整自己的工作方式。

訓練數據的來源非常聰明：直接復用手冊篩選階段已經收集到的成功執行軌跡，而不需要額外再跑一批任務來收集數據。只有那些成功完成任務的軌跡才會被保留，然后被分解成一個個"輸入-輸出"對：輸入是當前任務描述、手冊接口規范、已積累的觀察記錄、當前記憶狀態和可用動作；輸出是在這個手冊框架下應該做出的下一步行為。通過這種方式訓練出來的適配器，能讓助手更準確地按照新手冊的規范行事——不管是調用工具的格式、規劃任務的步驟還是管理記憶的方式，都會更符合新手冊的要求。

這種訓練方式使用的是監督微調（SFT），相當于"照著成功案例模仿"。研究團隊還探索了更強力但更耗資源的強化學習方法（GRPO和RLOO），發現它們可以進一步提升效果，但代價是需要更多計算資源——這個權衡關系在后續實驗中有詳細驗證。

**五、五個考場、兩種AI規模的全面檢驗**

研究團隊在五個各具特色的測試場景中驗證了HarnessForge的效果，使用了兩種規模的基礎模型：Qwen3-4B（40億參數，較小）和Qwen3-8B（80億參數，較大）。

第一個場景是ToolHop，專門測試多跳工具使用能力。什么叫"多跳"？就是為了回答一個問題，AI需要先調用工具A得到中間結果，再用中間結果去調用工具B，再把工具B的結果用于工具C……就像解一道需要多個步驟的數學題，每一步都依賴上一步的結果。第二個場景是SearchQA，由HotpotQA和2WikiMultiHopQA兩個數據集組成，考驗AI在本地文檔庫中檢索信息并回答多跳問題的能力。第三個場景是RestBench-TMDB，模擬調用電影數據庫的REST風格API接口，測試AI能否正確選擇API端點并組合調用。第四個場景是API-Bank，測試AI面對各類用戶需求時能否準確調用結構化API接口。

實驗結果顯示，與所有競爭方法相比，HarnessForge在絕大多數測試指標上都達到了最優水平，平均比最強的單一競爭方法高出3.56個百分點。最亮眼的結果出現在TMDB場景：在4B規模的模型上，成功率比最強基線提升了12個百分點；在8B規模的模型上，提升幅度也有6個百分點。在API-Bank場景，API調用準確率平均提升了近5個百分點。在ToolHop場景，最終答案正確率平均提升了約3.3個百分點。SearchQA的總體得分也達到了所有方法中的最高值42.83%。

值得關注的是，那些專門做策略訓練的競爭方法（RLOO和GRPO）消耗的計算資源比HarnessForge多得多，但大多數指標仍然不如HarnessForge——這說明聯合進化的效果并不只是靠"燒更多計算資源"換來的。

**六、缺哪一半都不行：拆開看看才知道**

為了證明手冊進化和助手訓練這兩個部分缺一不可，研究團隊做了一組對照實驗：分別去掉手冊進化（只訓練助手）和去掉助手訓練（只改進手冊），然后對比三輪進化后的效果差距。

結果非常清晰。去掉手冊進化之后，ToolHop的正確率在第三輪下降了6.15個百分點，SearchQA下降了5個百分點——而且隨著輪數推進，差距越來越大，說明手冊進化的價值是累積性的，越往后貢獻越重要。去掉助手訓練之后，第三輪的ToolHop下降了2.56個百分點，SearchQA下降了3個百分點。兩者相比，手冊進化對最終效果的貢獻更大，但助手訓練的缺失也會帶來不可忽視的損失。

這個結果很好地回答了一個可能有人會質疑的問題：既然手冊進化貢獻更大，為什么不干脆只做手冊進化？答案是，手冊再好，如果助手沒有經過專門適應性訓練，執行質量仍然會打折扣——兩者是相輔相成的關系，缺一不可。

**七、留幾本手冊備選，還是只留一本？**

在每輪進化中，最終留下多少本備選手冊，會對效果產生多大影響？研究團隊專門測試了留1本、2本和3本三種設置。

只留1本手冊往往太過保守，會錯過可能更優的探索方向。從第三輪的結果來看，從1本增加到2本，ToolHop提升了3.6個百分點，TMDB提升了6個百分點，API-Bank提升了2.6個百分點，SearchQA提升了0.7個百分點，平均提升約3.2個百分點。但繼續從2本增加到3本，大多數場景的提升就微乎其微了，有時候反而略有下降。背后的邏輯是，保留太多手冊會稀釋選擇壓力——相當于你在選拔優秀員工時，留的人太多，就失去了篩選的意義。2本這個數字在"保留足夠多樣性"和"保持足夠高的選拔標準"之間找到了一個平衡點。

**八、手冊和助手到底有沒有"專屬搭檔效應"？**

研究中最有說服力的一組實驗，是把所有進化過的手冊和所有進化過的助手兩兩配對，測試每種組合的效果。這就像是把所有版本的操作手冊和所有版本的員工隨機搭配，看看哪些組合表現好、哪些表現差。

在API-Bank場景，最基礎的手冊+基礎助手組合的成功率是69.30%。沿著對角線（也就是手冊和助手始終保持配套的進化路徑），最終版本的配對成功率達到了77.19%。但如果把最終版手冊配上早期助手，平均成功率只有71.93%；把最終版助手配上早期手冊，平均成功率也只有71.06%。這種差距非常清楚地說明了一件事：HarnessForge的進步不是靠著獨立打造了一個"超強手冊"或一個"超強助手"，而是靠著讓手冊和助手在相互磨合中形成了專屬的配合默契。把它們拆開來，效果就會大打折扣。

在ToolHop場景，類似的矩陣分析也顯示出同樣的規律：配套組合始終優于錯配組合，并且隨著進化輪次增加，配套效果的提升幅度也在累積增長。

**九、用更強的訓練方法，效果還能再提升**

HarnessForge默認使用的是最簡單的監督微調（SFT），也就是"照著成功案例模仿"。研究團隊還測試了用強化學習方法（GRPO和RLOO）來替換這個環節。

在第三輪，使用GRPO時ToolHop的答案準確率從50.77%提升到了52.31%；使用RLOO時API-Bank的成功率從71.05%提升到了72.80%。但代價是計算資源的大幅增加——第三輪使用強化學習需要消耗45600次模型調用，而使用SFT只需要12000次。這個對比揭示了一個很實際的選擇邏輯：如果計算資源充裕，強化學習可以進一步挖掘潛力；如果計算資源有限，SFT已經能在相對低的成本下獲得大部分收益。HarnessForge的框架設計對兩種方式都兼容，使用者可以根據實際需求靈活選擇。

**十、三輪進化的具體故事：手冊改了什么**

研究團隊通過一個具體的ToolHop場景，展示了手冊在三輪進化中究竟經歷了什么樣的改變。

第一輪進化主要改善了兩件事：一是任務分解變得更細致，把大目標拆成了更清晰的子目標；二是記憶管理變得更有規律，會把重要的上下文更一致地注入給AI。這輪改進帶來了2.14%的性能提升，隨后配套的助手訓練又額外貢獻了1.57%的提升。

第二輪進化的重點轉向了規劃的可靠性和動作執行的穩定性：加入了"證據臺賬"機制（讓AI明確記錄每個中間步驟的證據來源），并改進了工具調用的驗證邏輯（在提交最終答案前檢查是否有足夠的支撐證據）。這一輪的手冊改進貢獻了2.51%，助手訓練貢獻了2.10%。

第三輪進化聚焦于記憶檢索：改進了如何根據當前任務階段和問題結構來提取相關歷史信息，避免把陳舊或無關的記錄帶入當前推理過程。最后一輪手冊改進貢獻了0.94%，助手訓練貢獻了1.11%。三輪累計下來，性能從最初的41%提升到了52.82%，每一步的積累都清晰可見。

**失敗案例里藏著什么規律**

研究團隊還系統分析了不同場景下失敗的原因分布。在API-Bank和TMDB這類重度依賴API調用的場景中，大約四分之一的失敗來自"動作模塊"的問題——格式不對、接口調用順序有誤、工具反復調用陷入循環。在SearchQA這類多跳問答場景中，規劃類失敗占了相當大比例，主要表現為AI用了過時的查詢詞在重復搜索，而不是根據最新進展調整搜索方向。在ToolHop場景，多跳工具鏈的維護失敗和最終答案的錯誤支撐是主要問題。記憶相關的修復雖然占比較小，但往往以"配合修復"的形式出現，穩定著規劃和動作的執行。

研究團隊通過五個具體的父子軌跡對比案例，更直觀地展示了手冊改進的效果。例如，在一個需要比較兩位歷史人物出生日期的任務中，改進前的AI會反復提交沒有證據支撐的最終答案，改進后的手冊要求AI必須找到有實際證據支撐的答案才能提交。在一個涉及賬戶刪除的API任務中，改進前的AI會在認證步驟反復卡殼，改進后的手冊明確了認證和刪除操作的順序規范以及輸出格式要求，AI一次性就完成了任務。

**歸根結底，這項研究說明了什么**

說到底，HarnessForge揭示了一個關于AI助手系統的本質規律：讓一個AI系統真正好用，不是單獨打磨某一個零件就能做到的，而是要讓"操作手冊"和"執行者"形成真正的默契配合。這聽起來可能像是一句常識，但在AI領域，以前沒有人把這對搭檔作為一個整體來系統優化。

對于普通用戶而言，這項研究意味著未來基于AI的智能助手和自動化工具可能會在多步驟、多工具的復雜場景中更加可靠——不管是幫你查詢和整合多來源信息、調用各類應用接口完成復雜操作，還是在長時間對話中保持準確的上下文記憶。更重要的是，這種進步并不需要換用更大的AI模型，就連40億參數這種相對"輕量"的模型，經過HarnessForge的聯合進化，都能在多項測試中超過那些單獨優化的更大模型。

當然，研究團隊也坦誠地指出了這項工作的局限性。目前的測試主要在4B和8B規模的模型上進行，對于那些參數量大得多的頂尖模型，手冊與助手聯合進化能帶來多大的改善空間還有待探索。此外，每輪進化都需要多次運行任務來收集數據，在非常復雜的長流程場景中，這個成本可能會相當可觀。研究團隊提出了幾個潛在的改進方向，包括用更快的代理評估替代完整運行、自適應分配計算資源，以及引入更廣泛的手冊編輯操作（比如完整的代碼重寫或全新工具接口設計）。

這項研究還有一個更宏觀的意義：它為如何在資源受限的條件下讓小模型也能勝任復雜任務提供了一條清晰的路徑，不是靠堆算力，而是靠讓手冊和助手彼此適應、互相成就。有興趣深入了解技術細節的讀者，可以通過arXiv編號2606.01779查閱完整論文。

Q&A

Q1：HarnessForge框架的"手冊"（harness）具體指的是什么？

A：HarnessForge中的"手冊"是指規定AI如何執行任務的外部結構，由三個部分組成：規劃模塊（負責任務分解和重新規劃）、動作模塊（負責工具調用格式和協作規則）以及記憶模塊（負責信息的存儲、調取和整理）。它不是AI模型本身，而是告訴AI"按什么步驟干活"的執行框架，類似于員工的操作手冊。

Q2：HarnessForge和只訓練AI模型的方法相比有什么優勢？

A：單獨訓練AI模型（策略）的方法假設執行手冊是固定不變的，AI只能在既有框架內優化。HarnessForge同時進化手冊和AI適配器，讓兩者形成專屬配合。實驗顯示，即使單獨訓練方法消耗了更多計算資源（如GRPO和RLOO需要的調用次數是HarnessForge的近4倍），在大多數測試指標上仍不如HarnessForge，最大差距可達12個百分點。

Q3：HarnessForge需要多大規模的AI模型才能有效運作？

A：HarnessForge在40億參數（Qwen3-4B）和80億參數（Qwen3-8B）兩種規模的模型上都經過了測試，兩種規模都取得了顯著效果。研究表明，即使是相對輕量的4B模型，經過聯合進化后也能在多項測試中超越單獨優化的較大模型，說明這套方法并不依賴超大規模模型，在資源受限的場景下同樣有效。