成果を出す自律的なゴールループの構築

自律的な目標ループの構築とその成果

私たちが最初に構築したエージェントループは、ほとんどループと呼べるものではありませんでした。エージェントに計画を与え、テストがパスするまで実行させ、失敗を返すというものです。これは、テストがジョブを記述している場合には機能します。しかし、まだ理解していない製品機能を成長させるというジョブの場合は失敗します。

エージェントは動き続けますが、動きそのものが問題ではありません。テストは私たちがすでに知っていることしか保護せず、重要な失敗はそれらの外にあります。画面は何も保存していなくても、完成しているように見えることがあります。エージェントは間違った理由で正しい答えを出すことがあります。スコアラーはユーザーが望まない行動を報酬することがあります。より多くのターンを重ねることで、これらの失敗のそれぞれがより安価で高速になります。

The Convergence Problem で私は、エージェントがターンを所有し、人間がラウンドを所有できると主張しました。しかし、その境界の間にエージェントが必要とするものを説明しませんでした。それは3つのことを行うハーネスを必要とします。ハーネスは、実際の失敗を露呈し、欠けている機能を特定し、セッション終了後にその教訓を保存する必要があります。それは、リトライプロンプトを持つエージェントとは異なるマシンです。

開発中の2つのシステム

明白なシステムは機能です。あまり明白でないのは、次にエージェントが何を次に変更すべきかを決定するプロセスです。私たちは両方をエンジニアリングする必要があります。

ハーネスは、機能を改善しますが、開発コンテキストをテストに漏らしません。

graph TD
    DEVELOPMENT HARNESS HUMAN BOUNDARY
    goal --> authority
    authority --> protected measure
    LOOP CONTROLLER --> chooses the next gap
    DEVELOPMENT AGENT --> code + expected result
    REPOSITORY STATE --> memory between sessions
    FEATURE UNDER DEVELOPMENT --> PRODUCT AGENT
    PRODUCT AGENT --> fresh context
    PRODUCT SURFACE --> tools · UI · API
    STATE + EFFECTS --> BEHAVIOR DRIVER
    BEHAVIOR DRIVER --> sends a real request
    SCORER --> evidence + gap class
    protected measure --> protects

ハーネスは、機能がどのように機能すべきかを知っています。プロダクトエージェントは、ユーザーが受け取るものだけを受け取ります。

開発エージェントは機能を変更します。ドライバーは、ユーザーと同じサーフェスを通して機能にアプローチします。スコアラーは、何が起こったかを読み取ります。次にコントローラーは、その証拠から次のギャップを選択します。リポジトリステートは、セッション間の決定を運びます。

エージェント製品は通常、機能の中に別のエージェントを配置します。2つのエージェントは別々に保たれる必要があります。開発エージェントはコードと期待される結果を知っています。プロダクトエージェントは、新鮮な会話と製品が公開するツールのみを受け取ります。

それらがコンテキストを共有する場合、テストは無価値です。プロダクトエージェントは、ユーザーが決して提供しない知識で成功することができます。同じハーネスは、プロダクトエージェントなしでも機能します。ドライバーはブラウザ、API、コマンド、またはハードウェアシミュレータを使用できます。

重要なものはすべてプロンプトの外にある

プロンプトは、見やすいので最も注目を集めます。ループは、それを取り巻く世界に大きく依存します。まず、ハーネスは再現可能な開始点を必要とします。データ、サービス、モデル、環境、および提供されたコードは、記録された実行と一致する必要があります。リセットはシステムをその時点に戻す必要があります。プリフライトはそれを証明する必要があります。

世界が健全でない場合、ハーネスはスコアを記録しません。インフラストラクチャのトラブルは、機能が失敗したという証拠ではありません。この区別は、大規模な偽の修理を防ぎます。欠落したデータは、弱い推論のように見えることがあります。古いコードは、壊れた契約のように見えることがあります。

次に、ハーネスは実際の需要を必要とします。私たちは、人間が書いた、または承認したリクエストの小さなコーパスを使用します。ドライバーは、新鮮なインタラクションを通して変更されていないリクエストを1つ送信します。それは、回答、ツール呼び出し、拒否されたアクション、表示された結果、および永続的な効果を記録します。

