Claude Opus 4.7 пропустил задачу в агентном режиме: тот же баг, что у дешёвой Gemma 4

Claude Code отрапортовал: работа закончена. 4 задачи из 5 отмечены как выполненные. Пятая, "Commit and open PR", осталась открытой. Агент перешёл к следующему запросу, будто незакрытого пункта и не существует.

Это был Claude Opus 4.7 с максимальным уровнем рассуждений (extra-high thinking). Самая мощная модель, которая у меня есть, на самой высокой настройке.

Контекст. Я разрабатываю открытый агентный фреймворк Tuplet. Архитектура по задачам простая:

Ответственность за корректное закрытие списка лежит на модели. Фреймворк не навязывает поведение - предоставляет API.

На прошлой неделе я тестировал в Tuplet модель Google Gemma 4. Цена привлекательная: около 8 центов за миллион токенов. Для продакшена на потоке это разница между рентабельным и нерентабельным сценарием.

На практике Gemma 4 регулярно "забывала" задачи. Из 5 пунктов отмечала 2-3. Остальные пропускала. Работу заявляла завершённой. Проверяешь список - половина не сделана.

Диагноз казался очевидным: модель слабая, контекст держит хуже, дисциплины меньше. Классическое "вы получаете то, за что платите".

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

Идея такая: добавить в Tuplet слой верификации. Агент не может объявить работу законченной, пока в списке есть открытые пункты. Если пытается - фреймворк возвращает ошибку и требует либо закрыть оставшиеся задачи, либо явно их отменить с обоснованием.

Небольшой прототип я уже подкрутил. Полноценная реализация - в планах на ближайшее время.

В голове всё было логично: это помощь слабым моделям типа Gemma 4, чтобы они работали надёжно. Opus 4.7 такая страховка не нужна - он и так справляется.

Так я думал ровно до сегодняшнего утра.

Запускаю Claude Code на реальной задаче. Агент создаёт план из 5 шагов, работает 48 секунд, выдаёт результат.

На скриншоте: 4 галочки, одна пустая. "Commit and open PR" - незакрытая. Агент пишет: работа закончена.

Дальше интереснее. Я задаю другой, не связанный с этим списком вопрос. Агент отвечает. Открытая задача как стояла открытой, так и висит. Никакой попытки её закрыть, никакого упоминания, что что-то недоделано.

Если бы я не посмотрел на список сам, я бы просто поверил агенту на слово и пошёл дальше.

Сразу оговорюсь: Opus 4.7 и Gemma 4 ломаются не одинаково. Разница в частоте огромная:

Но редкие случаи - не то же самое, что их отсутствие. И это принципиально меняет выводы.

Раньше я относился к framework-level guardrails как к дополнительной работе, нужной только чтобы дешёвые модели хоть как-то работали. Мол, Opus 4.7 это всё не нужно.

Сейчас я вижу иначе. Это страховка для всей системы:

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

Продакшен-системы строятся на гарантиях, а не на том, что "обычно работает". Раньше я это знал применительно к базам данных и распределённым системам. Теперь - применительно и к LLM-агентам.

Возвращаюсь к плану по Tuplet с другим настроением. Делаю верификацию задач уже не "ради Gemma 4", а как базовую часть любого производственного агента. Это примерно та же история, что с типизацией, тестами и транзакциями - скучные слои, которые дают главное свойство системы: предсказуемость.

Кто работает с Claude Opus 4.7 в агентных сценариях - как ощущения в сравнении с 4.6? Стало заметно лучше держать длинные списки задач, или разница в пределах погрешности?

И второй вопрос - тем, кто строит агентов: вы полагаетесь на дисциплину модели, или уже вводите какие-то жёсткие проверки на уровне фреймворка?

#AI #ИИ #LLM #AIАгенты #Разработка