Raven Agent 框架：代理自己組裝與進化，成績有多可信？（2026）

2026 年 9 月 27 日，EverMind AI 在 arXiv 發布了〈Raven: The Harness of Harnesses for Composable Agentic Intelligence〉，提出 Raven Agent 框架：由一個主控代理把研究、寫程式、設計與長時間執行的代理組成工作網絡，並嘗試讓各自的工作方式隨經驗改進。這篇論文最值得追問的，不是「代理能不能變多」，而是組裝、交接與驗收能否讓最後成果更可靠。

先看作者實際造了什麼，再看分數測量的是規劃還是任務完成，最後把這套設計放進其他研究的證據邊界。

Raven Agent 框架要解的，是「專家如何合作」

Raven 把「模型＋周邊工作系統」視為一個可呼叫單位。所謂 harness，包含工具介面、上下文與記憶、技能、行動規則及故障恢復；因此同一模型換了 harness，也可能做出不同結果。這不是替模型加一段人格設定，而是改變它能看見什麼、能呼叫什麼、何時交付、怎麼判定失敗。

論文的 Host Agent 接收目標後，挑選專職代理，把任務排成有向無環圖（DAG）。圖上的節點是代理工作，邊是交接依賴：研究先產出需求，程式和設計可並行，最後才整合與測試。執行層檢查節點契約、等待上游成果、保存工件，遇到例外再決定重試或要求釐清。公開程式庫列出 Raven-Research、Raven-Code、Raven-Design、Raven-Oncall，也列出第三方代理接入方式；同一頁將專案標為 pre-alpha。

作者還把三種「下次做得更好」分開：Host archive 與 EverOS 存取過去脈絡；Skill Forge 把程序整理成可重用技能；外部 Evolver 比較不同 harness 設定，只有通過篩選的候選才被採用。這三件事分別處理記憶、程序與執行政策，不能用一個「自我進化」字眼混成同一種能力。

最醒目的成績，先測的是排工圖

We therefore evaluate the host’s proposed graph before dispatching workers.

中文：因此，我們在派出工作代理之前，就先評估主控代理提出的工作圖。

EverMind AI，論文第 7.1 節

這句話是讀分數的鑰匙。作者建立 Multi-Agent Orchestration Benchmark（MAOB），以 140 個任務和四種專長的參考工作圖，測主控代理選對節點、接對依賴的程度。論文報告：在 Qwen3.8-27B 下，Raven 的整圖完全吻合率為 0.711，最強比較組為 0.607；在 DeepSeek-V4-Flash-0731 下為 0.867 對 0.762。差距分別是 10.4 和 10.5 個百分點。

MAOB 的參考圖先於任務文字建立，再產生題目並人工審查。這可讓「正確工作圖」有明確標準，也讓測試較偏向辨認題目暗示的工作結構。尤其這個實驗在工作代理執行前打分，因此不能把 0.867 說成「86.7% 的跨領域工作已成功完成」。完成品質、返工、耗時與成本還要另外量。

長任務與進化：作者報告了什麼

論文的其他評估分別測研究、程式、設計、長任務、harness 演化與技能重用，並非同一套端到端實驗。較貼近「長時間工作」的是 Raven-Oncall：作者在自建的 17 題 AI4S 科研任務中，報告同用 Claude Opus 5 時 Raven-Oncall 完成 14 題、Claude Code 完成 11 題，平均成本為 5.10 對 13.60 美元。這是作者設置的任務、評分與成本口徑，值得看作待外部驗收的線索，而非通用代理效率定律。

對「自我改進」也要拆開讀：論文沿用團隊先前 HarnessBank 與 SkillCorpus 的實驗，分別支持固定模型下調整 harness、加入技能後提高某些測試分數。這能支持「周邊系統會影響成績」，仍未直接證明 Raven 的記憶、技能、演化與多代理編排串在一起，會在任意新任務上持續變好。

外部研究給這個主張加上什麼邊界

〈Towards a Science of Scaling Agent Systems〉在六個測試集、260 種設定中比較單代理與多代理架構：可拆解任務有收益，順序性任務則可能因協調開銷退步。它沒有測 Raven，但直接提醒我們：代理數量和成果品質之間，隔著任務可拆性、交接損失及驗證成本。

〈Rethinking the Evaluation of Harness Evolution for Agents〉則指出，harness 搜尋若反覆看同一組題目回饋，應與同預算的簡單搜尋比較，並拿保留題測泛化。另一項EvoHarnessBench研究發現，新增工具、技能或代理也可能讓先前已會的任務退步。這些研究不是對 Raven 成績的反證；它們指出下一輪驗收應問的問題。

AlphaLab 的判讀：主控代理的價值在交接品質

我同意：把依賴和工件寫清楚，比堆代理名稱有用

研究結論要交給程式代理，最重要的是輸入格式、來源、驗收條件和失敗時如何回溯。Raven 用工作圖、節點契約和工件記錄，把這些要求變成系統的一部分。對跨領域長任務，這種設計比單靠聊天紀錄接力更有機會定位錯誤，也更容易替換專職代理。

我存疑：漂亮的規劃分數能否換成可靠交付

一張正確的工作圖是必要環節之一，卻不能保證研究資料對、程式能跑、設計可用，或幾輪之後記憶仍準確。真正有力的下一組證據應固定模型、工具、總預算與驗收標準，對照單代理、同預算多次嘗試，以及 Raven 的完整流程，並公開失敗案例與工件。當題目需要多方專長時，增加協調可能划算；當題目只是線性的幾步，協調本身就是額外成本。

最關鍵的預測：改過的 harness 要在新題上贏

若演化只讓代理熟悉既有題庫，改善的是適應測試，而不是任務能力。更嚴格的驗收是：新任務先封存，修改前後在相同模型與預算下盲測；同時追蹤舊任務是否退步、成本是否上升、錯誤能否歸因。這比單看某一輪最高分更能回答「系統真的學會了什麼」。

你可以怎麼用這篇論文

若你在評估 Raven Agent 框架，先挑一項真的需要研究、程式與設計交接的工作，再挑一項簡單線性工作。兩者都定義可檢查的最終工件、固定總預算，記錄每次交接的輸入、輸出、重試與人工修正；比較單代理和 Raven 的合格成果、完成時間與總成本。若只有規劃圖漂亮、交付沒有改善，就先把資源用在單代理的工具和驗收上。