Это масштабное обновление изменило мой способ работы с Claude Code

AAI LABS
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Ни одной модели Claude не достаточно самой по себе. У Opus есть логика, но она быстро
00:00:04тратит ваши лимиты. Sonnet быстрая, но пасует перед сложными задачами. И решение не в выборе
00:00:10одной из них, а в их совместном использовании. Claude Code уже делает это в некоторой степени.
00:00:14Он сам распределяет задачи между моделями. Но Anthropic только что выпустили нечто,
00:00:18что не только экономит токены, но и делает маленькие модели почти такими же мощными, как большие.
00:00:23Работая с Claude, вы могли это заметить. Когда вы даете Opus задачу,
00:00:28и она понимает, что та не требует больших усилий, она передает ее Sonnet или Haiku,
00:00:32делегируя работу меньшим моделям для управления расходом токенов. Но в этом подходе есть проблема.
00:00:37Как мы упоминали в прошлом видео, Anthropic снижают лимиты,
00:00:42поэтому в часы пик ваше 5-часовое окно заполняется быстрее. К тому же, Opus тратит много
00:00:47токенов даже на простые задачи, а значит, с Opus ваш лимит контекста исчерпается быстрее.
00:00:52В Anthropic решили изменить правила игры и представили решение под названием
00:00:55стратегия «Советник» (Advisor). Суть в том, что роль исполнителя вы отдаете модели
00:01:00Sonnet, а Opus используете чисто как советника, к которому обращаются только при необходимости.
00:01:05В процессе участвуют два агента. Исполнитель — ваш основной агент на Sonnet, он отвечает
00:01:10за вызовы инструментов, правки кода и вывод данных пользователю. Советник работает на Opus,
00:01:15и его единственная задача — направлять исполнителя, когда тот застревает. Советник не пишет код.
00:01:20Эксперименты Anthropic показали, что такой подход превосходит одну Sonnet на тестах
00:01:25SWE-bench. Комбинация оказалась лучше Sonnet и по производительности, и по стоимости.
00:01:31Это значительно дешевле, чем использовать Opus как основного агента, так как Opus вызывается
00:01:36только тогда, когда это действительно важно, а не на каждой итерации. Вы можете подумать,
00:01:40что у нас и так полно готовых фреймворков для создания приложений, зачем возиться с этим?
00:01:45Причина в том, что большинство фреймворков не учитывают стоимость и эффективность токенов.
00:01:50Хотя они справляются с работой, им не хватает эффективности, чтобы Claude работал дольше,
00:01:54так как они сфокусированы на создании приложения, а не на оптимизации расхода токенов.
00:01:59С этой настройкой можно создать рабочее приложение на слабой модели, сделав
00:02:04весь процесс гораздо экономнее. И это возвращает нас к проблеме лимитов.
00:02:09Мы уже советовали переходить на меньшие модели, чтобы лимитов хватало надолго.
00:02:13Связь такова: Sonnet потребляет гораздо меньше токенов и ресурсов, чем Opus,
00:02:19выполняя ту же задачу. Opus — очень большая и мощная модель, поэтому она тратит много
00:02:24токенов даже на мелочи. Sonnet справляется со многими задачами эффективнее. Поэтому
00:02:30использование Opus только для сложных решений — это то, что дает реальный эффект.
00:02:35Вы призываете эту мощь только по нужде, а не для каждой задачи. Это делает
00:02:40использование токенов оптимальным и позволяет успеть больше. Мы делимся
00:02:45всем, что находим о создании ИИ-продуктов, на этом канале, так что если хотите больше —
00:02:50подписывайтесь и следите за обновлениями. Мы решили протестировать это
00:02:55на приложении, которое уже было построено на Sonnet. Чтобы включить стратегию в Claude Code,
00:03:00мы задали команду advisor с Opus 4.6 в качестве советника. Основным агентом-исполнителем
00:03:05была Sonnet, на которой я и собирал приложение. Приложение должно было иметь синхронизацию,
00:03:10и если перемещение элементов работало идеально, то удаление не синхронизировалось вообще.
00:03:16Мы пытались отладить это несколько раз с одной Sonnet, но проблема сохранялась,
00:03:20как бы она ни старалась. Тогда, включив Opus-советника, мы дали Claude промпт
00:03:25с описанием проблемы. Так как Sonnet уже несколько раз потерпела неудачу, вместо новой
00:03:30попытки она решила обратиться к советнику. Советник изучил историю диалога,
00:03:34чтобы оценить ситуацию. Он выдал точный список правок, указав,
00:03:40где именно ломалась логика и что нужно переделать. Модель-исполнитель приняла
00:03:45эти советы и применила исправления сразу, без лишних уточнений. Мы проверили это
00:03:50на разных устройствах и увидели, что проблема решена. Удаления теперь
00:03:55отображались корректно, даже если один пользователь выбрал объект, а другой удалил его,
00:04:00чего раньше не было. Если бы мы исправляли это только с помощью Sonnet,
00:04:05потребовалось бы гораздо больше итераций, так как Sonnet сама по себе слабее
00:04:09и не всегда тянет сложную логику. С другой стороны, использование только Opus
00:04:15сожгло бы уйму токенов и вряд ли было бы таким быстрым. Тандем Sonnet и Opus
00:04:20сделал процесс намного эффективнее. В целом, эта стратегия помогла отладить синхронизацию
00:04:25быстрее, чем раньше. Но прежде чем продолжить, пара слов о спонсоре — Juni от JetBrains.
00:04:30Если вы разработчик, вы знаете, как тяжело переключаться между терминалом, IDE и CI
00:04:36просто чтобы сделать работу. Большинство агентов запирают вас в одной среде или с одной LLM.
00:04:41Juni CLI другой. Это независимый от модели кодинг-агент, который работает везде: в терминале,
00:04:47IDE, GitHub, CI/CD и даже таск-менеджере. Один агент для всего. Поручайте ему
00:04:54реальные задачи: тесты, бэкенд, рефакторинг, авто-ревью кода при каждом коммите.
00:04:59Сейчас JetBrains проводит программу раннего доступа: $50 в кредитах Gemini для тестов
00:05:04и поддержка своих ключей (BYOK). Полный доступ ко всем функциям и поддержка
00:05:10напрямую от команды разработчиков. С Juni всё просто лучше.
00:05:15Переходите по ссылке в комментариях. Далее мы проверили, будет ли Sonnet
00:05:20советоваться при крупных изменениях UI. У нас было готовое приложение,
00:05:25интерфейс которого мы хотели перевести на другую библиотеку. Вдобавок,
00:05:31мы хотели внести сразу пачку правок, что обычно не советуют, чтобы посмотреть на их связку.
00:05:36Сначала агент изучил текущий UI через Playwright MCP. Поняв структуру,
00:05:41он не бросился сразу кодить, а обратился к советнику за лучшим планом,
00:05:46так как это критическое изменение, которое могло всё сломать при неверном подходе.
00:05:50Советник сообщил, что выбранная библиотека конфликтует по версиям
00:05:55с той, что уже была в проекте. Так что прежде чем менять UI, Claude нужно было
00:06:00решить эту проблему. Sonnet сделала это первой, выполнив команды для обновления зависимостей,
00:06:04затем проверила состояние через Playwright, чтобы убедиться, что приложение всё еще работает.
00:06:09Когда с зависимостями было покончено, она начала вносить изменения по совету Opus,
00:06:14прорабатывая компонент за компонентом и фактически перерисовывая всё приложение.
00:06:18Новый интерфейс стал более интерактивным и выглядел гораздо качественнее.
00:06:23Оставались небольшие огрехи, но прогресс был очевиден. И вот тут проявились ограничения.
00:06:27Весь процесс занял около 31 минуты. Opus в одиночку справился бы быстрее,
00:06:32потому что он лучше распределяет задачи, понимая, что можно запустить параллельно.
00:06:37Sonnet, будучи моделью поменьше, делала всё последовательно, не разбивая
00:06:43работу на параллельных субагентов. Для не самого сложного приложения
00:06:4831 минута — это слишком долго. Мелкие правки она по-прежнему делает сама,
00:06:53не привлекая советника, и это правильно. Но для масштабных изменений
00:06:58во всем приложении лучше использовать Opus напрямую — это сэкономит вам массу времени.
00:07:03Теперь мы проверили внедрение совершенно новой функции в существующий код.
00:07:08Мы хотели добавить в приложение еще одну страницу с другим функционалом.
00:07:13Мы дали промпт с описанием и ожидали, что модель обратится за советом,
00:07:17так как задача не из простых, но она пошла внедрять всё сама, вообще
00:07:22не спрашивая советника. Она восприняла это как рутинную работу,
00:07:27хотя масштаб задачи говорил об обратном. При тестировании
00:07:31мы нашли кучу багов. При изменении чего-либо и нажатии кнопки «Run»
00:07:37правки заголовков или цветов отражались на компонентах вне области предпросмотра,
00:07:41чего быть не должно. Плюс мы хотели синхронизацию без постоянных нажатий «Run».
00:07:46Мы дали повторный промпт и велели использовать советника для исправления.
00:07:51После этого она первым делом вызвала агента-советника. Советник изучил
00:07:56реализацию и понял, в чем причина обеих проблем. Оказалось,
00:08:00выбран неверный компонент. Он расписал, что нужно изменить и почему старый подход
00:08:06создавал эти баги. Исполнитель взял руководство и применил его ко всему приложению.
00:08:10При повторном тесте стриминг заработал правильно. Все изменения отражались мгновенно
00:08:16в процессе редактирования. Проблема с «растеканием» правок по другим компонентам
00:08:20исчезла, всё обновлялось строго в своих границах. Бывает,
00:08:25что всё работает как надо, но иногда исполнитель ошибочно считает задачу мелкой
00:08:30и не идет к советнику. В таких случаях его приходится подталкивать вручную.
00:08:35Модель не всегда оценивает сложность так же, как вы, и когда она ошибается,
00:08:40вылезают баги, которые советник мог бы отловить сразу. Также,
00:08:44если вам нравится наш контент, жмите кнопку хайпа — это помогает нам расти.
00:08:49С распределенным состоянием в реальном времени этому подходу всё равно
00:08:54потребовалось несколько раундов правок. Стратегия помогает, но у нее есть потолок,
00:08:58который стоит понимать, прежде чем выбирать ее для проекта.
00:09:02Для простых и средних приложений стратегия «Советник» может сэкономить
00:09:07несколько кругов уточнений, которые вы бы потратили, пытаясь выжать из Sonnet максимум.
00:09:11Если разработка требует глубокой логики лишь изредка, а в основном состоит из
00:09:16написания кода — это отличная структура. Вы сделаете больше в рамках лимитов токенов,
00:09:20не контролируя каждый шаг модели и не переплачивая за Opus всю сессию.
00:09:25Для сложных систем со множеством зависимостей лучше сразу
00:09:30использовать Opus как основного агента. Даже когда Sonnet следует советам,
00:09:36она может выбрать неверный путь реализации, так как ей не хватает глубины,
00:09:40чтобы оценить все варианты и последствия. Советник помогает сократить
00:09:45этот разрыв, но не убирает его полностью. В таких случаях правки могут стоить дороже,
00:09:50чем если бы вы запустили Opus с самого начала. Итак, стратегия полезна,
00:09:54когда лимиты токенов поджимают, а задачи не требуют уровня Opus на каждом шагу.
00:09:58Если оба условия соблюдены — стоит попробовать. На этом всё.
00:10:03Если хотите поддержать канал и выход новых видео, вы можете сделать это
00:10:08с помощью кнопки супер-спасибо ниже. Как всегда, спасибо за просмотр,
00:10:12увидимся в следующем видео.

