E3 讓 AI 先判斷任務大小

以前 agent 先把上下文全讀一遍，現在 E3 先判斷任務大小，再決定要不要擴大搜尋。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：MSE-Bench 成本降 85%
• 突破點：先估範圍再擴張

這篇論文在處理一個很常見、也很實際的問題：LLM agent 常常太「認真」。明明只是小任務，卻先把文件、依賴、上下文一路翻到底，結果不是更穩，而是更慢、更貴，還多了很多不必要的檢查。作者想證明的事很直接：agent 不只要會推理，還要會判斷這個任務到底值不值得花那麼多推理成本。

對開發者來說，這不是抽象的研究命題。它直接關係到 token 成本、工具呼叫次數、檔案讀取量、回應延遲，還有 agent 在 code review 或修 bug 時到底會不會一直重讀同一批內容。這篇論文的重點，不是把 agent 變得更會想，而是讓它學會先收斂，再在必要時才展開。

這篇論文要修的是什麼痛點

作者鎖定的是一種很典型的失誤模式：maximum-context-first。也就是說，agent 不先找最小可行方案，而是先把上下文擴到很大。放到實際開發場景，原本可能只要改一行程式、跑一次測試，結果 agent 卻先掃整個專案、重新抓一堆資料，最後花了很多工，卻沒有增加多少成功率。

論文把這件事定義成一種缺失能力：task-aware execution-scope estimation。白話講，就是在真正花算力和工具呼叫之前，先估這個任務有多難、需要哪些資訊、最短又可靠的路徑是什麼。這跟單純多讀文件、或把思考鏈拉長，是不同層次的問題。

為了讓這個想法可以被量化，作者提出兩個概念：minimum-sufficient execution，以及 Agent Cognitive Redundancy Ratio，簡稱 ACRR。摘要沒有公開完整公式，但命名已經很清楚：他們要量的是，agent 做了多少超出任務需求的額外工作。

這個切入點很重要，因為很多現有 agent 的評估只看有沒有做對，卻不太看做對之前多花了多少冤枉工。對使用者而言，那些多出來的讀檔、搜尋、驗證，全部都會變成成本。

E3 到底怎麼運作

這篇提出的方法叫 E3，全名是 Estimate、Execute、Expand。它是一個三階段策略。第一步先估計初始操作範圍。第二步用最小可行路徑去執行。第三步只有在驗證失敗時才擴大範圍。

這個順序就是整篇的核心。傳統 agent 常常是先擴張，再回頭證明自己為什麼要擴張。E3 則把「窄範圍執行」變成預設值，而不是退而求其次的備案。如果任務本來就能靠少量上下文和一個乾淨 patch 解掉，那就應該停在那裡。

從工程角度看，E3 等於把 agent planning 變成一種有預算的流程。它不假設每個任務都值得做一次全套審計，而是先走成本最低、但仍有合理成功機率的路徑。只有當驗證結果告訴你「這條路不夠」時，才付出更多上下文成本。

這也是為什麼論文特別強調 verification。它不是要 agent 偷懶，而是要 agent 先保守、再依據證據擴張。這比單純要求「少讀幾個檔案」更實際，因為它保留了必要時擴大的空間。

換句話說，E3 想解掉的不是推理能力不足，而是推理預算分配不合理。很多 agent 不是不會做事，是太早把事情做大了。

論文實際證明了什麼

作者主要用 MSE-Bench 來驗證。這是一個 deterministic benchmark，包含 121 個 edits，而且是在 capability-controlled simulator 裡做的。根據摘要與內文描述，E3 在這個設定下達到和最強 baseline 相同的 100% success rate，同時把成本降了 85%，token 降了 91%，檢查過的檔案數也降了 92%。另外，它也比一個強的 adaptive retrieval baseline 高出 16%。

這些數字的重點不是單純「更省」，而是「更省但沒掉成功率」。對 agent 研究來說，這很關鍵，因為很多效率優化最後都會犧牲準確率；但這篇報告的是，在這個受控 benchmark 上，E3 把冗餘工作壓下來，卻沒有把任務完成率一起拖下去。

