リポジトリ全体のレビューと修正を行うスキルが、コスト階層化されたエージェントのはしごに作業を分散させ、正確な最終 SHA が出るまで完了を宣言しない仕組みです。
私はここしばらく、ある Codex スキルを構築してきました。リポジトリ全体をレビューし、見つけた問題を修正するスキルです。レビュー自体は簡単な部分でした。難しかったのは、まだ完了していないのに「完了した」と報告させないことでした。
最終的にたどり着いた形を決定づけた 3 つの要素があります。
列挙と判断は別物だ。両方に同じ料金を支払う必要はない。
追跡対象ファイルをリストアップし、カバレッジのマニフェストを作成し、コマンドを実行して出力を返す ── それは事務作業です。リポジトリ全体の監査において、これはトークン消費の大半を占めながら、その割には思考をほとんど伴いません。これを最上位モデルにルーティングすることは、ファイル一覧を生成するためだけに大金を使う最も確実な方法です。
そこでこのスキルは作業を次のような「はしご」に分割します。
- ENUMERATE（列挙） —
cheap。存在するものをすべて列挙します。ファイル、モジュール、テストカバレッジ、main ブランチとの差分、これから触れる対象のマニフェスト。意見なし。判断なし。 - REVIEW（レビュー） —
mid。マニフェストを順に確認します。発見事項ごとにクラスタ化し、それぞれに対して最小限のパッチと、防ぐべき障害モードを明示する 1 段落の根拠を起草します。 - JUDGE（判定） —
top tier only。提案された各パッチを、それが触れるコードと照らし合わせて再度読みます。承認するか、却下するか、または別の列挙パスをやり直すために差し戻します。ここは間違うと高くつく場所なので、高価なモデルが真価を発揮するのもここです。承認経路、並行処理とキャンセル、トランザクションとマイグレーションの安全性、複数ファイルにまたがる契約などです。
図の破線ループは装飾ではありません。判定者からの却下は実行を終了させるものではなく、より狭いスコープで列挙担当に作業を差し戻します。「クリーンなパスを返すまで繰り返す」が実際のコントラクトです。
Codex サブエージェントは同一のファイルシステムを共有する。
これは私にとって予想外の部分でした。隔離されたコピーはありません。マージステップもありません。いずれかのエージェントによる書き込みは、他のすべてのエージェント ── これから生成されるエージェントも含めて ── から即座に可視です。
これはワークフローの設計方法を変えざるを得ません。3 人のレビュアーにそれぞれリポジトリをクローンさせ、それぞれ独自の差分を作成させるのは無意味です。最も最後に書き込んだエージェントのものが勝ち、他の作業はあとかたもなく消えてしまうからです。代わりにこのスキルは、作業ツリーを単一の共有ブラックボードとして扱います。列挙担当がマニフェストを書き込み、レビュー担当がそれを読み取ってクラスタごとにパッチファイルを追記し、判定担当がパッチを読み、承認したものを適用してビルドを再実行します。ループを閉じるのは検証ステップです。
もう一つの帰結として、スキルは自身の進捗マーカーを信頼できません。「14 件のパッチを適用しました」という情報は、次のエージェントがそれを上書きするのであれば意味を持ちません。そのため、カウンターや「完了」フラグを信用する代わりに、実際に唯一生き残るものによって完了を制御します。それは作業ツリーの 正確な最終 SHA です。判定者が承認したとき、その実行はその SHA を記録し、次の呼び出しは再開前に作業ツリーをその SHA と照合します。SHA が前回のクリーンパスの結果と一致しなければ、作業が間違っていたからではなく、その土台自体が動いたため、列挙からやり直しになります。
ステータスバッジは雰囲気ではない。それは SHA だ。
- READY FOR MERGE（マージ準備完了） — 記録された SHA が現在のツリー SHA と一致し、ビルドが成功し、判定者がすべてのパッチを承認した状態。
- INCOMPLETE（未完了） — 作業は適用されたが、前回のクリーンパス以降にツリーがドリフトしているか、判定者が 1 つ以上のクラスタを却下して再列挙に差し戻した状態。
- BLOCKED（ブロック中） — ループが実行されて失敗した状態。判定者が繰り返し却下するクラスタがあるか、ビルドがグリーンにならない状態。人間が対応します。
このはしご全体の目的は、安価なティアを安価に保ち、高価なティアが真価を発揮する場所のためだけにそれを温存し、ファイルシステムが嘘をつけない何かから判定を引き出すことでした。