コンテキストはいっぱいです、切り取ることを学びましょう

なぜコンパクトなのか？

エージェントが長時間実行されると、messages[] が拡張されます。各 read_file は数千のトークンを返し、各 bash は数百のトークンを返し、各ラウンドの対話にはモデルの思考テキストも含まれます。 50 ラウンド後、コンテキストは 100K 以上まで詰め込むことができます。 2 つの結果:

• モデルの上限に達した場合: ウィンドウ サイズに達するとモデルが崩壊するか、API 呼び出しごとに価格が直線的に増加します。
• 注意力の希薄化: 現在のタスクが 30 ラウンド前の無関係なツール結果に埋もれているため、モデルは焦点を失い始めます。

s06 のアイデア: エージェントに重要でないコンテンツを積極的に忘れさせますが、主要な状態は保持します。軽いものから重いものまで三層機構。

レイヤー 1 · micro_compact (ラウンドごとにサイレントに実行)

最も安い層。各 LLM 呼び出しの前にこれを実行し、3 つ以上の古い tool_results をプレースホルダーに置き換えます。

# 第 10 轮往前，大部分 tool_result 变成：
{
  "type": "tool_result",
  "tool_use_id": "toolu_01A",
  "content": "[Previous: used bash]"   # 从几千字符缩到几十
}

特殊な場合があります。read_file の結果は圧縮されません。なぜ？ read の出力は参考資料なので、モデルを押すと再度読み込む必要があり、コストが高くなります。

PRESERVE_RESULT_TOOLS = {"read_file"}  # 永不压缩

micro_compact を見て、turn を押して古い結果を表示します。

次の手順では、10 ラウンドのインタラクションをシミュレートし、各ラウンドの前に micro_compact を 1 回実行します。 messages[] 内の古い tool_result を見ると、[Previous: ...] になりますが、最後の 3 つは同じままです。

レイヤ 2 · auto_compact (しきい値を超えたときにトリガーされます)

マイクロが動き続けても、ある程度の大きさまで疲れると爆発します。 s06 はしきい値を設定します (デフォルトは 50000 トークン):

<オル>

トークン len(str(messages)) // 4 の数を見積もります (大まかですが十分です)。

しきい値を超える → 完全なトランスクリプトを.transcripts/transcript_TIMESTAMP.jsonl に書きます (下部は残します)。

LLM に会話全体の要約を書いてもらいます。

messages を 1 つの "[compressed] SUMMARY..." に置き換えます。

コストは明らかです。特定のツールの出力と会話のトーンが失われ、輪郭だけが残ります。ただし、 エージェントは業務を継続できることが重要な利点です。

レイヤー3・モデルを自分で調整するコンパクトツール

auto_compact はハーネスによって自動的にトリガーされ、モデルには認識されません。逆に、レイヤー 3: モデルに compact ツールを与え、 圧縮を積極的に要求させます。たとえば、以前の探索が役に立たず、新しいステージを開始する必要があると感じた場合です。

モデル呼び出し:

tool_use("compact", focus="keep the API design decisions")

トリガーは自動と同じですが、focus パラメーターを使用して、要約するときに何に焦点を当てるかを指示できます。これは実際の戦闘で非常に実用的です。モデルはどの「完了した小さなタスク」がどれであるかを認識しており、ハーネスのヒューリスティックよりも正確です。

どの層が適切ですか?本当か間違っているかの質問

次のシナリオは、マイクロ / 自動 / 手動のどのトリガーがより合理的であるかを決定します。