Laravel AI SDK 1.0: что проверить при переносе диалогов

При переходе на Laravel AI SDK 1.0 недостаточно обновить зависимость: нужно проверить сохранённые диалоги, ожидание подтверждения инструмента, потоковый экран и расчёт использования. Главный риск для работающего сервиса — сохранить текст переписки, но потерять смысл выполненного или ещё ожидающего действия. Приёмку стройте по продолжению старого разговора, а не только по новому приветствию.

Что объявлено в сентябре

Анонс от 23 сентября 2026 года описывает выпуск 1.0 и прямо предупреждает о несовместимых изменениях хранения conversations, middleware, usage и stream protocols. Поэтому обзор посвящён миграции существующего приложения. Номер первого выпуска не означает, что именно его следует выбирать вместо актуальных исправлений.

Перед внедрением сверяйте выбранную версию с официальными уведомлениями безопасности проекта. Эта статья не подтверждает защищённость конкретной установленной сборки и не предлагает выполнять обновление на рабочем сервере по одному анонсу.

История разговора — это последовательность, а не только текст

Официальное руководство обновления описывает замену отдельных tool_calls и tool_results на steps: результат хранится у породившего его вызова, сохраняются шаги обращения к модели. Состояние сообщения также меняется с approval_state на status. Для перенесённых таблиц нужен отдельный переход данных; прежняя миграция пакета не запускается повторно автоматически.

Для бизнеса это означает, что старый разговор нужно уметь не просто показать, но и правильно продолжить. Если результат отделён от нужного вызова, следующая реплика может опираться на неверное действие. Если ожидание согласия выглядит выполнением, интерфейс сообщит человеку больше, чем действительно произошло.

Это собственная матрица вымышленного приложения. Она не является отчётом о выполненном обновлении клиента. Точные поля и действия следует сверить с выбранной версией руководства и собственными таблицами, особенно если проект менял стандартные имена.

Что сделать с незавершённым подтверждением

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

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

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

Новый диалог не заменяет проверку старого

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

Отдельно проверьте идентификацию участника и доступ к разговору. Исправление формата хранения не должно расширять доступ между пользователями или организациями. Для приёмки достаточно обезличенных данных; настоящие обращения не нужно переносить в открытый стенд.

Потоковый интерфейс и учёт использования

Анонс выделяет поддержку протоколов обмена с frontend и изменение middleware на уровень шагов. Если приложение рассчитывало на единственный проход обработки, проверьте смысл своих побочных действий. Например, уведомление или запись расхода не должны незаметно повторяться из-за прежнего допущения.

Там же описана смена promptTokens/completionTokens на inputTokens/outputTokens и включение полных счётчиков провайдера. Число после обновления может иметь другой состав, поэтому нельзя автоматически назвать его рост увеличением цены той же работы.

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

Как организовать переключение без ложной уверенности

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

Проверьте связанные зависимости, используемые интеграции и способ фонового выполнения. Не переносите весь список возможностей SDK в план проекта, если приложение ими не пользуется. Приёмка должна покрывать собственные применяемые пути и их ограничения.

1. Зафиксируйте текущие таблицы, версии и используемые возможности.
2. Подготовьте разрешённые учебные истории разных состояний.
3. Разберите ожидания подтверждения до изменения формата.
4. Проверьте связь вызова, результата и шага после переноса.
5. Продолжите старые разговоры и проверьте права доступа.
6. Сверьте потоковый UI, обработчики и отчёт использования.
7. Согласуйте переключение и восстановление с учётом новых данных.

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