AIエージェントフレームワーク: 1つのAPIを複数のモデルに接続

AIエージェントフレームワークは、チームがエージェントの行動を定義する場所です：目標、ツール、メモリ、引き継ぎ、ループ、そしてエージェントが停止すべきタイミングのルール。しかし、モデルアクセス層は別の決定事項です。すべてのエージェントフレームワークが1つのプロバイダーに直接接続されている場合、製品はそのプロバイダーの価格設定、レート制限、障害、モデル変更、およびアカウントルールを引き継ぎます。.

そのため、AIエージェントフレームワークは、フレームワークが1つの安定したモデルAPIを呼び出し、モデル層が選択、ルーティング、フェイルオーバー、使用状況の可視性、および請求を処理する場合により良く機能します。ShareAIはその層に適しています。エージェントアプリケーションはShareAIの外部に留まり、ShareAIは開発者に150以上のモデル、マーケットプレイスシグナル、トークンごとの使用料金、およびエージェントトラフィックが収益化可能になるべき場合のBuilderパスを提供します。.

なぜAIエージェントフレームワークにモデルアクセス層が必要なのか

エージェントフレームワークは、作業を定義するのを助けるべきです。すべてのモデル呼び出し、ツールステップ、およびフォールバックの決定を1つのハードコードされたプロバイダーパスに強制するべきではありません。.

本番環境のエージェントは通常、異なる種類のモデル呼び出しを持っています。プランナーはより強力な推論を必要とするかもしれません。分類器は低コストと低遅延を必要とするかもしれません。要約器はより安価なルートを必要とするかもしれません。顧客に見える回答は、より高品質なモデルとより安全なフォールバックを必要とするかもしれません。これらすべてのステップを1つのデフォルトモデルとして扱うと、コストと信頼性の管理が難しくなります。.

ShareAIはアプリケーションに安定したモデル層を提供します。開発者は モデルを比較する, オプションをテストし、1つのAPIを通じてトラフィックをルーティングすることができ、すべてのフレームワークやエージェントステップごとに個別のプロバイダー統合を維持する必要がありません。.

基本的な接続パターン

ほとんどの統合は同じパターンに従います：

• エージェントフレームワークをワークフローのロジック、ツール、および状態の管理に責任を持たせます。.
• フレームワークのモデルクライアントをShareAIのチャット補完エンドポイントに向けます。.
• サーバーサイド環境からShareAIのAPIキーを使用します。.
• 各エージェントステップに適したモデルルートを選択します。.
• ローンチ前にユーザー、ワークスペース、機能、またはエージェントルートごとに使用状況を記録します。.

このパターンは、フレームワークがすでにOpenAI互換のチャットモデルクライアントをサポートしている場合に特に便利です。LangChainは、ChatOpenAI統合が設定可能なベースURLを使用できることを文書化しており、これはプロキシ、ゲートウェイ、または互換性のあるモデルAPIを通じてルーティングする際に多くのチームが使用するパターンです。 LangChain ChatOpenAI ドキュメント.

ステップ 1: ShareAI リクエストを証明する

フレームワークの設定を変更する前に、サーバー側で直接リクエストを1回行います。これにより、認証情報、モデル選択、レスポンス形式のクリーンな基準が得られます。.

curl -X POST "https://api.shareai.now/v1/chat/completions" \"

キーはサーバーに保持してください。ブラウザコード、公開リポジトリ、クライアントサイドプラグイン、または共有エージェントテンプレートで公開しないでください。リクエストが成功したら、同じエンドポイントとキーをフレームワーク設定に移動します。.

ステップ 2: フレームワークを ShareAI に向ける

コードファーストのフレームワークでは、通常、ベースURL、APIキー、モデル名のパターンが使用されます。LangChainでは、次のようになります:

import os

環境変数を使用するツールの場合、フレームワークのモデルAPI変数をShareAIキーとベースURLに設定し、デプロイ環境でワーカーまたはエージェントランタイムを再起動します。.

SHAREAI_API_KEY="your-server-side-key"

ビジュアルツールの場合、モデルプロバイダー設定またはカスタムプロバイダー設定を探します。たとえば、Difyのドキュメントでは、システムプロバイダーとカスタムプロバイダーをモデルプロバイダー設定で分けています: Dify モデルプロバイダー ドキュメント. 製品によって正確なラベルは異なりますが、実際の入力項目は通常同じです: キー、エンドポイント、モデル、使用範囲。.

ステップ 3: タスクごとにエージェントルートを分割する

フレームワークがShareAIを呼び出せるようになったら、習慣的にすべてのステップを同じモデルに送信するのを避けてください。より良い設定は、ジョブタイプごとにモデルルートを割り当てることです。.

• ルート計画: 分解、ツール選択、長い推論に強いモデルを使用します。.
• 高速ルート: 分類、書き換え、抽出、またはフォーマットに低コストモデルを使用します。.
• 顧客向けルート: 最終的な回答において品質、遅延、信頼性のバランスが最適なモデルを使用します。.
• フォールバックルート: 優先ルートが劣化した場合に同じタスクを完了できるバックアップモデルを選択します。.

これがワンAPIアプローチが役立つ場面です。フレームワークはプロバイダーの決定ごとに別々の統合を必要としません。アプリケーションは価格、遅延、可用性、または品質の変化に応じてチームがルートを変更しても安定した呼び出しパターンを維持できます。.

すでに複数のエージェントを運用している場合、これをコード設定だけでなく運用モデルの一部として扱ってください。 AIエージェントフリート運用 ガイドは、1つのエージェントが複数になるときにルーティング、価格設定、所有権がどのように適合するかを説明します。.

ビルダーモネタイズの適合場所