Key Takeaway

Стратегия «Советник» в Claude Code позволяет достичь производительности уровня Opus при затратах Sonnet, делегируя написание кода младшей модели и привлекая старшую только для архитектурного надзора и отладки сложных багов.

Highlights

Стратегия «Советник» (Advisor) использует Claude 3.5 Sonnet как исполнителя для написания кода и Claude 3 Opus как консультанта для решения логических тупиков.

Комбинированный подход превосходит одиночную модель Sonnet в тестах SWE-bench по производительности и стоимости.

Использование Opus только в критических ситуациях значительно экономит лимит контекста и токены в сравнении с работой на Opus по умолчанию.

В тестах рефакторинга интерфейса связка моделей потратила 31 минуту, что медленнее работы одиночной Opus из-за последовательного выполнения задач моделью Sonnet.

При внедрении новых функций Sonnet иногда ошибочно считает задачу рутинной и не обращается к советнику, что требует ручного принуждения через промпт.

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

Timeline

Ограничения одиночных моделей и архитектура Advisor

  • Claude Opus обладает высокой логикой, но быстро исчерпывает лимиты и бюджет токенов.
  • Claude Sonnet работает быстро, но не справляется со сложной логикой в изолированном режиме.
  • Роль исполнителя в новой стратегии отдается Sonnet, а Opus выступает в роли узкоспециализированного советника.

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

