Argus：會自我演化的長任務 runtime

Argus 怎麼讓代理在長任務裡不走偏？

Argus 把長任務代理的重點放在 runtime：固定模型權重，靠可驗證狀態與角色化審查，讓流程能在長流程中修正、延續與演化。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：SWE-Bench Pro 約 78%
• 突破點：可驗證狀態自我演化

長任務代理最怕的，不是第一步答錯，而是做了十幾步之後才發現整條路都歪了。這篇論文的重點，就是把這個問題當成 runtime 設計來處理，而不是只靠模型本身更會猜。Argus 的做法很直接：模型權重固定不動，真正會變的是 runtime 裡的狀態、流程與驗證機制。

這個切法對開發者很重要。很多 agent 失敗，不是因為模型完全不會推理，而是卡在記憶、路由、協作、回頭修正這些系統層問題。Argus 想做的，就是把這些東西變成可管理、可審查、可保留的工作流，而不是一個黑箱式的對話迴圈。

它想解的痛點是什麼

原始摘要把長程推理描述成一個 runtime 問題。代理要能在證據支持時持續前進，也要能在量測結果顯示失敗、隱藏限制，或目標其實被定錯時，及時轉向。這代表系統不能只會「回答一次」，而是要能跨很多步驟持續工作，還要保留已經學到的東西。

Argus 的設計，是把使用者意圖和執行層目標分開。使用者真正想要的東西保持穩定；但操作目標、限制條件、驗證標準，可以隨著任務進展調整。這種分層很像工程實務裡的需求管理：需求不一定變，但解法會一直修。

摘要裡提到，Argus 是一個 persistent、self-evolving runtime，讓 Manager、Planner、Engineer、Reviewer 四種角色在持久化的 project state 上執行 bounded missions。這不是單純多幾個 agent 名稱而已，而是把協作拆成不同職責，讓每一步都有明確的審查與交接點。

對開發者來說，這種設計的價值在於，它把「代理會記得什麼」和「代理憑什麼記得」講清楚了。不是所有內容都能直接寫進長期記憶。只有經過 role-owned review，且在可用時通過 task-native verification 的資訊，才會變成可持久化的狀態。這能降低壞捷徑被永久保存的風險。

方法到底怎麼運作

Argus 最核心的決定，是固定模型權重。也就是說，它不把線上學習放在模型參數上，而是放在 runtime 本身。系統的「學習」發生在持久化狀態與控制策略裡，這些狀態可以在 operator-owned escalation points 之間持續運作。

白話一點，Argus 想拆開三件常被混在一起的事：使用者要什麼、系統現在怎麼做、以及哪些東西已經被驗證過。這樣做的好處是，系統不會因為某次臨時的捷徑就把錯誤路線內建成未來行為。

摘要提到，runtime 內可以保存 memories、skills、procedures、verifiers、routing decisions，甚至 rejected routes。重點不是「有沒有記錄」，而是「哪些記錄經過審查後才准進入可重用狀態」。這讓 Argus 比一般 memory-augmented agent 更像一個有治理機制的工作系統。

四個角色的分工也很有意思。Manager 負責協調，Planner 負責規劃下一步，Engineer 實作，Reviewer 檢查。摘要沒有把每條內部規則全部展開，但它已經明確指出，review 和 verification 不是附加功能，而是讓 state 變成 durable 的必要條件。

這也解釋了為什麼 Argus 不是單純「多一層記憶」。它維護的是一個 persistent project state，裡面不只放成功路徑，也保留被拒絕的路線，方便之後分析。這種結構化軌跡，對長任務的可追蹤性很有幫助。

論文實際證明了什麼

摘要給出的數字，主要圍繞七個 GPT-5.5 benchmark 場景。最明確的一筆是 SWE-Bench Pro：約 78%，對照 Direct Copilot 的 59%。同時，Argus 使用的是 1.41 倍的 aggregate tokens。這代表它不是用更省資源換來更高分，而是用更多上下文與流程成本，換取更穩的結果。

