Transcription
Одной из моих целей за последние 6 месяцев было добиться того, чтобы мои агенты, мои кодирующие агенты, работали полностью в режиме AFK (Away From Keyboard). Эти AFK-агенты подбирали задачи из бэклога, реализовывали для меня функции, проводили QA и, что крайне важно, работали параллельно. Таким образом, у меня одновременно работало много таких агентов. Однако, чтобы они работали должным образом, вам нужно обрабатывать запросы на разрешения, которые они делают. И вопрос, который, вероятно, у вас сейчас возник, заключается в том, как заставить моего агента работать, не засыпая меня постоянно запросами на разрешения?
Конечно, вы можете просто перейти в режим YOLO (You Only Live Once) и полностью обойти любые запросы на разрешения. Но если вы сделаете это, Claude будет делать безумные вещи в вашей системе, например, удалит ваш домашний каталог. Или, если вы находитесь в корпоративной среде, могут возникнуть опасения по поводу, знаете ли, утечки данных или отправки вашего кода случайной третьей стороне.
Поэтому, чтобы агенты работали должным образом в режиме AFK, их нужно изолировать (sandboxed), и для этого существует множество решений. Однако я не был особенно доволен ни одним из них. Тот, который я действительно пытался использовать и заставить работать, — это Docker Sandboxes. Однако при запуске в режиме AFK возникло так много проблем, что я не буду вас сейчас утомлять.
Мне нужна была простая функция TypeScript, которую я мог бы запустить и просто сказать: «Выполни этот запрос в этой песочнице, используя этого агента». И все найденные мной инструменты пытались продать мне какую-то стороннюю услугу. Поэтому я понял, что мне нужно что-то создать. И это «что-то» — Sand Castle, библиотека TypeScript для оркестрации AI-кодирующих агентов в изолированных песочницах.
Вы можете использовать это для создания скриптов TypeScript, где вы просто говорите `run`, передавая агента, песочницу и запрос. Если вы посмотрите в любом из моих репозиториев с открытым исходным кодом, вы увидите эту маленькую директорию `sand-castle` или `dots-castle` здесь, которая содержит файл `main.ts`. И он полон этих маленьких функций `sand-castle.run`.
С помощью этой простой функции вы можете создавать действительно, действительно сложные системы. Вы можете создавать системы, которые параллелизуют агентов, работающих бок о бок. Вы можете иметь системы, которые проверяют свой собственный код, а затем объединяют его. Мне очень, очень понравилось использовать это, и теперь я думаю, что пора снять об этом видео.
Позвольте мне показать вам, как это настроить в репозитории. Сначала мы запускаем `npm install ai-hero-sand-castle`. После этого мы можем запустить `npx sand-castle init`. И вас сначала попросят выбрать агента. Давайте выберем Claude Code. Почему бы и нет? Затем вы можете выбрать одного из первоклассных поставщиков песочниц, которые мы предоставляем. В будущем я планирую добавить гораздо, гораздо больше из них, но вы также можете реализовать свой собственный, если хотите. Пока давайте просто выберем Docker.
Sand Castle также использует менеджер бэклога, потому что AFK-агентам нужен какой-то способ подбирать задачи и знать, что делать дальше. Мой предпочтительный способ делать это — GitHub Issues. У нас также есть пять шаблонов здесь, в настоящее время. Я имею в виду, их может быть гораздо больше к тому времени, когда вы это запустите. Давайте фактически максимизируем здесь. Давайте выберем параллельный планировщик с этапом обзора. И поскольку мы выбрали GitHub Issues, мы создадим метку `s-castle` для GitHub. Проблемы будут фильтроваться по этой метке. И это означает, что только элементы с меткой `s-castle` в нашем списке проблем GitHub будут подобраны агентом.
На этом этапе мы можем видеть, что куча всего была помещена в директорию `sand-castle` прямо здесь. Что стоит отметить сейчас, так это этот `Dockerfile` здесь, который, по сути, является инструкциями для настройки Docker-контейнера, который мы будем использовать. Sand Castle работает внутри этого Docker-контейнера. И это означает, что вы можете установить здесь все, что угодно. Мы устанавливаем некоторые важные системные зависимости. Мы устанавливаем GitHub CLI. Мы выполняем небольшую настройку для переименования домашнего каталога в `agent`. Мы устанавливаем Claude Code. И тогда мы готовы к работе.
Итак, давайте приступим к сборке этого стандартного образа Docker. Теперь это было действительно быстро, и он завершился. Наши следующие шаги: нам нужно установить необходимые переменные среды в `.sand-castle/.env`. Если мы посмотрим в `.sand-castle/.env.example`, мы увидим, что нам требуются ключ API Anthropic и токен GitHub. Если вы хотите использовать свою подписку Claude вместо ключа API, вы можете перейти по этой проблеме здесь, которая расскажет вам больше об этом. Если вы не знаете, Anthropic немного странно относится к тому, что люди используют их подписку для таких вещей. И поэтому там есть некоторые актуальные советы. Что касается меня, я скопирую некоторые переменные среды, которые у меня уже были.
После этого я зайду в свой контроль версий. Я закоммичу этот код и отправлю его, потому что я собираюсь показать вам, как мы можем использовать GitHub Issues для планирования некоторой работы для этого агента, которого мы создали. Итак, давайте перейдем к нашему репозиторию и создадим новую проблему. Давайте скажем: «Создай мне базовый шаблон TypeScript в репозитории. Дай мне базовое приложение TypeScript, которое использует Vitest, использует проверку типов, имеет очень, очень простой CLI, который я могу вызвать, используй Commander для CLI, добавь скрипт CI, который выполняет проверку типов и запускает тесты».
Итак, теперь я создам эту проблему, и мы можем запустить нашего агента, чтобы увидеть, что произойдет. Итак, после этого он должен быть готов к тому, чтобы его подобрали. Сначала я добавлю этот маленький фрагмент кода в свой `package.json` здесь, который просто позволит мне запустить скрипт здесь. Итак, давайте скажем `scripts` и затем добавим этот скрипт `sand-castle` здесь. Это просто запустит `npx tsx`, а `tsx` — это просто способ запуска TypeScript как скрипта, и он запустит этот файл `sand-castle/main.ts`. Итак, давайте фактически запустим это и посмотрим, что произойдет.
Мы сразу видим, что был запущен агент-планировщик, и мы можем щелкнуть по этим журналам, чтобы увидеть, что он делает. Мы видим, что он успешно настроил песочницу. Это агент-планировщик, работающий на Docker, и он смотрит на открытые проблемы здесь и видит, что есть только одна открытая проблема. Затем он выдает этот план здесь, который представляет собой набор проблем, над которыми будут работать. Наконец, внизу здесь показано количество использованного контекстного окна.
Если мы вернемся к нашему терминалу, мы увидим, что агент-реализатор также был запущен. Давайте щелкнем по этим журналам и посмотрим на них. И мы видим, что он вызвал GitHub Issue View 1. У него есть четкое представление, и он запросил базовое приложение TypeScript, Vitest для тестирования, проверку типов, простой CLI с использованием Commander. Отлично. Мы видим, что он выполняет команды bash внутри здесь. Он устанавливает зависимости, и у меня даже есть запрос. Итак, он делает немного красного-зеленого рефакторинга, где сначала пишет тесты, запускает Vitest и так далее. Мы видим, как все это происходит. Теперь он продвинулся немного дальше, и мы можем сидеть и наблюдать за этим, если хотим, или, знаете ли, мы можем пойти выпить чаю. Мы можем расслабиться, и это просто сделает свою работу без нас.
Пока это работает, почему бы нам не взглянуть на файл `main.ts` здесь? Мы видим планировщик, который мы видели ранее, находится прямо здесь, где у нас есть команда `sand-castle.run`, которая принимает имя планировщика. Она принимает агента здесь. Так что мы можем просто изменить это, если хотим. Если мы хотим планировать с помощью CodeX, скажем, вместо Claude Code, мы можем это сделать. И она также использует этот файл запроса здесь. Итак, `plan-prompt` здесь. Это создается шаблоном, и вы можете полностью редактировать это столько, сколько хотите, чтобы запускать что-либо в песочнице. Этот берет все открытые проблемы из репозитория, которые имеют метку `sand-castle`. Он получает все метки, все комментарии, получает весь текст комментариев. А затем он определяет, какие из них могут быть выполнены прямо сейчас. Итак, он ищет только незаблокированные проблемы здесь. И, наконец, мы говорим ему вывести свой план в виде JSON-объекта, обернутого в теги `plan`.
Если мы вернемся к `main.ts`, мы увидим, что это затем подхватывается здесь. Затем мы извлекаем JSON из плана и определяем проблемы. И для каждой из проблем мы запускаем отдельную песочницу здесь. Мы запускаем реализатор. И у этого есть `implement-prompt`, который находится прямо здесь. Итак, `implement-prompt`. Этот принимает некоторые аргументы запроса здесь. Итак, он принимает заголовок проблемы. Он принимает идентификатор задачи, который является идентификатором проблемы. Затем он говорит, что вы будете работать над определенной веткой. Опять же, все это просто настройка, которую я придумал. На самом деле, это не Sand Castle дает вам какие-либо предписания о том, как вы хотите это запустить. Это просто действительно крутой рабочий процесс, который я обычно использую в своих репозиториях. Поэтому я решил, что это принадлежит шаблону.
Если мы вернемся к `main.ts`, мы увидим, что результат здесь захватывается в переменной. И если есть более одного коммита, мы затем запускаем ревьюера. Этот шаблон оказался невероятно мощным, потому что реализатор может допускать ошибки, но ревьюер обычно их обнаруживает. И, конечно, если вы хотите провести враждебный обзор, где один агент запускает или проверяет код другого агента, то вы можете просто использовать `sand-castle.codeex`. Если вы хотите, чтобы несколько разных агентов запускались одновременно, приходили с реализацией, а затем какой-то другой ревьюер брал все эти ветки, выбирал лучшую или делал что-то вроде смеси из них, вы можете. В этом сила полностью агностической настройки относительно того, какого агента вы запускаете. В этом сила владения своим собственным процессом.
В любом случае, давайте посмотрим на `review-prompt` здесь. Стоит отметить этот маленький синтаксис здесь, потому что он действительно хорош. Это то, что я скопировал из Claude Skills, где, если вы указываете восклицательный знак перед кучей обратных кавычек, это будет выполнено при разрешении запроса. И поэтому он фактически выполнит `git diff source-branch <branch-name>`. Этот запрос на проверку использует очень простой процесс. Понимает изменения, анализирует их на предмет улучшений, проверяет корректность, поддерживает баланс и, что крайне важно, это отличный шаг для добавления ваших собственных стандартов проекта. Например, я добавил сюда `coding-standards`, которые вы можете заполнить любыми стандартами проекта, которые вы хотите добавить.
Давайте посмотрим обратно на `main.ts`, и мы увидим, что происходит после создания всех этих веток. Мы видим, что они затем передаются агенту-слиятелю внизу. И этот берет все ветки, берет все результирующие проблемы, поэтому он понимает сделанные изменения, а затем объединяет их обратно в основную ветку. Причина, по которой мы используем агента для этого, заключается в том, что между ними могут возникнуть конфликты слияния. И я обычно предпочитаю, чтобы мощный агент обрабатывал эти конфликты слияния для меня, потому что они иногда могут быть довольно сложными. И поэтому в конце этого у нас было несколько агентов, работающих одновременно, все коммитящих в свои ветки, а затем у нас есть старший разработчик-слиятель, который объединяет их обратно в основную ветку.
Просто эта настройка значительно увеличила мою скорость, и она работает очень, очень хорошо. И снова, Sand Castle не навязывает свое мнение. Если вы хотите превратить это в ветки PR, вы можете это сделать.
Хорошо, давайте проверим наш запущенный процесс. И посмотрим, что произошло. Итак, мы видим, что у нас был запуск реализатора. Затем ревьюер. Давайте проверим журналы ревьюера. Мы видим, что он обнаружил, что код уже чистый и хорошо структурированный. Минимальный шаблон именования ясен. А затем давайте посмотрим, что произошло при слиянии. Итак, мы можем просто открыть слиятель здесь. И слиятель выполнил проверки типов, объединил ветку и также закрыл проблему с комментарием. Прекрасно.
Мы также можем видеть, что если мы пойдем и посмотрим на остальную часть нашей кодовой базы здесь. Вау, у нас теперь больше кода. У нас есть `tsconfig.json`. У нас есть `vitest.config.ts`. И у нас есть несколько файлов, разбросанных по CLI здесь. Так что вы можете начать видеть, как работает Sand Castle. Вы можете создавать эти относительно сложные потоки, используя простую примитивную функцию, используя очень приятные эргономичные запросы в формате markdown. Вы можете заставить его работать в разных ветках и просто объединять их обратно в основную. Или вы можете заставить его выполнять очень приятные PR-потоки. Знаете, это просто код. Это программный способ запуска Claude Code, запуска CodeX и создания этих рабочих процессов, которые превращаются в эти мини-фабрики программного обеспечения.
Я был невероятно доволен этим, и мне очень интересно посмотреть, что вы тоже создадите с этим. Если вы тоже думаете об этих сложных проблемах, то вам стоит ознакомиться с моей рассылкой «AI Skills for Real Engineers». Она следует за репозиторием Skills, который стал абсолютно вирусным несколько дней назад. И я также публикую там советы и хитрости для получения максимальной отдачи от агентов, используя старые добрые фундаментальные принципы разработки программного обеспечения.
Итак, спасибо за просмотр, ребята. Я очень рад этому инструменту. Я думаю, что это будет очень хороший вклад в экосистему, и мне очень понравилось его использовать. Так что, отличная работа, и я увижу вас в следующем.