Transcription
Термин, который сейчас все чаще появляется в сфере ИИ, — это "инженерия оболочек" (harness engineering). Это следующая большая вещь этого года, как и инженерия контекста в прошлом году, и это действительно важно. Но, как и инженерия контекста, она начинает превращаться в модное словечко, которое люди бросают без реального понимания его значения. И это порождает вопрос: стоит ли изучать или принимать этот навык или даже образ мышления, как я скоро расскажу, и ответ — да.
И поэтому я хочу сегодня обсудить это с вами, помогая вам понять, что такое инженерия оболочек. Есть пара уровней, которые действительно стоит знать. И поэтому я разложу это для вас просто и понятно менее чем за 15 минут. И, конечно же, как обычно, у меня есть несколько примеров и демонстраций, чтобы сделать это по-настоящему конкретным. Итак, давайте приступим.
Инженерия оболочек — это создание "обертки" вокруг модели. Так, любой агент — это комбинация базовой большой языковой модели, такой как GPT или Claude, а затем обертки вокруг нее, которая дает ей контекст и определяет ваши процессы. И поэтому я в основном буду фокусироваться на помощи в написании кода с помощью ИИ для этого видео. Но на самом деле эта идея инженерии оболочек может быть экстраполирована на любого агента, которого вы создаете для чего угодно.
И есть действительно две части инженерии оболочек. У нас есть в рамках отдельной сессии помощи в написании кода с помощью ИИ. А затем у нас есть действительно настоящая эволюция здесь, на которой я сейчас больше сосредоточен. Это объединение нескольких сессий агентов для написания кода в более крупном рабочем процессе для выполнения более крупной задачи. И мы доберемся до этого, но я хочу начать с более фундаментальных вещей.
И одна действительно важная вещь, которую нужно понять, это то, что эта первая идея инженерии оболочек в рамках одной сессии, многие идеи здесь очень похожи на инженерию контекста. Это прямая эволюция инженерии контекста. Как мы можем предоставить правильную экосистему контекста нашему агенту для написания кода? Но есть некоторые важные отличия, на которых я хочу сосредоточиться.
Но прежде всего, я думаю, что эта диаграмма очень хорошо объясняет это. Мы начинаем с базовой большой языковой модели. Это рассуждение для нашего агента. И затем первая обертка вокруг нее — это не то, что вы строите сами. Это фактически инструмент, который вы используете, агент для написания кода, который вы выбираете. И поэтому Claude Code, Codeex, Pi, назовите миллионы агентов для написания кода, которые существуют. Все они на самом деле являются оболочками, которые компания разработала вокруг своей модели.
И поэтому это может не ощущаться как инженерия оболочек, потому что вы ничего не определяете, но вы выбираете оболочку, когда выбираете инструмент. Некоторые люди думают, что Claude Code — лучшая оболочка для написания кода. Некоторые люди думают, что Codeex — лучшая. Сейчас много споров. Но что еще важнее, чем агент для написания кода, который вы выбираете, это слой ИИ. Это окончательная обертка вокруг любой сессии агента для написания кода. И это то, что вы можете фактически построить.
И поэтому, когда мы думаем о том, что входит в слой ИИ, это действительно определение всего нашего контекста и процессов для наших агентов для написания кода. Так, наши глобальные правила, наши навыки и MCP-серверы, все возможности, которые мы предоставляем, поиск по базе кода, такой как LSP или графы знаний, наши хуки и наши под-агенты. На самом деле, эти шесть компонентов, которые практически встроены в каждый помощник по написанию кода с помощью ИИ сейчас, составляют ваш слой ИИ. Так что независимо от того, как вы хотите внедрить свой процесс или свои правила, вы будете делать это через одну из этих шести вещей.
Итак, есть пара статей, на которые я действительно хочу опереться, чтобы помочь вам понять инженерию оболочек. Я дам ссылки на них в описании. Первая из них содержит аналогию, на которой я хочу сосредоточиться. Мне это очень нравится. Итак, слева у нас есть представление о том, что модель может делать сама по себе, например, Claude или GPT. И спойлер: это не так уж много. Мы принимаем как должное все возможности, которые помощники по написанию кода с помощью ИИ, такие как Cloud Code и Codecs, предоставляют модели "из коробки".
LLM сама по себе не имеет доступа к файловой системе, не может получать или выполнять какие-либо команды. Это все, что входит в этот первый уровень оболочки, встроенный в инструменты, которые мы скачиваем и используем "из коробки". И поэтому именно это представляют собой эти верхние мосты. Это все возможности, которые эти инструменты предоставляют модели, чтобы она могла действовать как помощник по написанию кода с помощью ИИ. Правильно? Это возможности плюс системный промпт, встроенный в эти инструменты.
А затем, когда мы переходим к нижним мостам, здесь мы начинаем углубляться в слой ИИ более высокого уровня, где мы можем определять такие вещи, как используемые нами MCP-серверы, навыки, которые мы создаем или включаем, правила, подобные вещи. Даже спускаясь до циклов Ральфа, о которых мы поговорим ближе к концу этого видео, когда мы перейдем к объединению нескольких сессий агентов для написания кода. Конечная инженерия оболочек. Так что оставайтесь с нами. Но суть в том, что каждый из этих мостов — это инструменты, которые позволяют большой языковой модели функционировать и действовать как помощник по написанию кода с помощью ИИ.
Хорошо, отлично. С этим определением я теперь хочу обратиться к слону в комнате. Вопрос, который вы, возможно, задаете себе: Коул, разве большая часть этого не является просто инженерией контекста? Как будто я думал, что мы покрываем это в 2025 году, и ответ на самом деле да, в некоторой степени, и именно поэтому я думаю, что инженерия оболочек становится таким модным словечком прямо сейчас. Большинство людей не понимают, как это действительно является эволюцией инженерии контекста. Именно это я хочу доказать вам прямо сейчас.
И есть два важных отличия. Во-первых, большая часть оболочки вокруг модели, как описывает эта статья, — это просто инженерия контекста. Ваше внедрение контекста, ваши действия через инструменты и MCP, постоянство, наблюдаемость. Единственное, что действительно отличается, — это контроль. Как циклы Ральфа, оркестрация различных сессий агентов для написания кода и под-агентов. Я думаю, что это настоящая эволюция от под-агентов. И мы поговорим об этом дальше.
Но другое действительно важное отличие, которое описывает эта статья, — это переосмысление проблемы навыков. Я намекнул в начале видео на тот факт, что инженерия оболочек — это не просто навык, это также своего рода образ мышления, верно? Переосмысление. Автор говорит: "Я наблюдаю, как инженеры попадают в ловушку. Агент делает что-то глупое, инженер винит модель, и вина списывается на ожидание следующей версии". Как будто, знаете, Claude здесь ошибается. Ну, лучше подождать Opus 5, или GPT ошибается. Давайте подождем GPT6. И, знаете, лично я вижу это все время. Я тоже склонен так думать, и вы, вероятно, тоже.
Но образ мышления инженерии оболочек отвергает этот стандарт. И, кстати, я называю это эволюцией системы. Это очень соответствует тому, на чем я много фокусировался в последнее время. Вот что он говорит: "Ошибка обычно читаема. Агент не знал о соглашении, поэтому вы добавляете его в agents.mmd. Или агент выполнил разрушительную команду, поэтому вы добавляете хук, который ее блокирует". По сути, идея здесь в том, что каждая ошибка становится правилом. Или, как я люблю говорить, каждая ошибка становится возможностью улучшить вашу оболочку. Улучшение безопасности через ваши хуки, ваши процессы путем обновления ваших навыков, чего-либо в вашей оболочке, чтобы в следующей сессии агента для написания кода проблема, с которой вы столкнулись, была менее вероятна.
И это очень мощно. Эта эволюция системы означает, что вы берете на себя ответственность и улучшаете производительность вашего агента для написания кода с течением времени с помощью слоя ИИ, который вы контролируете, поверх помощника по написанию кода, который вы выбрали. И поэтому инженерия оболочек — это, по сути, получение этой самостоятельности, принятие ответственности за вашу систему, чтобы, когда что-то пойдет не так, вы не просто винили своего помощника по написанию кода с помощью ИИ и чувствовали себя беспомощными, потому что проблемы будут возникать, как и при работе с людьми-разработчиками. Будут проблемы. Но нам нужно убедиться, что у нас есть способ учиться на этом, а не просто быть во власти следующей сессии, которая не столкнется с этой проблемой снова. Мы хотим быть людьми, управляющими системой, продвигающимися вперед.
Итак, начальная генерация: у нас есть наши принципы и другие виды контекста, которые мы передаем, а затем у нас есть наши датчики для обратной связи, наши хуки, наши агенты обзора, навыки, которые мы предоставляем для этой самокоррекции, развивая наш слой ИИ с течением времени.
Спонсор сегодняшнего видео — Google Cloud, в частности их новый Agent CLI. И я в восторге от этого, потому что в наши дни оптимально создавать своих агентов с помощью других агентов, используя наших помощников по написанию кода с помощью ИИ, таких как Cloud Code и Codecs. Теперь легкая часть — это получить идею для агента, но фактически создать его и развернуть в продакшене — это совсем другое дело. Но Google сделал это невероятно просто с помощью своего Agent CLI. Это набор навыков, которые я могу привнести в своего агента для написания кода, которые дают ему полные четкие инструкции о том, как создавать агентов с помощью Google Agent SDK и даже развертывать их в продакшене и отслеживать их.
И вот прямо здесь, в моем Cloud Code, например, я могу сказать: "Используй Agent CLI для создания агента исследования, который ищет в Интернете". Очевидно, простой пример, но он будет использовать инструкции, которые действительно помогут вам создать любого агента, которого вы хотите. Затем с помощью навыков ваш агент для написания кода создаст весь код. Он справился со многими различными тестами, которые я ему дал. И затем у нас также есть наша локальная среда разработки. Мы можем запустить агента здесь, чтобы мы могли протестировать все локально с полным чат-приложением, прежде чем развертывать нашего агента.
И затем, когда вы будете готовы вывести своего агента в продакшен, это одна команда для развертывания вашего агента Google Agent SDK в Google Cloud. Супер просто, и ваш агент получает свою собственную идентичность в облаке. У вас есть игровая площадка здесь, чтобы протестировать его вживую, и у вас есть трассировки, полная наблюдаемость. Так что все, что вам нужно для развертывания в продакшене, но это не чрезвычайно сложно настроить, как это было раньше. И самое приятное то, что Agent CLI бесплатен и с открытым исходным кодом. Вы можете взять эти навыки, привнести их в любого агента для написания кода и увидеть, насколько легко сейчас создавать любого ИИ-агента. Я дам ссылку в описании. Я очень рекомендую ознакомиться с ним.
Итак, у меня также есть этот сопутствующий репозиторий для нашего видео, который дает вам очень конкретное представление о том, как может выглядеть слой ИИ. И это действительно хорошее представление всего здесь, слоя ИИ, который я буду использовать и развивать в каждой из моих кодовых баз. Итак, я хочу быстро рассмотреть это, прежде чем мы перейдем к последней эволюции инженерии оболочек, действительно мощным вещам, созданию рабочих процессов, где мы объединяем и оркестрируем множество сессий агентов для написания кода. И у меня есть примеры для этого, например, с циклом Ральфа в этом репозитории.
И я обещал, что это видео будет короче. Поэтому я не буду углубляться в каждый из компонентов слоя ИИ, но у меня есть видео, на которое я дам ссылку здесь, где я более подробно рассматриваю правила, навыки, LSP и хуки, каждый из компонентов. Я хочу остаться на очень высоком уровне, дать вам несколько золотых самородков, а затем вы, конечно, можете просто дать этот репозиторий своему агенту для написания кода и попросить его помочь вам реализовать вещи и понять все здесь.
Итак, действительно основой вашего слоя ИИ являются все правила, ограничения и соглашения, которым вы хотите, чтобы ваш агент для написания кода следовал, ваши шаблоны. И поэтому это ваши глобальные правила и любые другие виды контекста по запросу, которые у вас есть, такие как документы Markdown, Confluence, подобные вещи. А затем ваши навыки — это рабочие процессы, которые у вас есть для вашего агента для написания кода. Например, вот как вы хотите планировать, реализовывать и проверять. И у меня есть отдельный навык для каждого, потому что то, что я действительно хочу сделать, и я очень-очень рекомендую это, это выполнить планирование, реализацию и проверку все в отдельных сессиях агентов для написания кода, чтобы каждая из них оставалась эффективной по токенам и сфокусированной.
И поэтому каждый из этих навыков будет выдавать какой-то артефакт, чтобы вы могли использовать его как передачу следующей сессии. И поэтому это своего рода переход к объединению сессий агентов для написания кода, но мы все еще говорим о том, чтобы делать это вручную, верно? Например, вы запустите план и создадите план с агентом для написания кода с одним навыком, а затем возьмете этот Markdown и передадите его следующей сессии агента для написания кода для навыка реализации, верно? Вы проходите через это систематически сами. И мы поговорим немного позже о том, как мы можем действительно объединить все это.
А что касается хуков, то они, честно говоря, недооценены. Мне нравится использовать хуки для нескольких вещей. Во-первых, для безопасности. Так, хук перед использованием инструмента. По сути, это фрагмент кода, который срабатывает перед тем, как агент для написания кода выполнит любой вызов инструмента, например, запись в файл, выполнение любой команды. И поэтому здесь мы можем встроить функции безопасности, такие как запрет чтения файлов, потому что мы действительно не хотим этого в контексте LLM, или удаление каталогов очень разрушительным способом, например. Мне также нравится иметь какой-то хук проверки остановки. Поэтому, когда агент для написания кода говорит, что он закончил реализацию, я хочу детерминированно выполнить набор тестов, например, проходят ли модульные тесты, линтинг, проверка типов, все ли это действительно проходит? Потому что если нет, я хочу заставить агента для написания кода итерировать, пока это не произойдет. И именно это делает этот хук. И, наконец, просто выполнение быстрого линтинга после каждого редактирования файла очень хорошо для поддержания чистоты вашей кодовой базы, что также помогает сделать ваших агентов для написания кода более надежными в будущем.
Вот так. Всего пара золотых самородков для слоя ИИ, который у нас есть. И у меня даже есть инструкции в README для выполнения очень базового пит. Это фундаментальный подход к инженерии агентов. Итак, вы планируете с помощью навыка планирования, просто отправляя функцию, которую вы хотите. Вы итерируете план. Вы производите этот документ Markdown, который затем передаете навыку реализации в отдельной сессии агента для написания кода. У вас также есть стратегия валидации, чтобы агент мог проверять свою работу в Markdown. Так что не стесняйтесь попробовать это сами.
Но теперь, наконец, я хочу перейти к пику эволюции инженерии оболочек. Итак, я вернусь к диаграмме. Давайте поговорим об оркестрации сессий агентов для написания кода. Это когда мы действительно можем масштабировать объем работы, которую мы выполняем с помощью агентов для написания кода. Основная идея здесь в том, что вы не хотите просто взять огромную задачу или PRD и передать ее одной сессии агента для написания кода. Это не будет эффективно по токенам, и базовая большая языковая модель в оболочке будет полностью перегружена. Неважно, насколько хорош слой ИИ, который вы создали здесь с помощью таких вещей, как ваши навыки и правила. Если вы отправляете слишком много в LLM одновременно, она упадет лицом вниз.
И поэтому, оркестрируя множество сессий агентов для написания кода вместе, мы даем каждому агенту для написания кода очень сфокусированную задачу. И поэтому это также могут быть под-агенты, но, как вы увидите в цикле Ральфа, это фактические сессии агентов для написания кода, которые передают вещи друг другу. Таким образом, мы можем изучить реализацию, которая поступает из пользовательского требования. Пусть один агент напишет план. Передайте этот артефакт плана в реализацию. А затем, например, это просто пример оболочки, но у нас может быть много агентов для обзора кода, работающих параллельно. Один из них фокусируется на безопасности. Этот — на правильности реализации. А этот — на том, чтобы сделать ее максимально простой. А затем, если все пройдет, вы создадите пул-реквест. В противном случае вы будете итерировать и продолжать работать над реализацией.
И вы можете сделать все это вручную, как я говорил ранее. Мы можем перейти в Cloud Code и создать план, а затем открыть другой Cloud Code и выполнить реализацию. Но настоящая сила инженерии оболочек здесь в том, что мы можем автоматизировать все это. Мы можем создать систему, которая автоматически связывает все эти сессии агентов для написания кода с передаваемыми документами и созданием пул-реквестов и всем подобным. И именно это делает цикл Ральфа.
Итак, давайте вернемся к нашему примеру репозитория. Я хочу показать вам, как это на самом деле выглядит. Цикл Ральфа — это всего лишь один пример оболочки агента. Но Джеффри Хантли, создатель Ральфа, действительно является одним из пионеров в этой области. Это один из первых примеров, показывающий в очень простом смысле, как мы можем автоматизировать объединение множества экземпляров Cloud Code, Codecs. Я имею в виду, вы можете сделать это с любым помощником по написанию кода, потому что, по сути, все, что это такое, я не буду вдаваться в технические детали, но я просто хочу показать вам немного: у нас есть простой скрипт. Это может быть скрипт Python, это может быть скрипт Bash. Я не буду вдаваться в код здесь, но, по сути, вы даете ему более широкую область работы, например, массивный PRD, и он будет отвечать за разделение его на отдельные задачи, а затем за запуск сессий агентов для написания кода для их обработки по одной, пока все не будет сделано.
И поэтому вы даете ему промпт. Это ввод пользователя здесь, например, вот различные элементы, которые я хочу построить в спецификации. А затем он произведет план здесь. Это план исправления. Итак, вот что он будет делать в итерации один цикла, итерации два, итерации три. Он будет продолжать работать и как бы строить журнал по мере выполнения различных сессий Cloud Code. И когда он решит, что закончил, он выдаст какой-то индикатор этого. Например, здесь я использую done.ext. И вот здесь он решает: хорошо, все восемь элементов спецификации из исходного промпта выполнены. Мы удовлетворены. Мы можем выйти из цикла. И это единственное условие. Единственный способ выйти из основного цикла while здесь — это если у нас есть этот текст done.ext, и агент для написания кода уверен, что реализация завершена и вся валидация присутствует.
И поэтому я просто пытаюсь показать вам цикл Ральфа, чтобы дать вам один пример оболочки. Но вы можете увидеть идею здесь: мы используем множество сессий агентов для написания кода, чтобы каждая из них была очень, очень сфокусирована, но мы также автоматизируем это, чтобы нам не приходилось нянчиться с нашим агентом для написания кода при работе с этими более длинными задачами. Это действительно будущее инженерии агентов. Создание этих оболочек для обработки более широких областей работы по мере того, как модели и базовые инструменты становятся все более мощными. Это путь. Так что опирайтесь на это. Я имею в виду, существует так много ресурсов по инженерии оболочек. А затем есть Archon, мой конструктор оболочек с открытым исходным кодом. Бесплатно использовать. Это самый простой способ начать работу с инженерией агентов. Создание ваших собственных оболочек, таких как цикл Ральфа, но более индивидуализированных для вас, вашего точного процесса и жизненного цикла разработки программного обеспечения.
Так что я очень рекомендую ознакомиться с этим. В противном случае, я надеюсь, это видео было полезным для вас в целом, просто для понимания того, что такое инженерия оболочек, что является шумихой, что действительно стоит знать. Если вы нашли это полезным каким-либо образом, я был бы очень признателен за лайк и подписку. И на этом я увижу вас в следующем.