你有沒有經歷過這樣的場景：讓一個新來的實習生做一件複雜的事，比如"幫我把這個項目的所有測試跑一遍，修好報錯的地方，再寫份報告"。結果三天後他跟你說"做完了！"你打開一看，報告寫得漂漂亮亮，但代碼根本沒改，測試其實還在報錯。
他不是故意撒謊。他只是在漫長的工作過程中，自己也搞不清哪些事真的做完了，哪些事只是看起來做完了。
現在把這個實習生換成一個AI智能體，你會發現一模一樣的問題正在發生。而且更麻煩的是，這個AI智能體不僅會騙你，還會騙自己。它會把自己"以為完成了"的假象當成事實，繼續往下推進任務，最後整個項目跑偏到完全不知道哪裡出了錯。
這就是阿里巴巴DreamX團隊在這篇論文裡想解決的核心問題。他們給出的方案有個樸素到近乎直白的名字：LongHorizon-Harness（長視野執行框架
）。
長任務執行,到底難在哪
先說一個背景數據。研究機構METR做過一項追蹤，發現頂尖AI智能體能獨立完成的任務時長，大約每七個月翻一倍，最近這個速度還在加快，縮短到了四個月左右。像Claude Code、Codex這樣的編程智能體，已經能在一個項目上連續工作好幾個小時不停歇。
聽起來很厲害對不對?但論文一開篇就潑了盆冷水:時間變長了,不代表可靠性變高了。
這句話初聽平淡,細想卻挺扎心的。我們下意識會覺得,能力越強的模型,處理越長的任務應該越穩，可現實恰恰相反：任務越長，出錯的概率反而越會累積放大。這不是模型不夠聰明，而是一種結構性的困境。
論文指出了三個具體的病灶。
第一個是**錯誤累積和目標漂移**。想像一下你在導航時,第一個路口就走岔了,後面每一步都是在錯誤的基礎上繼續修正,越走越偏,最後可能完全偏離了原本要去的地方。AI智能體在長任務里就是這樣,早期的一個小判斷失誤,會像滾雪球一樣影響後面所有的決策。
第二個是**上下文腐化**（Context Rot）。
> 上下文腐化：隨著對話歷史越堆越長，模型越來越難從中準確檢索到真正有用的資訊，一旦歷史長度超過某個臨界點，模型表現會斷崖式下跌。
這個現象背後有研究(Liu et al., 2024)專門驗證過，叫"lost in the middle"，就是說模型對長文本中間部分的內容記憶力特別差，容易"讀了但沒記住"。
第三個是**任務狀態丟失**。這是最核心的一條：智能體不知道現在做到哪一步了，哪些要求已經滿足，哪些證據是真實的，哪些還懸而未決。
這三個問題疊加在一起，會導致什麼後果？現有的智能體框架，比如Claude Code、Codex CLI，雖然已經支持任務拆解、子代理、工具調用這些功能，但它們有個共同的結構性缺陷：執行任務和判斷任務是否完成，用的是同一套上下文，同一個"大腦"。
這就好比讓一個學生自己批改自己的考卷。他做錯了一道題，然後又用同樣的思路去檢查這道題，大概率還是會覺得自己做對了。
**執行者不該同時是裁判。**
這句話，就是整篇論文的出發點。
MEA循環：把"做事"和"驗收"徹底分開
論文提出的解法叫Manage-Execute-Audit循環，簡稱MEA循環，中文可以理解為"管理-執行-審計"循環。
這個設計的核心思路，是把一個長任務拆成一輪一輪的短回合，每一輪里有三個角色分別登場，各司其職，誰也不越界。
第一個角色是**管理者**（Manager）。
> 管理者：只負責維護任務的全局狀態，決定下一步該做什麼，但完全不接觸實際的執行環境，看不到螢幕、點不了按鈕、跑不了命令。
管理者手裡有的，只是當前的任務狀態記錄，和之前所有輪次留下的審計報告。它像一個遠程指揮官，從不親自上前線，只根據偵察兵傳回來的確認情報來下達下一步指令。
第二個角色是**執行者**（Executor）。
> 執行者：負責真正幹活的角色，是整個系統里唯一被允許修改環境的角色，比如點擊界面、編輯文件、跑測試腳本。
執行者每一輪都在一個全新的、乾淨的上下文裡工作，它看不到之前幾輪發生了什麼，只拿到這一輪需要完成的具體任務卡片。幹完活兒之後，它的整個思考過程和交互記錄會被直接丟棄，只留下一份執行報告。
第三個角色是**審計者**（Auditor）。
> 審計者：獨立檢查執行結果的角色，只能讀取環境狀態，絕對不能修改任何東西，它的任務是判斷這一輪到底真的完成了什麼。
審計者也是在一個全新上下文裡工作，它看不到執行者內部是怎麼想的，只能靠自己重新檢查環境，來判斷哪些是真的完成了，哪些只是執行者自己聲稱完成了。
這三者之間的關係，畫成一張圖就特別清楚。管理者根據審計報告，定一個明確的子任務，交給執行者；執行者在自己的沙盒裡幹活，交出一份執行報告；審計者獨立核實這份報告對不對，再把審計結果反饋給管理者，開始下一輪。
這裡有個細節特別值得琢磨：**跨輪次唯一保留下來的記憶，就是審計報告**。
執行者的原始交互記錄，無論多詳細，一輪結束就全部丟棄。這個設計乍一看有點浪費，但恰恰是它解決了上下文腐化的問題。
打個比方，這就像公司里的項目交接制度。如果新接手的人要把前任所有的聊天記錄、草稿、廢棄方案全部翻一遍才能上手，那交接效率極低，還容易被過時或錯誤的資訊帶偏。但如果交接的只是一份經過核實的"驗收清單"，寫清楚哪些模組已經通過測試、哪些接口還沒對接，新人反而能幹淨利落地接著干。**如果不這樣設計，會怎樣？**論文裡給出的答案很直接：執行歷史會越滾越大，最後連模型自己都分不清哪句話是三十輪前說的、哪句話是剛剛發生的，這正是上下文腐化的根源。
任務狀態本身也有嚴格的結構。它由三類記錄組成：需求（從原始任務里拆解出的目標或約束）、產物（執行過程中生成或修改的文件、結果）、事實（後續輪次需要用到的環境資訊）。每條記錄都標著完成、待定、受阻、或不可信這幾種狀態之一，而且必須附帶審計證據的引用。
這裡有個特別關鍵的設計：**執行者說"我做完了"，這句話本身不算數**。
只有當審計者獨立核實之後，這條記錄才會被標記為"完成"。這就相當於財務報銷制度里的"報銷單不能自己簽字通過"，必須有另一個人核實票據、核對金額，才能真正入賬。這不是不信任執行者，而是任何自我評估機制天生就帶有確認偏差,系統設計上必須把這個偏差隔離出去。
那審計者具體怎麼審？論文裡描述得很細：審計報告需要給出三類判斷。第一類是完成狀態，是完成了、沒完成、還是被卡住了；第二類是完整性狀態，環境有沒有被意外污染，比如執行者是不是偷偷刪了不該刪的文件；第三類是任務狀態更新，記錄審計過程中發現的新事實和還存在的缺口。
值得一提的是，管理者、執行者、審計者三個角色都可以用不同的底層模型和不同的智能體框架來實例化，比如管理者用Qwen，執行者用Claude Code，審計者用Codex，互不衝突。論文裡管這套接入機制叫AgentAdapter（智能體適配器），它是一個輕量級接口，作用是讓現有的這些成熟框架的原生工作流程完全不用改動，直接插進MEA循環里就能用。這個設計的好處是顯而易見的：企業不需要重寫自己已經跑得很好的智能體系統，只需要在外面包一層任務狀態管理就行。
三個基準測試，驗證效果到底有多大
光講設計思路不夠有說服力，得看實際數據。論文在三個近期發布的長任務基準上做了測試，分別覆蓋不同的應用場景。
第一個叫**WeaveBench**。
> WeaveBench：一個包含114個任務的評測集，特點是每個任務都需要圖形界面和命令行兩種操作方式配合完成，覆蓋桌面應用、文檔處理、遊戲、網頁開發、數據分析可視化、運維、三維空間應用、設計這八大領域。
用Qwen 3.7-Plus這個模型，配合Claude Code作為執行後端，原始框架的通過率是51.8%，套上LongHorizon-Harness之後，直接飆到了80.7%。這個提升幅度什麼概念呢？官方公布的所有成績里，表現最好的是Claude Opus 4.7配Claude Code跑出的41.2%，而這次的結果幾乎是把這個最強官方成績翻了一倍。
第二個叫**OSWorld 2.0**。
> OSWorld 2.0：一套包含108個桌面工作流任務的評測集，人類完成這些任務平均需要1.6個小時，屬於相當有挑戰性的真實場景任務。
論文裡報告了兩個指標，二值完成率（任務是否被徹底完成，拿滿分）和部分得分（衡量任務完成的比例）。Qwen 3.7-Plus原始表現是二值完成率2.8%，部分得分21.5%。套上框架之後，二值完成率提升到8.3%，接近三倍；部分得分提升到35.2%。
第三個叫**Terminal-Bench 2.1**，專門評估命令行環境下的高難度真實任務。這裡沒有圖形界面，純粹靠命令行操作。Qwen 3.7-Plus配Claude Code的成績從69.7%提升到77.2%；如果換成Codex配GPT-5.6 Luna，甚至能衝到83.1%，直接擠進這個基準的官方排行榜前列。
這裡有個特別值得注意的現象。Terminal-Bench不涉及任何視覺感知或者圖形界面路由的問題，純粹是文本命令的世界。這說明什麼？說明MEA循環帶來的提升，不是靠某種針對圖形界面的特殊技巧，而是一種通用的、跟具體交互方式無關的能力。
論文還額外測了一下**跨模型的泛化性**，把執行的底層模型換成Claude Opus 4.7，在OSWorld 2.0的34個任務子集上，二值完成率從20.6%提升到35.3%，部分得分從55.8%提升到66.9%。這說明這套框架不是專門為了拉一個弱模型及格線而設計的補丁，強模型套上之後同樣獲益。
下面這張表匯總了核心數據：
| 基準測試 | 模型配置 | 原始表現 | 套用框架後 |
|---|---|---|---|
| WeaveBench (PassRate) | Qwen 3.7-Plus + Claude Code | 51.8% | **80.7%** |
| Terminal-Bench 2.1 | Qwen 3.7-Plus + Claude Code | 69.7% | **77.2%** |
| Terminal-Bench 2.1 | GPT-5.6 Luna + Codex | 75.7%（官方原始） | **83.1%** |
| OSWorld 2.0 (二值完成率) | Qwen 3.7-Plus | 2.8% | **8.3%** |
| OSWorld 2.0 (部分得分) | Qwen 3.7-Plus | 21.5% | **35.2%** |
| OSWorld 2.0子集 (二值完成率) | Claude Opus 4.7 | 20.6% | **35.3%** |
代價：多花的錢和時間去哪了
任何提升都不是免費的午餐。這套框架的運行成本要怎麼算？
論文用一張圖（圖4）畫出了成本-性能的權衡曲線。Qwen 3.7-Plus在OSWorld 2.0上，套用框架前平均每個任務消耗2.89萬輸出token，套用後漲到10.4萬，差不多是原來的3.6倍。
但這筆賬不能只看倍數，得看具體花在哪了。論文把三個角色的token消耗拆開來看，管理者只占了WeaveBench上2.8%、OSWorld 2.0上2.0%、Terminal-Bench上8.1%的總消耗，說明維護任務狀態這件事本身開銷很小。真正花錢的大頭，是審計者，占到19.4%到38.1%不等。
這個結果其實很直觀。就像質檢環節一定比記賬環節耗時更長一樣，獨立核實一件事有沒有真的做對，本來就比記下"這件事該不該做"要費勁得多。審計者需要重新去看文件、截圖、日誌，重新走一遍驗證流程，這本身就是這套框架額外投入的主要部分。
不過更有意思的是，這個成本倍數並不是固定的。在Terminal-Bench 2.1上，套用框架後的token消耗反而比基線**少了24%**，同時成功率還更高。這說明框架的總成本高度依賴具體任務和底層模型需要多少輪"執行-審計-重來"的循環才能搞定。
論文裡還有個特別扎心的對比（表4），用同一批17個WeaveBench遊戲任務，分別測Claude Opus 4.7和Qwen 3.7-Plus。結果顯示，**框架帶來的token消耗變化方向，在兩個模型上完全相反**：Qwen的平均消耗從10.7M漲到34.3M，而Opus反而從16.5M降到11.1M。
這背後的道理是，越強的模型越能一次性把子任務做對，審計一次就通過，不需要反覆重試；而能力較弱的模型經常做不對，就得反覆經歷"執行失敗、審計發現問題、重新規劃、再執行"的循環，自然燒掉更多token。**這也從側面證明了一個反直覺的結論**：框架本身不創造能力，它只是讓已有能力更可靠地被兌現出來。強模型在這套框架下省錢，弱模型在這套框架下費錢但換來了原本根本做不到的完成度。
任務類型不同，收益差異也很大
論文沒有滿足於報一個總分了事，還專門拆解了不同類型任務上的表現差異（圖6），這個拆解特別有意思，因為它揭示了這套框架真正擅長解決什麼問題，以及它解決不了什麼問題。
在WeaveBench上，提升最大的是設計類任務（提升60個百分點）和空間/三維應用類任務（提升50個百分點），而桌面應用這個原本就已經做到83.3%及格率的領域，只提升了5.6個百分點。
在OSWorld 2.0上，提升最大的出現在流媒體交互、人機協作、以及跟隨教學這幾類任務里。
在Terminal-Bench 2.1上，系統運維和遊戲類任務提升明顯，但有幾個短小的分析類任務反而出現了輕微退步。
這個模式說明了什麼？論文給出的解釋很實在：**那些提升幅度大的任務，共同特點是需要智能體在很長的軌跡里保存、檢查、反覆修訂多個相互依賴的環境狀態**。而那些提升不大甚至倒退的任務，往往是瓶頸在於單一的模型能力，比如精細的視覺定位、數學推理、算法設計本身有沒有做對。
這個區別其實挺關鍵的。獨立審計能發現一個錯誤的結果，能觸發重新規劃，**但它沒辦法給模型補上一個它本來就不具備的能力**。審計者可以告訴執行者"你這道數學題算錯了"，但審計者沒辦法替執行者把這道題重新算對。
打個比方，這就像一個嚴格的編輯能幫作者發現文章里的邏輯漏洞、事實錯誤，能要求作者重寫某一段，但編輯沒辦法替作者把一篇本身構思平庸的文章變成一篇天才之作。編輯的作用是保證質量下限不失控，而不是抬高才華的上限。**如果沒有這層編輯機制會怎樣？**論文裡那個GUI卡死400多步的案例（後面會詳細講）就是答案：作者會在同一個錯誤里死循環，永遠意識不到問題，直到耗盡所有時間預算。
具體案例：從卡死到恢復
數字講完了，說幾個論文裡具體記錄下來的執行軌跡對比，這些例子比數字更能說明問題出在哪、框架又是怎麼解決的。
第一個例子是一個WebRTC網路分析任務。基線智能體在使用Wireshark抓包分析工具時，遇到一個叫"Decode As"的對話框卡死了不響應。它意識到了這個問題，但這個意識只停留在自己越來越長的對話歷史裡，沒有變成任何結構化的記錄。結果它在同一個交互上反覆嘗試了超過400步，始終沒能收集到任務需要的剩餘證據，最終得分只有0.59。
換成LongHorizon-Harness，管理者把"這個交互失敗了、還有哪些證據沒收集到"明確記錄進任務狀態，交給下一輪全新的執行者。新的執行者不再糾結那個卡死的對話框，直接去收集缺失的圖表和數據包證據，最終得分衝到0.92。
第二個例子更微妙，是一個文檔格式規範化任務。基線智能體直接改了文檔的底層XML文件，讓標題看起來像是正確的一級標題樣式，然後就此收工，覺得任務完成了。但任務其實要求必須通過LibreOffice這個軟體的正常操作流程來完成樣式修改，結果這個"看起來對"的答案得分是0.00。
LongHorizon-Harness這邊，執行者按照要求的GUI流程逐個操作，審計者隨後重新解析文檔的XML結構，獨立確認所有15個標題確實都用上了正確的樣式編碼，最終得分0.89。
這個例子特別戳中要害：**執行者覺得自己做對了，和這件事真的做對了，是兩回事**。如果沒有獨立的審計環節，那個"看起來對"的假象就會被直接寫進任務狀態，後續所有決策都會建立在這個錯誤假設之上，越走越偏。
第三個例子涉及證據的時序問題。任務要求先記錄一份修復前的Excel公式錯誤證據，再進行修復。基線智能體記錄了初始狀態，但還沒收集完所有該收集的證據，就直接開始改文件了，導致最後交出來的證據鏈前後矛盾，得分0.45。LongHorizon-Harness把"缺失的修復前證據"當作一條待完成的需求明確記在任務狀態里，逼著下一輪執行者先把證據收集完整，再動手修復，最終得分0.87。
這幾個案例合在一起看，能感受到一個共同的規律：**問題往往不出在智能體不會做事，而出在它不知道自己做沒做完**。
寫在後面
讀完這篇論文最讓我意外的一點是，這套方案沒有用任何前沿的模型訓練技巧，沒有微調，沒有強化學習，甚至沒有一個新的模型架構。它做的事情，說白了就是把"幹活"和"驗收"這兩件本來被強行捆在一起的事情拆開了，各自配一個獨立的大腦。
這讓我想起軟體工程里一個老掉牙但至今沒被完全解決的問題：寫代碼的人和測試代碼的人如果是同一個人，很容易漏掉自己代碼里的盲區。人類花了幾十年才把這個道理制度化成代碼評審、獨立QA團隊這些實踐。而AI智能體現在正在重走這條路，只不過這次不是靠組織架構，是靠三個AI角色的分工來實現。
論文裡有個細節我覺得特別值得單獨拎出來說：審計者查完一次，如果發現執行者動過了不該動的文件，會直接把這次的審計結果標記為"完整性受損"，這條記錄就永遠沒法被標記為"完成"，不管執行者怎麼解釋。這種"寧可信其無、也不信其自證"的機制設計，其實比技術細節本身更有意思，因為它體現的是一種對AI自我報告的根本性不信任，而這種不信任恰恰是讓系統變得可靠的關鍵。
論文裡也留了一個沒解決的問題：審計者的判斷質量依賴底層模型本身的理解能力，如果任務的驗收標準本身就很模糊，或者需要非常專業的領域知識才能判斷對錯，審計者會不會也犯錯？這個問題論文沒細談，但值得繼續追問下去。
Q&A
Q1：LongHorizon-Harness是什麼？
A：它是阿里巴巴DreamX團隊提出的一個智能體執行框架，核心思路是把長任務的"執行"和"狀態管理判斷"分離開，通過管理者、執行者、審計者三個角色分工協作，讓任務進度只被獨立核實過的事實更新，而不是被執行者自己聲稱的完成情況更新。
Q2：LongHorizon-Harness效果提升有多大？
A：在WeaveBench基準上，用Qwen 3.7-Plus模型時通過率從51.8%提升到80.7%；在OSWorld 2.0上二值完成率從2.8%提升到8.3%，接近三倍；在Terminal-Bench 2.1上從69.7%提升到77.2%，對Claude Opus 4.7同樣有效。
Q3：LongHorizon-Harness的額外成本高不高？
A：成本因任務和模型而異，在OSWorld 2.0上token消耗漲到原來的3.6倍左右，但在Terminal-Bench 2.1上反而減少了24%的消耗還提升了成功率，強模型使用框架時通常更省錢,因為它一次性做對的概率更高，不需要反覆重試。
