概要
ベンダーアダプターパターンは、ドメイン特化型エージェントやツールをShannonに統合することを可能にし、コアコードベースを汚染しません。このパターンは、以下の間にクリーンな分離を維持します:- 汎用Shannonインフラストラクチャ(オープンソースにコミット)
- ベンダー特有の実装(プライベートまたは別のリポジトリに保持)
コア変更なし
Shannonのコアコードベースに変更は不要
クリーンな分離
汎用インフラストラクチャとベンダー特有のロジック
簡単なメンテナンス
ベンダーロジックは別のディレクトリに隔離
優雅なフォールバック
ベンダーモジュールがなくてもShannonは動作
ベンダーアダプタを使用するタイミング
ベンダーアダプタを使用する場合:- 独自/内部APIをドメイン特有の要件と統合する
- OpenAPIツール用のカスタムリクエスト/レスポンス変換が必要
- 特定のビジネスドメイン向けの専門的なエージェントを構築する
- フィールド名の命名規則が内部システムと異なる
- セッションコンテキストからの動的パラメータ注入が必要
- カスタム認証またはヘッダーロジックが必要
- アナリティクスプラットフォーム(メトリクスのエイリアス、時間範囲の正規化)
- Eコマースシステム(製品フィールドのマッピング、SKUの変換)
- CRM統合(連絡先フィールドの正規化)
- 内部マイクロサービス(カスタム認証トークン、テナントID)
- ドメイン特有のデータ検証
アーキテクチャ
ファイル構造
コンポーネントの責任
クイックスタート例
架空のアナリティクスプラットフォーム「DataInsight」の完全なベンダー統合を作成しましょう。1
ベンダーアダプタの作成
python/llm-service/llm_service/tools/vendor_adapters/datainsight.pyを作成します:2
アダプタの登録
python/llm-service/llm_service/tools/vendor_adapters/__init__.pyを編集します:3
設定オーバーレイの作成
config/overlays/shannon.datainsight.yamlを作成します:4
ベンダーロールの作成(オプション)
python/llm-service/llm_service/roles/datainsight/analytics_agent.pyを作成します:注:allowed_toolsの意味は/agent/queryに対して:
- 省略/
null→ ロールプリセットがツールを有効にする可能性あり[]→ ツール無効["name", …]→ これらのツールのみが利用可能(名前は登録されたツールと一致する必要あり)
python/llm-service/llm_service/roles/presets.pyに登録します:5
環境変数の追加
.envに追加します:6
統合のテスト
再構築してテストします:
コンポーネントガイド
1. ベンダーアダプタークラス
目的: ベンダー固有のAPI規約に合わせてリクエスト/レスポンスを変換する 一般的な変換パターン:- フィールドエイリアス:
revenue→total_revenue - メトリックプレフィックス:
users→my:users - 時間範囲の正規化:
{start, end}→{startTime, endTime} - ソート形式の変換:
{field, order}→{column, direction} - フィルタ構造の再構築: リスト → 論理演算子を持つオブジェクト
- デフォルトの注入: セッションコンテキストから不足している必須フィールドを追加
2. 設定オーバーレイ
目的: 基本設定を変更せずにベンダー固有のツール設定を定義する ヘッダー値:"${ENV_VAR}"- 環境変数から解決される- 静的文字列 - そのまま使用
リクエストボディからの動的ヘッダーテンプレート(例:
{{body.field}})はサポートされていません。ヘッダーがボディ/セッションの値に依存する必要がある場合は、次のいずれかを行ってください:- OpenAPI仕様で明示的なヘッダーとして定義し、ツールパラメータとして渡す、または
- ベンダーアダプターを使用してリクエストボディを整形し、ヘッダーは静的/環境駆動のままにする。
3. ベンダー役割
目的: ドメイン固有の知識とツール制限を持つ専門のエージェント テンプレート:注:allowed_toolsを明示的に渡すと、リストに記載されたツールのみがLLMに利用可能になります。ツールを無効にするには空のリスト[]を渡してください。
ベストプラクティス
アダプターを一般化する
アダプターを一般化する
✅ 良い例: フィールド名を変換し、デフォルトを注入❌ 悪い例: アダプター内のビジネスロジック
優雅なフォールバックを使用する
優雅なフォールバックを使用する
変換を文書化する
変換を文書化する
秘密は環境に保管する
秘密は環境に保管する
✅ 良い例:❌ 悪い例:
孤立してテストする
孤立してテストする
変換前に検証する
変換前に検証する
テストと検証
ユニットテストアダプター
統合テスト
トラブルシューティング
アダプターが読み込まれない
アダプターが読み込まれない
症状: ログに「Vendor adapter ” applied」と表示される(空文字)修正:
インポートに失敗する
インポートに失敗する
症状:
ImportError: No module named 'myvendor'修正:変換が適用されない
変換が適用されない
症状: APIが元のボディを受け取る(変換されていない)デバッグ:確認:
__init__.pyにアダプターが登録されている- 設定でベンダー名が一致している
auth_config.vendorフィールドが存在する- アダプターが修正された辞書を返す(Noneではない)
セッションパラメータが注入されない
セッションパラメータが注入されない
症状: アダプター内の
prompt_paramsがNone原因: オーケストレーターがセッションコンテキストを送信していない修正: gRPCリクエストでコンテキストが送信されていることを確認:概要
ベンダーアダプターの利点
- ✅ クリーンな分離: 一般的なコードとベンダー固有のコード
- ✅ Shannonコアの変更は不要
- ✅ 優雅なフォールバックを伴う条件付き読み込み
- ✅ 環境ベースのシークレット管理
- ✅ 隔離してテスト可能
- ✅ メンテナンスと拡張が容易
- ベンダーアダプター - リクエスト/レスポンスの変換
- 設定オーバーレイ - ツールの設定
- ベンダーロール - 専門的なエージェント(オプション)
次のステップ
カスタムツール
カスタムツールの追加方法を学ぶ
Shannonの拡張
他の拡張方法を探る
設定
設定の完全なリファレンス
アーキテクチャ
Shannonのアーキテクチャを理解する