Anthropic только что убила ваши фреймворки для ИИ-агентов

AAI LABS
Computing/SoftwareManagementInternet Technology

Transcript

00:00:00За последние несколько месяцев мы рассмотрели множество фреймворков для ИИ-кодинга, включая BMAD, GSD, Speckit и Superpowers,
00:00:08и многие из вас начали их использовать. Но Anthropic только что провела эксперименты на собственном полигоне,
00:00:14удаляя компоненты один за другим и измеряя, что действительно имеет значение. Их вывод: большая часть этого теперь — балласт.
00:00:17Каждый компонент во фреймворке кодирует предположение о том, чего модель не может сделать сама,
00:00:25но с Opus 4.6 эти предположения устарели. Мы изучили всё и выяснили, что всё ещё важно, что можно убрать,
00:00:32и как на самом деле должна выглядеть ваша настройка сейчас. Агентные оболочки играют важную роль
00:00:37в том, чтобы агенты работали существенно лучше на длинных дистанциях. Anthropic уже выпустила свою оболочку,
00:00:43которую мы подробно разбирали в прошлом видео, объясняя, как её настроить и использовать. Мы также рассматривали
00:00:50другие фреймворки в том же контексте, и хотя их реализации различаются, все они преследуют одну цель. Но когда
00:00:55эти фреймворки вышли, модели не были так способны, как Opus 4.6 сейчас. Например, фреймворки вроде GSD
00:01:01сосредоточены на изоляции контекста, но для Opus 4.6 это не проблема. И дело не только в окне в миллион токенов,
00:01:06есть и другая причина, о которой мы скоро поговорим. Поэтому многие ранее внедренные фреймворки теперь
00:01:11являются лишней нагрузкой для новых возможностей моделей. Anthropic провела эксперименты, тестируя разные аспекты оболочки,
00:01:17удаляя каждый из них и измеряя влияние. По результатам они пришли к выводу, что всё, что действительно нужно агенту,” —
00:01:24это агенты для планирования, генерации и оценки. Остальное — лишь способы работы, ставшие балластом
00:01:29при нынешних способностях моделей. Основная теория в том, что каждый компонент в любой агентной оболочке
00:01:35опирается на один и тот же принцип: он кодирует предположение о том, что модель может сделать сама.
00:01:38Эти предположения нужно проверять на прочность, так как они могут быть ошибочными и устаревать по мере улучшения моделей,
00:01:46что они и сделали в статье. Следовательно, с эволюцией моделей должна эволюционировать и ваша оболочка,
00:01:54и если вы работаете по принципам многомесячной давности, вы отстаете. Планирование — это первый шаг,
00:02:01который остается неизменным во всех фреймворках, но способ планирования должен меняться для более мощных моделей.
00:02:06Прежние оболочки Anthropic для длительных задач требовали от пользователя детальной спецификации на старте.
00:02:14Фреймворки вроде BeMad и SpecKit буквально дробят задачу на мелкие фрагменты и микрозадачи, помогая агенту
00:02:20легко их внедрять. Это были не просто задачи, а детальные шаги, которым агенты следовали не раздумывая.
00:02:27Это было необходимо, так как модели тогда были недостаточно умны и нуждались в микро-руководстве. Но с Opus 4.5 и 4.6
00:02:30ситуация изменилась. В Anthropic обнаружили: если планировщик прописывает микротехнические детали заранее,
00:02:43одна ошибка вызывает каскад проблем на всех уровнях реализации, мешая агенту отклониться и исправить её самому.
00:02:45Всё зависело от качества плана. Поэтому планирование теперь стало высокоуровневым, а не детальным техническим ТЗ.
00:02:50Агенты стали намного умнее, и теперь достаточно просто указать, какие результаты нужны. Они сами разберутся,
00:02:55как к ним прийти. С этим сдвигом подходы к планированию в BeMad и SpecKit теряют свою актуальность.
00:02:57Вы можете ограничить BeMad этапом планирования до генерации PRD (документа о продукте),
00:03:02без необходимости переходить к техническому дроблению. Как мы упоминали, генерация PRD в BeMad эффективна,
00:03:08потому что там есть специализированные агенты для понимания требований, которые справляются лучше, чем чистая Claude.
00:03:18У этих агентов есть внешний контекст для конкретных задач, добавленный автором. Как вариант,
00:03:23можно использовать сессию вопросов из Superpowers, так как она предназначена для выявления крайних случаев,
00:03:32что может быть эффективнее многоуровневой документации. Но главная проблема излишне детального планирования в том,
00:03:40что оно сковывает агента и не оставляет места для открытий и самостоятельного поиска решений. Anthropic также привела
00:03:46пример плана от агента-планировщика, который вы можете использовать для настройки своего собственного агента.
00:03:52В нем четко указано, что план должен фокусироваться на масштабе и границах вашей идеи приложения.
00:03:56Суть в том, чтобы держать проект на уровне продукта, а не реализации. Это важно, так как при попытке
00:04:06спланировать реализацию внутри проекта, агент слишком уходит в технику и может не выдать целостный продукт.
00:04:12Вы можете подумать, что режим планирования в самой Claude делает то же самое, задавая вопросы и давая детальный план.
00:04:22Но разница вот в чем: даже с планировщиком Claude всё равно сильно фокусируется на деталях реализации,
00:04:31а не на уровне продукта, что идет вразрез с выводами Anthropic. Поэтому, настроив всё правильно, вы можете
00:04:40просто попросить Claude использовать вашего агента для планирования приложения — он создаст полный план
00:04:44и сохранит его в папку. План включает разбивку функций на уровне продукта и пользовательские истории для каждого этапа,
00:04:47что помогает Claude внедрять именно те рабочие процессы, которые ожидают пользователи. Но прежде чем продолжить,
00:04:56пара слов о нашем спонсоре — Minimax. Настройка ИИ-агентов — это кошмар: API-ключи, конфиги серверов, Docker,
00:04:59и в итоге ваш ассистент всё забывает сразу после закрытия вкладки. Решение — MaxClaw, облачный ИИ
00:05:02всегда под рукой. Никаких настроек и головной боли, вы можете развернуть свой собственный OpenClaw.
00:05:12Просто нажмите "развернуть", и вы в эфире менее чем за 10 секунд. Он создает сайты, пишет код, проводит исследования
00:05:21и автоматизирует рутину по текстовым подсказкам. MaxClaw подключается к Telegram, Slack, Discord и другим сервисам,
00:05:27позволяя автоматизировать процессы, искать инфо в сети и даже генерировать изображения или видео прямо в чате.
00:05:33Это часть Minimax Agent, ИИ-среды, где каждый может стать дизайнером агентов. Работает на Mac и Windows,
00:05:39базируется на M 2.7, который не уступает Claude Opus 4.6 в тестах Sweetbench. Хватит бороться со сложными настройками,
00:05:42доверьтесь MaxClaw — ссылка в закрепленном комментарии. Агент, пишущий код, не должен сам его оценивать.
00:05:46Это вторая по значимости проблема, которую редко обсуждают. Самопроверка проблематична: если тот же агент,
00:05:56что писал код, его оценивает, он склонен отвечать очень уверенно и хвалить свою работу, даже если качество хромает.
00:06:03Это проще контролировать в задачах с количественными метриками, например, работают ли внедренные API.
00:06:08Но проблема обостряется в задачах без четко проверяемых результатов. Самый яркий пример — это интерфейс (UI).
00:06:10Понятие "хороший UI" субъективно, и ИИ может не до конца понять ваши намерения. Он может счесть свою реализацию
00:06:15отличной, даже если она не соответствует вашим стандартам. Создатели многих фреймворков это осознали
00:06:19и внедрили свои механизмы оценки. Все фреймворки, что мы разбирали (GSD, BMAD, Superpowers), гарантируют,
00:06:26что пишущий код агент не будет его оценивать. Такой подход значительно повышает точность и надежность
00:06:34проверок. Поэтому, используете ли вы готовый фреймворк или строите свой, убедитесь, что проверяющий
00:06:39полностью отделен от исполнителя. Перед началом работы агенты генерации и оценки заключают контракт,
00:06:47согласовывая критерии готовности. Это помогает, так как оба агента четко знают, чего нужно достичь и что проверять.
00:06:54Даже при высокоуровневом планировании нужны конкретные шаги. Но во время тестов оболочки
00:06:58они попробовали убрать "спринт-контракт". Оказалось, что Opus 4.5 был менее эффективен в этом случае,
00:07:02так как оценщику всё равно приходилось вмешиваться. Но с Opus 4.6 возможности модели выросли настолько,
00:07:06что контракт стал не нужен. Генеративный агент был способен справиться с большей частью работы сам.
00:07:12Таким образом, для меньших моделей типа Sonnet или Haiku всё еще нужно документировать задачи, правильно
00:07:18разбивать их на спринты и согласовывать критерии готовности. Но с мощными моделями можно полагаться
00:07:22на Opus для выполнения высокоуровневого плана без лишних шагов. Мы говорили, что изоляция контекста важна.
00:07:27Это потому, что маленькие модели испытывают "контекстную тревогу" — феномен потери связности
00:07:32на длинных задачах по мере заполнения окна контекста. В такие моменты они завершают работу преждевременно
00:07:38и утверждают, что всё сделано верно, хотя это не так. Решением был сброс контекста — очистка окна
00:07:42перед началом реализации. После очистки они могли опираться на внешнюю разбивку задач, которая
00:07:51сохранялась между сбросами. Но тревога была настолько сильной, что одного сжатия не хватало.
00:07:57Требовались дополнительные меры для предотвращения проблем на долгих задачах. Однако начиная с Opus 4.5,
00:08:02модели больше не ведут себя так. Эти агенты могут работать непрерывно всю сессию, и того, как Claude
00:08:08сжимает данные, достаточно для их работы. Следовательно, сбросы контекста больше не нужны, как и детальные
00:08:13разбивки задач из BMAD или SpecKit — высокоуровневого руководства теперь вполне достаточно.
00:08:17Агент-генератор — это главный исполнитель, который строит приложение фича за фичей.
00:08:21Он берет спецификации из плана и последовательно внедряет их, интегрируясь с Git для контроля версий.
00:08:28Генератор работает в связке с агентом-оценщиком. После создания функции он передает её на тест
00:08:37и получает фидбек для правок. Его рабочий процесс разбит на этапы: понимание задачи, реализация
00:08:42и доработка. Даже фаза реализации делится на четыре подфазы для разных аспектов. Он следует дизайну,
00:08:47проверяет свою работу и передает её оценщику. Это создает структурированную схему, позволяя агенту
00:08:50строить всё приложение самостоятельно и систематично. Агент-оценщик выступает оппонентом генератора.
00:08:56Его задача — убедиться в правильности реализации, не просто формально ища баги, а критически подходя к делу,
00:09:02исходя из того, что баги точно есть. Он может использовать Playwright для симуляции действий пользователя,
00:09:07выявлять ошибки по критериям и отправлять отчет генератору. Читая план, оценщик понимает,
00:09:11что значит "готово", и тщательно всё проверяет перед одобрением. У каждого фреймворка свой валидатор,
00:09:18но подходы разные. BMAD использует специализированных агентов для код-ревью и QA, которые запускают тесты
00:09:21и оценивают код с разных сторон. GSD использует под-агента верификации, который сверяет результат с планом
00:09:30и создает отчет. Superpowers полагается на свежих под-агентов и строгий TDD, где никакой код не пишется
00:09:39раньше тестов. Попытки обойти это блокируются. SpecKit считает спецификации истиной и позволяет агенту
00:09:46проверять код по документации. Но ни один из них не дает механизма оценки с той строгостью,
00:09:50к которой стремились в Anthropic. Поэтому оценщик в их оболочке ближе всего к жесткому контролю Ральфа Лупа
00:09:57для Claude, гарантируя результат через систему баллов. Кстати, если вам нравится наш контент, жмите кнопку хайпа,
00:10:04это помогает нам расти и охватывать больше людей. Агент сам не знает, как выглядит идеальный результат для вас,
00:10:10особенно в субъективных вещах. Поэтому используются механизмы оценки по баллам, чтобы он понимал
00:10:13ваши ожидания. Когда Anthropic приводила пример метрик для фронтенда, они отметили, что ИИ часто выдает
00:10:18однотипные результаты. Они установили четыре критерия оценки для обоих агентов. Первый — качество дизайна:
00:10:24проверка на целостность, а не просто набор разрозненных компонентов. Затем — оригинальность,
00:10:35это важно, так как ИИ часто скатывается к стандартным фиолетово-белым градиентам. Это противоречит
00:10:43человеческому подходу, где каждый выбор осознан, и сразу заметно, если сайт выглядит плохо. Третий — мастерство:
00:10:49детали вроде типографики, отступов и гармонии цветов, где всё выверено технически и эстетически.
00:10:54И последний — функциональность, так как в UI каждый элемент визуально улучшает опыт пользователя.
00:11:02Claude уже хороша в функциональности, но с остальным есть трудности, и промпты должны заставлять её
00:11:06выдавать максимум, делая упор на качество дизайна. При создании приложения вы можете задать свои критерии
00:11:12для любых фич: архитектуры кода, фронтенда, UX-потоков и прочего. У каждого пункта в критериях должен быть
00:11:19свой балл, чтобы модель понимала приоритеты. Эти файлы используются оценщиком, так как его работа — выставлять
00:11:27оценки по заданному рубрикатору. Учитывая всё сказанное, что же вам делать теперь? Если вам нужен готовый
00:11:37фреймворк для легкого старта, выбирайте GSD, так как он по умолчанию использует цикл "план-генерация-оценка",
00:11:44хотя его оценщик просто сверяет код с планом и ждет одобрения пользователя. Там используется система
00:11:54прошел/не прошел, а не баллы. Поэтому можно взять лучшее от Anthropic и внедрить в GSD, заменив оценщика
00:12:02и добавив критерии. Но если вы хотите использовать именно подход Anthropic, вы можете реализовать его,
00:12:10создав агентов под конкретные роли и объединив их в команды. В команде один агент будет генератором,
00:12:17а другой — оценщиком. Преимущество команд в том, что агенты общаются напрямую, а под-агенты
00:12:21вынуждены писать в документы, что создает лишнюю нагрузку. Так Claude создает задачи на основе плана
00:12:35и запускает обоих агентов: один внедряет, а другой через Playwright MCP тестирует всё в браузере,
00:12:49ожидая обновлений от генератора. Оценщик постоянно проверяет работу и сообщает об ошибках,
00:12:58и они в координации создают приложение, отвечающее вашим стандартам. Все использованные здесь агенты
00:13:03и ресурсы доступны в AI Labs Pro для этого и прошлых видео, откуда вы можете их скачать. Если вам ценно то,
00:13:10что мы делаем, поддержка канала — лучший способ отблагодарить. Ссылка в описании. На этом видео
00:13:24подходит к концу. Если хотите помочь нам делать такие ролики и дальше, воспользуйтесь кнопкой Super Thanks.
00:13:33Как всегда, спасибо за просмотр, и увидимся в следующем видео!
00:13:43Это приносит нас к концу этого видео. Если вы хотите поддержать канал и помочь нам продолжать делать видео, подобные этому, вы можете сделать это, используя кнопку супер спасибо ниже.
00:13:48Как всегда, спасибо за просмотр, и я увижу вас в следующем.
00:13:57До встречи!

