Перейти к содержанию

Переход от демонстрационного скрипта к сервису, обслуживающему

## Синдром tool sprawl и деградация рассуждений

Переход от демонстрационного скрипта к сервису, обслуживающему 40 миллионов инженеров, мгновенно разрушает иллюзии о всемогуществе автономных агентов. Postman запустил Agent Mode на базе Amazon Bedrock, превратив платформу тестирования API в рабочую среду с поддержкой автономных цепочек действий. Инженерная реальность такого масштаба показала: проблемы современных AI-систем лежат не в плоскости алгоритмов генерации, а в фундаментальных ограничениях контекста и неуправляемом росте интерфейсов взаимодействия.

Синдром tool sprawl и деградация рассуждений

Первый барьер при создании масштабных агентов - разрастание каталога инструментов (tool sprawl). Разработчики часто пытаются снабдить модель исчерпывающим набором действий: отправка запроса, парсинг заголовков, поиск по коллекции, редактирование переменных окружения, выгрузка моков. В теории агент должен выбирать оптимальный шаг. На практике модель с 30-40 доступными инструментами начинает путаться в сигнатурах, выбирать неоптимальные вызовы или зацикливаться на ошибочных ветках выполнения.

Каждое описание инструмента в формате JSON Schema потребляет драгоценное место в системном промпте. Если на описание функций уходит несколько тысяч токенов до начала диалога, модель теряет способность удерживать фокус на долгосрочной цели пользователя.

Решением проблемы стало динамическое ограничение пространства действий. Вместо единого плоского списка инструментов в контекст передается минимально необходимый набор верхнеуровневых операций. Детализация происходит по принципу прогрессивного раскрытия: агент сначала выбирает категорию действия, и только затем получает доступ к специализированным сигнатурам. Это снизило нагрузку на модель и отсекло ложные срабатывания.

Схемное чтение против раздувания контекста

Второй критический фактор - обращение с данными. При тестировании сложных API ответы серверов содержат мегабайты вложенных JSON-структур, списков и служебных логов. Прямая передача таких ответов в контекстное окно мгновенно исчерпывает лимиты и генерирует огромные задержки в генерации (Time to First Token).

Контекст перестал быть хранилищем данных и превратился в узкое горлышко производительности. Чтобы изолировать модель от сырого потока данных, была внедрена концепция schema-based reads (чтение на основе схем):

  • Агент получает не тело ответа целиком, а его структурный скелет: типы полей, ключи первого уровня и краткие метаданные.
  • Если требуется конкретное значение для следующего запроса, агент формирует точечный JSONPath-запрос или фильтр.
  • Подстановка значений происходит на уровне детерминированного кода оркестратора, минуя фазу генерации текста через LLM.

Такой подход защищает вызовы от галлюцинаций: модель оперирует абстрактными связями между полями («взять token из ответа авторизации и передать в заголовок следующего запроса»), а фактическую подстановку выполняет рантайм. Это срезало расход токенов на порядок и устранило сбои, вызванные усечением длинных ответов.

Инфраструктурный фундамент на Amazon Bedrock

Обслуживание многомиллионной аудитории требует строгой предсказуемости инфраструктуры. Использование Amazon Bedrock позволило решить две задачи: изоляцию данных и управление задержками при пиковых нагрузках.

Для корпоративных пользователей критична безопасность: токены авторизации, приватные эндпоинты и структура внутренних микросервисов не должны попадать в публичные обучающие выборки. Bedrock обеспечивает выполнение условий комплаенса и приватности в изолированном контуре.

На уровне производительности Bedrock дает гибкость выбора между семействами моделей под разные фазы агентного цикла:

  • Быстрые и легкие модели задействуются на этапе маршрутизации, валидации входных параметров и базового синтаксического анализа.
  • Модели с развитыми способностями к рассуждению привлекаются только тогда, когда агенту требуется построить сложный план тестирования из пяти-семи шагов или разобрать нетипичную ошибку протокола.

Такое разделение снизило среднюю стоимость одной агентной сессии и удержало отклик интерфейса в рамках допустимых для пользователя секунд, а не минут.

Архитектурные правила для агентных систем

Опыт масштабирования Agent Mode дает четкий набор принципов для любых команд, создающих автономные рабочие процессы:

  1. Инструменты требуют изоляции. Нельзя давать модели универсальный доступ ко всей функциональности системы. Контекст должен содержать только те методы, которые релевантны текущему состоянию задачи.
  2. Данные фильтруются до попадания в LLM. Модели нужны контракты и схемы, а не сырой полезный груз. Детерминированная обработка данных всегда надежнее генеративной.
  3. Контекст - это оперативная память с высокой стоимостью доступа. Засорение истории промежуточными логами снижает качество логических выводов модели. Необходима регулярная компактизация диалога.
  4. Маршрутизация важнее размера модели. Каскадная архитектура, где легкие классификаторы готовят почву для тяжелых моделей рассуждения, оказывается быстрее и экономичнее попыток решать все задачи одной флагманской сетью.

Читайте также