効果が最も重要です。ソフトウェアは、正しいアクションを実行せずにそれを記述することができます。システムを変更せずに、もっともらしい画面をレンダリングすることができます。したがって、プロンプトは実行への単一の入力にすぎません。フィクスチャ、コードリビジョン、モデル、契約、およびスコアラーは、それらの隣に属します。それらの入力なしのスコアは、単なる数字です。

フロアと方向は異なる尺度

すべてのループには決定論的なフロアが必要です。テスト、バリデーター、スキーマ、および効果チェックは、機能がすでに獲得した動作を保持します。フロアはグリーンで始まります。それがレッドになった場合、そのリグレッションが次のジョブになります。フロアは、次に何を構築すべきかを教えてくれません。そのためには、実際のリクエストを駆動し、不足しているものを検査します。

一部のショートフォールは機械的なスコアをサポートします。他のものは、スクリーンショット、繰り返しのサンプル、または作業を理解している人を必要とします。これらの信号はノイズが多い可能性があります。1回の完璧な実行は、成功が可能であることを証明します。それが信頼できるかどうかについてはほとんど言いません。

信号は方向を選択し、フロアは以前の進捗を保存します。その分離はループを正直に保ちます。新しい機能は、後ろのパスを消去することなく製品を前進させることができます。

1ラウンドで1つのギャップを閉じる

世界と測定基準が存在すれば、ラウンド自体は単純です。

1. フィクスチャを復元し、実行中のシステムをチェックします。
2. 決定論的なフロアを実行します。
3. 承認されたリクエストを1つ、新鮮なインタラクションを通して送信します。
4. 動作、表示された結果、および永続的な効果を収集します。
5. 最大のギャップを分類します。
6. 必要なすべてのレイヤーを通してそのギャップを閉じます。
7. その動作のための決定論的なチェックを追加します。
8. 同じリクエストを再度送信し、結果を記録します。

1つのギャップは1つのファイルではありません。それは1つの因果関係の主張です。欠落している機能は、データモデル、ツール契約、ランタイム、エージェント命令、インターフェース、および効果チェックを横断する可能性があります。ラウンドは、そのパス全体を閉じるべきです。

request → representation → operation → persistent effect → visible proof

部分的なパスは、最も説得力のある失敗を生み出します。インターフェースは存在しますが、何もそのデータを生成しません。ツールは成功を返しますが、状態は変更されません。狭いパスがリクエストから効果まで機能することは、未完成の可能性の5つのレイヤーよりも価値があります。

分類ステップはランダムな修理を防ぎます。症状は、世界、ドメイン、契約、ランタイム、ステアリング、サーフェス、またはハーネスに属する可能性があります。そのステップなしでは、すべてのエージェントの失敗はプロンプトの問題になります。すべての視覚的な失敗はフロントエンドの問題になります。ループは、正しいことではなく、最も近いことを変更します。

1つの因果関係のギャップを変更すると、結果が帰属可能になります。ラウンドが5つの独立したレバーを変更した場合、どの教訓を保存すべきかを誰も知りません。

スコアラーは脅威モデルの一部である

自律ループは、たとえそれが悪いものであっても、到達できるあらゆる測定基準を最適化します。したがって、ハーネスは権威モデルを必要とします。私たちのモデルは3つのレベルを持っています。

Free ファイルは通常の実装レバーです。ループは、割り当てられたスコープ内でそれらを変更および測定できます。
Propose ファイルは境界を越えます。ループは証拠を記録し、変更を提案できますが、人間が決定します。
Frozen ファイルは試験を定義します。それらには、承認されたコーパス、フィクスチャ、既存のラング、スコア規則、および判断ルーブリックが含まれます。

graph LR
    AGENT AUTHORITY NARROWS TOWARD THE MEASURE
    FREE --> the loop changes these
    LOOP CODE --> NEW CHECK
    implementation levers --> PROPOSE
    PROPOSE --> evidence crosses a human gate
    EVIDENCE + proposal --> HUMAN CALL
    HUMAN CALL --> boundary changes
    boundary changes --> FROZEN
    FROZEN --> the loop cannot change these
    THE MEASURE --> corpus · fixture · score rules
    POWER OVER THE RESULT INCREASES · AGENT AUTHORITY DECREASES

ループは製品を変更できます。製品が改善されたかどうかを決定する証拠を変更することはできません。

ループは、観察した失敗のためにリグレッションチェックを追加できます。既存のチェックを弱めたり、しきい値を下げたりすることはできません。また、製品レバーとその測定値を同じラウンドで変更することもできません。そうでなければ、それは自身の修理を採点することになります。

