Transcription
Не так давно некоторые люди стали высказывать мнение о том, что мы можем перестать писать код руками полностью. И, кажется, это время уже постепенно наступает. Сегодня многие компании начинают нанимать инженеров с опытом работы с агентами на ежедневной основе. Задачи для этой позиции ставятся достаточно широкие, от получения идеи, которую нужно проверить до финальной реализации и доставки их конечным пользователям.
Очевидно, что такие большие задачи невозможно просто запихать в LLM и надеяться, что мы получим на выходе внятный результат. Поэтому мы вынуждены декомпозировать решение таких задач для того, чтобы на каждом этапе решать с помощью LM их эффективно. И в конечном итоге мы приходим в ситуацию, когда у нас большое количество разных агентов. Какие-то специализируются на дизайне, какие-то на написании кода, какие-то на документировании, и мы вынуждены это всё оркестрировать. Сейчас только начинают формироваться инструменты и подходы к оркестрации разных агентов.
В этом видео мы посмотрим на один такой инструмент, который позволяет как объединить разный набор агентов, будь то CLDCД, CDEX, OpenCД, так и построить конвейер, который позволит автоматизировать весь процесс разработки от изначальной идеи до финальной фичи. Поехали.
Для того, чтобы лучше понимать, где мы сейчас находимся и куда двигаемся, посмотрим на историю, откуда мы пришли. И изначально у нас появился чат GPT, в котором мы могли прийти и поразговаривать, спросить какой-то вопрос, закинуть м задачу для решения, получить какой-то код, скопипастить его в свою IDE и дальше с ним продолжать работать. Это было круто, но почти всегда неудобно. Нам приходилось переключаться постоянно между кодом и чатом. У чата не было полного контекста, как наш код организован, как мы его пишем, какие у нас правила, как тестировать и так далее.
После этого появился Copilot, который встраивался в IDE и позволял дополнять код. Это был такой code completion на стероидах. Но мы постепенно сдвинулись в сторону агентского программирования, когда у модели есть доступ до кода. Эта модель может сама по своим внутренним алгоритмам походить по коду, посмотреть остальные части кода для того, чтобы более точный ответ выдать по конкретной задаче. И постепенно мы всё меньше и меньше смотрели на код и больше и больше общались напрямую с LLM, которая генерировала нам этот код.
И в какой-то момент Anthropic зарелизили Claude-Code. Сначала это выглядело непонятно, а какая-то отдельная программа, которая не позволяет писать код внутри, и многие вернулись в режим, когда работают параллельно с Claude-Code и с IDE. После этого задачи всё быстрее и быстрее стали решаться. Многие разработчики стали запускать два-три и больше Claude-Code сессий для того, чтобы если в одной сессии LLM всё ещё соображает, то в другой параллельно можно решать либо другую задачу, либо эту же задачу, но, например, в другой части кода, там frontend, backend и так далее. Некоторые разработчики стали запускать до 10ти и больше даже разных сессий для решения более сложных задач. Обмазывали LLM разными скилами для более автономной работы.
И многие из нас сейчас находятся где-то между этапами, когда у нас есть одна сессия Claude-Code и когда у нас есть такое количество сессий, которые уже не умещаются в голове и мы постоянно про них забываем, либо у нас начинаются конфликты при merge разных сессий, потому что у нас слишком много было параллельных. Всё это приводит нас к состоянию, когда нам нужна какая-то структура между этими разными агентами. И кто-то, как Anthropic с Claude-Code, решают это с помощью своих внутренних сабагентов. Но здесь возникает проблема, что часто нам приходится запускать не только модели Claude-Code, например, OpenAI's Codex очень хорошо справляется с JS. И в таком случае нам всё равно приходится вручную либо с какими-то плагинами взаимодействовать для того, чтобы передавать контекст между одним агентом и другим. Но это сложно масштабируется, особенно в крупных компаниях.
И здесь на сцену выходит, э, сущность в виде гномика оркестраторы. И для того, чтобы лучше понять, что такое оркестраторы, давайте проведём небольшую аналогию с DevOps. Когда-то давно у нас были серверы, на которые мы выкатывали наши приложения, писали и скрипты. Это работало, но было достаточно много разных проблем по изоляции окружения. Каждому приложению нужно своё окружение, внутри которого должны быть свои версии библиотек, файлов и так далее. Для решения этой проблемы придумали виртуализацию. Но здесь возникла следующая проблема, что нам, как разработчикам, неудобно формировать собранное приложение внутри виртуальной машины. Возникла потребность формировать более легковесные контейнеры, которые содержали полное окружение и были изолированы от соседних приложений.
Здесь на сцену выходит всеми любимый наш Docker, который позволил любому разработчику описать конфигурацию и изолировать окружение от соседних приложений. И таким образом мы смогли разные сервисы распределить по изолированным окружениям, а, собственно, что и дало толчок развитию микросервисной архитектуры. Но опять же возникла проблема, как это всё менеджить. На рынке в тот момент присутствовало несколько решений по оркестрации контейнеров, начиная от Docker Swarm, который так и не взлетел, так и решение от сторонних производителей, например, Nomad от HashiCorp и Kubernetes, который по итогу залидил Google.
И в конечном итоге получилась следующая картина. Есть сервера, которые стоят где-то в дата-центре. На них установлены виртуальные машины, внутри них запускаются Docker-контейнеры. Все эти контейнеры управляются, оркестрируются Kubernetes, который предлагает разные, а, абстракции для построения конкретных сервисов, будь то HTTP-сервер и приём этих запросов до сетевого взаимодействия, который позволяет, вне зависимости от того, на какой сервер пришёл, отроутить запрос именно в тот контейнер, который должен этот запрос обрабатывать.
Я это рассказал для того, чтобы лучше понять аналогию, которая у нас сейчас происходит в процессах разработки. И вместо серверов у нас есть модели, которые предоставляются разными провайдерами Anthropic, OpenAI, Google и так далее. И мы можем работать с ними через API, либо API этих провайдеров, либо если у нас какие-то открытые модели, мы можем у себя их локально поднимать. И для того, чтобы у нас модель была не просто чатом, нам нужен набор тулов, инструментов, которые эта модель может вызвать харнесов, как сейчас это принято говорить.
И здесь как раз возникает та проблема, про которую я говорил в начале, что мы вынуждены запускать большое количество сессий, менеджить контекст между разными агентами, передавать его. И какого-то системного подхода у нас не сформировано. И начинают появляться инструменты, которые в будущем могут стать таким аналогом Kubernetes только для агентской разработки. И одним из таких решений является GAST C или GASTOWN. GASTOWN - это такая утилита, которая позволяет менеджить сессии внутри разных харнесов: Claude-Code, Codex, Open Code и так далее. Это набор сервисов, который позволяет структурно организовать решение большой задачи набором разных агентов. Сделать это персистентно и не зависеть от завершения сессии и отслеживать статус решения конкретной задачи и иметь единую точку управления этими агентами.
В этом проекте достаточно много разных абстракций, которые решают свои узкие задачи. В этом видео мы рассмотрим основные, которые будут необходимы для того, чтобы начать работать с этим фреймворком. После установки самой утилиты GASTOWN мы можем сформировать Workspace, внутри которого мы будем уже работать. При запуске создаются файлы конфигурации нашего Workspace. Дальше мы можем перейти в директорию и приаттачиться в сессию нашего Major или Major. И сессию этого агента-оркестратора предполагается использовать как входную точку на первом этапе для расширения конфигурации Workspace и делегирования конкретных задач для остальных агентов и контроля статусов выполнения этих задач. В сессии этого агента уже подгружена информация обо всех нюансах работы в этом Workspace.
Для управления нашим Workspace предполагается использование команды GT, у которой есть большое количество подкоманд на каждый аспект работы этого пайплайна. Самое простое, мы можем посмотреть статус нашего проекта. Здесь мы видим активные сессии Major, которого мы уже видели, и Deacon. Про него сейчас расскажу подробнее. Также для работы со своим репозиторием необходимо его добавить в виде Rig. Делается это примерно следующей командой. И по итогу в Workspace появляется новая директория с нашим репозиторием.
И посмотрим схематично, как Workspace выглядит и из каких частей он состоит. У нас есть сессия Major, которую мы видели. Также у нас есть Deacon, аналогично Major. На его функции посмотрим чуть позже. У нас есть Rigs - это Git-репозиторий, который мы создали, внутри которого есть так называемые Policats. Это отдельные сессии агентов, которые предназначены для выполнения конкретных задач, назначенных на них. И также с помощью отдельной команды GTC ADD мы можем добавить отдельные сессии, которые предполагается использовать как наши основные рабочие сессии внутри этого Rig. Мы также к ним можем приаттачиться с помощью команды GTQRE ATTACH имя агента. И с помощью этой команды мы также сможем подключаться в его сессию для интерактивного взаимодействия внутри Claude-Code.
И также общение между агентами и передача между ними контекста предполагается производить с помощью двух сущностей. Это почта и Bits. Это такая реализация таск-трекера для удобного обмена между агентами. Всё это управляется базой данных под названием DOL. И у каждого агента есть доступ на чтение, на запись в эту базу данных. И в каждом Rig у нас есть дополнительный агент, а, под названием Refinery, который собирает все правки от всех наших агентов, мержит их в целевую ветку и пушит в Git-репозиторий.
Обычный стандартный флоу при начале работе в этом фреймворке предполагается следующий, что мы аттачимся к Major, обсуждаем с ним какую-то задачу, которую предполагается решить. По результату формирует набор Bits, которые описывают уже конкретное решение конкретной задачи. И эти задачи попадают на вход в сессию конкретных агентов Policats. И Policats выполняют каждый свою задачу, формируют изменение кода внутри своего Work и отправляют их в очередь для merge. Эту очередь мониторит агент Refinery, выполняет merge этих правок и при успехе пушит в целевую ветку Git-репозитория. Если у него успешно не получилось замержить правки, он возвращает исполнителю и цикл повторяется до успешного merge. Ну и аналогично мы можем делегировать какие-то части задачи в сессии нашей команды, в которую мы уже вручную будем выполнять конкретные задачи, не доверяя автоматическим Policats. В принципе, как и в обратную сторону, мы можем подключиться в сессию нашей команды и сформировать какую-то задачу, которая потом пойдёт на выполнение Policats по стандартному нашему флоу.
Также мы можем создать новую задачу без общения с агентами. Прямо из командной строки мы можем выполнить команду GT SLINK, описать, что именно мы хотим и кому хотим это доверить. По результату создастся набор Bits, который назначится конкретному Policat, который будет свободен. Дальше обработка пойдёт по уже знакомому флоу. Policat выполнит работу, отправит в Refinery. Это в конечном итоге должно запушиться в Git-репозиторий.
Также в этом фреймворке запускаются дополнительные служебные сессии, которые не предполагается использовать напрямую пользователям, но они нужны для обеспечения работы разных подсистем. Один из таких сервисов - это Witness. Он необходим для того, чтобы отслеживать флоу работы Policats, чтобы они вычитывали назначенные на них Bits, чтобы они не зависали в обработке и продолжали свою работу. В общем, следить и обеспечивать жизненный цикл именно Policats. Ещё одна сессия - это Deacon. Он существует уже в скоупе целиком Workspace, а не Rig как Witness. И он следит, в том числе, за работой Major и остальными подсистемами на уровне Workspace. И логика работы этих Watcher'ов описана в специальных сценариях, которые называются патрули. Там описаны этапы, которые каждый из этих Watcher'ов должен проходить, как правильно проверить сессию, как правильно проверить зависшие Bits, и так далее.
Также в системе существуют и другие важные сущности, такие как Orders, Formulas, Molecules. Их мы разберём отдельно в других видео. Один из интересных механизмов этого фреймворка, то как он управляет передачей контекстного окна при инициализации сессии, например, при запуске Claude-Code. Здесь прописан Hook, который должен выполнить команду в контексте именно того агента, который стартует. Мы его можем здесь выполнить руками и увидеть то содержимое, которое попадает в системный промпт при старте Claude-Code. Здесь описана та информация, которая необходима этому агенту. Описана техническая информация, как именно сконфигурирован наш Workspace, как работать с Bits и как назначать задачи на Policats вот в этом конкретном примере с Major. Точно также можно выполнить такую же команду для Deacon. Здесь у него прописан свой сценарий, что он именно должен делать. Это также помогает, э, лучше разобраться во внутренностях этого фреймворка, просто почитав промпты, которые выдаются с помощью этой утилиты.
И перейду к минусам работы с этой системой, который я успел из практики на себе ощутить. Первое - это переусложнённость. У нас здесь есть много разных сервисов. Не сразу понятно, с какими мы должны работать напрямую, какие служебные, какой флоу работы с задачи предполагается. Документация на проекте какая-то есть, но по моему мнению она недостаточна. Всё приходится познавать на опыте, а разговаривать с LLM. LLM иногда придумывают, заводят не в ту сторону. В общем, много что остаётся непонятным.
Вторая проблема, которая сильно мешает жить - это неправильная работа агентов с задачками, с тасками. Они либо не закрывают их вообще, либо закрывают не те задачи, которые предполагается для продолжения флоу. Постоянно приходится либо руками в терминале пропихивать эти задачки и выставлять правильные статусы, либо перезапускать агентов, либо разговаривать с Major для того, чтобы он выполнил нужные команды и разобрался, где именно зависло. И это сильно замедляет процесс, потому что мы постоянно должны возвращаться и чинить то, что сломалось в системе.
У нас предполагается, что для решения второй проблемы у нас есть, э, разные дополнительные агенты, которые должны ходить в автоматическом режиме, проверять статус выполнения задач, пропихивать их, если что-то у нас отваливается. Но это приводит к третьей проблеме, когда у нас идёт очень большое потребление токенов. Я у себя заметил, при добавленном одном Rig и полном простое я никаких задач не выдавал. Просто запустил Workspace, добавил один Rig и оставил на 5 часов его отдыхать. И за эти 5 часов сервисы, которые занимаются мониторингом состояния нашего Workspace, потратили 30% от стодолларового лимита Claude. И это, конечно, сокращает наши возможности работать внутри лимитов, которых и так не хватает.
Ну и четвёртая проблема, которую хочется отметить - это большая утилизация CPU при активном статусе работы Workspace. Из моих наблюдений основные мощности уходят на поддержку работы сервера DOL. Я как понимаю, он не рассчитан на постоянную нагрузку, на чтение и на запись. Поэтому, если вы работаете на ноутбуке от батарейки, готовьтесь к тому, что это тоже для вас может стать проблемой.
И расскажу про родственный проект под названием GAST CITY, который берёт идею GASTOWN, но реализует её в более гибком варианте, где мы сами можем формировать тот флоу, который нам необходим. Основное отличие от GASTOWN в том, что в GAST CITY у нас есть концепция паков, которая может подключаться как на уровне Workspace целиком, так и на уровне конкретных Rig'ов. Внутри этих паков могут содержаться как конкретные агенты, так и целиком пайплайны, которые позволяют организовывать работу над проектом именно в том концепте, который предполагался разработчикам.
При инициализации Workspace в GAST CITY создаются системные паки, которые автоматически подключаются к Workspace. Здесь есть как паки для работы с Bits, с core-функционалом, включая скилы для работы с кодом. И здесь задаётся контекст для агентов, как правильно работать с этой утилитой. Также и пак GASTOWN, который реализует аналог всех сущностей из родительского проекта. Его можно подключить как на уровне Workspace, так и на уровне конкретных Rig'ов. И в этом случае мы внутри нашего GAST CITY можем получить либо часть, либо полную реализацию всех сервисов из GASTOWN. Но замечу, что при подключении пака GASTOWN и невыполнении ни одной реальной задачи, просто при простое, у меня весь пятичасовой лимит израсходовался за 1 час. Поэтому имейте в виду, что накладные расходы достаточно большие.
И из моего личного опыта я бы посоветовал начинать именно с GAST CITY, с пустого проекта для того, чтобы организовать именно тот workflow, который удобен именно вам. У проекта есть достаточно удобный туториал в репозитории, который проводит от базовых понятий к более сложным, и в процессе его прохождения можно реализовать именно тот функционал, который необходим под ваши нужды. Советую начинать погружение именно с этого туториала, а разобраться в базовых концепциях и использовать именно то, что необходимо под ваши конкретные задачи. Не использовать GASTOWN сразу, потому что возникнет куча проблем, которые будут отнимать дополнительное внимание вместо решения конкретных задач с агентами.
Отдельно отмечу, что к релизу готовится версия 1.0, но я бы не стал рассчитывать, что после этого релиза в проекте не будет кардинально меняться подход к взаимодействию между разными подсистемами. Я бы не стал рассчитывать, что она будет достаточно стабильная для продакшн использования в больших командах. Всё ещё меняется очень быстро, и многие моменты будут переделываться в будущем для будущих оптимизаций. Но этот проект для меня выглядит очень перспективным. Он позволяет гибко настраивать работу между разными агентами разных провайдеров, а формировать именно тот флоу, который предполагается на конкретном проекте. Плюс это в будущем позволит объединить разных разработчиков внутри команды для работы по общему флоу.
Ну и какие выводы по результату работы с этим проектом я могу сделать? Хотим мы того или нет, но разработчики сейчас пишут всё меньше и меньше кода своими руками. Как раньше, требовалось всё меньше и меньше системных администраторов и всё больше и больше DevOps'ов. Как раньше, разработчики переходили с более низких языков программирования на более высокие, что позволяло решать ещё больше задач. Так и сейчас мы переходим от написания кода своими руками на оркестрацию агентов, которые позволяют решать ещё более сложные задачи в более короткий срок. И аналогично тому, как раньше формировался Kubernetes для оркестрации контейнеров, сейчас формируется GAST CITY для оркестрации агентов. И возможно именно с ним нам придётся работать будущие несколько лет.
Что вы думаете по этому поводу? Пишите свои комментарии, подписывайтесь на канал. Подписывайтесь на канал в Телеграме. Там я буду выкладывать больше информации из личного опыта. И всем пока. M.