從生成方案到決定下一步：AutoResearch 如何無幻覺閉環研究過程

AutoResearch 把問題發現、方案生成、蜂羣實驗和獨立驗證串成一條可持續推進的研究流程。在 Django 修復任務中，它將官方新增功能測試從 2/7 推進到 7/7，同時保持 203/203 個迴歸測試通過；在三項 Kaggle 實驗中，它也能區分達標、接近目標與平台期，並據此繼續、換方向或停止。

AutoResearch 是一套自動化研究系統。它持續觀察論文、開源項目、社區討論和技術異常，從中發現值得研究的問題，組織多個模型把想法變成實驗，再讓外部結果決定下一步。

這條流程要解決一種比憑空編造更隱蔽的錯誤：代碼真實存在，本地測試也確實通過，系統卻把“這部分做對了”誤判為“整個問題已經解決”。

圖 1｜本地測試全綠，只能證明已經覆蓋的檢查通過；獨立評測負責發現尚未覆蓋的關鍵缺口。

在一次真實 Django 修復任務中，GPT-5.6 的 716 個 migration 測試和 39 個 optimizer 測試全部通過，官方新增功能測試卻是 0/7。AutoResearch 第一輪也沒有完整解決問題：本地測試全綠，官方結果只有 2/7。區別發生在失敗之後。系統繼續根據外部結果改寫問題，沿着 2/7、4/7、7/7 推進，直到新增功能測試和迴歸測試同時通過。

1. 四個動作構成研究主循環

圖 2｜找題、造題、做實驗、讓證據裁決，四個動作構成 AutoResearch 的主循環。

AutoResearch 的主循環包含四個連續動作：

1. 發現問題：從開放信息中篩出可以追溯的新現象、新結果或未解決矛盾。
2. 形成可驗證的 Idea：把線索改寫成有成功標準、資源邊界和失敗條件的研究假設。
3. 組織蜂羣實驗：讓計劃、實現、運行和審查由不同角色協作完成。
4. 讓證據裁決：外部結果決定繼續迭代、改寫方向或停止。

失敗不會自動關閉工作流。它會成為下一輪的輸入，促使系統收緊問題邊界或改變實驗路徑。

2. 在回答之前，先找到值得研究的問題

AutoResearch 關注 arXiv、Hugging Face Daily Papers、OpenReview、GitHub Trending，也關注 Reddit、Hacker News、研究博客、中文技術媒體和 Twitter/X。不同渠道的數據格式、熱度含義和信息密度差異很大，採集後需要先轉成統一結構，再進行質量過濾、同批去重和跨天去重。

第一層模型負責快速判斷一條信息中是否存在可以轉化為研究課題的洞察。留下的候選再交給能力更強的模型，從新穎性、技術可行性、資源需求和驗證方法等維度繼續篩選。候選足夠多時，系統再次排序，選出優先進入 Idea Forge 的研究種子。

這條漏斗把開放的信息流壓縮成少量值得投入實驗資源的候選。研究問題保留明確來源，後續方案才能回到最初觀察進行復核。

3. Idea Forge：把線索變成實驗計劃

研究種子只是來自外部世界的現象或問題。Idea Forge 還會從知識庫中選擇一個已有研究方向，將兩者組合成候選方案。當前知識方向包括多模態融合、視覺 Token 管理、大模型推理與測試時計算（test-time compute）、Agent Memory 等。

Gemini、GPT 和 Claude 分別提出並審查候選 Idea。三類模型的訓練背景和判斷偏好不同，有的更敏感於新穎性，有的更關注技術可行性，有的會先發現資源與評估漏洞。候選方案進入執行前需要完成四項檢查：

• 交叉評審：三個模型獨立判斷，同一 Idea 至少獲得兩票才能繼續。
• 時新性檢查：排除陳舊模型、舊年份和已經過時的技術表述。
• 知識共識檢查：確認方案真正使用了對應知識方向，沒有把熱門詞機械拼接。
• 多階段計劃：第一階段先做能夠快速判定方向的預實驗，後續再擴大實驗、增加消融並完成評估。

