Как сменить модель в задаче агента Fable 5.2 и сохранить прогресс

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

Мы проверили этот подход через Ofox 10 ноября 2026 года: Fable 5.2 запросила чтение остатков, получила три синтетические строки и завершила нативный цикл инструмента. Затем мы начали новый разговор с Opus 5.5, передав контрольную точку, созданную приложением. Итоговый JSON прошёл независимые проверки каждого SKU и количества. Это демонстрация одного небольшого процесса передачи состояния, а не многочасовой тест агента или сохранение скрытых рассуждений.

Почему успешное переключение всё равно может потерять состояние

Официальная документация preserved thinking различает совместимость моделей и прогресс приложения. На описанных маршрутах Claude API и управляемых Google старые модели не читают thinking-блоки Fable 5.2; неподдерживаемые блоки могут быть удалены при успешном запросе. Привязка к аккаунту создаёт дополнительную границу, если продолжение обрабатывает другой аккаунт.

Это не значит, что любая смена модели — ошибка. Это значит, что успешного HTTP-статуса недостаточно для доказательства непрерывности рассуждений. Каталог Ofox указывает возможности маршрутизации, но не доказывает поведение каждой передачи подписанной истории между провайдерами или аккаунтами. Мы не проверяли воспроизведение между аккаунтами, и наша передача задачи намеренно от него не зависит.

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

Скачайте небольшой воспроизводимый пример

Скачайте checkpoint_demo.py. Требуются Python 3.9 или новее и стандартная библиотека. Проверки по умолчанию не вызывают API. Положите файл в пустую папку, чтобы генерируемые файлы не затронули существующую задачу.

Для полного цикла «запрос инструмента Fable → продолжение с результатом → новая сессия Opus» скачайте туда же run_handoff.py. Команда python3 run_handoff.py выполняет только локальные проверки. После задания OFOX_API_KEY команда python3 run_handoff.py --live явно запускает до трёх платных запросов, сохраняет запросы и ответы в новую папку handoff-run и проверяет результат. Автоматических повторов нет; уже существующую выходную папку скрипт не использует. Прежде чем создавать новый запуск, разберите неудачную попытку или попытку с неопределённым результатом.

Каждый запрос ограничен 4 096 выходными токенами и небольшим синтетическим телом. Эти границы ограничивают демонстрацию, но не являются универсальным денежным лимитом и не гарантируют бесплатность запроса, завершившегося тайм-аутом. Опубликованный скрипт повторяет проверенную нами последовательность запросов; его локальные проверки и сериализация запросов проверялись отдельно.

python3 checkpoint_demo.py self-test
python3 checkpoint_demo.py prepare

Первая команда выполняет положительные и отрицательные проверки. Вторая создаёт checkpoint.json и handoff.txt, отказываясь заменять существующие файлы. Данные — синтетический пример складских остатков, а не данные клиента или бизнес-рекомендация:

Нужно вывести max(target − available, 0) для каждой строки. Оформлять заказы явно запрещено. Строка с нулевым дефицитом тоже обязательна: ответ только с товарами, которые нужно пополнить, здесь неполон.

Сохраните доказательства до передачи другой модели

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

{
  "schema_version": 1,
  "task_id": "synthetic-stock-20261110",
  "objective": "Report shortage=max(target-available,0) for every SKU. Do not place orders.",
  "completed": [{
    "operation_id": "read-stock-1",
    "operation": "read_stock",
    "status": "verified"
  }],
  "pending": ["Produce all three SKU shortage rows", "Pass independent validator"],
  "side_effects": []
}

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

У реального агента сохраняйте контрольную точку в устойчивом хранилище после завершённого шага инструмента. Записывайте ID вызова для сопоставления в разговоре и отдельный стабильный ID операции для журнала приложения. У них разные задачи. Новая модель может создать другой tool-call ID для той же логической операции, поэтому ID от провайдера сам по себе не защищает от повторного действия в общем случае.

Проверенный цикл инструмента Fable

В первом запросе использовались anthropic/claude-fable-5.2, нативный endpoint Messages Ofox, output_config.effort: "low", max_tokens: 4096 и один инструмент read_stock со схемой входа в виде пустого объекта. Выбор инструмента — auto.

Ответ завершился с tool_use и запросил read_stock с {}. Скрипт проверил имя и аргументы, вернул три строки примера с соответствующим tool_use_id и сохранил всё содержимое ассистента. Второй запрос Fable завершился с end_turn и сообщил дефицит 3, 0 и 4.

Это нативное продолжение важно: наличие контрольной точки не оправдывает сломанный цикл инструмента. Если запрос к той же модели падает из-за несовпадающего ID, сначала исправьте сопоставление результатов инструментов. Если ошибка указывает на подписанную историю, используйте диагностику подписи thinking и проверки обновления до 5.2.

Для крошечного арифметического примера мы намеренно выбрали low effort. Это ничего не говорит об усилии для сложной длительной задачи. Кроме того, указание aws_bedrock в каталоге не доказывает конкретный вышестоящий аккаунт для определённого ответа; в записи нашего теста зафиксированы нативный endpoint Ofox и полученный ID модели.