論文也提到，這些效率提升在 held-out instruction wording 和幾乎所有 cost weighting 下都成立。這代表結果不太像某個 prompt 或某個評分規則的偶然產物。換句話說，它不是只學會一個 benchmark 小技巧，而是真的比較會避免重複工作。

除了模擬環境，作者還做了 LLM-Case 這個對照 harness。這裡用的是實際的 gpt-4o agent，去編輯一個真實的開源 library，然後把候選 patch 丟進實際的 pytest suite，讓測試結果跟 measured oracle 對照。這個設定下，作者說過度讀取的現象比較輕，但仍然存在，而 E3 是在相近任務成功率下最省、也最快的策略。

不過這裡也有一個限制。論文提到，E3 在這個真實模型設定下唯一的短板，是 provider rate-limit，不是改錯。這表示它的問題比較像操作層面的限制，而不是方法本身把任務做壞了。

摘要沒有提供更多跨任務、跨模型家族、或非工程工作流的完整 benchmark 數字，所以我們不能從這篇摘要直接推論 E3 對所有 agent 場景都同樣有效。現階段能確定的是：它在一個受控的執行冗餘測試，以及一個真實程式庫驗證場景裡，都朝同一個方向前進。

這對開發者有什麼實際影響

如果你在做 AI coding tool、retrieval agent，或任何會碰 repo 的自動化流程，這篇論文其實是在提醒一件很現實的事：更多上下文不一定更好。多讀幾個檔案，除了增加 token 和延遲，也可能讓 agent 混進更多雜訊，反而不容易聚焦。

這會直接影響 agent 架構設計。現在很多系統預設把 retrieval、反覆檢查、或持續擴張上下文當成安全路徑。E3 提供的是另一種預設：先用有邊界的計畫執行，只有當證據顯示不夠時才擴張。這樣可以減少不必要的工具呼叫，也讓 agent 行為更可預測。

產品面也很明顯。如果你在做會改 code、跑測試、找檔案的 agent，使用者會很快發現它是不是總在重開同一批文件。對簡單任務來說，過度思考本身就是失敗模式。若能先估任務大小，系統體感通常會更快，也更像真的懂事。

而且這不只是成本問題。當 agent 的行為更接近「只做必要的事」，人類開發者也比較容易理解它下一步要幹嘛。對團隊來說，這會影響除錯、審核、與信任感。

這篇研究還有哪些限制

這篇論文自己也把定位講得很清楚：它是在做 controlled probe of execution redundancy，不是在宣稱已經找到一個可直接套用到所有部署 agent 的萬用解。這個謹慎是合理的，因為它代表結果值得注意，但還不能直接外推成「所有 agent 都應該完全照 E3 改寫」。

還有幾個問題是摘要沒有回答的。像是：在需求很模糊的任務裡，怎麼估最低可行範圍？在測試不穩、環境會波動的情況下，最小路徑怎麼判定？如果任務一開始就很難知道要不要擴張，E3 的第一步又要如何做得夠準？這些都還沒有在摘要裡完整展開。

另外，ACRR 的精確定義、估計階段的決策規則、以及實作細節，摘要也沒有全部公開。對讀者來說，這代表它目前比較像一個方法框架加上實驗證據，而不是一份可以直接照抄的落地手冊。

但就算有這些限制，方向還是很有價值。它把 agent 設計往更工程化的方向推：系統花多少力氣，應該和任務真實難度對齊，而不是習慣性地把上下文吃滿。這對開發者很實用，因為效率不只是省錢，也是在決定一個 agent 到底值不值得信任。

總結

E3 的想法很簡單，但切得很準：先判斷任務大小，再決定要花多少算力。根據這篇論文的結果，這個改動可以在不犧牲成功率的前提下，大幅減少冗餘工作，尤其是在小型 code edit 和類似工作流任務上。

對正在做 agentic tool 的團隊來說，重點不只是省 token，而是讓 agent 學會分辨什麼時候只要走最短路徑，什麼時候才真的需要擴大搜尋。這種能力，可能比單純把模型叫得更大聲，更接近實際可用的產品體驗。

• 這篇的主軸是 task-aware execution，不是換一個新模型。
• E3 的預設是先窄後廣，只有驗證失敗才擴張。
• 摘要可見的成果，是在維持成功率下大幅降低冗餘成本。