技術要約：プロンプトからハーネスへ：ゼロからのCoderlet

問題提起

プログラミングエージェントに関する現在の文献は、エージェントの振る舞いを制御する基礎的な制御メカニズムを隠蔽しがちである。小規模なデモンストレーションでは、通常、エージェントの相互作用をモデルと1つまたは2つのツールの間の単純なループへと還元してしまうが、プロダクションシステムでは、これらの関係は複雑で不透明なコンポーネント全体に分散されている。この複雑さにより、モデルの生成がどのように環境へのアクションへと変換されるのか、フィードバックがどのように後続の決定に統合されるのか、そしてリクエスト間でどのように状態が持続するのかを検証することが困難になっている。モデルサービス、ツール実行、および永続的な状態の境界を明確に定義した、明示的かつコンパクトな設計が不足しており、「ハーネス（harness）」、すなわちコンテキストを組み立て、呼び出しを検証し、アクションをディスパッチし、履歴を管理する制御層を理解することを難しくしている。

メソドロジー

本論文では、ゼロからコンパクトなハーネスを実装する実行可能なアーティファクトおよび設計フレームワークであるCoderletを紹介する。メソドロジーは、単一のユーザー・エージェント・セッションの要求ライフサイクルに焦点を当て、明確な制御フローを維持するためにリクエストを逐次的に処理することに重点を置いている。設計は、3つの明確な境界と5段階の要求ライフサイクルを中心に構成されている。

1. 3つの境界

アーキテクチャは、関心事を3つのリソースドメインに分離している。

• モデル境界（Model Boundary）: サービスとの相互作用を扱う。ハーネスはコンテキストとツールの説明をエンコードしてモデルに送り、レスポンスをテキストと構造化されたツール呼び出しへとデコードする。
• 実行境界（Execution Boundary）: ツールの環境（ファイル、プロセス、サービス）を管理する。提案されたツール呼び出しをスキーマに対して検証し、有効な呼び出しをディスパッチし、ツールの結果（値または期待されるエラー）を捕捉する。
• 状態境界（State Boundary）: 永続的なストレージを管理する。コンテキスト構築のための履歴/メモリのロードと、セッションをまたいで継続性を確保するためのリクエスト記録の保存を扱う。

2. 要求ライフサイクル

単一のリクエストは、5つの観測可能なポイントを通過する。

1. 準備（Preparation）: ハーネスは入力を読み取り、関連する履歴を選択し、ツールの説明をロードし、モデルのコンテキストを組み立てる。
2. モデルの決定（Model Decision）: モデルがコンテンツまたはツール呼び出しを提案する。ハーネスはレスポンスが完了するまで待機する。
3. 検証とディスパッチ（Validation & Dispatch）: ハーネスはレスポンスをデコードし、呼び出し識別子を確認し、ツールの名前と引数の形状を検証する。
   • 無効な呼び出しは即座に拒否され、環境を変更することなく拒絶の観察（observation）を生成する。
   • 有効な呼び出しは実行へと進む。
4. 観察の返却（Observation Return）: ツール環境がアクションを実行する。ハーネスは結果を元の呼び出しにバインドし、次のモデルコンテキストに含まれる「観察（observation）」を形成する。
5. 状態の継続（State Continuation）: ハーネスはリクエスト記録（指示、アクション、および観察を含む）を組み立て、それを保存する。保存が成功した後のみ、完了通知が呼び出し元に送信される。

3. ブートストラップ機構

この設計は、「継続的なブートストラップ（continued bootstrapping）」をサポートしている。これは、ハーネスが自身のツールを使用して、自身の実装を検査、修正、およびテストする場合を指す。コンテキストのルール、ツールのインターフェース、および制御フローをエージェントに公開することで、システムは実行をまたいで自身のメカニズムを反復的に洗練させることができる。

主な貢献

• 明示的なハーネス設計: 本論文は、モデルの生成と環境へのアクションを橋渡しする制御層の、明確で最小限の実装を提供し、「何をするか（モデルの出力）」と「どのように行うか（実行と状態管理）」を分離している。
• 境界の定義: モデル、実行、および状態の境界を正式に定義し、特定の遷移（例：検証、永続化）がどこで発生するかを明確にしている。この分離により、デバッグが局所化される。例えば、指示が欠落している場合はコンテキスト構築に、環境への影響が欠落している場合は検証またはディスパッチに問題があることが特定できる。
• 追跡可能性とリカバリ: 設計は、すべてのステージ（提案、実行、観察、記録）が個別に証拠として残ることを保証する。これにより、精密な失敗分析とリカバリが可能になる。例えば、ツール実行後に保存に失敗した場合、システムは観察を保持し、保存の失敗を状態層の問題として扱う。
• コンテキスト管理ルール: 本論文はコンテキスト選択の設計ルールを確立し、短縮されたコンテキストも解釈可能でなければならないことを強調している。また、観察とそれを生成した呼び出しの間のリンクを保持すること、および凝縮された資料には誤解を招かないよう「要約」というラベルを付けることを義務付けている。

結果と主張

本論文は、タスクの成功率やパフォーマンス指標において他のエージェントと比較する経験的なベンチマークを提示していない。代わりに、その「結果」はアーキテクチャ的かつ概念的なものである。

• 可視性: 設計は要求フローを可視化することに成功しており、最小限のハーネスがいかにして複雑なプロダクションシステムの不透明さを排除し、コンテキスト、ツールディスパッチ、および状態を管理できるかを示している。
• 堅牢性: 境界の分離により、部分的な失敗（例：ツールは実行されたが保存に失敗した）が相互作用の履歴を破損させないことを保証し、明確なリカバリポイントを可能にしている。
• ブートストラップの実現可能性: 本論文は、コンパクトなループが自己改善のためのシードとして機能できることを示しており、エージェントが自身のツールを使用してハーネスのメカニズムを改訂できることを実証している。

意義

本研究の意義は、新しい推論アルゴリズムやメモリ手法を提案することではなく、エージェントのランタイム構造に焦点を当てている点にある。著者は、ハーネスこそが、孤立したモデルのレスポンスを環境との継続的な相互作用へと変える重要なコンポーネントであると主張している。

ハーネスを「制御層」として扱うことで、本論文は以下のための実践的なフレームワークを提供している。

1. 判読可能性（Legibility）: 提案、実行、および観察を分離することで、ランタイムトレースを読み取り可能なものにする。
2. リカバリ（Recovery）: 失敗が発生した際に、特定のステージにおける具体的なリカバリの開始点を提供する。
3. 段階的な拡張（Gradual Extension）: エージェントが、完全なアーキテクチャの刷新を必要とせず、ブートストラップを通じて自身の組織的メカニズムを反復的に改善できる「シードシステム」を提供する。

本論文は、設計がフルプロダクションシステムと同等の機能や性能を主張するものではないが、エージェントの振る舞いを定義する制御層を理解し構築するための、基礎的かつ検査可能なアプローチを提供すると結論付けている。