摘要還提到 Argus 在 AARRI-Bench 達到 76.8%，以及在 mathematical data synthesis 上有 28.0 個百分點的差距。不過，原始摘要沒有公開完整 benchmark 細節，所以這裡能確認的是方向與部分結果，還不能補出完整表格或所有 baseline。

另一個重要訊號，是 verification-gated self-evolution 帶來的效率變化。在成熟的 SWE-Bench waves 中，Argus 每個任務的 solve-input tokens 減少 21%，active workflow time 也少了 15%。摘要同時提到 34 verifier recoveries 和 22 strict review-loop rescues，顯示系統不只是在成功時累積經驗，也能在中途卡關時把流程救回來。

除了 benchmark，摘要還列出幾個具體任務結果。包含一個 optimized RWKV6 kernel 被合併 upstream、一個多日數學 campaign 保留了 falsified routes 與 proof-backed frontier updates，以及六個 paper pipelines 完成 254 個 missions，過程中有 16 次 stage rollbacks。這些案例的共同點，是 Argus 被用在多步驟、可回滾、需要證據累積的工作上。

換句話說，這篇論文想證明的不是「模型更大所以更強」，而是「把代理當成 runtime 系統來管，長任務表現可以更穩，而且能保留可驗證的進展」。

對開發者的實際影響

如果你在做 coding agent、研究助手，或任何要跨很多步驟完成工作的自動化流程，Argus 提供了一個很實用的方向：長任務可靠性，也許不該先從更聰明的 base model 開始，而是先從更嚴格的 runtime 開始。

這篇摘要最值得抄的，不是某個單點技巧，而是它把 verification、routing、review 都變成一等公民。對團隊來說，這很像把 agent 從「會回答」升級成「會被管理」。只要任務夠長，這種差別就會變得很大，因為錯誤不再只是錯一次，而是會一路累積。

摘要也提到，這個系統會產生 structured trajectories，未來可供 supervised learning 與 reinforcement learning 使用。這代表 runtime 不只是拿來跑任務，還能順便產出更好的訓練資料。對做 agent 基礎建設的人來說，這點很有價值：今天的執行痕跡，可能就是明天的訓練素材。

但限制也要看清楚。摘要沒有給完整實驗設定，也沒有公開所有 benchmark 細節。結果主要綁在論文挑選的幾個場景上，所以不能直接推論到所有領域。另外，Argus 在 SWE-Bench Pro 上用了更多 aggregate tokens，表示它不是免費提效，runtime 的治理與驗證本身有成本。

所以，這篇論文比較像是在提醒大家：長任務 agent 的競爭點，正在從 prompt 技巧和單次推理，往 runtime 架構移動。能不能把狀態管好、把錯誤攔住、把驗證做成流程，可能比單次回答多漂亮更關鍵。

值得繼續觀察的地方

第一，要看這種 role-based runtime 的模式，能不能離開論文的 benchmark 場景，真的進到更雜的實務任務。第二，要看 token overhead 到底值不值得。當系統用更多上下文換更好的恢復能力，這個交換比在不同場景裡可能差很多。

第三，structured trajectories 會不會真的幫助後續的 supervised 或 RL 訓練，這也值得追。若答案是肯定的，Argus 這類 runtime 的價值就不只在執行，還會延伸到資料生成與訓練閉環。

總結來說，Argus 提供了一個很清楚的訊號：下一波 agent 進步，可能不只是模型更大，而是 runtime 更會管事。對工程團隊來說，這是很值得拿來拆設計圖的方向。

• 長任務代理的關鍵，可能在 runtime 治理，不只在模型能力。
• 驗證門檻、角色分工、持久化狀態，都是可落地的設計點。
• 更高準確率可能伴隨更多 token 成本，效率需要一起算。