Key Takeaway

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

Highlights

Модели Opus 4.5 и 4.6 устранили необходимость в микро-менеджменте задач, так как излишняя детализация планов ведет к каскадным ошибкам при реализации.

Разделение ролей на агента-генератора и агента-оценщика является обязательным условием для предотвращения предвзятости и завышенной уверенности ИИ в качестве своего кода.

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

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

Инструмент Playwright позволяет агенту-оценщику проводить реальное тестирование интерфейса в браузере, имитируя действия пользователя для выявления багов.

Timeline

Устаревание традиционных агентных фреймворков

  • Компоненты старых фреймворков кодируют предположения о слабостях моделей, которые больше не актуальны для Opus 4.6.
  • Фреймворки типа GSD, BMAD и SpecKit превращаются в балласт из-за роста внутренних способностей нейросетей.
  • Эволюция моделей требует немедленного упрощения внешней программной оболочки агентов.

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

Сдвиг от микро-менеджмента к высокоуровневому планированию

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

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

Принцип разделения ответственности и агент-оценщик

  • Агент, написавший код, не способен объективно его проверить из-за склонности к самовосхвалению.
  • Полная изоляция проверяющего от исполнителя критически важна для задач с субъективными результатами, таких как верстка интерфейса.
  • Увеличение мощностей Opus 4.6 сделало ненужными предварительные контракты на спринты и регулярные сбросы контекста.

Самопроверка ИИ часто приводит к ложной уверенности в успехе, особенно в дизайне. Модели склонны утверждать, что задача выполнена идеально, даже если UI не соответствует ожиданиям пользователя. Решением становится создание оппонента, который изначально ищет ошибки. При этом современные модели избавились от «контекстной тревоги» — страха потери данных при заполнении окна контекста, что позволяет им работать над длинными проектами без принудительной очистки памяти.

Методология оценки и практическое внедрение

  • Агент-генератор последовательно внедряет фичи, интегрируясь с Git и проходя через циклы правок от оценщика.
  • Система баллов по рубрикатору заставляет модель избегать шаблонных решений и фокусироваться на качестве типографики и эстетике.
  • Командное взаимодействие агентов через прямую переписку эффективнее, чем использование громоздких общих документов.

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

Community Posts

View all posts