Agentgateway для LLM, MCP и A2A: Когда единая плоскость данных ИИ оказывает помощь
В чём отличие Agentgateway от прокси, основанных исключительно на LLM: обнаружение MCP, отслеживание A2A, маршрутизация, безопасность, OpenTelemetry и управление затратами, а также когда стоит его использовать, а когда — пропустить.
Команды, разрабатывающие платформы с более чем одним конечным точкой модели, часто сталкиваются с множеством компонентов: поставщиками LLM, серверами инструментов и автономными агентами, у каждого из которых своя схема входного трафика. Прокси, специализированные на LLM, такие как Bifrost или LiteLLM, помогают с завершением чатов, но оставляют трафик между агентами и интерфейсы инструментов MCP как отдельные проблемы.
Agentgateway предназначен для устранения этой проблемы: это высокопроизводительный шлюз для трафика, ориентированного на ИИ, а не просто классический HTTP-прокси для LLM. В следующих разделах рассматривается, что делает его уникальным, как проходит быстрая настройка, какие параметры управления важны и когда стоит его использовать, а когда — пропустить.
Что делает Agentgateway уникальным: за пределами прокси для LLM
Основное преимущество заключается в нативном понимании протоколов, ориентированных на агентов, наряду с обычными HTTP-маршрутами больших языков моделирования. Он может по-прежнему обслуживать конечные точки, совместимые с OpenAI, но в то же время рассматривает серверы инструментов MCP скорее как микросервисы — с возможностью их обнаружения, чтобы агенты могли находить необходимые инструменты, — а также позволяет передавать информацию об идентификации и трассировке данных на протяжении всех взаимодействий между агентами, обеспечивая возможность отслеживания их действий.
В сложной системе агентов агенты отправляют запросы к инструментам, которые могут попадать на сервер MCP. В отсутствие общей среды передачи данных каждая команда создает собственные механизмы аутентификации, ограничений по частоте запросов и сбора телеметрии для таких вызовов. Agentgateway централизует решение этих проблем, как это делает API-шлюз для REST-микросервисов, при этом учитывая особенности маршрутизации больших языков моделирования, такие как выбор вариантов с учетом задержек, затрат и характеристик моделей.
Для трафика типа A2A важны идентификация узлов на каждом этапе маршрутизации и возможность отслеживания: операторам платформ необходимо знать, какой агент обращался к какому партнеру, под какими учетными данными и с каким бюджетом задержек. Рассмотрение этой задачи как части работы шлюза первого класса снижает соблазн добавлять временные дополнительные компоненты рядом с каждым процессом агента.
Практическое применение: быстрый старт
Типичная оценка начинается локально. Установка похожа на установку других инструментов шлюзов, ориентированных на командную строку:
# This is a conceptual installation command, similar to what you might find for many CLI tools
curl -sL <some_install_script_url> | bash
После установки создание базового прокси для LLM занимает несколько минут: достаточно настроить маршрут к бэкенду, совместимому с OpenAI, и отправить тестовый запрос. Упрощенный манифест маршрутов может выглядеть так:
# llm-route.yaml
apiVersion: gateway.agentgateway.io/v1alpha1
kind: LLMGateway
metadata:
name: my-llm-proxy
spec:
listener:
port: 8080
routes:
- match:
prefix: /v1/chat/completions
destinations:
- ref:
name: openai-backend
namespace: default
backends:
- name: openai-backend
llm:
provider: openai
credentials:
secretRef:
name: openai-api-key
namespace: default
В приведенном фрагменте показан слушатель, входящий маршрут и поставщик бэкенда. Преимущество заключается в том, что для запуска первого маршрута требуется минимум пользовательских настроек до внедрения дополнительных правил.
Сила управления: маршрутизация, безопасность, наблюдение, управление, затраты
Помимо маршрутизации, именно инструменты управления делают продукт привлекательным для корпоративных клиентов.
Маршрутизация. Речь идет не только об HTTP/gRPC: маршруты LLM могут отдавать предпочтение более дешевым или быстрым моделям, осуществлять переключение между поставщиками и обеспечивать транзакции агентов в одном пространстве с обычными API-запросами.
Безопасность и политики. Помимо проверок JWT и OIDC, операторы могут применять ограничения на частоту запросов и более сложные политики к маршрутам LLM. Пример:
# Example: Applying a rate limit policy to an LLM route
apiVersion: gateway.agentgateway.io/v1alpha1
kind: RateLimitPolicy
metadata:
name: llm-rate-limit
spec:
targetRef:
group: gateway.agentgateway.io
kind: LLMGateway
name: my-llm-proxy
rateLimits:
- local:
requestsPerUnit: 100
unit: MINUTE
key:
header: "x-api-key" # Rate limit per API key
Наблюдаемость. Встроенные инструменты OpenTelemetry полезны командам, уже использующим стандартизированные методы отслеживания трейсов и метрик. Теги гейтвея, включающие информацию о модели, маршруте и идентификаторе агента, помогают избегать незамеченных проблем при отладке медленных или дорогостоящих запросов.
Управление и затраты. Политики доступа к инструментам для целей MCP, квоты и механизмы маршрутизации с учётом затрат позволяют команде платформы установить бюджет один раз, вместо того чтобы переговариваться о лимитах в каждом репозитории агентов. Такое разделение обязанностей — команды приложений создают агентов, а команды платформы — слой обработки данных — и является основной преимуществом такого подхода.
Когда его внедрять, а когда пропустить
Внедряйте его, когда организация разрабатывает многоагентные системы с использованием нескольких поставщиков LLM, инструментов MCP и требуется общий механизм аутентификации, отслеживания и контроля расходов. Если объём трафика между компонентами растёт, а каждая команда заново создаёт шлюзы, консолидация приносит пользу.
Пока пропустите его, когда единственной потребностью является простой прокси к одному поставщику с минимальными политиками. Более лёгкий прокси на основе LLM может быть достаточен, пока протоколы агентов и механизмы управления для нескольких пользователей не станут серьёзной проблемой.
Демонстрации в новых проектах с одним чат-ботом редко оправдывают наличие дополнительной плоскости управления. В то же время производственные агенты, соответствующие требованиям к комплаенсу, обычно такое наличие требуют.
Практические выводы
Agentgateway направлен на устранение возникающего пробела в инфраструктуре: единое маршрутизирование и политики управления для LLM, MCP и A2A вместо множества специализированных прокси. Команды, разрабатывающие платформы, получают возможность определять политики, отслеживать взаимодействия и контролировать затраты, не переписывая каждый агент. Команды, разрабатывающие приложения, получают стабильные правила взаимодействия с инструментами и моделями.
Принятие этого решения должно основываться на данных: измерьте, сколько сегодня существует пользовательских путей входа, сколько из них не имеют общего трекинга, и как часто возникают неожиданные расходы. Если эти показатели высоки, единая плоскость данных для ИИ действительно заслуживает серьезного рассмотрения. Если они низкие, сохраняйте простую архитектуру и вернитесь к этой теме, когда начнется чрезмерное расширение числа агентов.
Детали маршрутизации, которые стоит протестировать
Маршрутизация с учётом задержек и затрат полезна только тогда, когда сигналы о состоянии системы достоверны. Во время пиковой нагрузки необходимо проверить, что неисправные бэкенды быстро покидают пул, а функция «липких сессий», если она используется, не приводит к направлению трафика на неисправную копию. Маршрутизация с учётом моделей должна показывать в логах, какая именно модель обработала запрос; в противном случае отделы финансов и SRE будут работать на основе разных панелей управления.
Также следует протестировать механизм переключения на резервные решения с использованием искусственных сбоев: аннулировать ключ поставщика, снизить лимит частоты запросов и убедиться, что агенты выдают контролируемые ошибки вместо того, чтобы продолжать попытки отправки запросов. Повторные попытки на уровне шлюза должны координироваться с повторными попытками со стороны клиента, чтобы избежать усиления сбоев.
Подробности по безопасности для анализа в корпоративных условиях
Проверка JWT и OIDC является базовой. Спросите, как правила доступа инструментов соотносятся с целями MCP, где хранятся секреты ключей поставщиков, и требуется ли полный перезапуск или горячая замена при изменении политик. Кластеры с несколькими арендаторами нуждаются в четкой изоляции, чтобы агент одной команды не мог вызывать инструменты другой команды.
Политики ограничения частоты запросов должны различать интерактивные чаты и задачи пакетной вставки. Единый глобальный лимит QPS слишком упрощен; лимиты по маршрутам и пользователям соответствуют тому, как платформы фактически берут плату у внутренних клиентов.
Ожидания по наблюдаемости
Стандартный OpenTelemetry необходим, но недостаточен. Убедитесь, что информация из фреймворков агентов передается в элементы данных гейтвея, и что атрибуты включают название маршрута, идентификатор модели, количество токенов при наличии и названия инструментов MCP. Без этого треки позволяют объяснить задержки, но не стоимость.
Стратегии отбора логов также имеют важное значение: полная запись запросов может быть запрещена; обычно компромиссом является использование структурированных метаданных с правилами конфиденциальности. Сначала необходимо убедиться в соответствии требованиям безопасности, прежде чем включать подробную запись данных в непродакшн-среде.
Управление затратами на практике
Механизмы маршрутизации с учётом затрат позволяют предпочитать более дешёвые модели для трафика с низкой степенью критичности, однако владельцы продуктов должны указывать, какие маршруты допускают снижение качества обслуживания. Необходимо связать бюджеты шлюзов с системами оповещений при приближении к месячному лимиту. Политики доступа к инструментам, ограничивающие дорогостоящие операции MCP (масштабные сканирования, массовые записи), предотвращают трату всех кредитов за месяц из-за одной ошибки агента.
План внедрения
- Разверните шлюз в пространстве имён сандбокса с одним маршрутом LLM.
- Подключите экспорт OTel к существующему сборщику данных; проверьте один эталонный путь обработки.
- Добавьте единственную цель MCP после процедур аутентификации и введения ограничений по частоте запросов.
Такая последовательность позволяет сведать к минимуму негативные последствия, сохраняя при этом возможности, отличающие Agentgateway от обычного прокси LLM.
Соответствие организационным требованиям
Группы, уже использующие API-шлюзы, сразу поймут принцип работы этой платформы: создание заявок на новые маршруты, использование политик в виде кода, общие панели управления. Команды, ранее использовавшие собственные LiteLLM-инструменты, могут сопротивляться до тех пор, пока шлюз не докажет снижение объема работы — через общие ключи, квоты и данные отслеживания. Планируйте период миграции, когда оба подхода сосуществуют, с четкими сроками.
Документация для авторов агентов должна содержать инструкции по указанию базового URL шлюза для SDK, способам передачи идентификаторов и интерпретации кодов ошибок шлюза. Без такой поддержки команды будут продолжать обходить стандартную архитектуру ради «одного эксперимента».
Основные выводы
- Единая плоскость данных: объединение управления трафиком, аутентификации, сбора телеметрии, настройки политик и ограничений использования в одном компоненте, понимающем протоколы HTTP/gRPC, а также протоколы моделей и агентов.
- MCP как сервисы: обнаружение и защита серверов инструментов как других микросервисов, а не как дополнительных компонентов рядом с прокси LLM.
- Прозрачность взаимодействия A2A: идентификация участников и отслеживание действий на этапах работы агентов превращают «черные ящики» в управляемые системы.
- Политики на периферии: ограничения скорости, аутентификация и правила доступа к инструментам должны реализовываться в шлюзе, чтобы код агентов мог сосредоточиться на выполнении логических операций.
Команды, стремящиеся к масштабируемым, безопасным и наблюдаемым приложениям на основе ИИ — особенно те, которые сочетают автономных агентов с различными поставщиками моделей — должны оценить, покрывает ли их текущий слой прокси уже протоколы агентов или только функции завершения чатов. Первый вариант является необходимым условием для следующего поколения производственных систем агентов; второй — лишь временное удобство.
С точки зрения эксплуатации начните с одного маршрута на основе LLM и одной цели MCP в непроизводственном кластере, убедитесь, что панели управления OpenTelemetry начинают отображать данные, а затем расширяйте настройки. Не стоит включать все функции с первого дня; узкий, наблюдаемый путь лучше, чем полностью настроенный шлюз, которому пока никто не доверяет.