一部のエージェントワークフローは内部コストセンターです。他は顧客向けの製品機能です。ビルダーがShareAI外でアプリ、プラグイン、ワークフロー、チャットボット、またはエージェント製品を所有している場合、そのエージェントトラフィックは使用量ベースのビジネスモデルの一部になる可能性があります。.

ビルダーは引き続きShareAI外でアプリケーションを構築し所有します。ShareAIはルーティングされたAI推論使用、ルーティングされた使用に対する顧客支払い、マージンまたは追加料金設定、生成された収益に基づく月次ビルダー支払いを処理します。.

これはエージェントフレームワークにとって重要です。なぜならエージェントは不均一な使用を生み出す可能性があるからです。ある顧客は月に数回のサポート要約を実行するかもしれません。別の顧客は数千回の研究、トリアージ、ワークフロー呼び出しを実行するかもしれません。ShareAIビルダーモネタイズを使用すると、ビルダーはAIトラフィックをShareAI経由でルーティングし、マージンを設定し、使用量の多い顧客に生成された推論の費用を支払わせることができます。.

商業面をマッピングする準備ができたら、 ビルダーコンソール. を開いてください。実装計画のために、 ShareAIのドキュメント を近くに置いてください。.

AIエージェントフレームワークのための生産チェックリストを保持してください。

• ShareAI APIキーをサーバー側に保持してください。.
• 各エージェントルートに名前を付けてから起動してください。.
• 顧客、ワークスペース、機能、またはエージェントごとに使用状況を追跡します。.
• 高度な推論ルートと低コストのユーティリティルートを分けてください。.
• 少なくとも1つのバックアップモデルパスでフレームワークをテストしてください。.
• モデル、遅延、トークン使用量、エラー理由、最終ルートを記録してください。.
• プロバイダーキーをプロンプトやエクスポートされたエージェントテンプレート内に入れないでください。.
• トラフィックが増加する前に、どのエージェントステップが顧客請求可能かを決定してください。.

最小限の有用な展開は、1つのエージェント、1つのルート、1つのバックアップ、1つの使用ラベルです。そのパスが測定可能になったら、次のエージェントステップにパターンを拡張してください。.

よくある質問

AIエージェントフレームワークとは何ですか？

AIエージェントフレームワークは、開発者がエージェントの動作、ツール、メモリ、ワークフロー、状態、実行ループを定義するのを支援します。それは、各リクエストにどのモデルを使用するかを決定するモデルアクセスレイヤーとは異なります。.

なぜAIエージェントフレームワークを1つのAPIに接続するのですか？

1つのAPIはモデルアクセスを変更しやすくします。チームは異なるエージェントステップを異なるモデルにルーティングしたり、市場のシグナルを比較したり、1つのプロバイダー統合への依存を減らすことができます。.

ShareAIはAIエージェントフレームワークですか？

いいえ。ShareAIはAIマーケットプレイスおよびAPIです。それはエージェントアプリケーションを構築しません。エージェントフレームワークの背後に配置され、モデルアクセス、ルーティング、使用状況、請求、収益化レイヤーとして機能します。.

ShareAIをLangChainと一緒に使用できますか？

はい、LangChainの統合がShareAIのチャット補完エンドポイントをShareAI APIキーとサポートされているモデル名で呼び出すように設定されている場合です。完全なチェーンに組み込む前に、直接APIリクエストをテストしてください。.

ビジュアルエージェントビルダーはこのパターンを使用できますか？

多くの場合、はい。ビジュアルツールがカスタムモデルプロバイダーまたはOpenAI互換エンドポイントをサポートしている場合、設定は通常、エンドポイント、APIキー、モデル名、およびツールがプロバイダークレデンシャルを保存する場所に帰着します。.

異なるエージェントステップに適したモデルをどのように選択すればよいですか？

仕事から始めてください。計画や高価値の応答には強力なモデルを使用し、単純な分類やフォーマットには低コストのモデルを使用し、静かに失敗できないステップにはバックアップルートを用意してください。.

フェイルオーバーはAIエージェントにどのように役立ちますか？

フェイルオーバーは、優先ルートが利用できない、遅い、高価すぎる、またはリクエストに適さない場合に、エージェントに別のモデルパスを提供します。これは、運用トラフィックが増加する前にテストされた場合に最も有用です。.

ビルダーはエージェントフレームワークの使用を収益化できますか？

はい、ビルダーがShareAI外部でアプリ、ワークフロー、プラグイン、チャットボット、またはエージェント製品を所有し、そのAI推論トラフィックをShareAI経由でルーティングする場合です。ビルダーはそのトラフィックに対してマージンまたは追加料金を設定できます。.

ルーティングされたエージェント使用料は誰が支払いますか？

ビルダーモデルでは、ルーティングされたAI使用を生成する顧客、ワークスペース、ユーザー、またはアカウントがその使用料をShareAIに支払います。ShareAIは、設定されたマージンまたは追加料金から生成された収益に基づいて、ビルダーに毎月支払います。.

プロバイダーとビルダーは同じ方法で収益を得ますか？

いいえ。ビルダーは、ShareAIを通じてルーティングするアプリケーショントラフィックから収益を得ます。プロバイダーは、ShareAIネットワークに適格な計算能力を提供することで、承認されたプロバイダープログラムを通じて収益を得ます。.

ローンチ前に何を追跡すべきですか？

エージェント名、ユーザーまたはワークスペース、モデルルート、レイテンシー、トークン使用量、エラー率、フォールバックイベント、および呼び出しをトリガーした機能または顧客アクションを追跡してください。そのデータは、後の価格設定やルーティングの決定を非常に容易にします。.