Интеграция ждёт от модели объект с резюме звонка, следующим шагом и сроком. Вместо него приходит строка, обрезанный JSON или корректный объект без обязательного поля. Самая дорогая ошибка здесь — всё равно записать ответ в CRM. Карточка выглядит заполненной, но робот не создаёт задачу, срок превращается в пустое значение, а менеджер доверяет неполному резюме.
Первое, что я бы проверил: сохраняется ли сырой ответ модели до преобразования. Не весь лог приложения и не токен авторизации, а request ID, HTTP-код, Content-Type, имя схемы и тело ответа с удалёнными персональными данными. Если исходного ответа нет, спор о том, кто сломал JSON, быстро превращается в гадание.
Разделите три разных класса ошибки
Ошибка транспорта означает, что вы не получили полезный ответ: timeout, 429 или 5xx. Синтаксическая ошибка возникает, когда строку нельзя разобрать как JSON. Семантическая ошибка хитрее: JSON корректный, но поле next_step отсутствует, дата имеет неверный формат или массив возражений заменён строкой. Для каждого класса нужен свой маршрут, иначе автоматический retry начнёт повторять запросы, которые повторять бессмысленно.
| Сигнал | Что это значит | Действие |
|---|---|---|
| HTTP 429 | Лимит запросов | Отложенный retry с ограничением попыток |
| HTTP 200, JSON.parse падает | Ответ не является JSON | Карантин, без записи в CRM |
| JSON разобран, нет ключа | Нарушен контракт | Ошибка schema validation |
| Все поля валидны | Ответ можно использовать | Запись и audit ID |
Проверка 1. Зафиксируйте HTTP-границу
Проверьте статус и заголовок Content-Type до разбора тела. Ответ 200 сам по себе не доказывает, что внутри нужная структура. Для диагностики безопасно повторить тест на обезличенном payload и сохранить заголовки:
curl -sS -D response.headers -o response.json https://ai-gateway.example/internal/test
node -e "const fs=require('fs'); JSON.parse(fs.readFileSync('response.json','utf8')); console.log('JSON_OK')"PASS: запрос завершился ожидаемым HTTP-кодом, JSON разбирается, в журнале есть request ID. FAIL: тело пустое, приходит HTML ошибки или парсер завершается исключением. Production-токен в командную строку и историю shell не вставляйте.
Проверка 2. Валидируйте контракт, а не наличие фигурных скобок
Опишите объект схемой: тип каждого поля, обязательные ключи, допустимые значения и запрет неожиданных свойств там, где он нужен. Например, next_step должен быть строкой, due_at — строкой даты либо null, а confidence не должен сам по себе разрешать запись. Structured Outputs с жёсткой схемой снижает вероятность нарушения формата, но проверка на вашей стороне всё равно остаётся publication gate для CRM.
{
"type": "object",
"properties": {
"summary": { "type": "string", "minLength": 1 },
"next_step": { "type": "string", "minLength": 1 },
"due_at": { "type": ["string", "null"] }
},
"required": ["summary", "next_step", "due_at"],
"additionalProperties": false
}PASS: валидатор возвращает ноль ошибок и версия схемы записана рядом с результатом. FAIL: хотя бы одно обязательное поле отсутствует или имеет другой тип.
Проверка 3. Не смешивайте fallback и нормальный результат
Если проверка не прошла, не записывайте в поле «Следующий шаг» текст вроде «Не удалось распознать». Это уже бизнес-данные, которые попадут в отчёт и роботов. Сохраните событие в отдельной очереди ошибок: request ID, версия prompt, версия schema, код ошибки и безопасный фрагмент ответа. Менеджеру лучше показать понятный статус «Требуется ручная проверка», а не правдоподобную догадку модели.
Рабочий алгоритм
- Присвойте запросу уникальный request ID до вызова AI.
- Проверьте HTTP-код и тип содержимого.
- Разберите JSON внутри контролируемого try/catch.
- Запустите JSON Schema validation.
- Отдельно проверьте бизнес-ограничения: непустой следующий шаг, допустимая дата, длина резюме.
- При ошибке отправьте событие в карантин без записи в рабочие поля CRM.
- При успехе запишите результат и идентификатор аудита одной операцией.
Типичные ошибки
- Доверять HTTP 200 и не проверять тело.
- Исправлять JSON регулярным выражением и молча продолжать.
- Повторять любой сбой, включая стабильную schema error.
- Писать персональные данные и API key в журнал.
- Менять схему без версии, после чего старые ответы невозможно воспроизвести.
Чек-лист перед включением записи
- Есть request ID и версия схемы.
- Транспортные ошибки отделены от ошибок формата.
- Обязательные поля проверяются по типу и содержанию.
- Ошибочный ответ не меняет рабочую карточку.
- Retry ограничен и применяется только к временным ошибкам.
- Логи очищены от секретов и персональных данных.
- На тестовом ответе проверены PASS и FAIL ветки.
Что делать, если не помогло
Соберите один воспроизводимый пакет: обезличенный input, request ID, имя модели, версия prompt, схема, HTTP-заголовки и сырой ответ. Затем прогоните его через валидатор отдельно от CRM. Если JSON стабильно нарушает один и тот же ключ, исправляйте контракт или prompt. Если формат ломается только при timeout и повторе, ищите ошибку в gateway и retry. Если валидный объект портится уже перед записью, проблема находится в mapping-слое интеграции.
CTR1 может показать, где AI реально встроить в процесс продаж и как защитить запись результата. Рядом полезны материалы про работу после звонка, границы AI-агентов и внедрение AI в отдел продаж.