Передайте новой модели явное описание продолжения

Сгенерированный handoff.txt содержит:

Resume this read-only task from verified application state.
Do not claim access to prior reasoning.
Do not call tools or place orders.
Return only a JSON object with key rows, containing every SKU
and integer shortage. No Markdown.
Checkpoint: [the complete generated checkpoint JSON]

Создайте принимающий запрос из этого файла. При выполнении пример расходует кредиты API; команды локальной подготовки выше — нет.

import json
from pathlib import Path

request = {
    "model": "anthropic/claude-opus-5.5",
    "max_tokens": 4096,
    "output_config": {"effort": "low"},
    "messages": [{"role": "user", "content": Path("handoff.txt").read_text()}],
}
Path("handoff-request.json").write_text(json.dumps(request))

curl --fail-with-body --max-time 180 \
  https://api.ofox.ai/anthropic/v1/messages \
  -H "x-api-key: $OFOX_API_KEY" \
  -H 'anthropic-version: 2023-06-01' \
  -H 'content-type: application/json' \
  --data-binary @handoff-request.json > handoff-response.json

В запросе нет прежних сообщений ассистента или подписанных thinking-блоков. Он продолжает задачу, а не тот же разговор провайдера. Поэтому смена модели здесь не требует редактирования старого префикса. Для более крупной задачи нужен более полный пакет доказательств — с расположением источников и нерешёнными вопросами, а не с длинным непроверенным рассказом.

Независимо проверьте полученный результат

Извлеките только завершённый текстовый вывод, разберите его как JSON и запустите приложенный валидатор:

import json
from pathlib import Path

r = json.loads(Path("handoff-response.json").read_text())
if r.get("stop_reason") != "end_turn":
    raise SystemExit("Incomplete response; inspect before accepting.")
text = "\n".join(b["text"] for b in r.get("content", []) if b.get("type") == "text")
result = json.loads(text)  # Reject prose and Markdown instead of guessing.
Path("result.json").write_text(json.dumps(result, indent=2))

python3 checkpoint_demo.py validate result.json

Фактический ответ Opus был разобран в такой объект:

{"rows":[{"sku":"DEMO-001","shortage":3},{"sku":"DEMO-002","shortage":0},{"sku":"DEMO-003","shortage":4}]}

Валидатор принял три строки с общим дефицитом 7. Он проверяет точное покрытие SKU, дубли ID, целочисленные типы и каждое заново вычисленное количество. Строка вроде "3", булево значение, пропущенные или лишние SKU и неверные числа отклоняются. Отдельная проверка контрольной точки отклоняет изменённые хеши источника/результата, неподтверждённую операцию чтения и неожиданные побочные действия.

Для этой задачи детерминированные проверки дают более сильное основание, чем вопрос одной из моделей: «Ты уверена, что ответ полный?» Но их область намеренно узка: скрипт не проверяет произвольный бизнес-процесс, не получает актуальные остатки и не является промышленной транзакционной системой.

Что показал запуск и чего он не доказывает

Во всех трёх ответах число токенов чтения и создания кэша равно нулю. Применение проверенных стандартных публичных тарифов даёт $0,022008 за три запроса: соответственно $0,004816, $0,014024 и $0,003168. Это расчёт по использованию, а не отдельно сверенный счёт. Статья со сравнением объясняет тарифы и почему столь маленький тест не определяет рейтинг моделей.

Мы не вызывали реальный сбой сервиса, не проверяли передачу thinking между аккаунтами, не сравнивали множество задач и не доказывали надёжность автоматического fallback. Исходные данные были синтетическими, инструмент чтения работал локально, заказы не отправлялись. Сами ответы моделей были реальными ответами API.

Англоязычный скриншот локально отображённого журнала теста, заполненного реальными ответами API. Это не скриншот интерфейса продукта Ofox.

Для прерывания записи нужен другой подход

Повторить операцию только для чтения может быть допустимо, если понятны актуальность и стоимость. Для записи тайм-аут оставляет более опасный вопрос: успела ли внешняя система выполнить действие до потери ответа клиентом?

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

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

Подберите контрольную точку под итоговую работу

Для исследовательского отчёта передавайте URL источника, извлечённые доказательства, статус утверждений и открытые вопросы. Для таблицы — версии ввода, ID строк, правила преобразования и проверки вывода. Для изменения кода — commit или diff, реально запущенные тесты, ошибки и оставшуюся работу. Сохраняйте доказательства завершённого, а не только процент прогресса.

Начните миграцию с одной задачи только для чтения, одной смены модели и независимого критерия приёмки. Расширяйте процесс, когда разберётесь со случаями отказа. Руководство по API описывает первое подключение, а нативный Messages Ofox и маршрутизация провайдеров — возможности интеграции. Непрерывность состояния остаётся ответственностью приложения, даже если следующий запрос успешен.