Agentに任せて走らせる：分解、コンテキスト、記憶

🚧 本章は開発中です。以下はコア論点の概要であり、完全版は今後のバージョンで公開されます。

第1巻では、単一のやり取りにおける品質の問題を解決しました。specを明確に書き、検証の closed-loop control を構築すれば、Agentの単発の成果物を安定して高い水準に保てます。しかしここには暗黙の前提があります。あなたが常にその場にいるということです。各タスクであなた自身が入力を与え、プロセスを監視し、結果を受け取り、次のステップを起動しています。Agentの速度はボトルネックではなく、あなたの帯域幅こそがボトルネックです。一日に3〜4個のタスクを監視するのが限界ですが、Agentは明らかにもっと多くのことができます。

ボトルネックはAgentの能力から人の可用性に移行しました。解決の方向性は明確です。リアルタイムの対話パートナーからタスク設計者・検収者へと変わることです。タスクを委ね、自分は別の仕事に取りかかり、戻ってきたときに利用可能な成果を受け取る。

この転換が直面するコアの構造的制約は context window です。Agentが agentic loop の中で自律的に動作するとき、各イテレーションの入出力がコンテキストに追加されていきます。累積トークンが有効容量を超えると、成果物の品質は緩やかに低下するのではなく、急激に崩壊します。この壁はバグではなく、LLMアーキテクチャの固有特性です。Agentに自律的に実行させるすべての方策は、この制約の下で機能しなければなりません。

この制約に対応するには、3つのレベルの能力が必要です。タスク分解は各実行ブロックの粒度を決定し、各ブロックがコンテキスト崩壊前に完了することを保証します。コンテキストエンジニアリングは各ブロックの context window に何を入れるかを決定し、重要な制約がノイズに埋もれないようにします。セッション横断の永続化は session 間の記憶リセット問題を解決し、次の session が前の session の進捗から継続できるようにします。

この3つの能力は独立したツールボックスではなく、同じ目標に向かって協調しています。数時間かかるタスクをAgentに委ね、自分はその場を離れ、戻ってきたときに検収可能な成果を受け取る。これを実現すれば、効率の天井は「同時にいくつのタスクを監視できるか」ではなく「同時にいくつのタスクを設計・検収できるか」になります。

Harness Engineering Playbook · AgentsZone Community