PACE-Bench、物理法則の変更で既存のエージェント設計が機能不全に――完全設定で最高のPass@2も35.9%にとどまる

多くの「自己進化型エージェント」のベンチマークは、システムが経験を生かして次の課題で性能を向上できるかだけを問い、実行ルールそのものは通常変更しない。[PACE-Benchの論文](https://arxiv.org/abs/2608.14441)は代わりに、実運用後の保守に近い状況を評価する。橋、車両、コントローラーの目標とAPIは変わらないものの、摩擦、重力、材料強度、トルク制限などが変更され、以前は検証を通過していたPython設計が必ず失敗するようになっている。エージェントは、サンドボックスから返される力、制約違反量、失敗時刻などの診断シグナルから原因を特定し、機構または制御ロジックを書き直さなければならない。

データセットは6種類の物理ドメイン、36件の基礎タスク、各タスクにつき難易度が段階的に上がる4つのターゲット環境で構成され、合計144件のsource-to-target適応ケースを形成する。各実行では最大20件の候補案を提出できる。参照解によってターゲット環境が解決可能であることを確認すると同時に、ソース環境の解をそのまま流用できないことも検証している。評価では最終的な合否だけでなく、制約を部分的に満たした度合いも記録し、二値の成功指標だけでは、エージェントが実行可能な解にどこまで近づいたかが見えなくなる問題を避けている。

研究では、Reflexion、Self-Refine、ACE、ExpeL、Tree of Thoughts、CodeEvolve、および複数のtest-time training手法を比較した。完全評価では、Qwen3-14Bと組み合わせたReflexionが最高のPass@2を記録したが、それでも35.9%にとどまった。同じモデルを使った拡張なしのループは32.0%だった。さらに注目すべき点として、ACE、ExpeL、ReasoningBankなどの記憶手法は、大規模なモデルではベースラインを下回ることが多かった。軌跡分析によると、以前の設計がアンカーとなり、エージェントは誤ったアーキテクチャを微調整し続けていた。どの物理パラメータが変更されたかを著者が直接明示しても、従来の性能上限を突破できなかった。このことは、ボトルネックが「何が変わったか」の特定ではなく、「どう作り直すべきか」という再設計にあることを示唆している。

[オープンソースリポジトリ](https://github.com/thunlp/PACE-Bench)では、Box2Dタスク、検証器、10種類の手法、OpenAI互換API、ローカルのvLLM／Transformers実行パスが提供されている。また、実際の検証器と認証情報をコンテナ外に保持する、隔離されたcoding-agentモードも追加されている。ただし、すべてのタスクは依然として著者が設計した2次元シミュレーションであり、完全な比較の中心となるモデルもQwen3の4B～14Bである。GPT-5.5の66.7%という結果は、24件のstaticsサブセットだけを対象としており、完全版リーダーボードと直接比較することはできない。今後は、他のチームが結果を再現できるか、また記憶手法に忘却、分岐、反実仮想的な再構築を導入することで、設計の固着を回避できるかが焦点となる。