TomasuLLM 像推測執行 CPU 一樣，以非順序方式執行代理工具呼叫

長時間執行的工具主導了編碼代理的延遲：編譯器、測試套件與儲存庫命令需時數秒至數分鐘，而代理在此期間閒置。這種觀察到的停滯，與當年推動亂序處理器的張力相同——循序介面隱藏了可預測並提早開始的工作，但推測性結果唯有在它本身及所有更早步驟都經過驗證之後，才能顯露出來。

TomasuLLM 將 CPU 的解答套用到 LLM 代理上。其執行環境以偏離軌跡順序的方式執行代理工具呼叫，同時維持任務執行的正確性：它預先草擬未來的動作，在隔離的寫入時複製沙箱中執行，追蹤其依賴關係與效果，並僅在對已提交狀態驗證通過後，依軌跡順序提交結果。

在涵蓋從不到一秒到數分鐘工具呼叫的三項基準測試中，加速幅度隨工具延遲而增加：在 100 項 SWE-bench Verified 任務上為 1.31 倍，在 28 項 Terminal-Bench 2.0 任務上為 1.35 倍，在 18 場 SWE-Marathon 工作階段上則以 1.27 倍達成相符的進度。在 4,010 筆經稽核的提交驗證紀錄中，該執行環境產生零誤接受——沒有任何推測性結果被當作真實結果提交。

把代理軌跡視為指令流：預先推測，依序提交

主導編碼代理實際耗時的是工具延遲，而非模型速度。

循序的軌跡介面隱藏了可在代理抵達之前預測並開始的工具工作。

寫入時複製沙箱讓錯誤的推測可被丟棄，而非造成災難。

驗證後依軌跡順序提交，使可見行為維持循序，同時保留加速效果。

老舊的硬體技巧依然通用：當管線因緩慢步驟而停滯時，預測工作、在可丟棄的副本中提前執行，並以驗證作為顯露結果的關卡。

該論文報告了在 100 項 SWE-bench Verified 任務、28 項 Terminal-Bench 2.0 任務與 18 場 SWE-Marathon 工作階段上的結果，且在 4,010 筆經稽核的提交驗證紀錄中零誤接受。第 2 版於 2026 年 10 月 1 日發布於 arXiv。