What is an AI agent?
LangChain Blog は、AI エージェントの定義を「LLM がアプリケーションの制御フローを決定するシステム」と明確化し、その能力を連続スペクトラムとして捉えるべきだと提唱している。
キーポイント
技術的なエージェント定義の提示
著者は AI エージェントを「LLM がアプリケーションの制御フローを決定するシステム」と定義し、単なるチャットボットや静的なワークフローとの違いを明確にしている。
能力の連続スペクトラム概念
エージェントを「完全自律」か「非自律」かの二択で議論するのではなく、Andrew Ng の提案のように、自律性の度合いが段階的に変化するスペクトラムとして捉えるべきだと主張している。
自律性のレベル分類
入力ルーティング（Router）、複数 LLM によるステップ処理、ループ制御（State Machine）など、LLM が決定する範囲に応じて「アジェンシー」の度合いが異なる具体例を挙げている。
重要な引用
An AI agent is a system that uses an LLM to decide the control flow of an application.
Rather than arguing over which work to include or exclude as being a true AI agent, we can acknowledge that there are different degrees to which systems can be agentic.
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントという用語が曖昧に使用されている現状に対し、開発者が実装レベルでシステムを設計する際の共通言語を提供する重要な役割を果たします。特に「自律性のスペクトラム」という概念は、過剰な期待や誤解を防ぎ、現実的な LLM アプリケーションのアーキテクチャ設計（例：Router から State Machine への移行）に直接的な指針を与えるでしょう。
編集コメント
業界全体で「エージェント」という言葉が乱用される中で、開発現場での実装基準を明確にするこの視点は非常に貴重です。自律性を二値ではなく連続値として捉えるアプローチは、今後のシステム設計において重要なパラダイムシフトとなるでしょう。
*「エージェントとは何ですか？」*
この質問は、ほぼ毎日受けます。LangChain では、開発者が LLM アプリケーションを構築するためのツールを提供しており、特に推論エンジンとして機能し、外部のデータや計算リソースと相互作用するアプリケーション向けです。これには、「エージェント」として一般的に呼ばれるシステムも含まれます。
皆が AI エージェントの定義についてわずかに異なる見解を持っているようです。私の定義は、おそらく他の人よりも技術的かもしれません：
💡
AI エージェントとは、LLM を用いてアプリケーションの制御フローを決定するシステムです。
ここでも認めざるを得ませんが、私の定義は完璧ではありません。人々はエージェントを高度で自律的、かつ人間らしいものと考えがちですが、LLM が 2 つの異なるパスの間でルーティングする単純なシステムはどうでしょうか？これは私の技術的な定義には当てはまりますが、エージェントに求められる能力に関する一般的な認識には当てはまりません。*正確に*「エージェントとは何か」を定義するのは難しいのです！
だからこそ、私は先週アンドリュー・エン（Andrew Ng）の ツイート を大変気に入りました。そこでは、「真の AI エージェントとしてどの作業を含めるか・含めないかで議論するのではなく、システムが『エージェント的（agentic）』である度合いには様々な段階があることを認めよう」と提案しています。例えば自動運転車にも自律性のレベルが存在するように、AI エージェントの能力もスペクトラム（連続体）として捉えることができます。私はこの見解に強く同意しており、アンドリューはこれを非常にうまく表現してくれたと思います。将来、「エージェントとは何か」と問われた際には、会話の内容を「『エージェント的』であることの意味」について議論する方向に転換しようと考えています。
エージェント的（agentic）であることの意味は？
私は昨年、LLM システムについて TED 講演を行い、以下のスライドを使って LLM アプリケーションに見られる自律性の異なるレベルについて説明しました。
LLM がシステムの振る舞いをどのように決定するかによって、そのシステムはより「エージェント的（agentic）」になります。
入力を入力して特定のダウンストリームワークフローへルーティングするために LLM を使用することは、ある程度の「エージェント的」な行動を含みます。これは上記の図における「ルーター（Router）」カテゴリーに該当します。
もし複数の LLM を用いて複数のルーティングステップを実行する場合、それは「ルーター」と「状態機械（State Machine）」の間にある位置づけになります。
もしそのステップの一つが、継続するか終了するかを決定することであり、結果としてシステムが完了するまでループして実行されるのであれば、それは状態機械（State Machine）に分類されます。
システムがツールを構築し、それらを記憶した上で、将来のステップでそれらを活用する場合、これは Voyager paper で実装されたものと同様であり、極めてエージェント的（agentic）であり、より高度な自律型エージェント（Autonomous Agent）カテゴリーに分類されます。
これらの「エージェント的」の定義はまだかなり技術的です。私は、LLM システムを設計・記述する際に有用だと考えるため、より技術的な「エージェント的」の定義を好みます。
なぜ「エージェント的」という概念は役立つか？
すべての概念と同様に、「エージェント的」という概念がなぜ必要なのか、またそれが何に役立つのかを問う価値があります。
システムがどの程度エージェント的であるかという考えを持つことは、開発プロセスにおける意思決定（構築、実行、対話、評価、さらには監視を含む）を導くのに役立ちます。
システムがよりエージェント的であればあるほど、オーケストレーションフレームワークの支援は大きくなります。複雑なエージェント型システムを設計する際、これらの概念を考えるための適切な抽象化を持つフレームワークを用意することは、開発速度の向上につながります。このフレームワークには、分岐ロジックとループに対するファーストクラスのサポートが必要です。
システムのアジェント性が強くなるほど、実行は困難になります。複雑さが増し、完了までに長時間を要するタスクも現れます。つまり、ジョブをバックグラウンドで実行したいと考えるようになります。また、途中で発生するエラーに対処するために、耐久性のある実行（durable execution）が必要となります。
システムのアジェント性が強くなるほど、実行中にそのシステムと対話したいという欲求が高まります。内部で何が起こっているかを観察できる能力を求めます。なぜなら、実際にどのステップが踏まれるかは事前に正確に予測できないからです。また、意図した経路から逸脱した場合に軌道修正できるよう、特定の時点でアジェントの状態や指示を変更する能力も必要となります。
システムのアジェント性が強くなるほど、これらの種類のアプリケーション向けに構築された評価フレームワーク（evaluation framework）を求めます。ランダム性の影響が累積するため、評価（evals）は複数回実行する必要があります。最終出力だけでなく中間ステップもテストし、アジェントの動作効率を検証できる能力が必要です。
システムのアジェント性が強くなるほど、新しい種類の監視フレームワークが必要となります。アジェントが踏むすべてのステップを詳細に調査できる能力を求めます。また、アジェントの行動ステップに基づいて実行履歴を検索・照会する能力も必要です。
システムにおけるアジェント機能のスペクトラムを理解し活用することは、開発プロセスの効率性と堅牢性を向上させることができます。
Agentic is new
私がよく考えるのは、この騒ぎの中で「実際に何が新しいのか」という点です。人々が構築している LLM アプリケーションのために、新たなツールやインフラストラクチャが必要なのでしょうか？それとも、LLM 以前の時代からある汎用的なツールとインフラで十分なのでしょうか？
私にとって、アプリケーションがよりアジェンティック（自律的）であるほど、新しいツールとインフラストラクチャを持つことがいっそう重要になります。まさにそれが、エージェントの構築・実行・対話を支援するエージェントオーケストレーター LangGraph と、LLM アプリ向けのテストおよび観測プラットフォーム LangSmith を構築した動機です。アジェンティックなスペクトラムのさらに先へと進むにつれて、支援するツールのエコシステム全体を再考する必要があります。
原文を表示
*“What is an agent?”*
I get asked this question almost daily. At LangChain, we build tools to help developers build LLM applications, especially those that act as a reasoning engines and interact with external sources of data and computation. This includes systems that are commonly referred to as “agents”.
Everyone seems to have a slightly different definition of what an AI agent is. My definition is perhaps more technical than most:
💡
An AI agent is a system that uses an LLM to decide the control flow of an application.
Even here, I’ll admit that my definition is not perfect. People often think of agents as advanced, autonomous, and human-like — but what about a simple system where an LLM routes between two different paths? This fits my technical definition, but not the common perception of what an agent should be capable of. It’s hard to define *exactly* what an agent is!
That’s why I really liked Andrew Ng’s tweet last week. In it he suggests that “rather than arguing over which work to include or exclude as being a true AI agent, we can acknowledge that there are different degrees to which systems can be agentic.” Just like autonomous vehicles, for example, have levels of autonomy, we can also view AI agent capabilities as a spectrum. I really agree with this viewpoint and I think Andrew expressed it nicely. In the future, when I get asked about what an agent is, I will instead turn the conversation to discuss what it means to be “agentic”.
What does it mean to be agentic?
I gave a TED talk last year about LLM systems and used the slide below to talk about the different levels of autonomy present in LLM applications.
A system is more “agentic” the more an LLM decides how the system can behave.
Using an LLM to route inputs into a particular downstream workflow has some small amount of “agentic” behavior. This would fall into the Router category in the above diagram.
If you do use multiple LLMs to do multiple routing steps? This would be somewhere between Router and State Machine.
If one of those steps is then determining whether to continue or finish - effectively allowing the system to run in a loop until finished? That would fall into State Machine.
If the system is building tools, remembering those, and then taking those in future steps? That is similar to what the Voyager paper implemented, and is incredibly agentic, falling into the higher Autonomous Agent category.
These definitions of “agentic” are still pretty technical. I prefer the more technical definition of “agentic” because I think it’s useful when designing and describing LLM systems.
Why is “agentic” a helpful concept?
As with all concepts, it’s worth asking why we even need the concept of “agentic”. What does it help with?
Having an idea of how agentic your system can guide your decision-making during the development process - including building it, running it, interacting with it, evaluating it, and even monitoring it.
The more agentic your system is, the more an orchestration framework will help. If you are designing a complex agentic system, having a framework with the right abstractions for thinking about these concepts can enable faster development. This framework should have first-class support for branching logic and cycles.
The more agentic your system is, the harder it is to run. It will be more and more complex, having some tasks that will take a long time to complete. This means you will want to run jobs as background runs. This also means you want durable execution to handle any errors that occur halfway through.
The more agentic your system is, the more you will want to interact with it while it’s running. You’ll want the ability to observe what is going on inside, since the exact steps taken may not be known ahead of time. You’ll want the ability to modify the state or instructions of the agent at a particular point in time, to nudge it back on track if it’s deviating from the intended path.
The more agentic your system is, the more you will want an evaluation framework built for these types of applications. You’ll want to run evals multiple times, since there is compounding amount of randomness. You’ll want the ability to test not only the final output but also the intermediate steps to test how efficient the agent is behaving.
The more agentic your system is, the more you will want a new type of monitoring framework. You’ll want the ability to drill down into all the steps an agent takes. You’ll also want the ability to query for runs based on steps an agent takes.
Understanding and leveraging the spectrum of agentic capabilities in your system can improve the efficiency and robustness of your development process.
Agentic is new
One thing that I often think about is what is *actually new* in all this craze. Do we need new tooling and new infrastructure for the LLM applications people are building? Or will generic tools and infrastructure from pre-LLM days suffice?
To me, the more agentic your application is, the more critical it is to have new tooling and infrastructure. That’s exactly what motivated us to build LangGraph, the agent orchestrator to help with building, running, and interacting with agents, and LangSmith, the testing and observability platform for LLM apps. As we move further on the agentic spectrum, the entire ecosystem of supportive tooling needs to be reimagined.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み