Agent のコンテキストがウィンドウの 8 割に達する。圧縮が発火し、古いターンから捨てられる。十分後、Agent はさっき読んだファイルをもう一度読み、さっき答えの出た問いをもう一度尋ねる。
閾値が知っていたのは「もう入りきらない」ことだけだった。何を失っても安全かについては、何も知らなかった。
これは長期タスク Agent 設計ノートの第三回である。きっかけは BEACON（浙江大学、arXiv:2605.06078）の精読だった。第一回は停滞検知、第二回はマイルストーン設計を扱った。
まず自分たちの実装から
Orkas はマルチ Agent のデスクトップクライアントで、長いタスクが当たり前の環境だ。だから圧縮は日常的に起きる。実装は token 閾値による発火で、コンテキストがウィンドウの 8 割程度に達したら圧縮する。これを書くまで、そこに問題があるとは誰も思っていなかった。
世の中でよく見る境界は三種類ある。ウィンドウ占有率、対話ターン数、あるいはモデルに要約を書かせて古い内容を置き換える方式。うちは一つ目だ。
最初の二つは内容をまったく見ない。三つ目は見るが、「何が重要か」の判断を丸ごとモデルに委ねている。
三つともいつ捨てなければならないかに答えている。しかし本当に知りたいのは何を捨ててよいかだ。閾値で切れば、捨てられるのは最も古い内容であって、最も重要でない内容ではない。
マイルストーンという境界と、その下にある仮定
前回のマイルストーンなら、この三つのどれよりも良い境界を与えられる。ただしここには落とし穴があり、前回はそこを少し滑らかに書きすぎた。
BEACON にはマイルストーン・マルコフ性という仮定がある。平たく言えば、あるマイルストーンに到達したあと、その先の展開は残りのサブゴールだけで決まり、そこまでどう辿り着いたかには依存しない。鍵を手に入れたあと重要なのはどの扉を開けるかであって、どうやって見つけたかではない。
これは圧縮の許可証のように聞こえる。マイルストーンを越えたら、その手前は畳んでよい、と。
だがこれは仮定であって事実ではない。論文が書いているのは ≈ であって = ではなく、著者はそれが崩れる場面についても議論している。
訓練には十分、圧縮には不十分
同じ仮定、二つの用途、厳しさは一桁違う。
訓練では統計的に成り立てばよい。数千の rollout のうち数十が違反しても、バイアスは平均されて消える。訓練にはさらに軌跡レベルの信号が下支えとして走っており、その層を外すと ALFWorld は 91.4 から 23.4 に落ちる。何もしないより大幅に悪い。
圧縮では各点で、目の前のこの一回について成り立たなければならない。一度でも間違ったものを捨てれば、そのタスクは終わりだ。平均する相手がいない。
だから論文がこの仮定に寄りかかっているからといって、それを圧縮に持ち込んでよいことにはならない。二つの用途がこの仮定に要求しているものは同じではない。
崩れる四つのケース
圧縮方針を考えるとき、私たちはこの四つをチェックリストとして使っている。
1. 途中で積み上がった暗黙の知見。どこかの手順で「この API はタイムスタンプを UTC で返す」と分かったとする。これはどのマイルストーンにも属さないが、その後のすべての手順が必要とする。
2. すでに消費したリソース。token 予算、呼び出し枠、残り時間。マイルストーンは予算を 6 割使ったとは記録しないが、その数字がリトライの可否を決める。
3. 経路依存の副作用。マイルストーンにはリファクタ完了とある。だがデバッグを始めた瞬間、実際にどの 5 ファイルを触ったのかが必要になる。
4. マイルストーン自体が underspecified。四つの中で最も厄介だ。論文のマイルストーンは環境が与える完全な状態で、鍵を持っているかいないか、曖昧さはない。一方、計画の一手順は自然言語の一文にすぎない。「データクレンジング完了」という一文では、その区間で何が起きたのかをまるで覆えない。
では何を持ち越すか
要約だけを残してはいけない。要約はモデルが書くもので、何が重要かを感覚で決めている。
人が決めた固定のフィールド群を残すこと。最低でも四種類。
- ワークスペースの現状：どのファイルを触り、どういう状態にしたか。
- 残りの枠：token、呼び出し回数、時間。
- 確定した事実：あの UTC の件と、以後の判断を左右する同種の結論すべて。
- 未解決の疑問：一度詰まって迂回したが、また当たるかもしれないもの。
上の四つの失敗ケースと突き合わせると、きれいに一対一で対応する。この対応関係こそ、圧縮方針が十分かどうかを判断する最も簡単な方法だ。
このうち半分はほぼタダで手に入る。前回書いたとおり、ホスト側はツール呼び出しのたびに決定的な事実を記録している。ファイルが本当に書き換わったか、コマンドが実際に走ったか。あのデータはマイルストーン検証のために集めたものだが、それはそのままワークスペースのスナップショットなので、モデルに要約し直させることなく圧縮時にそのまま持ち越せる。
難しいのは残り二つだ。確定した事実と未解決の疑問は、今のところモデルが書き残したときにしか存在しない。だからこそ圧縮で真っ先に失われる。
これは議論ではなく計測できる
圧縮のあと、Agent が圧縮で消えたファイルを読み直したり、すでに答えの出た問いを再び尋ねたりしたら、その時点でこの仮定はそのタスクで崩れており、証拠はそこにある。
計測は単純だ。圧縮点より後に読んだファイルパスと、圧縮点より前の記録との積集合を取ればよい。
この数字があれば、「どの種類のタスクなら積極的に圧縮してよく、どれがだめか」は設計段階の説得合戦ではなく、データを引くだけの話になる。シリーズ第一回と同じ筋道だ。まず測り、それから変える。
割り引くべきところ
この仕組みはまだリリースしていない。設計と計測の段階にある。
どのフィールドをどの粒度で残すかは、実際に何が読み直されているかのデータから決めるべきだ。今の時点で決め打ちすると、まず間違える。
そしてこれは数あるやり方の一つでしかない。境界をどこに引き、フィールドをどう定義するかは、プロダクトの形が変われば全く違う答えになりうる。持ち出せるのは四つのチェックリストであって、具体的な答えではない。
シリーズ最終回は自己反省を扱う。Agent がまとめる教訓がなぜ「もっと慎重に」のような空疎な言葉に落ち着いてしまうのか、そしてその入力に何が含まれ何が含まれていないかについての、かなり意外な発見について書く。