LangChainのDeepAgentsフレームワーク

 (blog.langchain.com)
21 ポイント 投稿者 GN⁺ 2025-08-07 | 1件のコメント | WhatsAppで共有
  • 従来のLLMベースのエージェントは、単にツールを繰り返し呼び出す「浅い（shallow）エージェント」構造が一般的だったが、Deep Agents は複雑で長期的な課題も深く解決する 計画的・構造的なAIエージェント である
  • Deep Research、Manus、Claude Code のような最新のエージェントは、より深いテーマ探索とコンテキスト管理が可能な「ディープエージェント」を実装している
    • 詳細なシステムプロンプト、計画ツール、サブエージェント、ファイルシステムの活用 が「ディープエージェント」の中核
  • LangChainは、誰でも自分のvertical（ドメイン）に合ったdeep agentを簡単に作れるよう、オープンソースパッケージ deepagents を公開
    • カスタムプロンプト・ツール・サブエージェントの設定が可能で、研究・開発などさまざまな分野で応用できる汎用フレームワークを提供

従来のLLMエージェントの限界とDeep Agentsの特徴

  • 従来型エージェント: LLMがループしながらツールだけを呼び出す → 短い文脈、短期・単純な作業にしか適さない
  • Deep Agents: 長期的な目標や複雑なタスクも、自ら分解・計画・追跡・協調できる

Deep Agentsを構成する4つの要素

  1. 詳細なシステムプロンプト

    広告
    • Claude Code などの代表例のように、ツールの使い方や行動例を詳しく明示したプロンプトを活用
    • 複雑な指示とfew-shot例によって、より「深い」思考と実行を促す

  2. 計画（Planning）ツール

    • 実際の機能がなくても、「To-Doリスト」などの計画ツールをルーチンに組み込み、文脈管理と実行力の維持 に役立てる
    • no-op（何もしない動作）であっても、プロンプトに文脈を与える効果がある

  3. サブエージェント（Sub Agents）

    • 下位作業ごとに サブエージェントを生成・分割 し、各エージェントが個別に作業した後に結果を統合
    • 大規模・複雑な問題も並列・分業構造で処理

  4. ファイルシステム

    広告
    • 実際のファイル操作だけでなく、ノート・コンテキスト保存領域 として活用
    • 複数のエージェント・サブエージェントがファイルシステムを共有し、協調と長期的な文脈維持を実現

LangChainのDeep Agentsフレームワーク: deepagents

  • オープンソースのPythonパッケージ（pip install deepagents）で、カスタムプロンプト・ツール・サブエージェントの設定が可能
    • Claude Codeに着想を得たシステムプロンプトを、より汎用的に修正
    • no-opのToDoリスト計画ツール（Claude Codeと同様）
    • サブエージェントの生成とカスタム指定が可能
    • LangGraphの概念を利用した仮想ファイルシステム（エージェントの状態を利用）
  • 例としてdeep research agentのサンプルを提供し、vertical特化エージェントを容易に制作可能

活用例と価値

  • 研究・開発、コード生成、リサーチ、複雑な自動化など、長期・複合的なAI作業 に最適化
  • 詳細なコンテキスト設計と分業構造 により、深みのある結果を生成可能
  • 誰でもドメインに合った「ディープエージェント」を構築でき、AI活用の次の段階を示す

関連記事

