Agentを走らせる：分解、Context、そしてMemory

最初の3章では、まだAgentの前に座り、対話形式で作業していた。仕様は書かれ、検証システムは整い、単一タスクのclosed loopが完成した。自然な次のステップは、Agentを自律的に走らせることだ。YOLOモードをオンにし、大きなタスクを渡し、コーヒーを買いに行き、戻ってきてコードを回収する。

現実はしばしば悲惨だ。コミュニティにはYOLOモードの失敗談が溢れている。Agentが2時間走り、数千行のコードを生成したが、前半のアーキテクチャ上の決定が後半で暗黙のうちに上書きされ、インターフェース定義が前後で一貫せず、同じ問題が3通りの方法で解決されていた。修正にかかる時間は、自分で書いた方が早かっただろう。AlibabaとSun Yat-sen Universityの研究もこれを裏付けている。超長時間タスクではAgentのパフォーマンスが体系的に低下し、タスクが長くなりcontextが膨張するほど、出力品質の劣化は深刻になる。[citation]

問題はcontext wallだ。Agentの実効的な処理能力にはハードシーリングがあり、十分な実行時間が与えられれば、そのシーリングにぶつかる。しかし、この壁は乗り越えられる。タスク分解は大きなタスクをAgentサイズのチャンクに切り分け、知識の永続化はセッション境界を超えて重要な情報を生かし続ける。これらのテクニックを習得すれば、Agentはセッションや日をまたいでプロジェクトを継続的に推進できる。あなたはAgentのリアルタイムな対話相手から、タスクの設計者・受け入れ者へと移行する。