CLAUDE · CRM · ПРОДОЛЖЕНИЕ ДИАЛОГА
Claude в CRM: как продолжить диалог после обновления интеграции
Если AI-помощник работает с заявкой в несколько шагов, важно проверить, что произойдёт после смены инструкции, набора инструментов или сокращения истории. Успешный первый ответ ещё не подтверждает, что разговор можно безопасно продолжить.
Что стало известно 12 октября
В отчёте от 12 октября Anthropic объяснила, как защита от извлечения рассуждений влияет на обычные интеграции Claude. Компания признаёт, что механизм preserved thinking потребовал изменений у части разработчиков. В том же отчёте отдельно указано: с 24 сентября некоторые запросы, остановленные защитой до ответа модели, снова оплачиваются. Это дата публикации объяснения уже действующих мер, а не запуск всех изменений 12 октября. Официальный отчёт Anthropic.
Для владельца CRM главный вопрос практический: после технического обновления незавершённая заявка должна либо продолжиться с понятным контекстом, либо перейти человеку. Недопустим вариант, когда ошибка скрыта повторной попыткой, а менеджер считает работу законченной.
Кого касается проверка
Проверка нужна командам, чей собственный код или подрядчик собирает запросы Messages API. Когда запросами управляют Claude Code, claude.ai, Claude Managed Agents или Claude Agent SDK, Anthropic не требует самостоятельного изменения их сборки. Кому нужно проверить интеграцию.
Preserved thinking проверяет возможность повторно использовать служебные блоки рассуждения, возвращённые API. Это не удаление переписки клиента или карточки CRM. В модели взаимодействия нужно различать три события:
- Изменился прежний контекст. Для поддерживающих эту проверку моделей изменение system, tools или предыдущих messages может сделать последующие thinking-блоки недействительными. В обычном Messages API запрос получает ошибку 400 либо, при выбранном режиме, продолжается без этих блоков.
- Изменилась модель. Совместимость блоков зависит от конкретной пары моделей. Неподдерживаемые блоки могут быть отброшены без ошибки; ответ продолжится без них.
- Запрос остановлен классификатором защиты. Такой отказ приходит с HTTP 200 и stop_reason: refusal. Это отдельный механизм со своими правилами оплаты.
Первые два случая описаны в документации по thinking; третий — в правилах отказов и fallback. По одному коду «запрос выполнен» нельзя понять, сохранился ли весь ожидаемый контекст.
Пример: клиент меняет время визита
Представим сервисную компанию. Помощник прочитал заказ и предложил варианты визита. Пока клиент выбирает, интеграция обновляет инструкцию менеджера или заново вставляет актуальную карточку заказа в самое начало уже начатого разговора. Затем она отправляет историю вместе с ранее полученными thinking-блоками.
Если проверка применяется, такое изменение может нарушить продолжение запроса. Однако резерв времени, созданный предыдущим инструментом, от этой ошибки сам не исчезает. Поэтому обработчик не должен заново запускать всю заявку вслепую. Сначала нужно установить фактическое состояние записи, затем выбрать продолжение. Это редакционный пример возможного сбоя, а не результат испытания Claude или SABSUS.
Для приёмки попросите подрядчика показать один и тот же заказ до изменения инструкции, после ошибки и после восстановления. На всех этапах записи должны относиться к тому же клиенту и заказу; изменения услуги, времени и согласия должны иметь проверяемое основание. Клиентское «да, подходит» нельзя потерять вместе с техническим контекстом или истолковать как согласие на другой вариант.
Что поручить технической команде
Для аккаунтов, созданных с 31 августа 2026 года, 00:00 UTC, проверка прежнего контекста включена по умолчанию для Fable 5.1, Opus 5.5, Sonnet 5.5 и Haiku 5.5. Старые аккаунты требуют явного включения: успешный тест без него недостаточен. Блоки Sonnet 5.5 и Haiku 5.5 также ограничены создавшим их или связанным аккаунтом. Область применения проверок.
Попросите разработчика подготовить два результата:
- Карту изменений запроса. Где обновляются данные заказа, инструкции, инструменты и старые сообщения? Новые сведения должны поступать поддерживаемым способом. Сохранность прежних блоков не оправдывает ответ по отменённому правилу: исправленная цена или пожелание клиента обязаны попасть в продолжение. Разработчик выбирает способ по документации модели и площадки; при необходимости команда начинает новую сессию с проверенным состоянием заявки.
- Явный способ восстановления. Если команда выбирает продолжение без недействительных thinking-блоков, это решение должно быть видно в журнале и проверено на качестве результата. Маскировать ошибку бесконечными повторами нельзя.
Beta-заголовок thinking-binding-controls-2026-08-01 открывает диагностику input_transformations. Сам заголовок не включает принудительную проверку старого аккаунта: разработчик явно задаёт prefix_mismatch_behavior. Значение drop_block продолжает запрос без недействительных блоков; это способ восстановления, не исправление причины. Совместимость параметров зависит от конфигурации. Диагностика и обработка несовпадения.
Сокращение длинного разговора проверяйте отдельно. Серверная compaction может сохранить применимость рассуждения в оставленных ходах при соблюдении условий; собственная сводка с механически приклеенными прежними thinking-блоками не эквивалентна ей. Функция описана как beta. Условия compaction и сохранения thinking.
Пять случаев для приёмки на одной заявке
Ниже — редакционный набор проверок. Проведите его на тестовых данных до допуска новой версии к клиентским сообщениям и изменениям рабочих записей.
Сначала убедитесь, что исходный ответ содержит thinking-блок. Адаптивный режим иногда не создаёт его; тогда отсутствие ошибки ничего не проверяет. Нужен контрольный разговор с блоком, который действительно отправлен повторно. Подготовка проверочного диалога.
- Обычное продолжение. Клиент уточняет пожелание после ответа инструмента. Помощник учитывает уточнение и сохраняет уже подтверждённые факты.
- Обновление инструкции посреди разговора. Команда меняет правило предложения времени. Видно, какой версией правила руководствуется продолжение; прежние согласия клиента не переиспользуются для новых условий.
- Возобновление после сохранения. Диалог сохраняют, перезапускают интеграцию и возобновляют с изменившейся датой. Техническая команда показывает восстановленные блоки и объясняет потери. Отдельно проверьте сериализатор: пустой текст thinking не делает блок бесполезным, в нём остаётся signature. Формат thinking-блоков. Если меняется модель или аккаунт, это отдельный вариант теста.
- Сокращение истории. После сводки помощник всё ещё знает цель обращения и незаконченный шаг. Текущие доступность и цену получает из системы заново, когда этого требует процесс.
- Ошибка после действия. Резерв уже создан, но следующий запрос к модели не проходит. Восстановление проверяет существующий резерв, не создаёт второй и оставляет сотруднику понятный статус.
Для каждого случая сохраните ожидаемый результат, фактические записи CRM, причину остановки и решение о продолжении. Число успешных HTTP-ответов не заменяет эту проверку. Любое незаметное повторение действия, утрата согласованных условий или исчезновение заявки из очереди должно останавливать запуск до исправления.
Какие расходы проверить отдельно
Отброшенный thinking-блок не оплачивается, но его удаление меняет кэшируемую часть запроса от соответствующей позиции. Поэтому наблюдайте реальное потребление после восстановления, а не предполагайте, что более короткая история автоматически дешевле. Thinking и кэширование.
В опубликованной базовой таблице Sonnet 5.5 на дату проверки указаны 2 USD за миллион входных токенов, 10 USD за миллион выходных и 0,10 USD за миллион токенов чтения из кэша. Запись кэша тарифицируется за миллион токенов: 2,50 USD со сроком хранения пять минут и 4 USD со сроком час. Это ставки модели, не цена всей CRM-автоматизации; проверьте условия своего провайдера и режима обработки. Тариф и доступность Sonnet 5.5.
Не смешивайте восстановление контекста с отказами защиты. По текущим правилам отказ до любого вывода оплачивается для категорий bio, frontier_llm и reasoning_extraction. Для других категорий или null такой отказ не оплачивается. При отказе в середине потока оплачиваются вход и уже выданный выход; повтор на другой модели может добавить расход. Эти правила не означают, что любой ответ 400 является платным отказом. Как оплачиваются отказы.
В смете соедините попытки с одной заявкой и проверенным итогом. Общий порядок такого учёта уже разобран в руководстве по затратам на принятую AI-задачу. Выбор дешёвой модели для короткого разбора сообщений — другая задача; для неё есть материал о Haiku 5.5.
Решение о запуске
Продолжать внедрение стоит, когда команда умеет объяснить состояние незавершённого диалога, показать изменения в CRM и воспроизвести восстановление без повторного действия. Если поставщик показывает только первую реплику и среднюю цену запроса, попросите испытать сохранение и возобновление сессии до расширения автоматизации.
Доступность нужно проверить для организации и региона: русский язык статьи не означает доступ из любой страны. Применяется политика поддерживаемых регионов Anthropic, включая использование через облачных партнёров.
Для проекта с SABSUS начните с разбора конкретного обмена через API: кто собирает запросы Claude, где хранится история, кто владеет записью клиента и кто принимает восстановление. Статья не подтверждает готовое подключение Claude или поддержку всех перечисленных режимов в SABSUS. Это условия, которые нужно согласовать и проверить для выбранной интеграции.
Источники проверены 13 октября 2026 года UTC. Автор: редакция SABSUS. Сценарий и критерии приёмки являются редакционными рекомендациями. Клиентские аккаунты, API-вызовы Claude и действующие CRM-интеграции при подготовке материала не тестировались.