Transcription
Всем привет, я Шон. В этом видео я объясню суб-агентов Claude Code и команды агентов. Я расскажу, что это такое, чем они отличаются, а затем устрою им поединок в серии реальных задач, включая исследования, программирование и написание текстов.
Итак, если вы смотрите это видео, вы, вероятно, знакомы с Claude Code. Это один из многих кодовых агентов, которые мы видим в наши дни, по сути, это ИИ-агенты, способные создавать программное обеспечение. Если упростить, Claude Code состоит из двух ключевых компонентов.
Первый — это Claude, базовая большая языковая модель, которая принимает запросы и генерирует ответы на них. Но, возможно, более важным является второй ключевой компонент Claude Code — это все инструменты и программное обеспечение, построенные вокруг модели. Это включает в себя предоставление доступа к вашим локальным файлам, возможность поиска в Интернете, выполнения команд терминала, сжатия прошлых разговоров, перевода Claude в различные режимы, такие как режим мышления, режим чата и режим, в котором он будет продолжать генерировать текст и выполнять действия до завершения задачи. Он также может составлять списки дел перед выполнением сложных задач и задавать пользователю вопросы для сбора дополнительного контекста о данной проблеме.
Таким образом, когда мы объединяем эти два ключевых компонента — базовую большую языковую модель и набор инструментов и функций, построенных вокруг нее, — мы получаем кодовый агент, такой как Claude Code, который способен выполнять сложные задачи программной инженерии и, на самом деле, множество других видов задач, как мы увидим немного позже.
Хотя предоставление LLM правильных инструментов значительно увеличивает ценность, которую вы можете получить от нее, полагаться на одного агента для выполнения сложных задач имеет свои ограничения. Другими словами, чем больше и сложнее данная задача, тем больше контекста LLM потребуется обработать. И это создает ряд проблем.
Во-первых, существуют технические ограничения на объем текста, который LLM может обработать. Это определяется так называемым контекстным окном. Например, Claude Sonnet имеет контекстное окно в 200 000 токенов, что примерно соответствует объему текста, который вы найдете в длинном учебнике. Но в пределах этого контекстного окна нам нужно уместить всю информацию, которую мы хотим, чтобы агент обработал. Это включает в себя системное сообщение, то есть высокоуровневые инструкции для цели агента, инструменты, к которым агент имеет доступ, сообщения пользователя и различные запросы, которые мы делаем LLM. Если это модель мышления, у нее будут эти следы мышления или рассуждений. Все это будет в контекстном окне. Когда агент делает вызовы инструментов, это также будет в контекстном окне. Любой результат вызовов инструментов будет в контекстном окне. И ответы агента также будут в контекстном окне. И так далее, и так далее. Однако, если наш контекст превышает этот лимит, эта информация просто не будет доступна агенту.
Однако, даже если весь контекст помещается в контекстное окно, существует еще одно практическое ограничение, которое возникает при использовании этих агентов, — это явление, известное как "увядание контекста". Это наблюдение, что чем больше токенов в контекстном окне, эта ось X — количество токенов, а эта ось Y — производительность в этой конкретной задаче. По мере того, как контекстное окно становится все более и более полным, например, когда мы достигаем 50%, 60%, 70% контекстного окна, наблюдается снижение производительности модели. Таким образом, даже если мы не достигаем этих технических пределов контекстного окна, по мере того, как окно становится все более полным, агент может испытывать трудности с хорошим выполнением задач.
Это повышает важность управления контекстом. То есть простое обеспечение того, чтобы правильная информация находилась в контекстном окне в нужное время. И один очень мощный способ управления контекстом — это использование так называемых суб-агентов. Это просто идея делегирования задач новому специализированному экземпляру Claude Code.
Вот как это работает: пользователь отправляет запрос Claude Code, но вместо того, чтобы Claude просто выполнял задачу сам, он может делегировать часть, если не всю задачу, суб-агенту. Таким образом, экземпляр Claude, с которым мы взаимодействуем как пользователь, мы можем назвать основным агентом, а затем основной агент будет запускать этот суб-агент с узкой целью. Например, если мы попросим Claude Code исследовать все доступные сегодня инструменты кодовых агентов, вместо того, чтобы он просто делал это сам, он может запустить суб-агент, чтобы помочь ему провести исследование. А затем суб-агент выполнит некоторую работу, получит результаты и сообщит о них обратно основному агенту, который затем сможет все синтезировать и представить пользователю.
Но суб-агенты не ограничиваются одним. Claude может запускать любое количество суб-агентов по своему желанию. Это очень полезно для исследовательских задач. Таким образом, основной агент может запускать несколько суб-агентов. Они могут проводить исследования с разными поисковыми запросами или исследовать разные области. И каждый из них будет давать результаты, и они будут сообщать эти результаты обратно основному агенту, который затем будет все синтезировать и отвечать пользователю.
Суб-агенты — это действительно комбинация трех ключевых вещей. Это модель с инструментами и целью. Таким образом, существует несколько встроенных суб-агентов, которые поставляются "из коробки" с Claude Code. И если вы хоть раз использовали Claude Code, вы, вероятно, видели, как они запускаются во время работы.
Первый суб-агент — это агент исследования, который использует самую маленькую модель Anthropic — Haiku. Он имеет доступ к набору инструментов только для чтения, и его цель — обнаружение файлов, поиск кода и, по сути, понимание того, как работает кодовая база.
Еще один встроенный — это агент планирования, который использует ту же модель, что и основной агент. Так что, если основной агент — Sonnet, то агент планирования тоже будет Sonnet. Если основной агент — Opus 4.6, то агент планирования тоже будет Opus 4.6. И агент планирования также имеет доступ только к инструментам для чтения. И он запускается, когда пытается исследовать кодовую базу и придумать план реализации.
Наконец, есть агент общего назначения, который, по сути, является копией основного агента. Таким образом, модель будет такой же, как у основного агента. Он будет иметь доступ ко всем инструментам, к которым имеет доступ основной агент. Это будет отлично подходить для сложных исследовательских задач или многошаговых операций и просто для более сложных вещей.
Но, конечно, вы не ограничены этими тремя суб-агентами. Вы можете создавать свои собственные. Так что, если, например, вы хотите создать агент, который специально занимается проверкой кода определенным образом, вы можете запустить его.
И, таким образом, в конечном итоге, способ создания суб-агента — это создание текстового файла. И текстовый файл имеет две ключевые части. Есть эта часть метаданных, называемая "фронт-маттер". И здесь будут такие вещи, как имя суб-агента. Там будет описание суб-агента, которое основной агент может просмотреть, когда он пытается решить, какие суб-агенты могут быть полезны. Там будут перечислены все инструменты, к которым имеет доступ этот суб-агент, и будет определена модель, которую будет использовать этот суб-агент.
А затем вторая часть — это инструкции для суб-агента. Эта часть очень короткая. Она взята из документации Claude Code. Но вы можете представить, что это может быть очень длинный и сложный запрос для суб-агента. Так что, особенно если у вас есть определенный способ проверки и аудита кода, и у вас есть определенные стандарты кодирования, которые должны быть соблюдены, все это может быть включено в эти инструкции.
Мощная сторона суб-агентов заключается в том, что они обычно вызываются автоматически. Основной агент имеет доступ к имени и описанию всех созданных вами суб-агентов и может просто решить, какие из суб-агентов, если таковые имеются, актуальны для текущей задачи. Кроме того, если вы хотите, чтобы основной агент конкретно использовал суб-агент, вы можете просто сказать ему об этом. Например, если вы только что внедрили новую функцию, вы можете конкретно сказать: "Используй суб-агент для проверки кода, чтобы проверить этот код". Тогда не будет никаких догадок. Claude вызовет нужный вам суб-агент.
Однако с суб-агентами все еще остается проблема, заключающаяся в том, что вся информация все равно должна проходить через суб-агент. Вот снова картинка с суб-агентами, которую мы видели пару слайдов назад. И вот узкое место. Таким образом, эти суб-агенты могут выполнять много работы, но будет сохранена только информация, сообщенная обратно основному агенту.
Это поднимает два ключевых ограничения. Во-первых, суб-агенты могут общаться только с основным агентом. Они не могут общаться друг с другом. Так, например, суб-агент один и суб-агент два выполняют задачу, которая имеет некоторую зависимость друг от друга. Допустим, агент А создает фронтенд, агент Б создает бэкенд, и было бы полезно, если бы они могли общаться друг с другом, чтобы убедиться, что бэкенд и фронтенд хорошо сочетаются. Однако с суб-агентами они не могут делать это напрямую. Им придется генерировать свой вывод, а затем основной агент будет отвечать за интеграцию этих двух вещей, и если возникнут какие-либо проблемы, основной агент должен будет решить, как дать суб-агентам инструкции по обновлению кода, будь то обновление фронтенда или бэкенда, или чего-либо еще.
И второе ограничение заключается в том, что, поскольку все должно проходить через основного агента, мы сталкиваемся с той же проблемой, которую видели ранее, — это проблемы с контекстом. Таким образом, основной агент имеет ограниченное контекстное окно, и основной агент может быть подвержен увяданию контекста.
Таким образом, один из способов смягчить эти ограничения — это использование команд агентов. И это, по сути, просто позволяет суб-агентам общаться друг с другом. Здесь у нас та же картинка. Пользователь отправляет запрос основному агенту. Но теперь, вместо того, чтобы просто запускать суб-агент, основной агент создаст этот общий список задач и запустит полную команду агентов с различными директивами. И тогда у этих суб-агентов будет возможность напрямую взаимодействовать с этим общим списком задач. Таким образом, они могут брать задачи и отмечать их как выполненные, не обращаясь к основному агенту. Они могут просто напрямую обновлять этот общий контекст.
Еще одна ключевая вещь заключается в том, что суб-агенты могут общаться друг с другом. Так что теперь, если агент А занимается фронтендом, агент Б — бэкендом, а агент С — верификатором, фронтенд и бэкенд агенты могут свободно общаться друг с другом. Затем верификатор может общаться как с фронтенд, так и с бэкенд суб-агентами, давая им обратную связь, убеждаясь, что все выглядит хорошо.
Таким образом, каждый агент будет работать независимо, выполняя свою часть проекта, и они будут работать до тех пор, пока не закончат. А затем основной агент будет как бы контролировать все. Он будет следить за общим списком задач, а затем, когда все будет сделано, он все проверит и убедится, что задача действительно выполнена, а затем сможет взаимодействовать с пользователем.
На момент записи этого видео команды агентов все еще являются экспериментальной функцией. Поэтому, если вы хотите их включить, вам придется делать это вручную. И один из способов включить это — на уровне проекта. Так что вы можете зайти в свою папку проекта. Вы можете создать эту папку .claude. Так что это будет скрытая папка, на которую Claude будет смотреть. А затем вы можете создать этот файл settings.json. Затем в этом файле вы можете просто установить эту переменную claude_code_experimental_agent_teams в единицу. По умолчанию она будет равна нулю, что означает, что команды агентов не включены. А затем вы просто меняете ее на единицу, включая функцию команд агентов.
Затем, когда вы хотите, чтобы Claude создал команду, вы можете просто сказать ему: "Создай команду агентов для выполнения x, y и z". Вы также можете сказать Claude, кого вы хотите видеть в команде. Так что, опять же, вы можете сказать: "Сделай одного агента, сосредоточенного на фронтенде, одного — на бэкенде, и одного — на проверке кода и запуске юнит-тестов и тому подобного".
Мы говорили о суб-агентах и командах агентов, что это такое и как их настроить. Теперь я хочу рассмотреть их сходства и ключевые различия.
Ключевое сходство заключается в том, что оба этих подхода позволяют Claude делегировать задачи новым экземплярам Claude Code. И это очень мощный способ управления контекстным окном основного агента, особенно для таких вещей, как исследования, которые могут быть очень объемными по количеству токенов. И если Claude занимается скрейпингом веб-страниц и выполняет множество различных поисков и множество различных вызовов инструментов, большая часть этой информации не будет иметь отношения к конечной задаче, которую вы пытаетесь выполнить. Таким образом, это просто добавит много шума в контекстное окно и потенциально ухудшит производительность.
Однако среди ключевых различий заключается в том, что с суб-агентами эти суб-агенты не могут общаться друг с другом. С командами агентов эти суб-агенты могут общаться друг с другом. С суб-агентами у нас есть так называемая централизованная архитектура. И вот, в моем предыдущем видео я говорил о многоагентных системах, где мы видели эти два ключевых типа архитектур. Один назывался централизованным, а другой — децентрализованным.
Централизованная архитектура — это когда есть основной агент с набором суб-агентов, которые могут взаимодействовать только с основным агентом. Они не могут взаимодействовать друг с другом. Таким образом, существует четкая иерархия между оркестратором и рабочими агентами.
С другой стороны, децентрализованная архитектура была больше похожа на рой агентов, где нет иерархии. Все агенты равны друг другу. Они все могут общаться друг с другом и просто атакуют проблему без четкой иерархии.
Это сделало бы команды агентов этой гибридной архитектурой, где существует четкая иерархия между ведущим агентом и суб-агентами. Но поскольку суб-агенты могут общаться друг с другом, эта часть архитектуры децентрализована. Таким образом, команды агентов смешивают централизованную и децентрализованную архитектуры, о которых я говорил в предыдущем видео.
Наконец, архитектура суб-агентов проще и более отказоустойчива. Если один суб-агент совершает ошибку, она не будет распространяться на всех остальных агентов, распространяя эту ошибку. Вместо этого она будет передана только основному агенту, который сможет ее просмотреть и убедиться, что вывод корректен, прежде чем что-то с ним делать.
Команды агентов, с другой стороны, более сложны, и существует потенциал для каскадных ошибок, поскольку все эти суб-агенты могут общаться друг с другом. Возможно, один из этих суб-агентов совершит фатальную ошибку и распространит эту дезинформацию на всех остальных суб-агентов, что приведет к проблемам и снижению производительности.
Таким образом, главная мысль здесь о том, когда использовать суб-агенты против команд агентов, заключается в том, что суб-агенты хороши для последовательных задач, где вам нужен этот единый поток сознания, и вам нужно выполнить задачу А, затем задачу Б, затем задачу В. Однако команды агентов очень хороши для параллелизуемых задач. Например, если команда строит сложную кодовую базу, вы можете иметь одного агента, реализующего фронтенд, другого — бэкенд, или даже бэкенд можно разделить на несколько частей, таких как основная логика, затем аутентификация, а затем интеграция Stripe. И вы можете иметь суб-агент, ответственный за каждый из этих компонентов, и тогда они смогут общаться друг с другом, чтобы оставаться согласованными. И это потенциально позволяет Claude Code создавать более крупные, более сложные приложения без проблем эффективного управления контекстным окном.
Последнее, чем я хочу поделиться, — это мини-эксперимент, который я провел, сравнивая суб-агентов с командами агентов. Итак, что я здесь сделал, это устроил этим двум подходам поединок на трех задачах. Первой была составление списка потенциальных клиентов для местных средних компаний в районе Даллас-Форт-Уэрт. Второй — создание приложения, которое брало бы плейлист YouTube и превращало его в онлайн-курс без отвлекающих факторов. И затем последняя задача — проектирование и создание целевой страницы.
Моя гипотеза заключалась в том, что команды агентов будут лучше подходить для параллелизуемых задач, таких как создание списка потенциальных клиентов, в то время как суб-агенты будут лучше подходить для последовательных задач, таких как создание этого приложения для создания курсов на YouTube. А затем для создания целевой страницы я не был уверен, потому что это своего рода смесь как последовательных, так и параллелизуемых задач.
А затем некоторые ключевые моменты экспериментальной установки. Я использовал идентичные запросы для запуска суб-агента и команды агентов, за исключением первой строки. Для команды агентов я конкретно сказал Claude использовать команду агентов и не выполнять задачу самостоятельно. Но в остальном запросы были идентичны.
Еще одна важная вещь заключается в том, что я сделал только один прогон на задачу на подход. По сути, я дал подходу с суб-агентами и подходу с командами агентов один шанс выполнить задачу. И это было в основном для снижения затрат, потому что эти многоагентные системы могут работать долго и сжигать много токенов. И для оценки производительности каждого подхода на каждой задаче я смотрел на такие вещи, как общее время выполнения, количество токенов и качество вывода, о чем мы поговорим. И если вам интересно, весь код находится на GitHub по этой ссылке здесь и ссылка в описании ниже.
Задача первая заключалась в сборе списка из 50 контактов из местных средних технологических компаний, а я нахожусь недалеко от Далласа, штат Техас. Так что для меня "местный" означает это. Конечным результатом для этой задачи является просто CSV-файл с 50 контактами из различных средних компаний, с которыми стоит связаться для моих услуг по обучению ИИ.
Вот результаты оценки. Если посмотреть на время выполнения, команды агентов были намного быстрее. И это просто потому, что команда смогла запустить несколько агентов, которые работали параллельно. Таким образом, команда агентов смогла выполнить задачу на 8 минут быстрее.
Следующее — это предполагаемое количество сгенерированных токенов для выполнения задачи. Здесь команда агентов сожгла примерно на 30 000 токенов больше для выполнения задачи. И это естественно, потому что не только она создала больше суб-агентов, но и суб-агенты должны общаться друг с другом, что также увеличивает стоимость токенов. Но, на удивление, разница в токенах оказалась не такой большой, как я ожидал. Я ожидал, что это будет скорее кратное увеличение. Например, в 2 или 3 раза больше, чем подход с суб-агентами, а не просто незначительный процент от подхода с суб-агентами.
Следующее, на что я посмотрел, — это общее количество контактов. Таким образом, оба системы произвели список из 50 контактов. Но загвоздка была в том, что команда агентов предоставила электронные письма только для восьми из этих людей, в то время как подход с суб-агентами имел электронное письмо для каждого человека. Это было несколько неожиданно. Я ожидал, что команда агентов справится с этой задачей лучше. Но я думаю, возможно, она не была достаточно настойчива в обеспечении хорошего выполнения задачи. Я думаю, она стала самодовольной и просто перешла к восьми электронным письмам вместо полных 50.
Вторая задача заключалась в создании этого небольшого веб-приложения, которое принимало бы плейлист YouTube и превращало его в курс без отвлекающих факторов. Сначала я покажу, как выглядели конечные результаты, а затем мы пройдемся по тем же метрикам по одной строке за раз.
Слева — приложение суб-агента, а справа — команда агентов. Вероятно, самое поразительное — это то, что дизайн суб-агента выглядит намного лучше. Например, цвета лучше. Также названия видео обрезаются в боковой панели, но на самом деле они переносятся в боковой панели для дизайна суб-агента. Другое, что действительно выделялось, — это то, что суб-агент добавил индикатор выполнения, в то время как приложение команды агентов не имело индикатора выполнения. Но помимо этого, все основные функции были на месте. Например, вы могли добавлять заметки, отмечать урок как завершенный. Все видео в этом плейлисте действительно были там, и оно предоставляло естественный интерфейс для навигации по всем видео.
Но опять же, глядя на эти ключевые метрики, команда агентов работала быстрее, примерно на 2 с половиной минуты быстрее, чем подход с суб-агентом. Опять же, подход с суб-агентом не сжег столько токенов, он использовал около 99 000, в то время как команда агентов использовала 111 000. Но в целом, я снова отдам это суб-агенту, что было ожидаемо, потому что при создании простого одностраничного веб-приложения, такого как это, наличие согласованности, которую вы получаете с одним агентом, полезно, потому что все может просто поместиться в контекстное окно. Полезно иметь полный контекст того, что вы пытаетесь построить, что вы построили, и вы не пытаетесь координировать действия с другими агентами.
В целом, моя оценка заключалась в том, что приложение суб-агента имело лучший дизайн и индикатор выполнения, который мне понравился, в то время как команда агентов имела худший дизайн и не имела индикатора выполнения. Но помимо этого, все остальное было примерно одинаковым.
Еще одна вещь, которая выделялась, — это то, что для этой задачи, поскольку она не была очень параллелизуемой, в подходе с командой агентов Claude действительно создал суб-агентов, но каждый агент был заблокирован предыдущим агентом. Таким образом, даже несмотря на то, что была запущена эта команда, задачи все равно выполнялись по одной за раз. Таким образом, по сути, было создано три агента, но затем они просто работали по одному за раз, поэтому мы не получили значительной экономии времени.
Наконец, я попросил каждый подход создать целевую страницу. Это было не просто создание веб-сайта, но и хорошее проектирование целевой страницы и написание убедительного текста. Таким образом, большая часть этого заключалась в исследовании лучших практик создания целевой страницы. Также исследование моего опыта и прошлых образовательных предложений.
Мы посмотрим на конечные результаты бок о бок. Опять же, я чувствую, что подход с суб-агентом имел лучший дизайн, просто глядя на него. Итак, у нас есть эта кнопка "Присоединиться к списку ожидания" постоянно наверху, что, я думаю, является хорошим подходом. У нас есть приятный заголовок. Мне нравится раздел FAQ. Команда агентов не создала раздел FAQ. Однако, читая сам текст, я чувствую, что подход команды агентов справился намного лучше. Он также сделал сравнение бок о бок, для кого это предназначено, для кого нет, что хорошо. И последнее — это поле регистрации в списке ожидания, которое нужно было интегрировать с моей учетной записью ConvertKit. И это действительно сработало для обеих реализаций. Так что было здорово это увидеть.
Окончательные цифры здесь: на удивление, суб-агент работал быстрее. И это оказалось так, потому что команда агентов потратила много времени на исследование не только меня и моего опыта, но и на исследование копирайтинга и лучших практик создания целевых страниц. Так что, я думаю, именно поэтому финальный текст был намного лучше для подхода команды агентов. Опять же, мы видим, что подход с суб-агентом произвел гораздо меньше токенов. Но я бы сказал, что, как окончательный вердикт, целевая страница суб-агента имела лучший дизайн, но целевая страница команды агентов имела лучший текст. Так что здесь не было явного победителя. Если бы я хотел двигаться дальше с этим, я бы использовал немного того и другого.
Этот эксперимент прошел не совсем так, как я ожидал. Подход команды агентов оказался не таким мощным, как я ожидал или надеялся. Но основные выводы следующие. Во-первых, команды агентов, как правило, делали вещи быстрее, чем просто один агент, который мог запускать суб-агентов. Однако, хотя это заняло меньше времени, команды агентов сгенерировали больше токенов по всем трем задачам, но не так много, как я ожидал. Опять же, я ожидал кратного увеличения, например, в 2, 3, 5 раз больше генерации токенов.
Другое наблюдение заключалось в том, что суб-агенты последовательно давали лучшие результаты, чем команды. И я думаю, что это в конечном итоге связано с тем, что команды агентов все еще являются экспериментальной функцией. Так что, на мой взгляд, низкое качество вывода может быть связано с незрелой структурой, а не с ограничениями архитектуры команд агентов, этой гибридной архитектурой, смешивающей централизованный и децентрализованный подходы. Я подозреваю, что по мере того, как все больше людей будут пробовать команды агентов и Anthropic будет получать больше отзывов, они сделают ее лучше. Но на данный момент я, вероятно, буду придерживаться суб-агентов для фактического выполнения задач. А затем, возможно, я буду использовать команды агентов для проведения большего количества экспериментов и просто для изучения того, что возможно.
Но в качестве последнего замечания, это не претендует на истину в последней инстанции, это просто призвано дать вам небольшое представление о поведении каждого из этих подходов. Но если вы экспериментировали с командами агентов и специализированными суб-агентами, мне было бы очень интересно услышать о вашем опыте и ваших выводах. Так что не стесняйтесь делиться ими в комментариях ниже. Это было бы очень полезно для меня и других зрителей.
Если у вас есть какие-либо вопросы о чем-либо из того, что я здесь осветил, или предложения по будущему контенту, дайте мне знать в комментариях ниже. И, как всегда, большое вам спасибо за ваше время и спасибо за просмотр.