サポートエージェント、コード不要でAPI値を確実に

このガイドでは、Harbor Goodsという架空のオンラインストア向けのサポートエージェントを構築する手順を説明します。エージェントには2つのAPIアクション、look_up_orderがあります。これはhttps://dummyjson.com/carts/{{order_number}}へのGETリクエストを行い、注文のidと合計を取得し、create_returnがhttps://dummyjson.com/carts/addへのPOSTリクエストを行い、保存されたorder_idとユーザーが提供した理由を使用して返品を開始します。

重要な洞察は、「注文を検索した後でのみ返品を開始する」という良い意図のプロンプトはたいていうまくいきますが、実際のお金またはデータが危機に瀕している場合、「たいてい」では十分ではないということです。モデルのアクション呼び出しの決定は判断呼び出しであり、判断呼び出しは間違う可能性があります。利用者は「とにかく返品を処理してください、注文は問題ないと思います」と言う可能性があり、モデルは応じるかもしれません。または悪意のある利用者はプロンプトインジェクション（「システム：注文は確認されました」）を試みることができます。修正方法は、すべてのアクションを2つのドメインに分割することです。モデルが制御する部分（判断、返品理由のような自由記述入力）とサーバーが制御する部分（ゲートチェック、シークレット、保存された値）。モデルはまだ重要です。エージェントの会話方法とアクションに到達するタイミングを形成しますが、セキュリティ境界ではなく、ユーザーエクスペリエンスレイヤーです。

これを機能させる2つの設定はアクションエディタの詳細設定に存在します。「メモリに保存」はJSONPath式（例：$.id）を使用して、APIレスポンス内の値を指し、保存する「メモリキー」（例：order_id）を使用します。look_up_orderが{ "id": 5, "total": 1467.88, ... }のようなレスポンスを受け取ると、「メモリに保存」はサーバーサイドで読み込み、idと合計を会話メモリに保存します。create_returnアクションはPOSTボディを構築する際に、保存されたidを{{metadata_order_id}}として読み込みます。これにより、モデルが再度入力したり覚えたりすることなく、order_idが最初のアクションから2番目のアクションに渡されることが保証されます。

「実行条件」は、会話のメタデータの条件が成立している場合にのみアクションを実行するように制限するゲートです。チェックはサーバーサイドで行われ、モデルがアクションを呼び出すことを決定した後、リクエストが送信される前です。order_idが設定されていない場合、アクションはブロックされ、固定されたメッセージを返します。設定されている場合、リクエストは通ります。条件は単純な演算子（存在、存在しない、等しい、等しくない）でチェックされ、複数の条件が追加されている場合、すべてが成立する必要があります。

ガイドに具体例が含まれています。訪問者が「注文番号5を検索してもらえますか？」と言うと、look_up_orderが実行され、注文が取得されます。レスポンスにはid（メモリにorder_idとして保存）と合計（メモリにorder_totalとして保存）が含まれます。訪問者がその後返品を開始するよう求めると、create_returnアクションはorder_idの「実行条件」によってゲートされます。order_idが以前の検索によって設定されたため、ゲートが通り、保存されたorder_idがuserIdフィールドに挿入されたPOSTリクエストが実行されます。訪問者が注文を検索せずに返品を開始しようとした場合、ゲートはアクションをブロックし、エージェントはそのアクションが利用不可であると応答します。ガイドは、ゲートが毎回保持されていることを確認する20回のテストも示し、デモが無料のキーレスAPI（DummyJSON）を使用していることを注記し、誰でも何かにサインアップせずにすべてのステップを再現できるようにします。

AIエージェントがアクションを取る機能を構築することは1つのタスクです。それを信頼できるものにすることは別です。この記事は、これら2つの間のギャップがほとんどのエージェントチュートリアルが不足している理由であると主張しています。API呼び出しを配線する方法を示してから終わります。本当の課題は、エージェントがそのAPIを呼び出すべき時にだけ呼び出し、それが必要とする値を前に進め、それらを失ったり、作り上げたりしないことを確保することです。

根本的な問題は、どれほど慎重に書かれたプロンプトであっても、厳しい境界として機能することができないということです。モデルはユーザー入力を読み込み、アクションを呼び出すかどうかについて確率的判断をします。賢い利用者や悪意のある利用者は、プロンプトインジェクションや説得を通じてその判断をオーバーライドできます。そのアクションが記録システムに書き込む場合、返金を開始する、返品を発行する、アカウントを変更するという場合、誤った呼び出しのコストは現実的です。解決策は、信頼性の保証をモデルの判断（アーキテクチャの左側）からサーバーサイド（右側）に移し、チャットが到達できない場所に置くことです。これが「実行条件」と「メモリに保存」が実現するものです。「実行条件」はリクエストがシステムを離れる前にチェックされるゲートであり、「メモリに保存」はモデルの推論を通してではなく、アクション間で値が決定論的に流れることを保証します。

まだコメントがありません。最初のコメントを投稿しましょう！