【要約】LangChainとLangGraphの違いを理解するために、ReActエージェントを自分で組んでみた [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMを用いたエージェント開発において、開発者は既存の仕組みによる制御の限界という課題に直面する。LangChainのAgentExecutorを使用する場合、以下の問題が生じる。
- ・ループ処理がブラックボックス化されており、内部挙動の把握が困難である。
- ・max_iterationsのような粗いパラメータ制御しかできず、状態に応じた細かな分岐が不可能である。
- ・ループの途中に人間の承認ステップを挟むなどの、複雑な制御が困難である。
// Approach
筆者は、LangGraphの基本要素を用いてReActエージェントをゼロから再構築するアプローチをとった。具体的には、以下のステップでグラフ構造を定義している。
- ・State（会話履歴等のデータ構造）の定義。
- ・Node（Python関数による処理）の実装。
- ・Edge（処理の遷移）による制御フローの構築。
- ・add_conditional_edgesを用いた、LLMのtool_callsに基づく動的な条件分岐の実装。
- ・builder.add_edge("tools", "call_model")による、ツール実行後のループ構造の明示。
// Result
LangGraphを用いることで、LLMの判断に基づいた柔軟なループ処理が可能になった。得られた成果は以下の通りである。
- ・LangChainのDAG（非巡回グラフ）の制約を打破し、循環的なワークフローを実現した。
- ・Stateの内容に基づき、次に実行するNodeを完全に制御可能にした。
- ・最新のLangChainエージェント機能が、内部的にLangGraphをランタイムとして利用していることを確認した。
Senior Engineer Insight
> 実戦投入の観点では、LangGraphの採用は「制御性」と「デバッグ性」の向上に直結する。AgentExecutorのようなブラックボックスは、大規模システムでは予期せぬ挙動の温床となる。LangGraphにより、状態遷移を明示的に記述できることは、複雑なビジネスロジックをLLMに組み込む際の必須条件だ。ただし、グラフ設計の複雑化による開発コスト増には留意すべきである。