Как проверить обработку ошибок, которую написал ваш агент программирования

Агент программирования говорит, что он добавил повторные попытки и обработку ограничения частоты запросов, и его тесты проходят. Прежде чем доверять этому, проверьте, против чего запускались тесты.

В тесте, который мы выполнили с 3 агентами программирования (210 запусков), мы попросили их обработать сбои API и показать, что они работают. В 76% из 140 запусков, запрашивающих рабочий код, агент создал сбой вручную с заглушками fetch, httpx.MockTransport или временным HTTP-сервером. В 75 запусках, где был доступен реальный API и запрос не исключал его, ни в одном приложение не было протестировано по его реальному URL-адресу API. Прохождение таких тестов свидетельствует о том, что код агента обрабатывает сбой, который воображается агентом. Это другой сбой, не тот, который отправляет API.

Checklist

  1. Спросите, с чем это тестировалось. Спросите агента: "Какой URL-адрес вызывало приложение во время вашего теста и что вернуло ошибку?" Если в ответе указана заглушка или локальный сервер, который он написал, рассматривайте тесты как модульные тесты для ветвей кода, которые он добавил.
  2. Найдите переключатели, добавленные для тестов. Выполните поиск по диффу для новых переменных среды, параметров базового URL-адреса или флагов. В нашем тесте в 61 из 105 запусков в приложениях, которые вызывают GitHub, OpenAI или API погоды, был добавлен один. Определите, хотите ли вы использовать его в продакшене.
  3. Проверьте код на соответствие документированному поведению API. Каждый API завершается ошибкой по-своему:
    • GitHub: при превышении основного лимита частоты запросов вы получаете 403 или 429 с x-ratelimit-remaining, установленным в 0, и вы ждёте до времени, указанного в x-ratelimit-reset, в секундах эпохи UTC. Для вторичных ограничений скорости подождите retry-after, если указано, в противном случае до тех пор, пока x-ratelimit-reset если x-ratelimit-remaining не будет 0, в противном случае не менее 1 минуты. Код, который проверяет только 429, пропускает 403s.
    • OpenAI: некоторые ошибки 429 связаны с выставлением счетов и ограничениями расходов, например credit_balance_exhausted. Повторять их не поможет. Код, который повторяет запрос при каждом ответе 429, скрывает от вас проблему.
    • Anthropic: ограничение расходов 429 не имеет retry-after HTTP-заголовка, а при перегрузке возвращается 529, чего может не ожидать код, который знает только стандартные коды состояния.
  4. Проверьте, как это читается Retry-After. Заголовок содержит либо количество секунд, либо дату HTTP (RFC 9110). Убедитесь, что код обрабатывает формат, который отправляет ваше API, ограничивает число попыток и общее время ожидания, а также не выполняет повторные попытки поверх SDK, который уже выполняет повторные попытки.
  5. Проверьте, что пользователь видит, когда повторные попытки исчерпаны. Найдите четкое сообщение, а не трассировку стека или бесконечный спиннер, и убедитесь, что пользователь не теряет свою работу.
  6. Запустите приложение на реальных URL-адресах с имитацией сбоев. Это единственный шаг, показывающий, как запущенное приложение, его пакет SDK и политика повторных попыток работают вместе.

Как проверить обработку ошибок, написанную агентом

Approach Что вы найдете Что вы пропустили
Ознакомьтесь с diff Выглядит ли код правильно Правильно ли оно ведет себя в отношении реальных ответов API
Запустить тесты агента Что ветви, которые она создала, выполняются Все, что заглушка не моделировала: реальные коды состояния, заголовки, тела ошибок и повторные попытки пакета SDK
Вызывайте реальный API до тех пор, пока он не завершится ошибкой Реальное поведение Вы не можете вызывать сбои по требованию, и вы тратите реальную квоту
Запустите приложение на реальных URL-адресах с имитацией сбоев Как работающее приложение, его SDK и политика повторных попыток обрабатывают ошибки самого API Ваш код в изоляции. Оставьте для этого модульные тесты агента.

Попробуйте в вашем приложении

Dev Proxy перехватывает запросы, которые приложение отправляет в реальный API, и возвращает выбранные ошибки без изменений в коде приложения. Для популярных API начните с предустановки. Чтобы проверить обработку ограничения скорости GitHub, ваш агент написал:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Запустите приложение и просмотрите выходные данные Dev Proxy. Предустановленный набор возвращает 429 с заголовками лимита запросов GitHub после того, как ваше приложение превысит лимит. RetryAfterPlugin в предустановке сообщает, вызывает ли приложение API снова до истечения времени ожидания. anthropic-throttling и openai-throttling предустановки выполняют то же самое для ошибок ограничения частоты запросов поставщика, а openai-throttling также возвращает credit_balance_exhausted значение 429, которое не следует повторять.

Для других API:

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

Чтобы установить Dev Proxy, см. Настройка Dev Proxy.

Дальнейшие действия

Протестируй(те) мое приложение на наличие случайных ошибок

См. также

  • Последнее обновление: