Промпты для Claude Fable 5: что поменять для длинных агентов

Для чего рассчитана эта модель

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

Ходы по умолчанию стали длиннее

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

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

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

Уровни усилия под задачу

Уровень усилия (effort) - основной рычаг баланса между силой модели, задержкой ответа и стоимостью на Claude Fable 5. Для большинства задач по умолчанию подходит уровень high, для самых требовательных к возможностям - xhigh, а для рутинной работы достаточно medium или low. Даже пониженные уровни усилия на Fable 5 нередко превосходят максимальный уровень усилия у прежних моделей - стоит снижать усилие, если задача решается, но дольше, чем нужно, или если важнее интерактивный темп работы, чем максимальная тщательность.

На рутинной работе с высоким усилием модель иногда собирает контекст и рассуждает больше, чем требует задача, - но то же высокое усилие часто даёт отличную самопроверку и самый строгий результат. Чтобы избежать лишней уборки кода и рефакторинга там, где просили только исправить баг:

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

Сильное следование инструкциям

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

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

Проверка прогресса на длинных прогонах

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

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

Явные границы автономности

Claude Fable 5 иногда предпринимает незапрошенные действия - например, черновик письма, которое никто не просил написать, или защитную резервную ветку в git. Стоит прямо задать рамки того, что модель должна и не должна делать:

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

Параллельные субагенты и память

Claude Fable 5 охотнее прежних моделей запускает параллельных субагентов - стоит явно обозначить, когда делегирование уместно, и предпочитать асинхронное общение между оркестратором и субагентами блокирующему ожиданию каждого из них.

Модель особенно хорошо работает, когда может записывать выводы из прошлых прогонов и обращаться к ним позже - для этого достаточно простого markdown-файла с заметками:

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

Осторожно с просьбой показать ход рассуждений

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

Чек-лист