Code as Agent Harness — コードをエージェントの実行基盤として捉える102ページのサーベイ
(code-as-harness.github.io)UIUC × Meta × Stanford の共同研究。5月に arXiv に掲載されたサーベイ論文で、視点がかなり面白い。
中核となる主張
「コードはもはや LLM が生成する成果物ではない。エージェントが推論し、行動し、状態を保存し、フィードバックを検証する operational substrate（実行基盤）である。」
つまり、コードは単なる .py ファイルではなく、エージェントが生きる世界そのものだという見方だ。これを code as agent harness と呼ぶ。
3層構造
論文ではエージェントシステムを3つのレイヤーに分けて分析している:
① Harness Interface — コードがエージェントを環境と接続する方法
- Program-of-Thoughts のように推論をコードとして externalize し、実行・検証する
- GUI やロボット制御では、生成されたプログラムがポリシーとして動作する
- コードベース、トレース、シミュレータが環境そのものを表現する
② Harness Mechanisms — 長期実行を持続させる制御システム
- Planning: 単純な decomposition を超え、
PLAN.mdのようなファイルシステムベースの持続的計画へ進化中。Meta-Harness は harness 設計そのものを search space として扱う - Memory: working / semantic / experiential / long-term / multi-agent + context compaction に分けて分析。「メモリは単一のベクターDBではなく、統合された状態管理レイヤーである」という点が核心
- PEV Loop: Plan → Execute → Verify サイクルを cybernetic governor として再定義。実行は read-only → sandbox-edit → full-access(HITL) の3段階権限モデル
- AHE: harness 自体を測定・最適化するメタレイヤー
③ Scaling the Harness — マルチエージェントがコードという共有媒体の上で協調する方法
- 興味深い発見: 「トポロジの複雑さは、共有状態表現の未成熟さが生む税である」 — 状態をうまく設計したシステムは単純な構造でもうまく動き、暗黙状態に依存するシステムはその欠如を複雑なトポロジで埋め合わせる
印象的なポイント
- Context Compaction + State Offloading: コンテキストウィンドウにすべて入れるのではなく、意思決定に必要な要約だけを active context に置き、全データは MCP-style プロトコルで offload せよ — これは完全に実践的なコツ
- 検証を決定論的センサーに: リンタ、型チェッカー、テスト、ファザーのような決定論的フィードバックは、LLM critique より信頼できる制御信号になる
- 失敗の原因はモデルではなく harness にある: 「ほとんどのエージェント失敗は、不十分なストレージコンテキスト、壊れやすいツールインターフェース、弱い検証器、過大なトークンコスト、誤ったリトライポリシーに起因する」
Open Problems
論文が残した7つのオープンな問題のうち:
- 最終的な成功以外の評価: 中間トレース、復旧の試み、安全性チェックも一級の指標として扱う
- 回帰のない harness 改善: 失敗から学びつつ、既存の動作を壊さない方法
- マルチエージェント間のトランザクション的共有状態: 複数のエージェントが同時にコードを修正するときの競合解決
参考
まだコメントはありません。