Режим рассуждения

Когда аналитик просит модель найти противоречия в ТЗ на сорок страниц, ответ «с ходу» будет хуже ответа после размышления. Режим рассуждения (extended thinking) даёт модели место подумать до того, как она начнёт писать ответ. В этом уроке разберём, как он устроен на актуальных моделях, чем управлять, сколько это стоит и какие правила действуют в агентном цикле.

Что происходит при рассуждении

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

Токены рассуждения оплачиваются как выходные, поэтому режим — не бесплатная кнопка «сделать лучше». Его нужно включать там, где задача этого стоит, и ограничивать там, где не стоит.

Адаптивный режим

На моделях начиная с поколения 4.6 (Opus 5, Opus 4.8, Sonnet 5 и других) режим рассуждения адаптивный: модель сама решает, сколько думать над конкретным запросом. На простой вопрос она почти не тратит токенов, на сложный — думает долго. Настраивать фиксированный бюджет не нужно.

const response = await client.messages.create({
  model: "claude-opus-5",
  max_tokens: 16000,
  thinking: { type: "adaptive", display: "summarized" },
  output_config: { effort: "high" },
  system: ANALYST_RULES,
  messages: [
    {
      role: "user",
      content: `Вот техническое задание:\n\n${spec}\n\nНайди требования, которые противоречат друг другу.`,
    },
  ],
});

for (const block of response.content) {
  if (block.type === "thinking") console.log("[рассуждение]", block.thinking);
  else if (block.type === "text") console.log(block.text);
}

На Opus 5 рассуждение включено по умолчанию: если параметр thinking не указан, модель всё равно работает в адаптивном режиме. Явное { type: "adaptive" } эквивалентно его отсутствию, но в коде лучше писать явно — так намерение видно тому, кто будет читать код после вас.

Старый способ — thinking: { type: "enabled", budget_tokens: N } — на Opus 5, Opus 4.8, Sonnet 5 и Fable возвращает ошибку 400. Он остался только на Haiku 4.5 и более ранних моделях. Если вы встретите budget_tokens в чужом коде или в старом примере из интернета, это признак устаревшего кода, а не рабочий рецепт.

Уровень усилия

Главный рычаг управления рассуждением — уже знакомый output_config.effort. Он влияет и на глубину рассуждения, и на общую подробность ответа, и на число вызовов инструментов в агентном цикле.

Для помощника аналитика логичны high или xhigh; для классификатора обращений — low. Не задавайте усилие глобально: у каждого маршрута в приложении свой уровень, подобранный по измерениям на реальных примерах.

Выключить рассуждение совсем на Opus 5 можно (thinking: { type: "disabled" }), но только при усилии high и ниже, и делать это не рекомендуется: с выключенным рассуждением модель иногда пишет вызов инструмента текстом вместо блока tool_use, и агентный цикл его не увидит. Хотите сэкономить — снижайте усилие, а не выключайте рассуждение.

Что видно в ответе

Поле display управляет тем, что вы получите в блоке thinking. По умолчанию на актуальных моделях оно omitted: блок приходит с пустым текстом, хотя рассуждение произошло и оплачено. summarized возвращает читаемое краткое изложение. Полный внутренний текст рассуждения не возвращается ни в каком режиме.

Зачем нужно summarized? Во-первых, для отладки: когда модель находит в ТЗ «противоречие», которого там нет, по изложению рассуждения видно, где она свернула не туда. Во-вторых, для интерфейса: если пользователь ждёт ответа десять секунд, показать ему «анализирую раздел про авторизацию…» лучше, чем пустой экран. В потоковом режиме изложение приходит событиями thinking_delta, а текст — text_delta, и их можно рендерить по-разному.

Рассуждение в агентном цикле

В цикле с инструментами блоки thinking попадают в response.content рядом с блоками tool_use. Правило то же, что и раньше: добавляйте в историю весь response.content без изменений. Блоки рассуждения нельзя редактировать, обрезать или удалять из истории — модель использует их на следующем шаге, и API проверяет их целостность. Если вы сохраняете историю в базу, сохраняйте блоки целиком, включая служебные поля.

Адаптивный режим сам переплетает рассуждение с вызовами инструментов: модель думает, вызывает get_diff, думает над результатом, вызывает read_file, думает снова. Никаких дополнительных параметров для этого не нужно.

Что рассуждение не делает

Рассуждение не заменяет хороший промпт и не добавляет модели знаний. Если в системном промпте помощника аналитика не сказано, что считать противоречием, модель будет долго думать и всё равно ответит не то. Сначала внятная постановка, потом усилие.

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