コンテキスト

すべてのエージェントは、コンテキストウィンドウの中で動作します。これは、会話、エージェントが読んだファイル、実行したすべてのツールの出力を記録し続けるものです。短いタスクでは、この記録は小さいままです。しかし長いタスク、たとえば何段階にもわたるフォレンジック調査、大規模なリファクタリング、午後いっぱいのやり取りでは急速に大きくなり、大半のエージェントはそこで目立った兆候もなく機能しなくなります。

長い実行が逸脱する理由

ウィンドウが埋まるにつれて、モデルは元の指示を確実に参照できなくなります。最初に設定した制約を忘れ、古いツール出力に頼り、本題から外れた目標へと流れ始めます。重要なのは、品質がトークン数の上限に達した時点ではなく、そのかなり手前で落ちることです。エージェントは問題なく見えても、すでに作業の筋道を保てなくなったコンテキストで動いていることがあります。さらに進むと、劣化するだけでなくウィンドウからあふれ、呼び出しそのものが失敗します。

Perchは長時間動作するように作られています。そのため、コンテキストウィンドウを、エラーになるまで埋めていくものではなく、毎ターン積極的に管理すべきものとして扱います。

コンパクションのパイプライン

モデルを呼び出す前に毎回、Perchは作業中のコンテキストを、順序の決まったパイプラインに通します。各段階は次の段階よりも低コストで、失われる情報も少ないため、コストが高く情報が失われる処理は、低コストで情報を失わない処理だけでは足りなかったときにしか実行されません。

最初の段階：重いアーティファクトを常に先に削る

長時間の実行は、かさばるわりに価値の低いペイロードで膨らみます。ブラウザのページ全体のスナップショットや、オペレーターのスクリーンショットです。Perchはこれらを毎ターン、予算を確認する前に削ります。ページのスナップショットは操作に必要な部分（モデルが操作する可能性のあるコントロールと構造）だけに切り詰められ、最も古いものは簡単なスタブに縮小されます。スクリーンショットは削除されるか、トークン数の厳格な上限まで圧縮されます。これは純粋な無駄の除去なので、無条件に行われます。生のDOMスナップショットやスクリーンショットは、一つだけで実際の推論の何十ターン分よりも多くのコストがかかることがあり、数ステップ後に必要になることはほとんどありません。

次の段階：古いツール出力を小規模に圧縮する（モデル呼び出しなし）

それでも予算を超えている場合、Perchは古いツール結果の本文を消去し、最新のものはそのまま残します。ツール呼び出しとその結果の対応関係は保たれ、古い結果の本文だけが短いマーカーに置き換えられます。これが最も効くのは、まさにPerchが想定しているワークロードです。何十ものファイルを読み、多数のサンドボックスチェックを実行するフォレンジック調査では、膨大なツール出力がたまります。しかし、モデルが二十ステップ前に読んだファイルの生テキストを必要とすることはまれで、必要なのはそこから導いた結論だけです。このステップは低コストで、追加のモデル呼び出しもなく、多くの場合はコストの高い要約を丸ごと省けるだけの余裕を生みます。古いツール本文の消去は日常的なコスト削減であり、作業を中断してまで知らせる出来事ではないため、この処理は表示されずに行われます。

その次の段階：まだ予算を超えている場合に限り古いターンを要約する

低コストのステップを経てもなお予算を超えている場合、そしてその場合に限り、Perchは会話の古い部分を、何が起き何が決まったかをまとめた簡潔な記録に要約します。それ以前の要約があればそれも取り込み、その記録をもとに作業を続けます。これはコストが高く情報が失われる唯一のステップなので、最後に実行されます。実行されたときは、それが表示されます。トランスクリプトにその時点が示され、何が変わったかが報告されます。

最後の段階：上限を厳格に適用する安全策

最後の保証として、Perchは送信前に、実際のペイロードサイズがモデルの上限に収まるようにし、直近のターンを最低限残しながら、最も古いメッセージから削ります。これが、オーバーフローによる失敗を構造的に起こり得なくする安全網です。まれなケースでも、モデルに届くリクエストは必ず収まります。

推測ではなく実際のウィンドウを測る

文字数に基づくトークン数の推定は、密度の高いコンテンツを一貫して過小評価します。CSV、JSON、コード、長い数値の列などです。財務やドキュメントを扱う実行には、まさにそうした内容が大量に含まれます。単純な推定ではコンパクションの発動が遅れるか、まったく発動せず、ペイロードがあふれます。Perchは、同じ実行の直前の呼び出しでプロバイダーが返した実際のプロンプトトークン数を使って推定値を補正し、コンパクションの発動条件をそれに合わせます。コンパクションは、よりによって困る方向に外れる推測ではなく、コンテキストの実際のサイズに基づいて発動します。

進行中の流れを守る

コンパクションは、あなたが今取り組んでいるものには決して手を付けません。Perchは会話の直近部分を常に一語一句そのまま残します。その範囲は、メッセージ数の固定値ではなく、実際のトークン予算で決まります。また、ツール呼び出しとその結果を対にして残すので、直近の履歴の一貫性が保たれます。古いコンテキストは圧縮され、進行中の流れはそのまま残ります。

モデルの実際の予算を尊重する

Perchは、そのターンを処理している裏側のモデルの素のウィンドウではなく、上位の階層で使える大きなウィンドウも含めて、あなたの実行に実際に適用されるコンテキストの上限に合わせてコンパクションを行います。また、上限ぎりぎりまで詰めて次のステップですぐにまた埋まるようなやり方ではなく、余裕を持たせた実際に作業に使える予算を目標にします。そのため、モデルはこの先のターンで考えるための余地を保てます。

黙って行わず、見えるようにする

本格的なコンパクションは、目に見えるものです。コンテキストメーターはウィンドウがどれだけ埋まっているかを示し、Perchが要約を実行すると、トランスクリプトにその時点を示して何が変わったかを報告します。どれだけ解放されたか、どれだけ要約されたか、要約の大きさ、直近の履歴がどれだけ残されたかです。エージェントがまだ流れを把握しているのかどうか、推測を強いられることはありません。低コストのバックグラウンド処理は静かに行われ、情報が失われる唯一のステップは必ず表示されます。

なぜ重要なのか

これが、五ステップのタスクでデモ映えするエージェントと、長くリスクの高い実行で信頼できるエージェントとの違いです。何十ものファイル読み込みとサンドボックスチェックにわたるフォレンジック調査は、最初から最後まで元の問いに根ざしている必要があり、ウィンドウがあふれたせいで途中で失敗するわけにはいきません。Perchは設計によって長い作業の正確さを保ち、コンテキストを上限内に保つので、最後に出る答えは、最初に与えたのと同じ指示に基づいています。