多數票只用於盡早暴露盲點。最終方案仍要落到可測假設、明確預算和能夠判定成敗的實驗上。

4. 從計劃到實驗：蜂羣如何協作

圖 3｜研究種子經過交叉評審和計劃後，進入計劃、實現、運行、審查與外部評測組成的協作流程。

進入執行階段後，AutoResearch 把工作拆成連續的任務單元。協調角色維護全局狀態，規劃角色把目標改寫成可證偽的實驗方案，實現角色負責編寫代碼，實驗執行角色運行代碼並整理結果，評審角色從不同角度尋找遺漏。

簡單任務可以減少角色，複雜任務可以增加 Subcoder、Monitor 或獨立驗證角色。角色名稱並不決定結果，關鍵是計劃、實現、運行和審查不再擠在一次模型回答裏。

計劃、代碼、實驗記錄和評審意見保留在同一個持久工作區。循環執行機制會繼續處理沒有完成的單元，直到外部指標和停止條件允許工作流關閉。規劃會被實驗結果推翻，評審也會誤判；角色給出的結束建議不能關閉工作流。是否繼續、何時結束，由可復現結果和獨立成功標準決定。

5. 系統驗證一：把研究目標推進到可驗證結果

AutoResearch 在三個 Kaggle 題目上採用相似的實驗協議：先以低成本預實驗驗證方向，再根據結果設計主實驗；每個階段都有成功標準、代碼審查、運行記錄和停止判斷。三個題目分別使用準確率、均方根對數誤差（RMSLE）和 F1 作為主要指標，指標方向與 Kaggle 官方賽題一致 [1][2][3]。

圖 4｜同一套實驗協議產生三種結局：Titanic 達標，House Prices 接近目標，Disaster Tweets 進入平台期。三張圖的縱軸彼此獨立，不作跨任務數值比較。

5.1 Titanic：嚴格對照確認特徵工程的提升

第一階段使用 9 個基礎特徵建立基線，Gradient Boosting 的 5 折交叉驗證準確率為 0.8272。第二階段加入 Title、FamilySize、IsAlone、Age 分箱和 Fare 分箱等特徵。

Control 與 Treatment 使用相同隨機種子、相同數據折和相同模型。Control 保留基礎特徵，Treatment 加入擴展特徵。Control 完整復現第一階段結果，Treatment 達到 0.8428，越過 0.8300 的目標線。兩組實驗的主要差異只有特徵集合，因此結果支持特徵工程帶來本輪提升。

5.2 House Prices：先找到貢獻最大的改動

目標是把 5 折交叉驗證 RMSLE 降到 0.1200 以下。系統先在小樣本上建立 Ridge 基線，再只改變預測目標，對房價做 log1p 變換，RMSLE 從 0.2008 降到 0.1566。加入少量派生特徵後為 0.1563，繼續堆特徵的收益已經很小。

進入全量實驗後，模型族從線性模型切換到 LightGBM，結果降到 0.1258；擴展特徵和交互項最終做到 0.1251。目標沒有達到，但實驗已經定位主要增益來源：目標變換和模型族切換貢獻了絕大部分改善，追加特徵只有邊際收益。系統據此停止機械擴張調參範圍。

5.3 Disaster Tweets：平台期觸發停止

目標是 F1 達到 0.8350。系統從 TF-IDF 和邏輯迴歸開始，建立 0.7680 的詞法基線，再嘗試 SBERT、DistilBERT 微調和軟投票集成，最高達到 0.8049。

隨後參數量從 66M 增加到 125M，換用 RoBERTa-base，最好成績為 0.8005，沒有超過 DistilBERT。連續 21 次實驗後，最優結果仍為 0.8049。更大的模型沒有帶來增益，系統停止沿同一路線追加實驗，並將下一步收斂為三類選擇：增加有效數據、增加訓練資源，或改變建模路線。

