エージェントゲートウェイシリーズ(第2部/全7部)|エージェント時代のサービスレジストリ

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
マイクロサービスアーキテクチャでは、サービスを見つけるためにDNSを使用します。請求サービスが必要な場合、billing.svc.cluster.localを呼び出します。関係が静的であるため、これはシンプルです。 サービスAがサービスBを呼び出す。
「 エージェントアーキテクチャ」では、関係は動的です。「マネージャーエージェント」がfinance-agent-v1への接続をハードコードするのを望まないでしょう。あなたは次のように尋ねさせたいはずです。 「第3四半期の収益を照会できる機能を見つけてください。」
その機能がツールであることもあります(MCPサーバーを介した直接的なSQLクエリなど)。
その機能が別のエージェントであることもあります(SQL出力を分析する推論エンジンなど)。
この問題を解決するため、TrueFoundryは 統合MCP&エージェントレジストリ」を導入します。これは、 ツール と エージェント を発見可能で相互運用可能なアセットとして扱う単一のカタログです。
1. 統合抽象化レイヤー
この AIエージェントレジストリ 統一的な抽象化レイヤーとして機能します。Pythonスクリプト、LangGraphエージェント、Postgresデータベース、SaaS APIといった異なるリソースを取り込み、それらすべてを標準化されたものとして提示します 機能.
オーケストレーターにとって、「データベース」も「ジュニアアナリストエージェント」も同じに見えます。どちらもJSONスキーマを受け取り、結果を返す単なるエンドポイントだからです。

図1:エージェントレジストリエントリのデータモデル
2. 「ツールとしてのエージェント」パラダイム(MCP経由)
マルチエージェント連携における最大の障壁は、インターフェースの不一致です。LangGraphエージェントは「状態更新」を扱い、CrewAIエージェントは「タスク」を扱います。
TrueFoundryは、モデルコンテキストプロトコル(MCP)を使用してこれを標準化します。
ゲートウェイにエージェントを登録すると、 レジストリ 自動的にMCPインターフェースでラップします。これにより、あなたの洗練された「金融アナリストエージェント」は、システム全体から見ると標準的な関数呼び出しとまったく同じに見えるようになります。
- 内部の実態: メモリ、プランニング、3つのサブエージェントを持つ複雑なPythonエージェント。
- 外部インターフェース: MCPツール定義。
これにより、「マネージャーエージェント」は電卓を呼び出すのと同じくらい簡単に「サブエージェント」を呼び出すことができ、オーケストレーションを単一のプロトコルに簡素化します。

図2:ツールとしてのエージェントの例
3. セマンティックディスカバリー:アイデンティティだけでなく、機能を見つけること
エージェントはどのツールを使うべきかをどうやって知るのでしょうか?名前を知る必要はありません。
その レジストリ ベクトル埋め込みを使用して、自然言語の意図を技術的な機能にマッピングします。
- エージェントの意図: 「サーバーが正常かどうか確認する必要があります。」
- レジストリクエリ: 登録されているすべてのMCPサーバーとエージェントの説明をスキャンします。
- セマンティックマッチ:
- prometheus-mcp (ツール): 「Prometheusからメトリクスをクエリ」 (スコア: 0.92)
- sre-bot-v1 (エージェント): 「インフラストラクチャの問題を診断して修正」 (スコア: 0.88)
ゲートウェイは両方のオプションを返します。呼び出し元のエージェントは、その後決定できます。 生のメトリクス(ツール)が必要か、それとも診断(エージェント)が必要か?
4. 信頼ベースのルーティング: 「私に 検証済みの エキスパートを」
分散型エンタープライズでは、異なるチームによってデプロイされた5つの異なる「コーディングエージェント」が存在する可能性があります。どちらを使用すべきでしょうか?
静的なレジストリは、それらをすべてリストするだけでしょう。TrueFoundryレジストリはステートフルです。それは AIゲートウェイの可観測性 レイヤーに接続し、
成功率、レイテンシー、評価スコアを含む、すべてのアセットのライブパフォーマンスを追跡します。
- coder-agent:v1 (成功率: 88%, レイテンシー: 2秒)
- coder-agent:v2-canary (成功率: 95%, レイテンシー: 5秒)
ルーティングポリシーは レジストリで直接 設定できます。
本番コードの変更については、最新の評価実行で忠実度スコアが90%を超えるエージェントにのみルーティングする。
これにより、オーケストレーションレイヤーが単に 利用可能な エージェントに接続するだけでなく、 有能な エージェントに接続することが保証されます。
5. トポロジー制御:組織図ファイアウォール
数百のエージェントと数千のMCPツールにスケールアップすると、すべてのエージェントがすべてのツールを呼び出せる「スパゲッティメッシュ」のリスクが生じます。これはセキュリティ上の悪夢です。
レジストリは グラフ・トポロジーを適用します。これは、デジタルワーカーの「組織図」として機能します。
- ルール: Public-Support-BotはDocumentation-MCPを呼び出すことが許可されています。
- ルール: Public-Support-Botは 拒否 Payroll-Agentへのアクセス。
このチェックは ディスカバリーレイヤーで行われます。サポートボットが「給与について誰が助けてくれますか?」と尋ねると、レジストリは単に「結果が見つかりません」と返します。見えないものは攻撃できません。
結論
統合MCP&エージェントレジストリは、コグニティブエンタープライズの基盤です。 エージェントとツールを 同等で発見可能な市民として扱い、それらを統合されたセキュリティおよび可観測性レイヤーで包み込むことで、TrueFoundryは、異なる構成要素から複雑で信頼性の高いワークフローを構築することを可能にします。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














.webp)
.webp)


.png)

.png)














