代理系統與評測
本機電腦代理增加推論預算未必更準，四張歷史畫面後效益開始反轉
一項 OSWorld 實驗顯示，本機 GUI 代理加入少量畫面歷史可明顯降低重複操作，但繼續延長上下文或步數主要是在改變失敗型態。兩階段規劃架構也因格式與協調成本落後單一代理，平行產生更多計畫只能以高昂 token 成本追回部分差距。
研究人員以 OSWorld 的 361 項 Ubuntu 任務，測試 Qwen3-VL-8B、Qwen3-VL-30B-A3B、UI-TARS-1.5-7B 與 OpenCUA-7B，系統化調整四種推論期資源：保留多少張歷史畫面、允許多少操作步驟、是否拆成規劃與定位兩階段，以及同時生成多少候選計畫。所有代理僅讀取螢幕截圖，不使用 accessibility tree，推論則在單張 A100 80GB 上透過 vLLM 執行。
最明顯的收益來自「一點點歷史」。平均成功率由完全不保留畫面的約 18%，升至保留一張時的逾 25%；以 Qwen3-VL-30B-A3B 為例，四張歷史畫面取得 28.56%，但增加至八張反而降至 27.16%。歷史能讓代理知道剛才已經點過什麼，減少原地循環與步數耗盡，卻無法改善完成判斷；上下文愈長，失敗反而更常變成代理過早宣告成功。
把最大操作步數由 15 提高到 50 或 100 也呈現相同現象：代理較少撞上步數上限，任務成功率卻大致持平，累積 prompt token 與操作成本持續增加。這表示錯誤軌跡通常不會因多走幾步自行修正。更複雜的「規劃器—定位器」架構甚至整體落後單一代理，原因包括計畫與畫面不一致、遺漏必要欄位及輸出格式無法解析。一次產生四份候選計畫能避開部分格式錯誤，但改善幅度低於額外計算量。
工程上的訊息是，本機代理不宜直接套用前沿大型模型的 test-time scaling 配方。較實際的方向是保留經篩選的短期狀態、加入循環與停滯偵測，並以獨立驗證器確認任務是否真的完成。限制是研究只涵蓋單一基準、Ubuntu 任務與一種 GPU 設定，也未公開新的訓練方法；結果說明的是現有本機模型的資源配置，而非所有 GUI 代理的普遍定律。