Как обрабатывать ошибки Anthropic API без бесконечных повторов

1. Отдельный тестовый проект или среду, где ошибка не затронет клиентов.
2. Один обезличенный пример данных и ожидаемый результат в двух-трёх предложениях.
3. Журнал: время, версия модели или интеграции, идентификатор запроса, итоговый статус.
4. Правило остановки: какие ответы нельзя публиковать или выполнять автоматически.

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

Порядок работы

Разделите ошибки на четыре группы: некорректный запрос, проблема авторизации, временная перегрузка и ограничение скорости. Для первой группы исправляйте данные, для авторизации прекращайте выполнение и уведомляйте администратора, для временных ошибок используйте ограниченный повтор. Логируйте request id, статус и безопасный контекст без секретов.

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

Готовый шаблон запроса

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

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

Пример и проверка результата

Вход: запрос получил 529, затем второй запрос получил 400. Ожидаемый результат: первый идёт в ограниченный retry, второй не повторяется и попадает в очередь исправления данных.

Проверяйте результат по пяти пунктам:

1. Использованы ли только переданные и явно разрешённые данные.
2. Выполнен ли обещанный формат: поля, типы, длина, язык.
3. Отмечены ли пропуски, неоднозначности и рискованные действия.
4. Не изменился ли бизнес-смысл при сокращении или классификации.
5. Можно ли повторить запуск и объяснить, почему система приняла решение.

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

Типичные ошибки