6. 系統驗證二：從局部修復推進到完整解決

第二組實驗來自 SWE-bench Lite 的 django__django-16820。SWE-bench 將模型生成的補丁應用到真實倉庫，並運行倉庫測試判斷問題是否解決 [4]。這項任務源於 Django 對 Meta.index_together 的棄用處理，涉及 migration optimizer 和 autodetector 對 RenameIndex、AddIndex、RemoveIndex 及循環外鍵的協同處理；Django 上游討論也記錄了這些索引操作與複雜遷移優化之間的關係 [5]。

圖 5｜GPT-5.6 在本地測試通過、官方新增測試 0/7 後結束；AutoResearch 根據 2/7 與 4/7 的反饋繼續改寫問題，最終達到 7/7，並保持 203/203 個迴歸測試通過。兩組的時間與反饋條件不同，這裏比較的是失敗後的流程。

GPT-5.6 找到一個真實缺口：CreateModel.reduce() 缺少對 RenameIndex(old_fields=...) 的摺疊邏輯。補丁通過 39 個 optimizer 測試、716 個 migration 測試和 203 個官方迴歸測試，官方新增功能測試仍為 0/7。補丁解決了 RenameIndex 子問題，沒有覆蓋 AddIndex、RemoveIndex、autodetector 和循環外鍵。

AutoResearch 第一輪同樣把重點放在 RenameIndex。代碼審查發現 no-match guard 缺失，修復後 41 個 optimizer 測試、11 個 squashmigrations 集成測試和 719 個 migration 測試通過，首輪官方結果為 2/7。

外部結果將研究視角從單個 reduce() 分支擴展到 optimizer 與 autodetector 的協同，第二版提升到 4/7。下一輪繼續追蹤索引狀態如何進入遷移流程、如何摺疊並最終收斂。最終，官方新增功能測試達到 7/7，同時保持 203/203 個迴歸測試通過。

7. AutoResearch 自動化的是研究決策

這兩組實驗説明 AutoResearch 的核心能力落在五個環節：

1. 把研究問題變成可執行對象：Idea 必須落到預實驗、成功標準、資源預算、消融方案和交付物。
2. 把不同模型放在合適的位置：輕量模型篩選大量候選，能力更強的模型深入判斷，多類模型交叉提出和審查 Idea。
3. 讓階段性結果指向下一步：達到目標、接近目標和負結果都會留下證據，分別觸發擴展、調整或停止。
4. 把完成條件交給獨立指標：內部角色達成共識、本地測試全綠，都不能替代預先定義的完整成功標準。
5. 允許系統停止：當方向進入平台期或投入產出比下降時，系統關閉當前路徑，並留下重新啓動所需的狀態和結論。

模型負責提出、實現和質疑，證據負責決定下一步。

8. 成功是一條沒有斷掉的證據鏈

大模型已經很擅長快速生成候選答案。AutoResearch 進一步設計了答案之後的完整迴路：問題怎樣變成實驗，結果由誰審查，失敗如何改寫下一步，什麼證據足以支持繼續，以及系統在什麼條件下停止。

這套方法可以稱為循環工程（Loop Engineering）：需要設計的不只有角色和提示詞，還包括狀態如何保留、證據如何流動、判斷如何被複核。角色可以犯錯，迴路必須讓錯誤暴露，讓缺少證據的“成功”無法關閉工作流。

9. 參考文獻

1. Kaggle. (2012). Titanic - Machine Learning from Disaster. Kaggle Getting Started Competition.
2. Kaggle. House Prices - Advanced Regression Techniques. Kaggle Getting Started Competition.
3. Kaggle. Natural Language Processing with Disaster Tweets. Kaggle Getting Started Competition.
4. Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. The Twelfth International Conference on Learning Representations.
5. Django Software Foundation. (2023). Fixed #34529, Refs #34525: Reduced index operations with Meta.indexes / index_together when optimizing migrations. django/django Pull Request #16820.