多代理分工機制與驗證流程

該實驗採用主管-工作者（Lead-Worker）架構，由 DeepSeek-V4.1-Flash 擔任主管角色。主管負責反組譯二進位檔、命名函數、恢復函數簽名與記憶體佈局，並將帶有提示的任務發布到共享看板上。

四個 Qwen3.5-9B 模型作為工作者，從看板領取任務並將單一函數重寫為 Python 程式碼。為了確保正確性，系統設有一個名為 diff_test 的驗證機制（Oracle），會將約 600 個測試案例同時輸入原始二進位函數與重寫的 Python 程式碼，比較回傳值及所有狀態位元組。

工作者僅在通過 100% 測試後才會提交結果。整個流程基於一個簡化的 ipython 環境執行，且主管被允許修改工作者的提示詞與工具設定，若認為這樣有助於提升表現的話。

小型程式測試數據顯示協作成本較高

研究團隊以兩個由 Claude Code 生成並編譯的小型 C 語言程式作為概念驗證目標，這些程式的符號表未被移除。實驗同時運行了僅由 DeepSeek 單獨處理任務的基準組進行比較。

在「HF logo animation」測試中，多代理團隊成功重寫全部 38 個函數，但有 15 個函數最終仍需由主管接手處理。該過程花費 2.97 美元與 86 分鐘；相比之下，DeepSeek 單獨執行同樣完成 38 個函數，僅花費 0.87 美元與 14 分鐘。

在「Space shooter」測試中，多代理團隊重寫全部 56 個函數，其中 20 個需主管接手，花費 3.60 美元與 100 分鐘。DeepSeek 單獨執行則花費 3.28 美元與 54 分鐘（經過四次啟動）。數據顯示在小型任務上，多代理架構因主管需協調並修正小模型的錯誤，導致時間與成本均高於單一大模型獨立作業。

主管動態調整工作模型指令以修正常見錯誤

實驗中最具啟發性的部分在於主管如何介入修正工作模型的行為。在處理射擊遊戲程式時，DeepSeek 主管三次修改了 Qwen 模型的指令。

工作模型初期出現多種問題，包括自行發明輔助函數名稱、忽略有符號與無符號整數的區別、以及未使用記錄的記憶體佈局。具體錯誤包括將 b.ls（無條件小於等於）誤讀為 <（嚴格小於）、以錯誤參數數量呼叫函數，以及手動計算欄位偏移時出現錯誤。

針對這些問題，主管新增了規則要求工作模型遵循特定規範，並開發了一個查詢工具讓工作模型可以直接查詢函數簽名與欄位偏移，而非自行重新推導這些資訊。

測試限制與結果適用範圍

研究團隊明確指出測試存在多項限制。首先，測試用的二進位檔並未移除符號表（stripped），這使得主管在映射函數時的工作大幅簡化，而大多數真實世界的軟體發行版本通常不包含這些符號名稱。

其次，測試對象是小型、乾淨且由 AI 生成的程式，並非經過最佳化的真實世界複雜程式碼。實驗僅包含兩個數據點，雖然任務規模與協作效益之間的趨勢具有暗示性，但尚未得到證實。

此外，即使在多代理架構下，仍有約 40% 的函數最終需退回由主管模型處理，顯示小模型在獨立完成複雜邏輯重寫上仍存在能力限制。