12 ноября 2026 г.

Агенту кодинга, работающему над эндпоинтом оформления заказа, нужно знать больше, чем просто содержимое редактируемого файла. Ему необходимо понимать, как Inventory резервирует товары, что возвращает Payments при отклонении платежа и каково правильное поведение системы, если любой из этих сервисов перестает отвечать. Прежде чем что-либо проверять, ему также нужно место для выполнения этих вызовов.

Умножьте это на количество разработчиков, репозиториев и новых сессий агентов, и ваша команда в итоге будет постоянно оплачивать одно и то же обучение. Агент читает код зависимостей, интерпретирует контракт API, запускает временную заглушку и отлаживает локальное окружение. Токены сгорают. Время уходит. И ни один из этих результатов не сохраняется для следующей сессии.

Я экспериментировал с симуляциями Postman как со способом сделать эти знания пригодными для повторного использования между агентами. Идея проста: команда, владеющая сервисом, поддерживает вызываемую модель своего API, включая сценарии сбоев, которые должны обрабатывать потребители. Любой агент, работающий с зависимым сервисом, может обнаружить эту симуляцию, запустить ее локально и начать работу с общей базы, вместо того чтобы заново открывать поведение системы.

Вот как это выглядело на практике.

Я запустил две сессии Claude Code в одном и том же рабочем пространстве.

Агент А взял на себя роль владельца зависимости. Он сгенерировал mocks для Inventory и Payments на основе их спецификаций OpenAPI, составил базовую симуляцию, а затем добавил три варианта сбоев, которые должны обрабатывать потребители:

Inventory нет в наличии → 409 Conflict
Платеж отклонен → 402 Payment Required
Тайм-аут платежа → ответ с задержкой 8 секунд

Агент А опубликовал все четыре симуляции в Postman workspace, чтобы их можно было найти позже.

Агент B создал реальный Node.js сервис оформления заказа, который вызывал эти заглушки по HTTP. Чтобы упростить локальную настройку, мы поместили обе зависимости за один порт с маршрутизацией по путям:

Агенту B не нужно было читать исходный код Inventory или Payments. Он получил симуляцию, запустил ее и начал кодировать, опираясь на известное поведение.

Запуск симуляции локально

На стороне потребителя используется Postman CLI для получения и запуска опубликованной симуляции. Агент выполняет примерно такую команду:

Это и есть вся передача данных. Владелец зависимости опубликовал; потребитель запустил. Никто не писал специализированный сервер-заглушку, никто не запускал Docker Compose с фейковыми сервисами, никто не писал вручную JSON-фикстуры в четвертый раз за квартал.

Чтобы протестировать другой сценарий, Агент B остановил базовую версию и запустил один из вариантов сбоя на том же порту. Тот же контракт, другое поведение.

Что мы обнаружили

Четыре запуска, четыре разных результата, и один из них оказался по-настоящему полезным.

Первые три были «зеленым светом». Путь компенсации для отклоненного платежа работал именно так, как предполагал контракт.

Четвертый случай был тем самым, ради которого все затевалось. Клиентский timeout тайм-аут оформления заказа сработал раньше, чем 8-секундный ответ заглушки, что привело сервис в худшее из возможных состояний: удаленное списание могло пройти успешно, могло не пройти, а сервис оформления заказа не имел возможности узнать результат. Это не та ошибка, которую агент нашел бы, просто читая код. Она проявляется только тогда, когда что-то отвечает медленно, что как раз и может сделать общая симуляция по запросу.

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

Почему это важно для сессий агентов

Новые сессии агентов начинаются без памяти. В этом вся суть. Каждый раз, когда запускается новая сессия для работы над сервисом, она должна восстанавливать ментальную модель своих зависимостей. Если восстановление означает чтение исходного кода, написание одноразовых заглушек и угадывание режимов сбоя, вы платите за одни и те же рассуждения снова и снова.

Общие симуляции превращают эти рассуждения в артефакт. Владелец зависимости фиксирует их один раз, включая неудобные сценарии сбоев, и каждый последующий агент-потребитель начинает работу с этого уровня. Симуляция становится формой долгосрочных знаний команды, которые агент может не просто прочитать, но и выполнить.

Приятный момент заключается в том, что симуляция живет рядом с контрактом API. Если контракт меняется, меняется и симуляция. Если в продакшене появляется новый режим сбоя, команда-владелец добавляет вариант, и каждый последующий агент наследует возможность тестирования против него.

Симуляция также снижает затраты на настройку связей. Агент направляет один порт на весь граф симулируемых зависимостей вместо того, чтобы обнаруживать и редактировать N отдельных точек конфигурации для N отдельных заглушек. Долговечный артефакт — это не просто знание о режимах сбоя. Это способ действовать в соответствии с ними в один шаг.

Где это вписывается в жизненный цикл разработки с использованием агентов

Этот паттерн полезен в нескольких местах:

Реализация. Агенты строят работу на основе известного поведения, а не выводят его из кода. Меньше ошибок типа «Я предположил, что Payments вернет 400 здесь».
Тестирование. Сценарии сбоев, которые сложно вызвать в реальном окружении (тайм-ауты, специфические коды ошибок, частичные сбои), становятся однострочными повторами.
Обзор. Сама симуляция подлежит проверке. Человек может посмотреть, на каких предположениях основывается агент, и возразить, если они неверны.
CI/CD. Те же сценарии могут запускаться в pipeline. Регрессии в том, как потребитель обрабатывает 402 ошибку или тайм-аут, обнаруживаются до релиза.

Как начать, не пытаясь объять необъятное

Не пытайтесь симулировать всю систему целиком. Выберите одну границу сервиса, которую ваша команда постоянно объясняет новым инженерам (или переобъясняет новым сессиям агентов). Пусть команда-владелец зафиксирует базовое поведение и один значимый сценарий сбоя в поддерживаемой симуляции. Опубликуйте ее в , где агенты-потребители смогут ее найти.

Этого достаточно для начала. Вторую границу будет легче настроить, потому что паттерн уже существует. Третью — еще легче.

То, к чему я постоянно возвращаюсь после запусков Claude Code: ошибка с тайм-аутом была найдена бесплатно. Мы не собирались ее искать. Она проявилась при запуске потребителя против симуляции, которая моделировала медленную зависимость — это тот тип теста, который вы обычно пропускаете, потому что его настройка раздражает. Когда стоимость настройки падает до одной команды из Postman CLI, вы запускаете этот тест, и ошибка обнаруживается до того, как ее найдет клиент.

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

Ресурсы

Симуляция условий API (Документация Postman): Справочник по созданию симуляций, которые объединяют несколько заглушек и определений, которые можно запускать локально или в общем рабочем пространстве.
Справочник команд Postman CLI: Описывает команды postman simulation list и postman simulation run --port для получения и запуска общих симуляций из окружения потребителя.
Обзор Postman CLI: Руководство по установке и контекст использования Postman CLI в локальной разработке и CI/CD.
Спецификация OpenAPI: Формат спецификации, который большинство команд используют для описания API, и естественный источник для генерации заглушек.
: Авторитетный справочник по кодам состояния (402, 409) и семантике идемпотентности, на которые ссылаются шаблоны компенсации и повторных попыток выше.
Документация Claude Code: Справочная информация о кодирующем агенте, использованном в эксперименте из двух сессий.