導入
このシリーズの最初の記事では、AI エージェントとは何か、そしていつそれらを使用するかを定義しました。 今度は、それらを支配するメカニズムの核心に迫る時が来ました。 3つの基本概念 最新のあらゆるエージェント システムのバックボーンを形成します。 OODAループ のために 意思決定構造、 反応パターン 推論と行動の交互の場合、 そして ツール呼び出し 外の世界とのやり取りのために。
これらは抽象的な学術概念ではなく、すべての開発者が実行する実装パターンです。 効果的で信頼性が高く、デバッグ可能なエージェントを構築する方法を習得する必要があります。ランググラフ、CrewAI AutoGen はそれらをすべて内部で実装しますが、理論的な基礎を理解することが重要です。 開発者を区別します。 アメリカ合衆国 ある人からのフレームワーク 理解します 建築家であり、問題が発生したときに解決する方法を知っています。
この記事で学べること
- OODA (Observe-Orient-Decide-Act) ループとその AI システムへの応用
- ReAct パターン: 推論と行動を構造化された方法で交互に行う方法
- ツール呼び出しメカニズム: コンセプトから実装まで
- ReAct、Chain-of-Thought、純粋な関数呼び出しの比較
- 高度なパターン: 思考の木と計画優先
- エージェントを設計するときに避けるべきよくある間違い
OODA ループ: 観察、方向性、決定、行動
ループ ウーダ (観察、指示、決定、行動) は意思決定の枠組みです 大佐が開発した ジョン・ボイド 1970年代のアメリカ空軍の、 元々は戦闘機パイロットの状況下での意思決定をモデル化するためのものでした 高速性と不確実性。ボイドは空中戦で勝ったパイロットはそうではないと観察した。 必然的に最速の飛行機を持っている人、しかしサイクルを完了した人 相手よりも意思決定が早い。
このモデルは、軍事戦略から軍事戦略まで、非常に多用途であることが証明されています。 サイバーセキュリティから人工知能までのビジネス。エージェントシステムに適用され、 OODA ループは、AI エージェントがどのように処理するかを理解するための構造的なフレームワークを提供します。 情報を取得し、意思決定を行います。
OODA ループの 4 つのフェーズ
1.観察する
観察フェーズは次のもので構成されます。 環境からのデータの収集。 AI エージェントの場合、観測ソースには次のものが含まれます。
- ユーザー入力: 受け取ったメッセージ、質問、または指示
- ツールの結果: 外部ツールの呼び出しから返されたデータ (検索結果、APIからのデータ、ファイル内容)
- 記憶の状態: 以前のインタラクションのコンテキスト、 長期記憶に保存される情報
- 環境からのフィードバック: エラー メッセージ、HTTP ステータス コード、 例外、システムメトリクス
- タスクの現在のステータス: どのサブ目標が完了したか、 どれがまだやるべきことなのか
観察フェーズの品質によって、残りのサイクルの品質が決まります。 十分なデータを収集しないか、重要なシグナル (コードなど) を無視するエージェント HTTP エラー 429 レート制限) により、次善の決定が行われます。
2. 方向を定める (方位を把握する)
ボイド氏は、これがループ全体の中で最も重要なフェーズであると考えました。オリエンテーションは次のもので構成されます 文脈を理解して解釈する 観察中に収集されたデータ。 データを持っているだけでは十分ではありません。現在のコンテキストにおいてデータが何を意味するのかを理解する必要があります。
AI エージェントの場合、オリエンテーションには次のものが含まれます。
- 分析: 受信したデータを重要なコンポーネントに分解します。
- パターンマッチング: すでに遭遇した状況と同様の状況を認識する
- 優先順位付け: 何が緊急なのか、何が重要なのか、何が待っていてもよいのかを明確にする
- コンテキストの評価: 新しいデータがタスクの全体像にどのように適合するか
- 情報ギャップの特定: 取得するにはどのような情報が不足していますか 情報に基づいた決定
実際には、このフェーズは次のようになります。 LLM 推論: モデル 完全なコンテキスト (システム プロンプト、履歴、ツールの結果) を分析し、定式化します。 現状の理解。ここでは、システム プロンプトの品質が非常に重要です。 モデルがコンテキストを明示的に考慮して評価するようガイドするプロンプト 代替案を選択し、リスクを特定することで、より効果的なガイダンスが生成されます。
3. 決める（決める）
オリエンテーションに基づいて、エージェントは 実行するアクションを選択します。 決定は次のとおりです。
- ツールを呼び出す: 外部関数を呼び出してデータを取得します または操作を実行する
- 応答を生成する: ユーザー向けの最終出力を生成します。
- 追加入力を要求する: ユーザーに説明を求めます
- 計画を立て直す: 現在のアプローチを放棄して試してください 代替戦略
- 仕上げる: 目的が達成されたと結論付けます (または 利用可能なリソースでは到達できません)
4. 行為
エージェント 決められたことを実行する。このフェーズは意図を変換します 具体的なアクション: ツールが呼び出され、応答が生成され、リクエストが 明確化が定式化されます。アクションの後、ループは観察フェーズから再開されます。 エージェントはアクションの結果を収集し、新しいサイクルを開始します。
AI エージェントに適用される OODA ループ
| OODAフェーズ | AIエージェント | 技術コンポーネント |
|---|---|---|
| 観察する | ユーザー入力、ツールの結果、メモリの状態を収集する | 入力処理、コンテキストの組み立て |
| オリエント | コンテキストを分析し、ギャップを特定し、優先順位を付ける | LLM 推論、システム プロンプト ガイダンス |
| 彼が決める | 選択: ツール呼び出し、最終応答、または入力要求 | LLM 出力の解析、アクションの選択 |
| 活動 | ツールを実行し、出力を生成し、状態を変更します | ツールの実行、応答の生成 |
サイクルタイム: 重要な指標
ボイド氏は、競争上の優位性は単一の製品の品質にあるのではない、と主張した。 決定ですが、 サイクル全体が完了する速度。同じ この原則は AI エージェントに適用されます。つまり、複数の OODA ループを迅速に完了するエージェント、 反復ごとに適応するため、エージェントが到達しようとするよりも効果的です。 単一の長いサイクルで完璧を実現します。
実際には、これは次のようなエージェントを設計することを意味します。 アトミックで高速なツール モノリシックで遅いツールではなく。単一のクエリを迅速に実行し、 ミリ秒単位で結果を返すため、エージェントは迅速に反復処理を行うことができます。 10 の異なるソースからデータを集約し、30 秒かかるツールはサイクル全体をブロックします。
ReAct パターン: 推論 + 行動
パターン 反応する (推理 + 演技)、研究者によって 2022 年に導入 論文「ReAct: Synergizing Reasoning and Acting in Language Models」におけるプリンストンと Google の論文、 これは、AI エージェントの設計における根本的な進歩を表しています。 ReAct より前から存在していました 2 つの別々のアプローチ: 思考の連鎖 (CoT)、機能が向上しました モデルの推論については理解できましたが、外部のアクションやシステムは予測できませんでした。 アクション 計画、行動を実行しましたが、明確な推論はありませんでした。
ReAct は、これら 2 つのアプローチを 1 つの構造化されたループに統合します。 思考のフェーズと行動のフェーズを明示的に交互に行う:
Thought: Devo trovare le vendite globali di EV nel 2025.
Cerchero prima i dati aggregati più recenti.
Action: web_search("global electric vehicle sales 2025 data")
Observation: I risultati mostrano che nel 2025 sono stati venduti
18.2 milioni di EV a livello globale, con una crescita
del 25% rispetto al 2024...
Thought: Ho i dati aggregati. Ora ho bisogno della suddivisione
per produttore per identificare i leader di mercato.
Action: web_search("top EV manufacturers market share 2025")
Observation: BYD guida con il 23% del mercato, seguita da Tesla
con il 18%, Hyundai-Kia con il 9%...
Thought: Ho dati sufficienti per la prima parte del report.
Posso ora sintetizzare le informazioni raccolte
in un formato strutturato per l'utente.
Action: generate_response(report strutturato con dati e trend)
ReAct ループの構造
ReAct ループは、3 つの繰り返しコンポーネントを含む厳密な周期パターンに従います。
- 考え: モデルはその推論を明示的に示します。 これまでに何を知っていますか？彼には何が欠けているのでしょうか？どのツールを使用する必要がありますか?その理由は何ですか?その思いと、 見える エージェント トレース内で、動作を透過的にします。 デバッグ可能。
- アクション: 思考に基づいて、モデルはツールを選択します 特定のパラメータを使用して呼び出されます。アクションは具体的で検証可能であり、制御可能です どのツールがどの引数で呼び出されたか、呼び出しが成功したかどうか。
- 観察: アクションの結果が返されます モデルに。観察はその後の思考の背景の一部となり、 推論を目標に導く継続的なフィードバック ループを作成します。
ReAct ループの擬似コード
def react_loop(user_query, tools, max_iterations=10):
context = [system_prompt, user_query]
for i in range(max_iterations):
# Il modello genera Thought + Action
response = llm.generate(context)
# Parse della risposta
thought = extract_thought(response)
action = extract_action(response)
# Se l'azione è "final_answer", termina il loop
if action.name == "final_answer":
return action.arguments["answer"]
# Esegui il tool
try:
observation = execute_tool(action.name, action.arguments)
except ToolError as e:
observation = f"Errore: {str(e)}"
# Aggiungi thought, action e observation al contesto
context.append(f"Thought: {thought}")
context.append(f"Action: {action.name}({action.arguments})")
context.append(f"Observation: {observation}")
# Limite di iterazioni raggiunto
return "Impossibile completare il task nel limite di iterazioni"
ReAct が推論だけよりもうまく機能する理由
純粋な思考連鎖に対する ReAct の主な利点は、モデルが 彼は自分の内なる知識（つまり、 時代遅れ、不完全、または間違っている可能性があります)。アクションを通じて、モデルは次のことができます。 新鮮な情報を入手する 現実世界から抽出し、それらを使用して洗練します あなた自身の推論。
ReAct パターンの具体的な利点は次のとおりです。
- 推論の透明性: すべての論理ステップがトレース内に表示されます。 エージェントが予期しない結果を生成した場合のデバッグと事後分析を容易にする
- 事実に基づいた根拠: ツールからの観察が推論を固定します 実際のデータに変換し、モデルの幻覚や作話を軽減します。
- 適応性: エージェントは、次の情報に基づいて戦略をリアルタイムで変更できます。 厳格な計画に縛られることなく、行動の結果を重視する
- 優れたパフォーマンス: 実証研究では ReAct が優れていることが示されています CoT 単独と、推論および意思決定のベンチマークに基づいた行動計画単独の両方
ツール呼び出し: AI と現実世界の間の架け橋
Il ツール呼び出し （OpenAIでは「関数呼び出し」とも呼ばれる）の仕組みです。 これを通じて、AI エージェントは外部の世界と具体的に対話します。ツールを呼び出すことなく、 LLM はテキストのみを生成できます。呼び出しツールを使用すると、Web 検索とクエリを実行できます データベース、ファイルの作成、電子メールの送信、API の呼び出しなど。
このメカニズムは、次の 3 つの基本的なステップで機能します。
- モデルは構造化されたツール呼び出しリクエストを生成します: 生産する代わりに フリーテキストの場合、モデルはどのツールをどのツールで呼び出すかを指定する JSON オブジェクトを生成します。 どのパラメータか。モデルは、次のことを判断したときにこの形式を生成するようにトレーニングされています。 外部からのアクションが必要であるということです。
- ランタイムは対応する関数を実行します: フレームワーク (LangGraph、 CrewAI (カスタム ランタイム) はリクエストを受信し、パラメーターを検証し、関数を実行します。 そして結果をキャプチャします。
- 結果はモデルに返されます: ツール出力が追加されます 会話のコンテキストを「観察」として認識し、モデルは会話を続けることができます。 新しい情報をもとに推理すること。
ツールの定義: スキーマ
各ツールは、モデルが理解できる明確なスキーマを使用して定義する必要があります。 スキーマには、ツールの名前、ツールの説明という 3 つの基本要素が含まれています。 自然言語 (LLM が理解するために使用する言語) いつ それを使用してください）、および仕様 パラメータ (LLM が理解するために使用するパラメータ) として それを使ってください）。
{
"name": "search_database",
"description": "Cerca record nel database dei clienti. Usa questo tool quando l'utente chiede informazioni su clienti specifici, ordini o dati storici. Supporta ricerca per nome, email o ID ordine.",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Il termine di ricerca (nome cliente, email o ID ordine)"
},
"filter_type": {
"type": "string",
"enum": ["name", "email", "order_id"],
"description": "Il tipo di campo su cui filtrare"
},
"limit": {
"type": "integer",
"default": 10,
"description": "Numero massimo di risultati da restituire"
}
},
"required": ["query", "filter_type"]
}
}
ツール呼び出しの流れ
モデルがツールの使用を決定した瞬間から、ツール呼び出しの完全なフローを見てみましょう。 結果が返されるまでツール:
1. L'utente chiede: "Trova gli ordini del cliente Mario Rossi"
|
v
2. L'LLM analizza la richiesta e i tool disponibili
|
v
3. L'LLM genera una tool call strutturata:
{
"tool": "search_database",
"arguments": {
"query": "Mario Rossi",
"filter_type": "name",
"limit": 5
}
}
|
v
4. Il runtime:
a) Valida gli argomenti contro lo schema del tool
b) Esegue la funzione search_database("Mario Rossi", "name", 5)
c) Cattura il risultato
|
v
5. Il risultato viene restituito all'LLM:
{
"results": [
{"order_id": "ORD-2024-1542", "date": "2024-03-15", "total": 249.99},
{"order_id": "ORD-2024-1897", "date": "2024-06-22", "total": 89.50}
],
"total_count": 2
}
|
v
6. L'LLM genera la risposta finale per l'utente:
"Ho trovato 2 ordini per Mario Rossi:
- ORD-2024-1542 del 15/03/2024: 249.99 EUR
- ORD-2024-1897 del 22/06/2024: 89.50 EUR"
ツールの説明: 最も重要な要素
La ツールの説明 それはメカニズム全体の中で最も重要な要素です ツール呼び出しの機能ですが、見落とされがちです。 LLM はコードを実行しません。記述を読み取ります。 自然言語で記述され、それにのみ基づいてツールを呼び出すかどうか、いつ呼び出すかを決定します。 その説明について。
効果的な説明には、次の 3 つの質問に答える必要があります。
- ツールは何をするのでしょうか? わかりやすく簡潔な機能説明
- いつ使用しますか? ツールが適切な具体的な使用例 (使用しない場合には暗黙的に)
- 使い方は？ 予期されるパラメータ、制約、形式に関する情報
例: 良い場合と悪い場合の説明
悪い説明: 「データベースを検索してください。」
曖昧すぎます。 LLM は、どのデータベースにどのようなタイプのデータが含まれているか、それが適切な場合には認識しません。 このツールを使用するか、他の利用可能なツールを使用するか、またはクエリの形式を選択します。
良い説明: 「企業顧客データベース内のレコードを検索します。 ユーザーが顧客、注文、または請求書に関する情報を要求する場合は、このツールを使用します。 顧客名 (部分または完全)、電子メール、注文 ID (ORD-YYYY-NNNN 形式) による検索をサポートします。 または請求書番号。日付の降順で並べ替えられた最大 50 件の結果を返します。」
LLM を支援する形式と制限に関する、特定の状況に応じた情報が含まれています。 正しいパラメータを生成します。
比較: ReAct、思考連鎖、関数呼び出し
提示されたパターンの理解を強化するために、表で比較してみましょう。 これは構造的な違い、利点、制限を強調しています。
推論パターン比較表
| 特性 | 思考連鎖 (CoT) | 純粋な関数呼び出し | 反応する |
|---|---|---|---|
| 明示的な推論 | はい (段階的に) | いいえ (暗黙的) | はい (見えると思われる) |
| 外部アクション | No | Si | Si |
| 新しいデータへのアクセス | いいえ (トレーニング データのみ) | はい (ツール経由) | はい (ツール経由) |
| デバッグ可能性 | 高 (痕跡が見える) | 平均 (I/O ツールのみ) | 非常に高い (思考 + 行動) |
| 幻覚の危険性 | 高（接地なし） | 低い (実際のデータ) | 低（根拠＋推論） |
| トークンコスト | 中くらい | ベース | 高 (思考 + 行動 + 観察) |
| 理想的な使用例 | 数学的推論、論理 | APIを使った簡単なタスク | 複雑な複数ステップのタスク |
| 採用 | 高度なエンジニアリングプロンプト | OpenAI 関数呼び出し | LangGraph、最新のエージェント |
パターンの選択は使用例によって異なります。純粋に認知的なタスク（推論）の場合 数学的、論理的分析）、思考連鎖で十分です。単純なタスクの場合、 単一の外部アクション (API の呼び出し、データベースのクエリ) が必要です。 純粋な関数呼び出しは効率的かつ経済的です。必要な複雑なタスクの場合 複数のアクションを伴う反復推論では、ReAct がゴールド スタンダードです。
高度なパターン: 思考の木と計画優先
基本的なパターンに加えて、AI エージェントの分野の研究により、 推論の質と能力を向上させるためのより洗練されたアプローチ 計画の。特に注目すべきは 2 つのパターンです。
思考の木 (ToT)
Il 思考の木、2023年に提案、思考連鎖を拡張 線形チェーンから広告構造まで albero。フォローする代わりに モデルは単一の推論パスを探索します 複数の選択肢 並行して、各ブランチを評価し、最も有望なブランチを選択します。
実際には、これはエージェントが次のことを行うことを意味します。
- 問題を解決するために考えられる戦略をいくつか生成する
- 実行可能性スコアと成功確率を使用して各戦略を評価します。
- 最も有望なブランチを探索しますが、他のブランチはフォールバックとして保持します
- 選択したブランチが失敗した場合は、バックトラックして別のブランチを試してください。
ToT は、解決策が明らかではない問題 (パズル、計画) に特に効果的です。 戦略的、複雑なトレードオフを伴う意思決定）が、計算コストが高くなります ツリーの各ノードに複数の世代が必要になるためです。
計画第一
アプローチ 計画第一 従来の ReAct のロジックを逆にします。代わりに エージェントは思考と行動を段階的に交互に切り替えます。 計画を立てる アクションを実行する前に完了する計画を段階的に実行し、 必要に応じて調整します。
Plan-First フローは次の構造に従います。
[FASE 1: PIANIFICAZIONE]
Input: "Crea un report sulle performance del team Q4 2025"
Piano generato dall'agente:
Step 1: Recuperare i dati di sprint completati Q4 2025
Step 2: Calcolare velocity media e trend
Step 3: Identificare i blockers più frequenti
Step 4: Generare grafici delle metriche chiave
Step 5: Sintetizzare il report in formato strutturato
[FASE 2: ESECUZIONE]
Eseguire il piano step-by-step, con possibilità di:
- Re-pianificare se un step fallisce
- Aggiungere step intermedi se necessario
- Saltare step non più rilevanti
Plan-First は、概要が必要な長くて複雑なタスクに有利です 基本的な。リスクは、当初の計画が間違った仮定に基づいていることです。 実行中のみであり、費用のかかる再計画が必要です。このため、 最新の実装では、Plan-First と ReAct の柔軟性が組み合わされています。 最初は変更されますが、反復のたびに計画を適応させることができます。
OODA、ReAct、ツール呼び出しの間の相互作用
この記事で紹介する 3 つの概念は代替案ではありません。 補完的で相互接続されている。 OODA は意思決定の枠組みを提供します 大まかに言うと、ReAct はその中に推論とアクションのパターンを実装します。 フレームワークであり、ツール呼び出しはアクションを可能にする技術的なメカニズムです。
3 つの概念がどのように統合されるか
| レベル | コンセプト | 役割 |
|---|---|---|
| 戦略的 | OODAループ | 意思決定のフレームワーク: 推論と行動のサイクルをどのように構築するか |
| 戦術的 | パターン反応 | 実装パターン: 思考と行動を明示的に切り替える方法 |
| オペレーティング | ツール呼び出し | 技術的なメカニズム: エージェントが実際に外部アクションを実行する方法 |
たとえば、LangGraph エージェントでは、状態グラフは OODA ループ (各ノード) を実装します。 フェーズに対応)、推論ノードは ReAct (思考-行動-観察) パターンに従います。 そして、アクションはツール呼び出しを通じて具体化されます (モデルは JSON ツール呼び出しを生成し、 ランタイムがそれらを実行します)。設計には 3 つのレベルすべてを理解することが不可欠です 有効性、デバッグ性、保守性を同時に備えたエージェント。
避けるべきよくある間違い
AI エージェントの設計には、有効性を損なう可能性がある特定の落とし穴があります。 システムの信頼性とセキュリティ。ここでは、最も一般的な間違いとその防止方法を紹介します。
エージェント設計で最もよくある 7 つのエラー
-
1. 無限ループ: エージェントは、解決策に収束することなく反復を続けます。
典型的な原因: 終了基準があいまいであるか、存在しません。解決策: 常に設定する
ある
max_iterationsループ検出メカニズムを実装する (最後の N 個のアクションが同一の場合、エラー メッセージが表示されて終了します)。 - 2. あいまいなツールの説明: ツールの説明が正確でない場合、 LLM はそれをいつ使用すればよいかわからない、または不適切に使用する可能性があります。各説明では次のことを指定する必要があります ツールが何をするのか、いつ使用するのか、そしてどのようなパラメーターが期待されるのか。テストの説明 曖昧なクエリは基本的な習慣です。
- 3. 停止条件の欠如: エージェントはいつ作業が完了するかわかりません。 システム プロンプトには、何が構成されているかについての明示的な指示が含まれている必要があります。 正常に完了した場合と、エージェントがループを終了して結果を返す必要がある場合。
- 4. コンテキストのオーバーフロー: ループの各反復により、トークンがコンテキストに追加されます。 何度も反復すると、LLM コンテキスト ウィンドウを超える危険があり、 切り捨てまたはエラー。コンテキスト圧縮戦略を実装する (要約) 以前のイテレーションでは、関連する情報のみを保持します)。
- 5. エラー処理の失敗: ツールが失敗する可能性があります (タイムアウト、 レート制限、無効なデータ）。エージェントはエラーを処理できるように設計されている必要がある 適切に: バックオフ、代替ツール、制御された劣化を使用して再試行します。 部分的な答え。
- 6. 粒度が高すぎる、またはモノリシックすぎるツール: 機能が少なすぎるツール エージェントにあまりにも多くの反復を強いることになります。機能が多すぎるツールは柔軟性を低下させます デバッグが困難になります。最適な粒度は単一の概念、単一の 道具に対する責任。
- 7. ガードレールの不在: 操作上の制限がなく、エージェントは実行できます。 破壊的な行為（データの削除、誤ったメールの送信、不正な購入） 許可されています）。セッションごとのコスト制限、アクションのホワイトリストを常に実装します。 許可、不可逆的なアクションに対する人間の承認ポイント。
結論
この記事では、行動を支配する 3 つの基本的な柱について説明しました。 すべての最新の AI エージェントの。の OODAループ 意思決定の枠組みを提供します 高いレベルで、観察、方向性、決定、行動の継続的なサイクルを構築します。 の 反応パターン 明示的な切り替えを使用してこのフレームワークを実装します エージェントの推論を透明化し、デバッグ可能にする思考と行動。 の ツール呼び出し エージェントを有効にする技術メカニズムを提供します。 意図を現実世界での具体的な操作に変換します。
Tree-of-ThoughtやPlan-Firstなどの高度なパターンも導入し、分析しました。 エージェント設計における最も一般的なエラー。これらの強固な理論的基盤により、 実際の実装に移る準備ができています。
次の記事では、 「LangChain と LangGraph: 状態グラフを使用したエージェントの構築」、 コードを書き始めます。 LangGraph をインストールし、状態グラフを定義する方法を見ていきます。 推論ノードとアクションノードを実装し、最初の動作するエージェントを構築します ツール呼び出しとメモリ付き。コンセプトからコードへ: 旅は続きます。