Экономическая эффективность и оптимизация ресурсов

  • Большинство AI-фреймворков игнорируют стоимость токенов в пользу функциональности приложения.
  • Переход на малые модели-исполнители увеличивает доступное время работы в часы пик за счет меньшего потребления ресурсов.
  • Вызов Opus по требованию дает максимальный эффект при минимальных затратах.

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

Практический тест: отладка синхронизации и UI

  • Команда advisor с параметром Opus 4.6 активирует режим консультации в Claude Code.
  • Советник выявил конфликт версий библиотек, который блокировал обновление пользовательского интерфейса.
  • Исполнитель мгновенно применил список правок от советника, устранив баги синхронизации, с которыми Sonnet не справлялась самостоятельно.

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

Ограничения стратегии и рекомендации по применению

  • Последовательный характер работы Sonnet увеличивает время выполнения масштабных задач до 30 минут и более.
  • Младшая модель может игнорировать советника при выполнении крупных задач, ошибочно принимая их за простые.
  • Для систем с множеством глубоких зависимостей использование Opus напрямую остается более быстрым и надежным вариантом.

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

Финальный вердикт по использованию тандема моделей

  • Стратегия «Советник» оптимальна для проектов, где глубокая логика требуется лишь изредка.
  • Разрыв в глубине понимания между Sonnet и Opus сокращается, но не исчезает полностью.
  • Выбор между «Советником» и одиночной Opus зависит от приоритета: экономия токенов или скорость реализации.

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

Community Posts

View all posts