«Узкое место — контекст, а не возможности»: Postman рассказала, как вывела Agent Mode на 40 миллионов разработчиков через Amazon Bedrock

Что построила Postman

Agent Mode — это ИИ-агент внутри Postman, который работает с продуктом «нативно для ИИ» сразу в четырёх областях: тестирование API, документация, поиск и реализация. Postman развивается 11 лет, и разработчики привыкли искать информацию через интерфейс — раскрывая боковые панели, переключая вкладки и открывая запросы; перенести это «понимание» на агента оказалось отдельной инженерной задачей.

Сам Postman формулирует разницу так: собрать агента для демо и вести его для 40 миллионов разработчиков — две разные задачи. Трудности пришли не от качества модели и не от промптов, а от встраивания агента в зрелый продукт с многолетними интерфейсными допущениями и широкой поверхностью. Agent Mode работает на Amazon Bedrock: AWS берёт на себя обслуживание моделей, а Postman сохраняет контроль над пропускной способностью, географией обработки и стоимостью при резком и неравномерном трафике.

Тулсет дороже сорока инструментов

Сначала команда делала инструменты предельно атомарными — открыть запрос, изменить одно поле, получить конкретные метаданные. Подход помогал точности, но у него обнаружились издержки: реальные сценарии требуют длинных последовательностей вызовов, и каждый шаг обязан возвращаться к модели, прежде чем начнётся следующий. Пользователи видели, как агент «перебирает» действия, которые человек считал одной операцией.

Ключевой факт из тестов Postman: как только число видимых агенту инструментов превышало примерно 40, ошибки выбора инструмента начинали расти — агент вызывал несуществующие инструменты, передавал неверные аргументы при валидной схеме или выбирал формально разумные, но неверные по контексту инструменты. Более крупные и новые модели уменьшали такое поведение, но не убирали его полностью.

Поэтому текущая архитектура выбирает инструменты по потребности и контексту, а не показывает модели весь каталог. Корневой агент обращается к векторной базе эмбеддингов инструментов и сужает более чем 170 инструментов примерно до 15 релевантных запросу, после чего передаёт их в изолированного по контексту субагента — модель видит только то, что нужно для задачи. Отдельно Postman расцепляет инструменты с вкладками интерфейса: часть клиентских API была неявно привязана к состоянию UI, и агенту приходилось открывать вкладку, чтобы прочитать данные. Теперь Agent Mode умеет отправлять запросы в фоне без открытой вкладки, но одобрение пользователя всё ещё требуется.

Читать схемы вместо роста числа инструментов

Второй приём — доступ агента к данным через схему, а не через отдельный инструмент на каждый вопрос. Для таких продуктов, как API Catalog, Postman свёл несколько узких представлений в один инструмент запроса: имея схемы нижележащих таблиц ClickHouse, агент сам строит сложные запросы с соединениями и условиями WHERE.

Смысл изменения в том, что инженерная работа смещается от «инструмент на каждый вопрос» к «один раз хорошо смоделировать данные»: агент может породить куда более широкий набор запросов, чем команда успела бы перечислить отдельными инструментами.

Контекст оказался настоящим узким местом

Изначально Postman предполагала, что главным блокером станут нехватающие инструменты. На практике нехватка или неполнота контекста приводила к большему числу отказов, чем нехватка возможностей. Под контекстом здесь понимается знание агента о том, где пользователь находится в Postman, какие сущности активны и какое состояние уже установлено: при неверном контексте даже корректные инструменты становились бесполезны.

Проблема оказалась структурной. Сериализовать существующую модель данных интерфейса не получилось: эти объекты спроектированы под отрисовку и передачу данных, а не под рассуждение. Postman построила отдельные обработчики контекста, которые сжимают каждую сущность до того, что агенту действительно нужно знать, а затем столкнулась со следующей проблемой — усечением: поля вроде описаний запросов, спецификаций OpenAPI и полезной нагрузки могут заполнить окно контекста, поэтому бюджет контекста приходится вести так же аккуратно, как и бюджет токенов.

Три составные части агента

К сложившейся архитектуре Agent Mode сходятся три компонента, каждый решает свою задачу. Первый — клиентские инструменты внутри приложения Postman: именно они выполняют финальные действия вроде открытия запросов, изменения настроек и запуска коллекций (плюс серверные инструменты для веб-поиска и управления циклом агента).

Второй — общие инструкции агента, задающие системное поведение: насколько агент инициативен, как сообщает о неуверенности и каким базовым знанием о продукте владеет. Третий — база знаний на подходе Retrieval Augmented Generation (RAG): закодировать всю поверхность Postman статическими промптами было невозможно, поэтому для старта использовали обучающий центр Postman, а в рантайме агент подбирает статьи под запрос и контекст — например, при выборе mock server автоматически подставляет связанную статью.

Почему Agent Mode работает на Amazon Bedrock

Все три компонента сводятся к одному действию рантайма — вызову инференса к фундаментальной модели. Agent Mode не привязан к одной модели: через API вывода Amazon Bedrock Postman обращается к поддерживаемым моделям семейства Anthropic Claude и подбирает модель под нагрузку — более быструю для массовых чувствительных к задержке запросов и более крупную там, где важнее качество рассуждения. Переключение между поддерживаемыми моделями Claude — это в первую очередь изменение конфигурации, а не новая интеграция.

Для высокого и «всплескового» трафика используется cross-Region inference: приложение передаёт ID или ARN профиля вывода как modelId в Converse или InvokeModel, а при необходимости выбирает географический профиль (маршрутизация только внутри заданной географии, например США или ЕС) либо глобальный — когда географическая граница обработки не нужна. Для корпоративных клиентов Postman настроила нулевое хранение данных: data_retention_mode выставлен в none для поддерживаемых моделей Agent Mode, а доступность и поведение зависят от модели и требуют сверки с актуальной документацией Bedrock по защите и хранению данных.

Стоимость сдерживает кэширование промптов. Агент заново отправляет значительный неизменный контекст на каждом ходу — системные инструкции, общее поведение агента, ядро набора инструментов, выбранное знание и историю диалога. Amazon Bedrock prompt caching переиспользует стабильные префиксы промпта: почти неизменное ядро (системный промпт, инструкции агента, определения ключевых инструментов) использует часовую контрольную точку кэша объёмом в один час, а более изменчивый контекст — пятиминутную, которая обновляется при попадании в кэш; длинная контрольная точка обязана идти раньше короткой.

Частью продакшн-дизайна остаётся надзор человека: Agent Mode требует одобрения пользователя перед действиями, меняющими состояние приложения, а как средство ответственного ИИ используется Amazon Bedrock Guardrails — он вычищает персональные данные до того, как они дойдут до языковой модели.

Что это значит

Опыт Postman AWS сводит в набор переносимых правил: считать бюджет инструментов таким же важным, как бюджет токенов, и динамически сужать набор под задачу; предпочитать чтение по схеме росту числа одноцелевых инструментов; расцеплять действия агента с состоянием интерфейса; строить контекст осознанно и вести окно контекста как дефицитный ресурс; выпускать документацию вместе с функциями, потому что RAG-база полезна только пока развивается в ногу с продуктом; и относиться к инференсу как к задаче маршрутизации и кэширования, а не только выбора модели.

Практический вывод, который авторы называют главным: разрыв между возможностями языковых моделей и устройством зрелых продуктов — интерфейсные допущения, связанные клиенты, разрастающийся каталог инструментов и знание, размазанное по документации и командам — не закрывается одной сменой модели. Чтобы масштабировать агент, этот разрыв приходится перестраивать в архитектуре.