誰もが同じエージェントアーキテクチャに収束しているように感じます:サンドボックス内でループ実行され、ツールを呼び出すLLMです。 Claude Code はおそらくこの最初の著名な現れで、1年半以上前に登場しました。 Deep Agentsである私たちのエージェントハーネスも、1年以上前にローンチしました。このパターンはしばらく前から形成されてきました。
この収束自体に何か悪い点があるわけではありませんが、最近話をした一部のAIエンジニアの間で、「難しい問題はすべて解決済みだ」あるいは「解くべき新しいAIエンジニアリングの問題はもうない」という感覚が生まれています。
人々がこうした感覚を口にするとき、その多くは、エージェントを機能させるために行う コンテキストエンジニアリング の実践について語っているのだと思います。そしてある程度はその通りです。私たちがみな行き着いた、標準的なコンテキストエンジニアリングのソリューションは数多くあります:
- 長いスレッドの要約 コンテキストウィンドウに入りきらなくなったときの対応
- 大きなツール呼び出し結果のオフロード
- 段階的な開示のための Skills
- 多くのツールに対応するための Tool search
- コンテキスト分離のための Subagents
- 主要なツール としてのBash
良いニュースは(私のようなコンテキストエンジニアリング愛好家にとって)、エージェントの能力、あるいは少なくともその使い方にステップ関数的な変化が起きていると感じることです。具体的には、ここ数ヶ月で話をしたすべてのエージェント開発者が、 proactiveで常時稼働、目標指向のエージェントについて考えていました。このエージェントの核心はコーディングエージェントと多くの共通点がありますが、新たな課題のセットも存在します。以下にいくつか挙げます。私たち(LangChain、そして業界全体)はこれらに対する解決策(少なくとも一般的な解決策)を必ずしも持っていないため、これらについて考えることは、ここしばらくで最も楽しい経験でした!
迷惑にならずにどうproactiveであるか:これらのproactiveエージェントはバックグラウンドで動作し、 イベントフィードをlisten するか、ハートビートで起動されます。一方で、ユーザーに物事をプッシュできる必要があります。それが助けになっているという感覚を生み出すからです。他方で、あまりに多くの通知をユーザーにプッシュすると、ユーザーを圧倒してしまうリスクがあります。これを心地よい体験(多すぎず、少なすぎず)に調整することは、依然として難しいコンテキストエンジニアリングの課題です!
メモリ: エージェントのためのメモリ については、開発者たちと長いこと話し合ってきたテーマです。メモリシステムには最終的に2つの部分があります:基盤となるデータ構造と、そのデータを囲むインテリジェンス層(エージェント)です。データ構造は多くの場合かなりシンプルです(ファイル(単一の文字列)。インテリジェンス層で最も難しいのは、何を記憶すべきかを見極めることです。プロアクティブさと同様に、どちらの極端でも失敗しやすい(まったく記憶しないか、細かすぎるレベルの詳細まで記憶してしまうか)。何を記憶するかを決めるこのインテリジェンス層は、それ自体が(単純な)エージェントであることが多いため、何をいつ記憶するかというコンテキストエンジニアリングは依然として未解決の問題です。
非同期 (Async): こうしたエージェントはますます長時間実行されるようになり、それ自体がますます長時間実行される他のシステム(ツール、他のエージェント)とやり取りするようになっています。しかし、ユーザーとやり取りするメインのエージェントが新しいメッセージに応答できる状態を保ちたいケースはほとんどすべてに共通しています。これらが組み合わさることで、より多くの処理が非同期に行われるアーキテクチャへとつながります ツール および サブエージェント。これにより、一連の新たなコンテキストエンジニアリングの課題が生まれます。 通知 メインエージェントは、その作業が終わったときにどうなりますか？メインエージェントがまだ実行中の場合と、すでに完了している場合とで、状況をどう処理しますか？人間の承認を待って一時停止している場合はどうなりますか？
目標トラッキング`: エージェントはタスクの実行からゴールに向かって取り組む段階へと移行しつつあります。例えば次のようなエージェントです。` 磨き上げる その良い例がこれらです。目標をより小さなステップに分解し、実験を実行し、フィードバックを得て、より大きな目標に向けて反復を続けられるエージェントをどう設計するのでしょうか。目標達成のために新しい実験を試みる（そして同じことを繰り返すだけではない）エージェントを実現するのは困難です。小さなタスクだけでなく、広範な目標について考えられるエージェントにするのも困難です。長い時間軸にわたって一貫性を保たせるのも困難です。
アラインメント: 上記に関連する。ゴール設計はそれ自体が困難である。ユーザーがエージェントに裏切られない（ cheat できない）ゴールを設計するのは非常に難しいだろう。エージェントが盲目的にゴールを最適化しようとすれば、達成できるかもしれないが、しかし〜するかもしれない。 私たちが予想できない方法での不正行為例:「コードベースからすべてのバグを取り除く」という古典的な例では、コードベース全体が削除されてしまいます(コードがなければバグもない)。エージェントが目標に集中し続けるだけでなく、その目標に対して過度に最適化しないようにするハーネスをどう設計するか、という問題です。
Browser Use: コーディングエージェントにとって、最も重要なツールはコードを実行できるbashツールでした。これらのより汎用的なエージェントの多くにとって、 ブラウザ そのツールになりつつあります。ブラウザーははるかに複雑で ドライブ 端末以上のものです！画像やDOMを操作しますか？どちらも巨大なオブジェクトです — その周りのコンテキストをどう管理するのでしょうか？これらはふと浮かぶ疑問のほんの一部にすぎません。
数ヶ月前なら、コンテキストエンジニアリングにはそれほど多くの未解決の問いはないと、ある程度同意していたかもしれません。しかし、こうした常に稼働するプロアクティブなエージェントの登場により、まったく新しい一連の課題が生まれてきています。生きているのはなんと素晴らしい時代なのでしょう。