1件のコメント

 
GN⁺ 2025-08-07
Hacker Newsのコメント

  • 著者です。最近では claude code、manus、deep research のような一連のエージェントが、長い時間軸にわたる作業を特にうまく実行しているのが印象的です。実際のところ、内部では LLM がループしながらツールを呼び出しています。しかし、何も考えずにこうすると、LLM が複雑または長い作業をきちんとやり遂げられないという問題が起きます。そこで、他のエージェントはこれをどう実現しているのか気になりました。共通して見つかった点は次のとおりです。1) プランニングツールを使う 2) サブエージェントを使う 3) ファイルシステムのようにコンテキストをオフロードする構造を使う 4) 詳細なシステムプロンプトを設計する（プロンプトエンジニアリングは今でも重要です） それぞれは以前からあった手法ですが、実際にエージェント開発をするときに広く使われているやり方ではありません。この組み合わせこそがむしろ重要なインサイトだと思います。フィードバック歓迎です

  • いろいろな意見を見ていると、deep agents という概念も結局は agent + tool の組み合わせと大きくは違わない、という点には同意します。私にとっての核心は次のとおりです。1) ベースとなる知識には優れた LLM が必要 2) LLM を適切に導くためのプロンプトが重要（エージェントに仕立てるため） 3) 別個の判断を必要としない機能はツールとして実装する 4) agent+tool のフローが複雑になったら、フォーカスしたプロンプトと少数のツールを持つサブエージェントに分割して、各ドメインを分離する

    • 結局、最上位のエージェントは何をすべきかを選び、どのエージェントがその作業に適しているかを振り分ける「オーケストレーター」モデルへと発展していく気がします。この構造は再帰的に続けることもできます（例: 各プロダクトごとにエージェントがあり、そのエージェントがフロントエンド/バックエンド作業を担当するエージェントへ分岐する）。この構造では、実際に業務を行うエージェントは限られたコンテキストとツールだけに集中すればよく、上位のエージェントはサブエージェントが何をできるかだけ把握していれば済みます

  • deep agents = プランニングが追加されたエージェント + エージェントツールの組み合わせなので、結局は従来のエージェントと似たようなものだと思います。LangChain は単純な概念までいつも複雑に見せて、わざわざ新しい用語や概念を作って宣伝しているように感じるので残念です。もちろん LangSmith をもっと売りたいなら仕方ないのでしょうが

    • 以前、こういうコンサルティングをしていました。完全に同じだとは言いませんが、本質的にはよくあるやり方です。ありふれたものを芝居がかった形で包み、自分独自の用語や分類法を作って、それを売る戦略です。次の段階は、自分の概念で SEO を埋め尽くすことです。deep * や agent のような人気キーワードに乗ればいいので……。こういうことを考えていると、根本的に企業環境では魂だけ抜かれていく感じがします

  • 私が予想していた結果に近いです。もう MCP サーバーを直接書くのはあまり通用しないことが明らかになってきたので、すばやく波に乗れる新しい方法が必要な状況です。gemini や claude code のように直接エージェントを作ってみるのが最近のトレンドです。参入障壁が低く、ある程度は役に立ち、深い AI の専門知識も不要で、宣伝もしやすい。まるで「cursor for X」方式ですが、むしろもっと速く製品化できます。こうして作られるコーディングエージェントは大量に増えそうですが、今のところ何か新しい感じはあまりしません。それでも、これほど速く始められるなら、直感的に作った claude code クローンの価値はすぐ 0 に収束するだろうという点では前向きに見ています

  • このリポジトリのコードを追いながら分析し続けています https://github.com/ghuntley/claude-code-source-code-deobfuscation 作者が Claude Code をリバースエンジニアリングして、アーキテクチャをうまく説明してくれています。リンクをより良いリポジトリに変更しました

    • これが何を示しているのか説明してもらえますか？ ただものすごく大きい readme とシステムコマンドが見えるだけのようですが

  • rust で汎用 agent cli+library を作っています: https://github.com/fdietze/alors まだ開発初期ですが、すでにこれ自体の開発にも使っています。フィードバック歓迎です

  • 私の見るところ、Jetbrains の Junie が最初に非常に高品質な to do list 機能を書いていて、それがいちばん気に入っていました。有料化されてからは使っていませんが、当時の Junie は遅い代わりに慎重でした。Cursor は問題のないファイルまで繰り返し上書きし、Claude はその中間という感じでした

    • Cursor は todo list 用の専用 UI も提供していて、それを使うよう agent を誘導しています（UX 自体は良いですが、ファイル自体を直接見ることはできません）。amazon の kiro は tasks.md でやるべきことと仕様の両方を管理する方式を使っています。ツールが増えてきたので、自分に合うものを選んで使えばよいです

  • いちばん興味深い部分が完全に隠されています。パースから実行まで、ツールコールをどう管理しているかが肝です

  • sub agent でコンテキストを分離するのが本当の革新ポイントです。残りはただの langgraph react agent です

    • これは価値がありますが、実際に完全に新しいアイデアというわけではありません

  • todo list ツールが no-op だという部分について、もう少し情報があるのか気になります。正確にどう動くのか知りたいです

    • コードで直接見たいなら、私たちが作った Sketch agent は TODO list ツールをこのように活用しています: https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go agent にこれを使わせるのは比較的簡単です。作業の大半は UI で見えるようにするところに費やされます
    • 同じ質問です。どういう意味なのかよく分かりません。ただ、Claude Code が優れている理由としては明らかに見えます
    • 私の考えでは、単なる concat 機能です。実際に有用なプロンプト手法の多くは、実装自体はたいていシンプルです。それだけに TODO という単純なアイデアがかなり遠くまで通用するのは、むしろ驚きです！（本番環境での agent フレームワークは難しいです。例えば、適切な組み合わせと設定は本当に難しく、インフラ面でもマルチテナンシー、マルチスレッディング、ストリーミング、キャンセルなど考えるべきことが多いです）。TODO list が重要だという点には全面的に同意します。louie.ai のセキュリティログ分析コンテストのようなものも、この方法のおかげで非常に高速化します。CoT が数ターンで壊れてしまうのを防げます。面白かった aha moment は、nested todo（A.2.i...）を使うと良いのですが、LLM 側から見るとどうせ線形化されるので、特に難しくなく処理できる点です。私たちは claude code の代わりに、内部的にはこのような plan プロンプトで管理しています: https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
    • ツールコールがあったという事実だけがコンテキストに記録されます。実際に todo list のデータ自体を再取得することはありません
    • 私の理解では、単に TODO list を書けというプロンプト程度だと考えればよさそうです