AI 代理與研究基礎設施
Meta 讓推薦系統研究代理跨伺服器接手多日 GPU 實驗，操作修復次數降至每輪 0.5 次
Auto-RecSys 將研究構想、分散式訓練、故障恢復與結果分析串成可跨工作階段延續的雙迴圈。31 輪內部實驗顯示操作修復次數由每輪 4.0 次降至 0.5 次，但尚未證明代理提出的模型改動能穩定改善推薦品質。
Meta 研究團隊公開 Auto-RecSys，試圖把自動研究代理從數分鐘即可回饋的小型實驗，推向單次訓練可能耗時數日的工業級推薦系統。系統沒有縮短模型訓練本身，而是讓多個構想在不同伺服器非同步執行，並把研究人員的注意力從提交、監看與重跑工作中釋放出來。
核心設計是把「認知」與「程序」分開。代理透過每個模型專屬的 Markdown playbook 理解關鍵程式位置、驗證流程、已知死路及成功策略；GPU 類型、資源權限、套件層版本、工作狀態等不能含糊的資訊，則交由固定 schema 的 JSON／JSONL 與確定性腳本處理。集中式記憶會保存構想登錄表、追加式實驗歷史、工作階段軌跡及草稿程式差異，因此原伺服器或代理工作階段失效後，另一工作階段仍能還原上下文、查詢遠端訓練工作並繼續分析。
Auto-RecSys 另設兩個演化迴圈：Execution Evolution Loop 從失敗軌跡提煉「不要再做」的規則與可重用管線；Idea Evolution Loop 則依已完成實驗調整後續假設。團隊在同一推薦模型的 31 次迭代觀察到，穩定期的重大操作修復由平均 4.0 次降至 1.3 次。第 21 輪更換模型基線後錯誤一度回升，但第 26 至 31 輪降至 0.5 次，六輪中有五輪無須操作修復；最長案例連續執行 110 次工具呼叫而未要求人工介入。
這些數字主要衡量基礎設施可靠度，沒有對照組，也排除了實作新構想時的推理與除錯，更未報告推薦指標或研究產出的成功率。資料只涵蓋一個模型的 31 輪內部軌跡，系統與程式碼亦未公開。工程團隊下一步應關注 playbook 更新是否經獨立驗證、多人同時修改共享狀態時如何解決衝突，以及代理是否會因自動套用舊經驗而悄悄浪費高成本 GPU 工作。