複製應用，而非複製程式碼：微軟 ProgramDistill 把能跑的軟體變成 4,063 道可驗證的編程任務

每一個編程代理（coding agent）基準測試都藏著同一個不能說的秘密：任務總得有人寫。人類標註員憑空想出一個 bug、種進儲存庫、寫好修補程式，然後祈禱那份「標準答案」真的無懈可擊。結果就是幾百道手工謎題組成的語料庫，而且幾個月內就被刷到飽和——SWE-bench Verified 的 500 道任務，如今已被前端代理視為例行公事。9 月 14 日，微軟研究院位於蒙特婁的 Froggy 團隊（與 KAIST 研究實習生 Jeonghye Kim 合作）發表了 ProgramDistill，一條徹底翻轉這套安排的管線：不再是人類替軟體發明任務，而是能運作的軟體自己生成任務。

光看數字就值得關注：從 26 個開源網頁應用出發，ProgramDistill 的多代理管線挖掘出 1,975 個可重播驗證（replay-verified）的行為，並全自動建構出 4,063 道編程任務——2,862 道原子任務（還原一個缺失行為）加上 1,201 道累積任務（還原一串相互銜接的行為）——全程零人工標註。每道任務都自帶可機器檢驗的驗證器，因為驗證器就是應用程式自己被錄下來的行為。

這招是怎麼做到的

ProgramDistill 的核心是作者所稱的 mine-craft-patch 管線，由多個 LLM 代理協同運作。起點是一個真正能跑的應用程式——管線可以看它的原始碼，但受測代理永遠不行。

挖掘代理（mining agents）探索應用並錄下可重播的軌跡。 每條軌跡（trace）記錄瀏覽器操作、預期的成功訊號，以及一條可選的前置依賴連結。因為操作可以機械式重播、預期訊號的檢查完全不需要 LLM 介入，每條軌跡本身就是一個可執行的行為驗證器。驗證過的軌跡再進一步播種出依賴行為的探索——卡片得先存在才拖得動、看板得先建立才放得下卡片——只有能穩定重現的軌跡會被保留。在這 26 個應用中，前置關係形成分支的依賴樹，其中一條 StreamView 脈絡深達 12 層。

鵝刻代理（crafting agents）移除選定行為的實作。 管線外科手術式地刪掉某個行為背後的程式碼，接著跑建置與重播檢查，確認三件事：前置行為仍正常、目標行為現在會失敗、而且內建的 gold patch 能把它修回來。最後這一關是大多數合成任務產生器會跳過的——ProgramDistill 在出貨前先證明每道任務都有解。

編程代理（coding agents）接著修復被破壞的應用，只能透過瀏覽器與可運作的參考版本互動，既看不到參考的原始碼，也拿不到 gold patch。當初驗證破壞是否成立的那套重播機制，這時反過來替修復成果打分數。

這個設計順帶化解了困擾合成基準測試的資料污染問題。參考應用是真實、流行的儲存庫，但「哪些行為被拿掉、以何種組合被拿掉」是由管線即時生成的，代理無法背下它必須透過操作一個活生生的應用才能發現的答案。

基準測試發現了什麼

主打評測 ProgramDistill-300 讓九個編程代理在 26 個應用、還原深度 1 到 8 的 300 道任務上對決——深度代表在二分計分下，一次得連環還原多少個相互依賴的行為。

在深度 1，GPT-6 Astra 全數解出——提醒我們單一行為修復（也是多數基準測試在測的東西）已接近被解決。但到了深度 8，成功率跌到 64.0%，因為後面的行為依賴前面建立的狀態。其他所有受測代理在深度 8 的表現都不足深度 1 的一半。

全應用重建（full reconstruction）的設定更嚴苛：給代理一個最小可執行骨架、一段產品級功能描述、加上對參考應用的瀏覽器存取權，要它把整個應用重建出來，並以 12 個應用中的 590 個個別行為與 413 個累積工作流評分。結果把前端模型的差距拉得非常開：

代理	個別行為	累積工作流
GPT-6 Astra（max）	58.98%	49.15%
Claude Opus 5（max）	42.03%	28.81%
GPT-5.6 Sol（max）	33.39%	21.07%

最強的代理也只能還原 49.2% 的累積工作流——這說明實作出一堆有用的零件，並不保證這些零件能組合起來協同運作。這些重建過程平均約 700 個代理步驟，最高衝到 1,921 步。

贏家的行為側寫

最具策略意義的發現，不在於最強的代理「得分多高」，而在於它「怎麼做事」。GPT-6 Astra 被作者形容為觀察密集、編輯稀疏（observation-intensive, edit-light）：它平均每條軌跡對自己實作中的應用進行 96.3 次觀察——約為 GPT-5.6 Sol（45.8 次）的兩倍——同時編輯／寫入步驟卻是所有代理中最少的，每條軌跡僅 9.9 次。它的致勝模式是對自己的實作進行大量行為檢查，然後才做出高度選擇性的程式碼修改。它的軌跡讀起來像面對活參考的迭代開發，而不是一次性程式碼生成。

失敗分析則量化了另一條路的代價。在 36 次重建、977 個失敗的原子行為中，59.2% 涉及代理在參考應用裡「從未觀察過」的行為；其餘分別是 27.9% 產生錯誤的狀態、路由或結果；11.1% 呈現錯誤的可觀察形態；1.8% 觀察到了卻沒實作。探索參考應用，才是真正的瓶頸。

文件裡記載的一個案例幾乎帶著詩意：某代理實作了卡片拖放，卡片看得見地移動了，功能看起來完成了——但同樣的拖放手勢之後，產生的卡片順序與參考應用不同。互動成功了，結果狀態卻是錯的。代理在最後一次編輯之後驗證了其他看板互動，偏偏沒有重播那個會暴露不一致的精確工作流。

還有一個值得所有打造代理的人警惕的「努力配置病灶」：從深度 1 到深度 8，需要還原的程式碼量成長超過 9 倍、目標軌跡的總動作量成長超過 10 倍——但代理「平均每個修復目標」投入的觀察與編輯力道反而隨深度下降，其中觀察萎縮得最厲害。代理們集體在最需要檢查的深層工作流上投資不足，最終修補也留下更多未還原的實作。單純餵更多瀏覽器回饋也救不了：Claude Opus 5 獲得的瀏覽器狀態回饋遠多於 Astra，還原的行為卻更少。關鍵在於代理是否找對細節、忠實實作，並在修改後重新檢查相關的工作流。

為什麼重要

ProgramDistill 出現的時機，正值整個產業深陷基準通膨的泥沼。微軟讓真實應用程式擔任任務產生器、讓重播機制擔任裁判，等於造出了一把同時具備可規模化、抗污染、而且對複合工作流誠實到殘酷的尺——而複合工作流正是實際產品開發的形貌：功能是以相互依賴的鏈條問世，而不是一個個孤立的 diff。

作者勾勒的下一步指向兩個方向：用還原深度當作課綱，訓練參考引導的代理（以重播為強化學習的獎勵訊號）；以及把整套範式擴展到多模態代理，讓它們用截圖與參考互動，在行為正確之外同時被評分視覺保真度。

對押注編程代理的開發者與企業來說，實際的啟示相當清醒：單一功能修復大勢已去，但要求代理重建或深度還原一個有狀態的應用時，連當前最強的模型都只能交出大約一半的工作流。「會修 bug」與「能重建產品」之間的距離，如今是一個被量測出來的數字——49.2%。