学習したジャッジも同様の保護が必要です。視覚的なジャッジは、そのランキングが繰り返しの人間によるランキングと一致するまで、証拠として残ります。これはループの権威を制限しますが、結果を信頼できるものにします。

2番目のループが最初のループを改善する

すべての製品ラウンドは、ハーネスもテストします。ドライバーは失敗を隠すことができます。フィクスチャは必要なケースを省略する可能性があります。スコアラーは正しい行動を罰する可能性があります。手順は、同じ時間を2回無駄にする可能性があります。

各ラウンドを1つの質問で締めくくります。

ルールまたはチェックで防止できた、時間を無駄にしたことは何ですか？

最初の発生が証拠になります。繰り返しの摩擦は、ドライバー、事実、または標準的な手順を変更する可能性があります。ループが特定の失敗を永続的な制約に昇格させるとき、自己改善が発生します。それは、すべての驚きにオペレーティングシステムを書き直すわけではありません。時には正しい変更は減算です。偽の警告または誤解を招くラングは、ループに良い行動を避けるように教えます。

実際には異なる速度で実行されている3つのループがあります。製品ループは、ラウンドごとに1つの機能を閉じます。ハーネスループは、繰り返しの証拠が開発の失敗を露呈したときに変更されます。方向ループは両方の外側にあります。人間が証拠のバッチを読み、続行するか、リダイレクトするか、停止するかを決定します。

graph TD
    FAST INSIDE · SLOW OUTSIDE
    FEATURE + evidence --> HUMAN
    HUMAN --> continue · redirect · stop
    continue · redirect · stop --> DIRECTION LOOP
    DIRECTION LOOP --> after a batch of evidence
    after a batch of evidence --> HARNESS LOOP
    HARNESS LOOP --> after repeated friction
    after repeated friction --> PRODUCT LOOP
    PRODUCT LOOP --> one capability each round

内側のループは製品を改善します。外側のループは、プロセスと方向を変更すべきかどうかを決定します。

それらのループを分離しておくことは重要です。開発エージェントは新しい方向を提案できます。それは自身の結果が良いと自分で決定することはできません。

リポジトリはコントロールプレーンである

これのどれも現在の会話だけで生きることはできません。エージェントセッションは終了し、コンテキストは圧縮され、古い推論なしに次のセッションが開始されます。私たちは goals/ の下に小さなパッケージを保持しています。

LOOP.md はプロセスが変更されるときに変更されます。STATE.md は各ラウンド後に変更されます。この区別により、作業を忘れさせずにセッションを破棄可能になります。新しいエージェントは、目標、手順、状態、および証拠を読み取り、同じ決定から続行します。

これは単なるコンテキストの保存ではありません。これらのファイルにより、開発プロセスが検査可能になります。ループがギャップを選択した理由、変更をサポートした証拠、および次の実行が同じリクエストを改善したかどうかを確認できます。

人間はまだ十分かどうかを決定する

内側のループを小さなバッチで実行します。通常、3ラウンドで決定を下すのに十分な証拠が得られ、システムがドリフトする余地を与えません。境界で、人間はキューを続行するか、次のバッチをリダイレクトするか、または停止するかを選択します。ループは、失敗を再現または帰属できない場合に早く停止します。また、世界が健全でない場合や、修理にフローズン変更が必要な場合にも停止します。

これは、コンバージェンス投稿からの人間が所有するラウンドです。エージェントは、その中のターンを所有します。スコアが製品の方向を決定できないため、境界が存在します。

ほとんどのチケットには、これのいずれも必要ありません。完了したテストが作業を記述している場合は、エージェントにテストを与えて完了させます。ハーネスは、使用によって機能シーケンスを明らかにする必要がある場合にコストに見合う価値があります。システムは、ハーネスが観察できる効果も公開する必要があります。

3つのリクエスト、1つのフィクスチャ、1つのスコアコマンド、1つのループファイル、1つのステートファイル、および3ラウンドの予算から始めてください。失敗がそれを正当化した後でのみ、新しいコントロールを追加してください。

エージェントループの品質は、実行時間やコミット数ではありません。それは、ラウンドの後に残るものです。良いラウンドは、機能する機能、それが機能することの証拠、そして同じ教訓を2度支払わないハーネスを残します。それが、複雑な機能と一緒に放置する価値のあるエージェントループです。