Devin 背後的秘密：Cognition 如何用 Agent RFT 讓 AI 學會平行處理

本文整理自 OpenAI DevDay 的技術分享。

Devin 是 Cognition 推出的 AI 程式碼代理，它能夠自主完成複雜的程式開發任務。但「自主完成」這件事背後有一個核心挑戰：代理要怎麼知道該修改哪些檔案？一個大型程式碼庫可能有成千上萬個檔案，選錯了檔案，後續的所有工作都是白費。Cognition 用 OpenAI 的 Agent RFT 來訓練這個「程式碼編輯規劃」的能力，結果不只是效能提升，而是讓 Devin 學會了一種全新的工作方式。

問題的本質：在龐大的程式碼庫中精準定位

當使用者給 Devin 一個任務——比如「修復這個 bug」或「加入這個功能」——Devin 需要先搞清楚要動哪些檔案。這個階段叫做「程式碼編輯規劃」，Devin 會檢視整個程式碼庫，執行一系列的 shell 工具（像是 grep、檔案讀取等），然後決定一個檔案清單。

這個任務的困難之處在於，你必須在兩個方向上都做對。選太少，你會漏掉關鍵的依賴檔案或相關程式碼，導致後續的修改不完整。選太多，你會給下游的編輯模組製造額外的雜訊，拖慢處理速度，甚至可能導致不必要的改動。

傳統的做法是透過提示詞工程來引導模型的行為，告訴它「要全面」或「要精確」。但這種方式有天花板——模型對你的程式碼庫沒有任何實際經驗，它只能依賴通用的程式設計知識來做判斷。Agent RFT 提供了一個不同的路徑：讓模型在你的真實環境中反覆嘗試，從成功和失敗中學習什麼才是「選對檔案」。

Cognition 的訓練設計

Cognition 的做法是收集真實的使用資料：使用者提出的查詢，以及使用者最終實際修改了哪些檔案。這些資料形成了「輸入-正確答案」的配對，但他們並不是直接拿這些配對去做監督式學習。他們用這些資料來定義獎勵函數，然後讓模型自己去探索該怎麼到達正確答案。

獎勵函數的設計選擇了 F1 分數。這是一個同時考慮精確度（precision）和召回率（recall）的指標。精確度問的是「模型選的檔案中，有多少是對的」；召回率問的是「該選的檔案中，模型選中了多少」。F1 是這兩者的調和平均，會懲罰任何一邊的極端表現。

為什麼這個選擇很重要？想像兩種失敗模式。如果模型只追求精確度，它會變得非常保守，只選那些「百分之百確定」的檔案，結果漏掉很多其實應該修改的。如果模型只追求召回率，它會把可能相關的檔案都選進來，結果塞進一堆不相關的雜訊。F1 分數讓模型必須在這兩端之間找到平衡。

基礎設施的設計也值得注意。Cognition 為每一個訓練軌跡都啟動一個獨立的虛擬機，這個 VM 會承載程式碼庫的副本、執行模型發出的工具呼叫、最後根據結果計算 F1 分數。這樣設計的目的是確保隔離——一個訓練軌跡執行的 shell 指令不會影響另一個，這對訓練的穩定性和可重現性至關重要。

想像如果沒有隔離會發生什麼：一個訓練軌跡可能不小心刪除或修改了某個檔案，下一個軌跡看到的程式碼庫狀態就不對了，評分結果會變得不可靠，模型學到的東西也會是錯的。這種「環境污染」在多步驟的代理任務中特別容易發生，獨立 VM 的設計從根本上避免了這個問題。

從 100 到 1000：資料量的影響

Cognition 觀察到一個清楚的規律：資料量和效能提升之間有直接的關係。

他們一開始用大約 100 個範例來訓練，得到了 5 個百分點的效能提升。這個結果已經不錯——只用 100 個範例就能看到明顯改善，說明 Agent RFT 確實能從少量資料中學習。

但當他們把範例數擴大到 1,000 個，提升幅度跳到了 10 個百分點。這是一個兩倍的增長，說明在這個規模區間內，資料量的邊際效益並沒有遞減。更多的高品質範例，直接轉換成更好的代理行為。

