この1年間、私たちは様々な業界で大規模言語モデル（LLM）エージェントを構築するチームと仕事をしてきました。一貫して、最も成功した実装は、複雑なフレームワークや専門的なライブラリを使用せず、シンプルでコンポーザブルなパターンで構築されていることがわかりました。
この投稿では、私たち自身が顧客と協力してエージェントを構築した経験を共有し、効率的なエージェントを構築するための実践的なアドバイスを開発者に提供します。
インテリジェント／エージェント／代理人は、以下の意味と同じである。
エージェントとは？
「エージェント "には様々な定義がある。ある顧客は、エージェントを、複雑なタスクを実行するために様々なツールを使用し、長時間独立して動作できる完全に自律的なシステムと定義している。また、事前に定義されたワークフローに従う、より規定的な実装を説明するために使用する人もいます。Anthropicでは、これらのバリエーションを総称して次のように呼んでいます。 エージェント化されたシステムしかし、そこには建築的な課題がある。 ワークフロー 歌で応える 責任ある立場で代行する 重要な区別がなされた：
- ワークフロー は、あらかじめ定義されたコードパスを通してLLMとツールをオーケストレーションするシステムである。
- 責任ある立場で代行する は、LLMが自身のプロセスとツールの使用を動的に指示し、タスクの達成方法を制御し続けるシステムである。
以下では、これら2つのエージェント化されたシステムについて、さらに詳しく説明する。付録1（「実践におけるエージェント」）では、クライアントがこれらのシステムを利用することで特に価値が高まった2つの分野について説明する。
プロキシを使うべき時（そして使ってはいけない時
LLMでアプリケーションを構築する場合、可能な限りシンプルなソリューションを探し、必要な場合にのみ複雑さを追加することをお勧めします。これは、エージェント化されたシステムを全く構築しないことを意味するかもしれません。プロキシされたシステムは、タスクのパフォーマンスを向上させるためにレイテンシーとコストをトレードオフすることが多く、このトレードオフがそれに値するかどうかを検討する必要があります。
ワークフローは、より複雑なタスクが必要な場合、明確に定義されたタスクに対して予測可能性と一貫性を提供し、エージェントは、柔軟性とモデル駆動型の意思決定スケーリングが必要な場合に優れた性能を発揮する。しかし、多くのアプリケーションでは、単一のLLMコールを最適化し、検索と文脈例を組み合わせることで十分な場合が多い。
フレームワークをいつ、どのように使うか
エージェント化されたシステムの実装を容易にするフレームワークは、以下のように数多くある：
- LangChainからLangGraph；
- アマゾン・ベッドロックの AIエージェントのフレームワーク.;
- リベットLLMワークフロービルダーは、ドラッグ＆ドロップのGUI LLMワークフロービルダーです；
- ベラム複雑なワークフローを構築し、テストするためのもう1つのGUIツール。
これらのフレームワークは、LLMの呼び出し、ツールの定義と解析、呼び出しの連結といった標準的な低レベルのタスクを簡素化することで、開発プロセスを容易にする。しかし、抽象化されたレイヤーが追加される傾向があり、基本的なヒントやレスポンスが不明瞭になり、デバッグが難しくなる。また、実際にはもっとシンプルなセットアップで十分なのに、複雑さを増す方向にスケールが傾いてしまうこともある。
開発者はまずLLMのAPIを直接使うことをお勧めする。フレームワークを使う場合は、基礎となるコードを理解していることを確認してください。フレームワークの基礎となるロジックに関する誤った思い込みは、クライアントエラーの一般的な原因です。
詳細はこちら 料理本 を参照してください。
ビルディングブロック、ワークフロー、エージェント
このセクションでは、プロダクション環境でよく見られるエージェント化されたシステムのパターンを探ります。基本的な構成要素であるEnhanced LLMから始め、単純な組み合わせワークフローから自律エージェントまで、徐々に複雑さを増していきます。
ビルディング・ブロック：強化されたLLM
エージェント化されたシステムの基本的な構成要素は拡張LLMであり、検索、ツール、記憶などの拡張機能を統合している。現在のモデルは、これらの機能を積極的に利用することができる。つまり、独自の検索クエリを生成し、適切なツールを選択し、保持すべき情報を決定することができる。
強化LLM
私たちは、実装の2つの重要な側面に焦点を当てることを推奨します。それは、特定のユースケースに合わせてこれらの機能をカスタマイズすることと、LLMへの使いやすく、十分に文書化されたインタフェースを確実に提供することです。これらの機能拡張は様々な方法で実装することができますが、最近リリースされたモデル・コンテキスト・プロトコルを使用することも一つの方法です。
本稿の残りの部分では、LLMを呼び出すたびにこれらの機能強化にアクセスできると仮定する。
ワークフロー：プロンプト・チェイニング
ヒントチェーンはタスクを一連のステップに分解し、各ラージ言語モデル（LLM）呼び出しが前のステップの出力を処理する。任意の中間ステップで手続き的なチェック（下図の "gate "を参照）を追加することで、プロセスが正しい方向に進んでいることを確認することができる。
キュー・チェーン・ワークフロー
このワークフローをいつ使うか：
このワークフローは、タスクが簡単かつ明確に固定されたサブタスクに分割できる場合に理想的である。主な目的は、各LLMコールをより管理しやすいタスクに合理化することで、待ち時間を短縮しながら精度を向上させることである。
キューチェーンが適用される例
- マーケティングコピーを作成し、それをさまざまな言語に翻訳する。
- 文書のアウトラインを書き、そのアウトラインが一定の基準を満たしているかをチェックし、アウトラインに基づいて文書を書く。
ワークフロー：ルーティング
ルーティングは入力を分類し、特別なフォローアップタスクに誘導する。このワークフローを使用することで、関心の分離と、より特化したプロンプトの構築が可能になる。このワークフローを使用しない場合、あるタイプの入力に対して最適化すると、他の入力のパフォーマンスが低下する可能性がある。
ルーティングワークフロー
このワークフローをいつ使うか：
ルーティングワークフローは、複雑なタスクが別々に処理される必要のある異なるカテゴリーを持ち、分類がLLMやより伝統的な分類モデル／アルゴリズムで正確に処理できる場合にうまく機能する。
ルーティングの適用例：
- さまざまなタイプのカスタマーサービス（一般的な質問、返金要求、テクニカルサポート）を、さまざまな下流プロセス、ヒント、ツールに誘導する。
- 単純な問題やよくある問題を、より小さなモデルにルーティングする(例) クロード 3.5 Haiku）、複雑で一般的でない問題をより強力なモデル（例えばClaude 3.5 Sonnet）にルーティングしてコストとスピードを最適化する。
ワークフロー：並列化（パラレル化）
LLMは時にタスクを並行して処理することができ、その出力はプログラムによって集約される。並列化ワークフローの主なバリエーションは2つある：
- セクション分け： タスクを、並行して実行できる独立したサブタスクに分解する。
- 投票する 同じタスクを複数回実行し、多様な出力を得る。
並列化されたワークフロー
このワークフローをいつ使うか：
並列化は、分割されたサブタスクを並列処理することでスピードアップを図る場合や、より信頼性の高い結果を得るために複数の視点や試みが必要な場合に有効である。複数の考慮事項がある複雑なタスクの場合、各考慮事項は通常、別々のLLMコールで処理する方が、各特定の側面に集中できる。
パラレリゼーションが適用される例：
- セクション分け：
- 1つのモデルインスタンスがユーザークエリを処理し、もう1つのモデルインスタンスが不適切なコンテンツやリクエストのスクリーニングを行うセーフガードを実装する。これは通常、同じLLMコールにガードとコアレスポンスの両方を処理させるよりも良い方法です。
- LLM性能の自動評価。各LLMコールは、与えられた手がかりに対するモデルの性能の異なる側面を評価する。
- 投票する
- コードの脆弱性をレビューし、さまざまなプロンプトを通じて何度もコードをチェックし、見つかった問題にフラグを立てる。
- コンテンツが不適切であるかどうかを評価し、異なる側面を評価するために複数のプロンプトを使用したり、誤検出と脱落のバランスをとるために異なる投票しきい値を要求したりする。
ワークフロー：オーケストレーター・ワーカー
コーディネータとワーカーのワークフローでは、センターLLMがタスクを動的に分解し、ワーカーLLMに委譲し、その結果を合成する。
コーディネーターとワーカーのワークフロー
このワークフローをいつ使うか：
このワークフローは、タスクが複雑で、必要なサブタスクが予測できない場合に非常に適している（たとえば、コーディングでは、変更するファイルの数や各ファイルの変更内容が特定のタスクに依存する可能性がある）。並列化ワークフローと似ていますが、主な違いは柔軟性です。サブタスクは事前に定義されているのではなく、特定の入力に基づいてコーディネーターが決定します。
コーディネーターとワーカーの応用例：
- 一度に複数のファイルに複雑な変更を加えるコーディング製品。
- 複数の情報源から情報を収集・分析し、関連する可能性のある情報を見つける検索タスク。
ワークフロー：評価者-最適化者
評価者-最適化者のワークフローでは、一方の大規模言語モデル（LLM）呼び出しが応答を生成し、他方が評価とフィードバックを提供し、ループを形成する。
評価者-最適化者ワークフロー
このワークフローをいつ使うか： ワークフローが特に効果的なのは、明確な評価基準があり、反復的な最適化が測定可能な価値をもたらす場合である。適用可能な2つの特徴は、第一に、人間がフィードバックを表明することでLLMの応答が大幅に改善されること、第二に、LLMがそのようなフィードバックを提供できることである。これは、人間のライターが洗練された文書を書くときに経験するような、反復的な執筆プロセスに似ている。
エバリュエータ・オプティマイザの適用例：
- 文芸翻訳では、翻訳者のLLMは当初すべてのニュアンスを把握できないかもしれないが、評価者のLLMは有益な批評を提供できる。
- 包括的な情報を収集するために何度も検索と分析を繰り返す必要があり、さらに検索が必要かどうかを評価者が判断する複雑な検索タスク。
インテリゲンチア／エージェント
エージェント(Agent)は、複雑な入力の理解、推論と計画、ツールの確実な使用、エラーからの回復などの主要な能力においてLLMが成熟するにつれて、徐々に生産現場に現れてきている。エージェントは、人間のユーザーからの指示、あるいは対話的な議論を通じて作業を開始する。タスクが明確な場合、エージェントは独自に計画を立て、操作し、より多くの情報や判断のために人間に戻ることもある。実行中、エージェントはその進捗を評価するために、各ステップで環境から「実際の情報」（例えば、ツール呼び出しやコード実行の結果）を取得しなければならない。エージェントは、人間のフィードバックを得るために、チェックポイントや障害物に遭遇したときに一時停止することがある。タスクは通常完了時に終了するが、制御を維持するために停止条件（最大反復回数など）を含むことが多い。
エージェントは複雑なタスクを処理することができるが、その実装は通常比較的単純である。それらは多くの場合、ツールを使用するための環境フィードバックループに基づいた大規模な言語モデルに過ぎない。したがって、ツールセットとそのドキュメントの設計は、明確でよく考えられたものである必要がある。ツール開発のベストプラクティスについては、付録2（「ツールのヒントエンジニアリング」）で詳しく説明する。
自律エージェント
いつプロキシを使うか： エージェントは、必要なステップ数が予測できず、固定パスがハードコードできないようなオープンエンドな問題に使うことができる。LLMは複数ラウンドの操作を必要とすることがあるので、その意思決定能力にある程度の信頼が必要である。エージェントの自律性は、信頼できる環境でのタスクのスケーリングに適している。
エージェントの自律性は、より高いコストと潜在的なエラー蓄積のリスクを意味する。適切なセキュリティ対策が施されたサンドボックス環境での広範なテストを推奨する。
プロキシの使用例：
以下の例は、私たちが実際に実装したものです：
- タスク記述に従って複数のファイルを編集するSWEベンチタスクを解くためのコーディングエージェント；
- 私たちの "コンピューター使用 "の参照実現この場合、クロードはコンピューターを使ってタスクをこなした。
コーディング・エージェントのハイレベル・プロセス
これらのモデルを組み合わせてカスタマイズする
これらのビルディング・ブロックは必須ではない。開発者がさまざまなユースケースに適応し、組み合わせることができる一般的なパターンである。他のLLM機能と同様に、成功の鍵はパフォーマンスを測定し、実装を繰り返すことです。繰り返しになるが、複雑さを追加することは、それが結果を著しく改善する場合にのみ検討すべきである。
抄録
大規模言語モデリング（LLM）分野での成功は、最も複雑なシステムを構築することではなく、ニーズに最も適したシステムを構築することです。シンプルなヒントから始め、徹底的な評価を通じて最適化し、シンプルなソリューションがニーズを満たせない場合にのみ、マルチステップエージェントシステムを追加する。
プロキシを導入する際、私たちは3つの基本原則に従っている：
- エージェントの設計を維持する シンプルさ .
- プランニングのステップに優先順位をつける。 透明性 .
- 詳細なツール ドキュメンテーションとテスト エージェント・コンピュータ・インターフェース（ACI）を慎重に設計すること。
フレームワークは、素早く始めるのに役立ちますが、本番環境に移行する際には、抽象化レイヤを減らし、ベースコンポーネントで構築することを躊躇しないでください。これらの原則に従うことで、強力なだけでなく、信頼性、保守性、そしてユーザから信頼されるエージェントを作成することができます。
礼状
この記事はErik SchluntzとBarry Zhangによって書かれました。この記事は、Anthropicでエージェントを構築した経験と、お客様から共有された貴重な洞察に基づいています。
付録1：プロキシの実用例
我々の顧客との共同作業により、AIエージェントの特に有望な2つの応用例が明らかになり、上述のパターンの実用的価値が実証された。これらのアプリケーションは、対話と行動の組み合わせを必要とし、明確な成功基準があり、フィードバックループをサポートし、効果的な人間による監督を可能にするタスクにおいて、エージェントが最も価値を発揮することを示している。
A. クライアント・サポート
カスタマーサポートは、使い慣れたチャットボットインターフェイスとツール統合のための強化された機能を兼ね備えています。このシナリオは、よりオープンなエージェントに最適です：
- 外部情報へのアクセスやアクションの実行を必要としながらも、自然に対話の流れに沿ったインタラクションをサポートする；
- 顧客データ、注文履歴、ナレッジベース記事を抽出するためのツールを統合することができる；
- 払い戻しの発行や作業指示の更新などの）オペレーションは、プログラムで処理することができる；
- 成功は、ユーザーが定義したソリューションによって明確に測定することができる。
いくつかの会社は、解決に成功したケースにのみ料金を請求する利用ベースの価格設定モデルを通じて、このアプローチが実行可能であることを実証し、代理店の有効性に対する自信を示している。
B. プログラミング・エージェント
ソフトウェア開発の分野では、コード補完から自律的な問題解決へと発展し、LLM機能の大きな可能性が示されている。エージェントが特に効果的なのは
- コードソリューションは、自動テストによって検証することができる；
- エージェントは、テスト結果をフィードバックとして使用し、ソリューションを反復することができる；
- 問題点は明確で構造化されている；
- アウトプットの質は客観的に測定できる。
私たちの実装では、プロキシはプルリクエストの記述を SWEベンチ検証済み ベンチマークにおける実際のGitHubの問題しかし、自動化されたテストは機能の検証に役立ちますが、ソリューションがより広いシステム要件を満たしていることを確認するためには、やはり手作業によるレビューが欠かせません。
付録2：ツールチップ・プロジェクト
どのようなエージェントシステムを構築するにしても、ツールはエージェントの重要な部分でしょう。ツールは、クロードが外部のサービスやAPIと対話することを可能にします。Claudeが応答するとき、もしツールを呼び出す予定であれば、API応答に ツール使用ブロック .ツールの定義と仕様は、全体的なプロンプトと同様に、プロンプトエンジニアリングの対象となるべきである。この付録では、ツールをどのようにヒン トエンジニアリングできるかを簡単に説明する。
通常、同じ操作を指定するには、いくつかの方法がある。たとえば、diffを書くことでファイルの編集を指定したり、ファイル全体を書き換えることで編集を指定したりできる。構造化された出力の場合、マークダウンでコードを返すことも、JSONでコードを返すこともできる。ソフトウェアエンジニアリングでは、これらの違いは化粧品的なものであり、損失なく相互に変換することができる。しかし、いくつかのフォーマットは、LLMにとって他のフォーマットよりも書くのが難しい。例えば、diffを書くには、新しいコードが書かれる前に、ブロックヘッダの何行目が変更されるかを知る必要がある。JSONでコードを書くには（マークダウンとは対照的に）、改行と引用符のエスケープを追加する必要がある。
ツールのフォーマットに関する提言は以下の通り：
- モデルに十分な トークン マンネリに陥らないように "考える"。
- 書式は、モデルがインターネット上で自然に目にするテキストに近づけてください。
- 何千行ものコードを正確に計算しなければならないとか、書いたコードをエスケープしなければならないとか、フォーマットに「余計な負担」がかからないようにすること。
経験則によれば、ヒューマン・コンピューター・インターフェース（HCI）にどれだけの労力が費やされているかを考慮し、また、良いものを作ることを計画することである。 責任ある立場で代行する -コンピュータ・インターフェース（ACI）にも同等の労力を費やす。以下はいくつかの提案である：
- モデルの観点から考える。説明とパラメータから、このツールを使うことは明らかだろうか？注意深く考える必要があるなら、それはおそらくモデルにも当てはまる。良いツールの定義には通常、使用例、境界ケース、入力フォーマット要件、他のツールとの明確な境界が含まれる。
- パラメーターの名前や説明を変更して、よりわかりやすくするにはどうしたらいいでしょうか？これは、チームの若手開発者のために優れたドキュメントノート（docstring）を書くことと同じだと考えてください。これは、多くの似たようなツールを使うときには特に重要です。
- モデルがツールをどのように使用するかをテストする：ワークベンチで多くのサンプル入力を実行し、モデルがどのような間違いを犯すかを観察し、反復する。
- ポカヨケ あなたのツールパラメータを変更して、ミスをしにくくする。
SWE-bench用のエージェントを構築する際、プロンプト全体の最適化よりもツールの最適化に多くの時間を費やしました。例えば、相対ファイルパスを使用するツールは、エージェントがルートディレクトリから移動したときにエラーが発生しやすいことがわかりました。これを修正するために、常に絶対ファイルパスを要求するようにツールを変更した。
