Stellar Colosseum 以依賴圖與證偽迴圈管理長程數學代理

Stellar Colosseum 試圖解決長程研究代理最常見的失敗：模型在開頭選錯策略，之後卻持續為錯誤前提補寫數十頁內容。系統先讓多個代理產生「策略卡」，記錄核心機制、必要引理、證據、瓶頸與未完成義務，再由 readiness gate 判斷路線是否成熟。通過後，策略才會被轉成帶有依賴邊的證明區段圖；互不相依的區段可並行處理，驗證器發現問題時，也只需把批評送回受影響的區段。

每個階段都會產生多個候選並要求其他代理主動尋找反例、循環論證、遺漏假設或錯用定理。候選與批評不是直接多數決，而是透過重疊隨機取樣樹逐層合併；論文所列 TCS-Bench 配置依序把寬度由 32、16、8、5 收斂至 1，每個聚合節點取五份材料。共享目錄則保留已知引理、失敗路徑、文獻與計算觀察，讓後續回合不必重複踩坑。相同架構移植到程式題時，末端區段改為 C++ 實作，並把編譯、公開範例及壓力測試結果送回修訂迴圈。

在由 300 個研究級定理任務組成的 TCS-Bench 上，單獨使用 Colosseum 時，Gemini 3.1 Pro 與 Gemini 3.7 Flash 分別得到 54% 與 55%。團隊再用八次 Flash 批評判斷應採用哪個模型的證明，得到 71%、即 213 題；理想化的 best-of-two 上限為 77.3%，顯示選擇器仍會丟掉正確候選。另一組 222 題 Codeforces 實驗中，加入執行回饋後解出 218 題，無該回饋的比較組為 213 題。

這項工作的重要性在於把推論時計算從「多抽幾個答案」提升為具有狀態、依賴與回滾範圍的工程流程。不過 71% 結果混合兩個模型、八次批評及參考輔助評分，不能直接當成單一代理準確率；Codeforces 比較也同時改變修訂預算。論文公開部分證明產物，但未釋出可直接重跑的完整 Colosseum harness、成本明細或逐題軌跡。接下來應關注元件消融、形式化驗證，以及在固定 token／時間預算下是否仍勝過簡單 best-of-N。