這個發現對於想要使用 Agent RFT 的團隊有實際的指導意義。如果你的初步實驗顯示有效，值得投資收集更多的訓練資料。「夠用就好」的心態可能會讓你錯過進一步提升的機會。

當然，這裡有一個前提：資料品質。Cognition 收集的是「真實使用者的查詢 + 真實使用者實際修改的檔案」，這是最接近生產環境的資料來源。如果你的訓練資料是人工捏造的、或者來自不同的任務分布，增加數量可能不會帶來同樣的效果。

最驚人的改變：從串列到平行

效能數字的提升固然重要，但 Cognition 觀察到的另一個變化可能更有意思：模型的工作方式改變了。

訓練之前，模型的行為模式是這樣的：推理一下、呼叫一個工具、等待結果、再推理一下、再呼叫一個工具。這個循環會重複 8 到 10 次才能完成任務。每一步都是串列的，下一步要等上一步完成才能開始。

訓練之後，模型學會了一種完全不同的策略：在第一步就同時發出多個工具呼叫。這些呼叫可以平行執行，不需要互相等待。結果是，整體步驟數從 8-10 降到了 4。

這個改變不是人工設計的。沒有人在提示詞裡告訴模型「你應該平行呼叫工具」，也沒有人在獎勵函數裡直接獎勵「平行呼叫」這個行為。模型是自己發現的——透過大量的嘗試和 F1 分數的反饋，它發現「先一次問完、等全部結果回來再一起分析」是一個更高效的策略。

這說明了強化學習的一個強大之處：它能讓模型發現人類可能沒想到的、或者難以用規則描述的最佳策略。你不需要事先知道「正確答案」長什麼樣，你只需要定義清楚什麼是「好的結果」，模型會自己找到達成結果的方法。

對 Devin 使用體驗的實際影響

從使用者的角度來看，這個改變意味著什麼？

最直接的影響是速度。程式碼規劃階段是使用者提交任務後的第一個等待環節。如果這個階段從 8-10 步變成 4 步，使用者能更快看到「Devin 開始動手修改程式碼」這件事發生。在互動式的工作流程中，這種延遲的減少對使用體驗的影響很大——它讓 Devin 感覺更像一個「能幹的同事」，而不是一個「需要等很久才會回應的系統」。

另一個影響是可預測性。串列的多步驟流程，每一步都有出錯或卡住的風險。步驟越多，出問題的機會越大。收斂到更短的流程，意味著更少的潛在故障點，行為更穩定、結果更一致。

從工程的角度來看，更短的流程也意味著更低的運算成本。每一個步驟都涉及 API 呼叫、工具執行、結果處理，這些都是需要付費的資源。把 10 步變成 4 步，不只是省下 60% 的步驟，而是省下相應的 token 消耗、網路延遲、以及潛在的錯誤處理成本。

可以借鏡的經驗

Cognition 的案例提供了幾個可以借鏡的經驗。

獎勵函數的設計要考慮多個面向。F1 分數之所以有效，是因為它同時約束了兩個方向的錯誤。如果你的任務也有類似的「不能太多、不能太少」的特性，找一個能平衡兩端的指標會比只優化單一方向更好。

環境隔離很重要。對於涉及真實系統操作的訓練，每個軌跡都應該在乾淨、獨立的環境中執行。這是一個看似繁瑣的工程投資，但它確保了訓練過程的可靠性。

資料量有明確的回報。如果初步實驗顯示 Agent RFT 對你的任務有效，投資收集更多高品質的訓練資料通常是值得的。Cognition 從 100 到 1,000 範例的經驗顯示，這個規模區間的邊際效益仍然很高。

最後，讓模型自己發現策略。與其嘗試在提示詞裡規定每一個細節，不如設計好獎勵函數，讓模型自己探索。Cognition 沒有告訴模型要平行處理，但模型自己發現了這個策略。這可能是 Agent RFT 相對於傳統微調最獨特的價值：它能讓模型學到人類難以明確傳授的「訣竅」。