27 октября 2026 г.

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

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

Я потратил некоторое время на работу с Claude Code и плагином Postman, чтобы проверить, какую часть этого рабочего процесса можно запустить как единый непрерывный процесс вместо пяти разрозненных. Краткий ответ: большую его часть, благодаря Postman Context Graph.

Что Context Graph дает агенту

Postman Context Graph — это актуальный индекс сервисов, эндпоинтов, schemas, потребителей, владельцев, развертываний, сред, телеметрии и связей между вызовами во время выполнения, к которым у вас есть доступ. Он разрешает сущности в этих системах и выстраивает связи между ними, поэтому агент может спросить, например, «от чего зависит сервис выставления счетов», и получить реальный ответ, а не догадку на основе случайно открытых файлов.

Это различие важнее, чем кажется на первый взгляд. Исследования Postman в области ИИ-агентов для написания кода указывают на тип сбоя, который проявляется у моделей последнего поколения. Агенты теряют эффективность при извлечении из длинного контекста задолго до того, как окно контекста заполнится, а точность в отношении информации, запрятанной в середине длинного промпта, может упасть на 30% и более. Выгрузка всего монорепозитория в промпт в надежде, что модель найдет нужную схему, — это не стратегия работы с контекстом. А граф, который уже знает, какие сервисы существуют и как они связаны, — это стратегия.

Claude Code получает доступ к Context Graph через плагин Postman для Claude Code, используя навык api-discovery. Это один примерно из дюжины навыков, поставляемых с плагином, которые также охватывают остальные этапы жизненного цикла API: создание коллекций, написание тестов, создание заглушек (mock), мониторинг и настройку CI. В этом обзоре затронуто большинство из них.

Добавление сервиса с помощью Context Graph

Я применил это к приложению медицинского шлюза, которое поддерживает моя команда — myhealthcare.dev. Это приложение имитирует бэкенд больницы и содержит разные сервисы для пациентов, врачей, лекарств, аптек и т. д.

Используя режим планирования (plan mode) в Claude, я начал продумывать этот новый сервис. Я хотел создать сервис управления случаями (case management), который бы открывал дело для пациента и имел множество зависимостей, включая его врача/поставщика медицинских услуг, лекарства, страховку и т. д. Но как создать этот сервис и убедиться, что все нисходящие зависимости не сломаются в процессе? С помощью Context Graph.

Первое, что сделал Claude перед написанием любого кода, — использовал навык api-discovery, чтобы запросить у Context Graph информацию о нисходящих зависимостях для patients-service и providers-service, поскольку они были фундаментальными для этого обновления. Получив ответ от Context Graph, Claude приступил к выполнению плана: созданию сервиса, новой схемы, коллекции, тестов, а затем обновлению нисходящих зависимостей.

Превращение контекста API в коллекцию

После создания схемы Claude превратил план в коллекцию в соответствии с collection schema v3 format, используя навык collection-schema-v3 для сохранения структуры файлов согласованной с остальной частью рабочей среды. Затем, используя навык api-testing, Claude написал тестовые скрипты, которые проверяют, ведет ли себя новый сервис так, как прописано в его контракте, а не просто возвращает ли сценарий успешного выполнения что-то правдоподобное:

Запуск коллекции извлек реальные тестовые учетные данные через Postman Vault Integrations, а не из файла .env, хранящегося в репозитории, — это именно та деталь, которую мне больше всего хотелось бы, чтобы товарищ по команде скопировал. Postman разрешил ссылку на секрет во время выполнения, и сами учетные данные никогда не попадали в файлы, которые Claude мог прочитать или зафиксировать (commit).

Замыкание цикла после развертывания

Добавление сервиса и написание тестов охватывают ту половину проблемы, которая предшествует слиянию (merge). Вторая половина — это то, что происходит после развертывания, когда этот сервис или один из одиннадцати других, с которыми он взаимодействует, изменяется без обновления другой стороны. Я попросил Claude справиться с обеими задачами в рамках одного промпта: настроить монитор, чтобы тесты продолжали выполняться после развертывания, и добавить тесты в CI-пайплайн.

Claude последовательно выполнил оставшуюся часть работы. Сначала он сгенерировал mock-сервер на основе коллекции и запустил против него набор тестов, чтобы подтвердить сохранение контракта до внесения каких-либо изменений в рабочую среду. Для этого он использовал навык api-mocking, а затем применил навык ci-integration для интеграции коллекции в рабочий процесс GitHub Actions.

Затем он создал периодический монитор для той же коллекции, используя навык api-monitoring, чтобы проверка контракта продолжала выполняться в рабочей среде с фиксированным интервалом, а не только в момент слияния. Он также отправил локальные сущности рабочего пространства (коллекции, среды, спецификации и моки) в общее рабочее пространство, чтобы их могла видеть остальная команда. В завершение Claude открыл пулл-реквест (pull request), объединяющий изменения во фронтенде, миграцию схемы, новую коллекцию, обновление рабочего процесса CI и конфигурацию монитора.

К чему все это ведет

Самой быстрой частью всего этого обзора было вовсе не написание коллекции или тестов. Это были те несколько секунд, которые потребовались Claude, чтобы запросить у Context Graph информацию о реальных зависимостях patients-service и providers-service, вместо того чтобы мне открывать оба репозитория и вручную отслеживать их. Выяснение того, где находится каждая зависимость, проверка ее актуальности и надежда на то, что вы не пропустили что-то запрятанное в репозитории, который у вас не открыт, — это обычно та часть добавления нового, тесно связанного сервиса, которая съедает весь день. Здесь же на это ушел один вопрос.

Эта точность важнее, чем кажется. Собственные исследования Postman в отношении ИИ-агентов для написания кода показали, что агенты теряют точность по мере того, как им приходится удерживать в контексте все больше информации одновременно, а данные о зависимостях, разбросанные по дюжине репозиториев, — это как раз то, что теряется, угадывается или тихонько пропускается. Context Graph обходит эту проблему: Claude не пришлось восстанавливать карту зависимостей по случайно открытым файлам. Он задал прямой вопрос с помощью навыка api-discovery и получил прямой и правильный ответ.

Все последующее вытекало из наличия правильной карты с самого начала. Как только Claude узнал, какие сервисы действительно важны, плагин Postman для Claude Code перенес эту информацию на остальные этапы жизненного цикла разработки ПО (SDLC) за один проход: создание коллекции с помощью навыка collection-schema-v3, написание тестов с помощью api-testing, создание заглушки сервиса с помощью api-mocking, настройку CI с помощью ci-integration и настройку монитора с помощью api-monitoring. Ничто из этого не потребовало переключения инструментов, повторного объяснения устройства сервиса или ручной перепроверки списка зависимостей на каждом шаге.

Именно в этом заключается реальный прирост скорости и точности. Написание любого из этих элементов — коллекции, тестового скрипта, монитора — само по себе не намного быстрее. Быстрее то, что вам не нужно заново определять одну и ту же карту зависимостей пять раз подряд, рискуя получить слегка отличающийся и неверный результат в каждом случае. Подробнее о том, как строится эта карта и как управляются нисходящие зависимости на протяжении жизненного цикла API, читайте в обзоре Postman Context Graph.

Если вы хотите опробовать это на своем собственном репозитории, установите плагин Postman для Claude Code и попросите его сопоставить зависимости для того, что вы собираетесь изменить. Сначала отправьте свои коллекции и спецификации в свое рабочее пространство. Граф может рассказать Claude только о тех зависимостях, которые он видит.