Transcription
В эпоху генеративного ИИ скорость, с которой вы можете создавать и управлять своими агентами, становится ограничением вашей инженерной производительности. Когда ваши агенты медленны, вы медленны. Когда у ваших агентов проблема, у вас проблема. Если вы используете агентов в масштабе, вы точно знаете, что я имею в виду. Прямо сейчас каждый инженер находится на одном из этих уровней. Базовые агенты, лучшие агенты, больше агентов и пользовательские агенты. Тема здесь проста. На каждом шагу вы масштабируете свои вычисления, чтобы масштабировать свое влияние. Речь идет уже не о том, что вы можете сделать. Речь идет о том, чему вы можете научить своих агентов делать для вас. Есть еще один уровень, один гигантский скачок вперед, которым я поделюсь с вами в этом уроке. Инженеры, такие как вы и я, использующие агентов каждый день. Мы все думаем об одном и том же. И голоса за Gentic Horizon это показывают. Чтобы масштабировать своих агентов, вам нужно управлять своими флотами агентов. Мультиагентная оркестрация — это следующий шаг в нашем путешествии как инженеров Gentic. Итак, позвольте мне представить вам одно мощное решение для мультиагентной оркестрации. Один агент, чтобы править всеми, агент-оркестратор. [Музыка] Это шаблон единого интерфейса, примененный к вашему флоту агентов. Это существующая инженерная парадигма, которую великие инженеры использовали десятилетиями. Мы применяем шаблон единого интерфейса к агентам. Но важен не только агент-оркестратор. Мы объединяем три столпа. Агент-оркестратор, ваш унифицированный интерфейс к вашим агентам. Ваш агент-оркестратор разблокирует CRUD для ваших агентов. Это дает вам агентов в масштабе. И, наконец, мы объединяем наблюдаемость для мониторинга в реальном времени производительности, затрат и, как вы увидите, результатов ваших агентов. Когда вы объединяете эти три, вы получаете мощное решение для мультиагентной оркестрации. Где наше поле ввода? Это не обычное приложение для обычных пользователей. Это для вас и меня, агентичного инженера. Мы максимизируем плотность информации, не теряя качества UX. Если мы нажмем Command K здесь, мы увидим наш интерфейс ввода подсказок. Он содержит полезные метаданные о возможностях этой кодовой базы, которые мы рассмотрим чуть позже. Мы начнем с простой подсказки ping. Наш агент-оркестратор, конечно же, даст нам быстрый ответ. Теперь давайте запустим несколько агентов. Мы создадим трех отдельных агентов. Мы попросим их обобщить кодовую базу, создать сводку структуры приложения внутри файла markdown с таблицами mermaid. Мы запустим это и по-настоящему продемонстрируем потенциал и возможности агента-оркестратора. Теперь наш агент-оркестратор создаст трех новых агентов, а затем даст им подсказки. Таким образом, у нас будет в общей сложности шесть уникальных вызовов инструментов, построенных вокруг управления и оркестрации агентов. Как вы можете видеть здесь, вот наш первый агент. Вот наш второй агент. И наш агент-оркестратор запустит нашего третьего агента. Прямо сейчас наш QA-агент, который будет выполнять работу по обобщению как фронтенда, так и бэкенда. Вот наш QA-агент. И вы сразу видите, что это дифференцированный опыт агентичного кодирования. С мультиагентной наблюдаемостью вы можете видеть все. Наблюдаемость является ключевым компонентом успешной мультиагентной системы. Почему это так? Потому что если вы не можете это измерить, вы не можете это улучшить. И если вы не можете это измерить, вы не можете это масштабировать. Хорошо? Если 10 агентов делают что-то не так, имеет ли значение, что их 10? Конечно, нет. Вот почему наблюдаемость является ключом. И именно поэтому оркестратор — это продвинутая концепция агентичного кодирования. Она идет последней, после пользовательских агентов. Вы можете видеть здесь, у нас есть интерфейс, который сообщает о работе каждого из наших агентов. Итак, у нас есть ответы, у нас есть инструменты, у нас есть мышление. Мы, конечно, можем фильтровать по любому из них. Мы можем фильтровать по ответам, отдельным вызовам инструментов, мы можем фильтровать по нашим отдельным агентам. Итак, вот только наш QA-агент. Наблюдаемость здесь имеет решающее значение для масштабирования влияния. С помощью одной подсказки я развернул в три раза больше вычислительных ресурсов, чем инженер, работающий в терминале. Хорошо. И это только начало. У нас есть два быстрых агента. Мы разделили эту работу на фронтенд, бэкенд, а затем у нас есть основной мощный агент, который будет выполнять ключевую работу по обобщению как фронтенда, так и бэкенда. И наш оркестратор позаботился о фактическом управлении и создании наших агентов. Если мы прокрутим вверх, вы можете увидеть все шесть вызовов инструментов. Создать агента, создать агента, создать агента, а затем три вызова команд. Уже у нас есть этот очень интересный шаблон, когда наш агент-оркестратор берет нашу высокоуровневую подсказку, а затем подробно описывает фактическую конкретную работу, которую мы хотим, чтобы наши агенты выполнили. Уже это дифференцированный опыт. Я сразу знаю, что некоторые инженеры подумают: разве это не просто субагенты? Почему вы просто не используете субагентов? Наличие основного агента, связанного с вашим агентом-оркестратором, дифференцировано. Вы будете видеть это снова и снова. Мы можем сделать гораздо больше, когда контролируем наши агентичные единицы с помощью нашего агента-оркестратора. И вы заметите на протяжении всего этого, что наш агент-оркестратор перестал работать, верно? Его задачи оркестрации на данный момент завершены. Он создал и управлял нашими агентами. Теперь наши агенты выполняют работу. И если мы перейдем к интерфейсу отдельного агента, вы увидите несколько ключевых вещей. У нас есть имя, у нас есть статус, у нас, конечно, есть контекстные окна. Мы управляем основными четырьмя элементами каждого агента, которого мы запускаем. Если вы не примете точку зрения своих агентов, если вы не знаете, что они могут делать, вы не знаете, что можете делать вы. У нас есть наши ответные сообщения, у нас есть вызовы инструментов и у нас есть хуки. И, конечно, у нас есть рассуждения. Вы можете видеть здесь, ни один из наших агентов здесь не думает. Они вообще не рассуждают. Это нормально. Для этих задач у нас, конечно, есть наши модели и наши затраты. Теперь произошло что-то невероятное. Как вы можете видеть здесь, наш основной QA-агент закончил свою работу. У нас есть потребленные им активы и произведенные им активы. Инженерия — это, прежде всего, коммуникация работы. Поэтому ваша мультиагентная система должна отражать это. Она должна демонстрировать это. И вот здесь, в одном ответном сообщении, вы можете увидеть фактические прочитанные файлы и произведенные файлы от нашего QA-агента с первого взгляда. Мы можем сделать что-то очень мощное. Мы, конечно, можем просто увидеть разницу прямо здесь, в строке, но что еще более важно, мы можем перейти в наш редактор одним щелчком мыши. Теперь мы работаем в цикле. Мы смотрим на этот файл. Мы фактически просматриваем и понимаем, что было сделано в режиме markdown. Здесь мы можем точно увидеть, что наш агент разбил для нас. И это отличная возможность поговорить об архитектуре кодовой базы. Вы должны наращивать свою инженерию с каждой точкой рычага агентичного кодирования, которую вы добавляете к своей кодовой базе. А затем вы строите систему, в которой вы находите такую, которая позволяет вам решать проблемы, пока вы продолжаете переходить от цикла к циклу. Есть так много проблем, которые вам не нужно решать, сидя в терминале, отправляя подсказки туда и обратно. Итак, имейте в виду, что специализированный инструмент, такой как этот, будет мощнее некоторых готовых облачных инструментов. Почему это так? Потому что эти инструменты разработаны для кодовой базы каждого, а не для вашей. Когда вы создаете что-то подобное, вы получаете специализацию до самого конца. Очень важно отметить, что я развернул это для нескольких кодовых баз. Я могу получить доступ в любое время и в любом месте через несколько устройств, и все это потому, что это разработано как система вне цикла. Вы можете видеть, что наши фронтенд и бэкенд агенты также завершили свою работу. Мы можем видеть все файлы, которые они потребили. Мы можем видеть фактические конкретные произведенные результаты. Хорошо, вы не получите этого с помощью готовых инструментов агентичного кодирования. Вы не получите этого ни с одним облачным инструментом, верно? Это специализированное решение для управления агентами в масштабе. Это мультиагентная оркестрация. Итак, мы можем углубиться в любой из этих результатов. Вы можете видеть здесь, наш бэкенд QA-агент очень усердно поработал над документацией бэкенда. Это все фантастика. Мы, конечно, можем углубиться в любую из них, если захотим, одним щелчком мыши, и нас перенаправят прямо в часть документации, которую мы затем можем настроить, удалить, изменить. Еще одно огромное преимущество нашей системы оркестрации заключается в следующем. Она разработана, чтобы помочь нам управлять нашими агентами в масштабе. Список агентов, а затем проверка статуса наших агентов. Хорошо. И это снова запустит нашего агента-оркестратора и заставит его фактически понять проделанную работу. Теперь это очень важно. Наш агент-оркестратор не всегда смотрит на результаты, верно? Я имею в виду, посмотрите, что только что произошло между всеми этими агентами. Это невероятно ошеломляет. Слишком много информации. Хорошо? И поэтому то, что мы сделали здесь с нашим агентом-оркестратором, это то, что мы разработали его как — это очень важно. Мы коснемся этого через мгновение. Мы разработали его как — он не всегда наблюдает за журналами. Он не может. Мы должны защитить его контекстное окно. Это верно для вашего O-агента. Это верно для ваших основных агентов. Вы всегда должны отслеживать и понимать основные четыре элемента каждого агента, которого вы запускаете. Помните, знаете, поверх каждой функции, любых сборок лаборатории, любого UI, который вы видите, любого опыта, это все просто основные четыре элемента. Никто не должен вас обманывать, хорошо? Контекст, модель, подсказка, инструменты. Знаете ли вы, что эти четыре точки рычага являются критическими в каждый момент? Хорошо, это ключ. Как вы можете видеть здесь, через наш интерфейс, у нас есть отличное представление о состоянии основных четырех элементов для всех наших агентов. Хорошо. И поэтому вы можете видеть здесь, агент-оркестратор, знаете, запускал некоторые специализированные инструменты, чтобы фактически проверить статус каждого агента, а затем он сообщает нам. Хорошо. Таким образом, этот шаблон единого интерфейса очень важен здесь для оркестрации агентов в масштабе. Мы защищаем контекстные окна. У нас есть специализированные, выделенные, сфокусированные агенты, верно? Сфокусированные на одной конкретной задаче. Это важно. Мы коснемся этого через мгновение. А затем наш агент-оркестратор сообщает нам. Хорошо, мы можем продолжить нашу работу. Это мощная часть наличия такой системы. Хорошо, мы можем построить все, что нам нужно, чтобы выполнить работу. Итак, вы можете видеть здесь, у нас есть куча метаданных. Мы рассмотрим это через мгновение. Давайте просто запустим это. Я скажу Command All Agents, создайте один раздел, одно предложение каждого ключевого узла в системе. Быстро, кратко, включите мышление. Хорошо, давайте включим режим мышления здесь, и мы приступим к запуску. Итак, снова здесь, шаблон тот же. Подсказка один, подсказка два, подсказка три. У нас есть значок мозга здесь. И теперь они начинают фактически обдумывать, что здесь происходит. Это должно быть просто краткое резюме. Они внесут небольшое изменение в верхнюю часть своего файла. Это не просто одноразовые субагенты, где контекст теряется или нам приходится управлять тем, что или где был субагент. Это основные агенты, к которым мы можем обращаться снова и снова, пока эта конкретная задача не будет выполнена. Хорошо. Произойдет кое-что очень важное. Знаете, вот наши результаты. Снова мы можем просто углубиться в них. Мы можем видеть все потребленные файлы по сравнению с произведенными файлами. Важно, чтобы наш агент-оркестратор мог обращаться к каждому агенту, когда ему нужно управлять ими, читать из них. Но опять же, мы не хотим, чтобы наш агент-оркестратор вмешивался в фактическую работу. Он здесь только для оркестрации. Давайте посмотрим на наше резюме фронтенда. Итак, если мы просто нажмем на это, мы должны увидеть ключевые узлы фронтенда. Итак, посмотрите на это. У нас есть ключевые компоненты. У нас есть композиты. У нас есть сервисы и у нас есть основные файлы. Так что это здорово, верно? У нас есть ключевое резюме. Вы можете видеть все ключевые технологии, которые мы использовали. Мы постоянно движемся от цикла к циклу. И мультиагентная оркестрация с O-агентом помогает нам уменьшить наше присутствие. Это помогает нам понять, что делают наши агенты. И это помогает нам масштабировать наших агентов. Теперь, когда работа выполнена, любая работа, которую вам нужно было выполнить вашему агенту, завершена. Хорошо? Есть путь, который проходит каждый инженер. Сначала вы учитесь читать код, затем вы создаете код, затем вы обновляете код, и, наконец, вы понимаете, что лучший код — это отсутствие кода. Вы учитесь удалять. Command K, удалить всех агентов. Агентичное инженерия ничем не отличается. Вы должны относиться к своим агентам как к удаляемым временным ресурсам, которые служат одной цели. Вы можете видеть, что здесь поступило три вызова инструмента. Наш агент-оркестратор уничтожил наших агентов. Работа сделана. Задача выполнена. Отпустите агентов домой. В уроке по тактическому агентичному кодированию шесть мы углубляемся в эту концепцию с одной ключевой тактикой. Это то, что более 80% всех инженеров постоянно заново открывают каждый раз, когда они расширяют свое контекстное окно. Мультиагентная оркестрация с нашим O-агентом позволяет нам делать именно это. Что мы делаем здесь? Мы используем фреймворк НИОКР. Мы обсуждали это в уроке по элитному контекстному инженерингу Agent Horizon. Кстати, если вы не прошли тактическое агентичное кодирование и предыдущие уроки Agent Horizon, остановите это видео, посмотрите их. Все это станет намного понятнее. Мы наращиваем нашу инженерию с помощью тактик агентичного кодирования и мощных паттернов снова и снова. Каждый урок имеет значение. Каждый урок был разработан с критической идеей, критической тактикой, чтобы расширить ваши возможности. Позвольте мне быть предельно ясным. Я очень рад большим эффективным контекстным окнам, но 200 тысяч контекстных окон достаточно. Вы просто загружаете одного агента слишком большим количеством работы, как это делал ваш босс на вашей прошлой работе. Не заставляйте вашего агента переключать контекст. Вы знаете, как это ощущается. Заставьте его сосредоточиться, а затем отпустите его домой, обратно в дата-центр. Удалите его. Итак, как это работает? Давайте сделаем шаг назад и поговорим на высоком уровне. Как это на самом деле работает? Позвольте мне быть предельно ясным кое в чем. Агент-оркестратор — это даже в случае с одним агентом многие инженеры едва используют потенциал своих агентов. Я буду использовать нашего разведчика-оркестратора и создавать простые плоские бесцветные серые таблетки для информации в заголовке приложения, ключевое слово здесь — местоположение в кодовой базе, активные рабочие журналы. Это здесь, верно? Так отображаются текущие затраты. Итак, мы просто создадим несколько простых UI-таблеток. Это простая одноразовая задача. Я просто хочу продемонстрировать вам эту подсказку. Мы запускаем небольшую команду агентов для выполнения задачи. Каждое контекстное окно. Каждая задача нашего агента будет сфокусирована. И вы можете видеть здесь, что эта подсказка вызвала мышление оркестратора. Наш оркестратор теперь думает и теперь запускает рабочий процесс. Итак, вот оно. У нас есть заголовок разведчика, и мы создадим двух агентов: разведчика и строителя. Вот наш строитель, вот наш разведчик, и наш разведчик приступит к работе после того, как наш оркестратор запустит его. Вот оно. Мы можем запускать и останавливать их одним запросом. Это еще один мощный пример мультиагентной оркестрации. У нас есть агенты, выполняющие работу, создающие полезные наборы информации, и они передадут это следующему агенту. Итак, мы говорим о планах, мы говорим о журналах, мы говорим о результатах, мы говорим о документации, а затем наш оркестратор связывает все это вместе. Посмотрите, что делает наш оркестратор здесь. Он фактически участвует в этом процессе. Итак, наш оркестратор находится в цикле сна. Вы, вероятно, видели этот шаблон. Ваш основной агент будет спать, запускать других агентов для выполнения некоторой работы, а затем проверять ее. Итак, это распространенный шаблон агентичного кодирования, который вы можете использовать, верно? Мы масштабируем вычисления для мониторинга этого мультиагентного рабочего процесса. И поэтому каждые 15 секунд он будет запускать проверку статуса агента на разведчике, чтобы увидеть, как дела у разведчика. И поэтому вы можете видеть, что разведчик только что закончил свою работу. Теперь мы получим произведенные активы, верно? Каждый агент должен производить конкретный результат. Иначе какой смысл? Мы, конечно, можем углубиться. Мы можем увидеть там резюме. И он точно знает, куда поместить эти файлы. Имейте в виду, сколько работы провел оркестратор до этого момента. И его контекст все еще плавает, потому что мы действительно весь контекст. Теперь наш оркестратор передал работу нашему агенту-строителю. Очень мощные вещи там. Есть еще один инструмент командного агента, и вы можете видеть, посмотрите на этот отчет. Посмотрите на этот подробный отчет, который наш оркестратор дал нашему строителю. Он занимается серьезным инжинирингом подсказок. Вы можете видеть поступающую работу. Имейте в виду, что эти агенты работают над этим проектом. Они работают над собой. Строитель очень точен, потому что у нас был разведчик, который искал изменения, которые нужно внести. Очевидно, относительно простое изменение UI, но мы привлекаем команду агентов, чтобы убедиться, что работа выполнена. Если вы можете выделить немного больше вычислительных ресурсов, чтобы иметь больше уверенности и доверия к своим агентам, почему бы и нет, верно? Вычисления могут решить так много ваших инженерных проблем, если вы заставите вычисления работать. Итак, вот наш строитель, который думает, верно? Мы можем просто углубиться во все мысли нашего агента здесь, если хотим. И, конечно, мы можем специализироваться только на журналах нашего агента-строителя. Если вы хотите видеть только отдельные инструменты, мы можем увидеть и это. Но больше всего нас интересуют результаты. Наш оркестратор снова думает, все еще выполняет, выполняет проверку. Выглядит отлично. Изменения на месте. Он проверит синтаксис для нас. Все это происходит для нас с нашей системой мультиагентной оркестрации. Все управляется нашим оркестрационным агентом. Мы объединили три критически важных компонента, чтобы разблокировать следующий уровень агентичного инженеринга. У нас есть оркестратор. У нас есть CRUD для агентов, чтобы мы могли разблокировать агентов в масштабе. И у нас есть наблюдаемость. Эти три элемента дизайна открывают что-то особенное. Мы собираемся сделать что-то немного более сложное, еще несколько изменений в UI. Мы хотим, чтобы наш список агентов сворачивался. И мы хотим обновить наш чат-оркестратор, чтобы он перешел в маленький режим, когда ширина браузера меньше 650. Мы будем предельно ясны здесь и скажем меньше. Хорошо, мы запустим это, и это, конечно, вызовет агентичную подсказку, разработанную для нашего оркестратора. Это то, чего многие инженеры не осознают. Как только вы создадите пользовательского агента, настоящая компромисс здесь, настоящий баланс заключается в том, что это требует времени для создания, верно? Очевидно, мультиагентная оркестрация и O-агент требуют первоначальных инвестиций, и вам нужно управлять вашим оркестрационным агентом. Вам нужно управлять подключением, базой данных, веб-сокет-соединениями, и это может быть много координации. Стоит ли в это инвестировать? Я думаю, ответ очень четкий — да. Вы хотите иметь, даже если вы не используете это, ключ здесь в том, что вы хотите иметь какую-то систему агентичного кодирования вне цикла, верно? Вы хотите иметь несколько режимов инженерии. Если вам нужно перейти в цикл, что мне пришлось сделать при разработке этого, мне приходилось делать это много раз. Вы можете, верно? Зайти в цикл, зайти в терминал, увеличить свое присутствие, верно? Отправляйте эти подсказки туда и обратно. Это нормально. Я полностью признаю, что это действительный режим инженерии. Но все больше и больше есть работы, которую вы не должны делать. Вы тратите свое время впустую. Правильный способ думать об инженерии сейчас — это агентичный способ. Вы хотите думать о масштабировании своих агентов. Помните тактику восемь. Точки принятия решений в цикле человека будут очень важны. Вы можете видеть простой интерфейс поверх этого, где ваш агент хочет задать вам вопрос. Ваш агент хочет побудить вас. Это ключевой момент в агентичном инженеринге, когда ваши агенты начинают задавать вам вопросы, а не наоборот. Что-то еще отсутствует. Если мы хотим форкнуть контекстное окно агента и, по сути, дублировать агента из определенной точки, это один инструмент, и благодаря облачному SDK агента, это несколько модулей, которые нужно разработать. Похоже, наш строитель закончил свою работу. Это фантастика. Вы снова видите всю проделанную работу. Один клик, верно? Ориентированная на результат инженерия в едином интерфейсе, верно? Наша система вне цикла очень, очень мощная. Многие системы полагаются на запросы на извлечение. Это здорово, но это упускает большую часть истории. Это упускает большую часть пути, верно? Мы получаем все это здесь с нашим интерфейсом наблюдаемости. Итак, наш агент закончил. Посмотрим, как это сделано. Итак, эта функция выпущена. Теперь у нас есть наш агент-рецензент, подтверждающий, что работа была выполнена. Большие лаборатории будут делать что-то подобное, верно? Вы уже видите это с облачными инструментами кодирования. Они идут. И будет много разновидностей этого, верно? Будут ваши инструменты для подсказок в стиле "один выстрел" и ваши настоящие инженерные инструменты. Очевидно, мы будем очень сильно опираться на настоящие инструменты агентичного кодирования вне цикла для разработки программного обеспечения, такие как эта система, но они появляются. Мы хотим иметь спектр инструментов, которые мы можем использовать. Более конкретно, мы хотим иметь выделенное решение для решения наших предметно-ориентированных проблем с нашими специализированными агентами. Это преимущество агентичного инженеринга. Вы можете создавать агентов, которые знают вашу проблему лучше, чем кто-либо. Лучше, чем любой облачный инструмент, лучше, чем любая команда. Это преимущество. И вы можете масштабировать это сейчас с помощью мультиагентной оркестрации и агента-оркестратора. Агент-оркестратор — это первый шаблон, в котором я почувствовал идеальное сочетание наблюдаемости, настраиваемости и агентов в масштабе. В этом уроке мы без усилий запустили множество агентов с выделенным сфокусированным контекстом. Мы, конечно, можем очистить наших агентов одной командой. Мы можем контролировать все и управлять нашими вычислениями лучше, быстрее, чем когда-либо. Любой выпуск или система, которая позволяет вам увеличить скорость информации между вашими агентами и вашей работой, требует вашего внимания, требует вашего фокуса. Агент-оркестратор — одна из таких систем. Увидимся на следующем уроке Agentic Horizon.