Коротко напомним первую часть этой мини-серии: minions — это собственный автономный процесс агентного кодинга в Stripe. Каждую неделю в Stripe вливается больше 1300 pull request-ов (на момент первой части было 1000), полностью подготовленных minions: людьми проверены, но человеческого кода в них нет.
Если вы не читали первую часть, загляните сначала туда — там про опыт разработчика, который пользуется minions. В этом посте разберём подробнее, как они устроены, с упором на те куски процесса, что специфичны именно для Stripe.
Devbox-ы: горячие и готовые к работе
Чтобы автономный агентный кодинг масштабировался по-настоящему, нужна облачная среда разработки — параллелизуемая, предсказуемая и изолированная. Человек должен уметь раздавать многим агентам логически независимую работу. У агентов должны быть чистые окружения и рабочие директории: если один агент лезет в правки другого, токены утекают впустую на разрешение конфликтов. Полная автономность также требует, чтобы агент был системно ограждён от разрушительных действий над привилегированными или чувствительными машинами — особенно под личной учётной записью разработчика.
Добиться всех этих свойств на ноутбуке разработчика непросто. Контейнеризация или git worktree помогают, но плохо стыкуются друг с другом, да и в принципе тяжело собрать локальных агентов, у которых оставалась бы вся мощь разработческого шелла, но при этом стояли бы нужные рамки.
Minions в Stripe получают всё это по умолчанию — потому что работают в той же стандартной среде разработки, которой пользуются и инженеры Stripe: на devbox.
Devbox в Stripe — это инстанс AWS EC2 с нашим исходным кодом и запущенными внутри сервисами в разработке. Большую часть кода в Stripe люди уже пишут в IDE, подключённой к devbox по SSH. В терминологии DevOps devbox-ы — это «скот, а не питомцы»: стандартизированные и легко заменяемые, а не штучные и долгоживущие.
Многие инженеры заводят отдельный devbox под каждую задачу — у инженера Stripe их может крутиться с полдюжины одновременно.
Фрагмент списка активных devbox-ов инженера вместе с запущенными minion-ами.
Нам хочется, чтобы поднять новый devbox было проще простого, поэтому ориентир — 10 секунд. Ради этого стандарта «горячо и готово» мы заранее выделяем и прогреваем пул devbox-ов, чтобы они уже ждали разработчика. В прогрев входят клонирование гигантских git-репозиториев, разогрев кэшей Bazel и проверки типов, запуск сервисов кодогенерации, которые постоянно крутятся на devbox-ах, и многое другое. Через 10 секунд у владельца devbox-а уже лежит свежая копия master по всем основным репозиториям Stripe — бери и запускай REPL, прогоняй тест, вноси и проверяй по типам правку, поднимай веб-сервис.
Devbox-ы мы собирали под нужды живых инженеров — задолго до появления LLM-агентов. Оказалось, что параллелизм, предсказуемость и изоляция — свойства, которые и людям в Stripe здорово упрощают жизнь. Что хорошо человеку, то хорошо и агенту: опора на этот инфраструктурный примитив стала естественным домом для LLM-агентов и окупилась сторицей.
Агент
В отличие от devbox-ов, которые уже давно двигали человеческую разработку, обвязку агента мы писали под minions с нуля.
В конце 2024 года, когда по индустрии прокатилась волна кодинг-агентов, мы внутренне форкнули goose от Block — один из первых по-настоящему массовых кодинг-агентов — и подогнали его под LLM-инфраструктуру Stripe. Со временем разработку goose мы сфокусировали именно на задачах minions, а не на инструментах с человеком в петле: эту нишу прекрасно закрывают сторонние продукты вроде Cursor и Claude Code, которые мы и так выдаём нашим инженерам.
Самая характерная черта minions — отсутствие надзирающего человека. Готовые локальные кодинг-агенты обычно заточены под работу плечом к плечу с инженером, который, что называется, смотрит через плечо. Minions же полностью автономны, поэтому наша обвязка агента не может опираться на человеко-ориентированные возможности — прерывания или ручные команды для запуска и корректировки прогона.
Обратная сторона медали: в карантинном окружении devbox агенту не нужны подтверждающие промпты. Любая ошибка агента заперта внутри одного devbox — радиус поражения минимальный, и агента можно спокойно запускать с полными правами, без «Вы уверены?».
Ещё мы можем точно подкручивать оптимизации под процессы Stripe. Мелких улучшений накопилось много — все под особенности наших систем. А одна крупная оптимизация — blueprint — оказалась фундаментальной для того, как устроены minions.
Blueprint-ы
Самые распространённые примитивы оркестрации LLM-потоков — это workflow и агенты. Workflow — LLM-система, которая работает по фиксированному графу шагов: каждый узел отвечает за узкий кусок общей цели, а заранее заданные рёбра определяют порядок выполнения между дискретными узлами.
Агент же — обычно более простая схема «цикл с инструментами»: LLM сама решает, как снова и снова вызывать доступные инструменты, и на основе их результатов выбирает следующий шаг.
Оркестрация minions держится на примитиве, который мы зовём blueprint. Blueprint — это workflow, описанный кодом и управляющий прогоном minion. Blueprint-ы совмещают детерминизм workflow с гибкостью агентов в обращении с неизвестным: отдельный узел может выполнить либо детерминированный код, либо агентный цикл под конкретную задачу. По сути blueprint — набор агентных навыков, переплетённых с детерминированным кодом так, чтобы каждая подзадача обрабатывалась там, где это уместнее.
Скажем, в blueprint, который движет minions, есть агентные узлы с названиями вроде «Реализовать задачу» или «Починить падения CI». У них широкая свобода в решениях на основе входных данных. Но там же стоят узлы «Запустить настроенные линтеры» или «Запушить изменения» — полностью детерминированные: они не дёргают LLM, а просто выполняют код.
Так blueprint гарантирует, что часть подзадач внутри агентного прогона выполнится детерминированно. По структуре blueprint minion напоминает конечный автомат, где перемежаются детерминированные узлы кода и свободно идущие агентные узлы.
Пример blueprint. Детерминированные узлы показаны прямоугольниками, агентные подзадачи — облачками.
Наш опыт: если код детерминированно закрывает мелкие предсказуемые вопросы — например, «в конце прогона всегда запусти линтер» — это экономит токены (и деньги на CI) в масштабе и лишает агента очередного шанса ошибиться. В сумме практика «сажать LLM в ограниченные коробки» оборачивается общесистемным ростом надёжности. Механика blueprint упрощает контекстную подгонку этих подагентов: ограничиваем инструменты, подправляем системные промпты, упрощаем контекст разговора — всё под нужды конкретной подзадачи.
Отдельные команды могут собирать blueprint-ы под свои специфичные задачи. Например, несколько команд сделали кастомные blueprint-ы под хитрые LLM-ассистированные миграции по кодовой базе, которые прямолинейным детерминированным codemod-ом не вытянуть.
Сбор контекста: файлы правил
В большой кодовой базе вроде нашей агент, отпущенный без подсказок, легко сбивается с принятых практик или берёт не те библиотеки, даже если за ним присматривают линтеры. Здесь выручают разные форматы правил для агентов — тот же CLAUDE.md или AGENTS.md — позволяющие агентам «узнавать» кодовую базу автоматически, пока они ходят по её директориям.
Из-за размеров наших репозиториев безусловные глобальные правила мы применяем очень скупо: иначе контекстное окно агента забилось бы правилами ещё до того, как он начал работать. Вместо этого мы почти всегда кормим minions контекстом из файлов, привязанных к конкретным поддиректориям или шаблонам путей, — такие файлы автоматически подцепляются, когда агент проходит по файловой системе.
На наш взгляд, дублирования файлов правил лучше избегать и позволить нашему агенту читать тот же контекст, которым пользуются агенты под руководством человека. Поэтому мы стандартизировались на популярном формате правил, поддерживающем нужные нам возможности, — формате Cursor, — и доработали обвязку, чтобы minions читали эти правила наряду с нашим прежним самописным форматом.
Теперь мы ещё и синхронизируем правила Cursor в формат, который понимает Claude Code, — так три наших самых популярных кодинг-агента (minions, Cursor и Claude Code) одинаково подхватывают подсказки из файлов правил, которые инженеры Stripe расставляют по кодовой базе.
Сбор контекста: MCP
Чтение с файловой системы неплохо покрывает статический сбор контекста, но агентам часто нужно и динамически подгружать информацию сетевыми вызовами инструментов. В частности, чтобы полноценно «напитать» запрос пользователя, minions подтягивают внутреннюю документацию, детали тикетов, статусы сборок, кодовую аналитику и многое другое. Сразу после релиза Model Context Protocol (MCP) стал отраслевым стандартом для сетевых вызовов инструментов — и мы интегрировали minions с ним.
В Stripe мы собрали и подключили массу агентов на разных фреймворках: no-code конструктор внутренних агентов, кастомные агенты на выделенных сервисах, сторонние готовые агенты, агентные CLI-инструменты и другие кодинг-агенты, агентных ботов в Slack. Всем им — не только minions — требовались возможности MCP, причём зачастую с пересекающимися наборами общих инструментов.
Чтобы обслужить всю эту компанию, мы подняли централизованный внутренний MCP-сервер Toolshed: инженеры Stripe пишут в нём новые инструменты, а наши агентные системы подхватывают их автоматически. Все наши агентные системы используют Toolshed как общий слой возможностей — стоит добавить инструмент в Toolshed, и он тут же доступен сотням наших разных агентов.
Сейчас в Toolshed почти 500 MCP-инструментов к внутренним системам и SaaS-платформам Stripe. Агенты работают лучше, когда у них «коробка поменьше» со вкусом подобранным набором инструментов, поэтому разным агентам мы отдаём только релевантное их задачам подмножество Toolshed. Minions не исключение: по умолчанию им достаётся намеренно узкий набор. Но инженер может подключить своим minions дополнительные тематические группы инструментов.
Поскольку minions автономно дёргают свои MCP-инструменты, поверх стоит внутренний фреймворк контроля безопасности, не дающий им совершать разрушительные действия. Впрочем, первая линия обороны встроена раньше: devbox-ы работают в нашем QA-окружении, поэтому у minions нет доступа ни к реальным данным пользователей, ни к продакшен-сервисам Stripe, ни к произвольному исходящему трафику. Это не случайность: изолированные devbox-ы мы задумывали именно такими, чтобы у людей была безопасная песочница. И снова тот же урок: среда разработки, безопасная для людей, оказалась ровно такой же полезной и для minions.
…и итерируем
Да, мы хотим, чтобы minions решали задачу с одного прогона, — но без автоматической обратной связи для итерации агенту вперёд не двинуться. Огромный задел Stripe — больше трёх миллионов тестов — как раз и даёт такую обратную связь. Правда, хотя на пуш ветки в CI прогоняются все релевантные тесты, ставить всю обратную связь на CI нам не хотелось бы.
В вопросах продуктивности разработчика мы держимся принципа «сдвиг обратной связи влево». Смысл в том, что если известно: автоматическая проверка уронит CI, — лучше включить её и в IDE, чтобы инженер увидел проблему сразу. Это самая быстрая обратная связь.
Например, у нас есть pre-push-хуки, которые чинят самые частые замечания линтеров. Фоновый демон заранее считает эвристики правил линтинга под конкретное изменение и кэширует результаты прогонов, так что при пуше исправления линтера обычно приходят к разработчику меньше чем за секунду.
Minions вписываются в эту схему естественно, так что им не приходится жечь токены и CI-минуты на войну с автоформатером. Часть линтеров мы запускаем как детерминированный узел внутри blueprint цикла разработки агента и гоняем этот узел локально до того, как ветка агента уйдёт в пуш, — чтобы у ветки был честный шанс пройти CI с первого раза.
Прогнать все тесты локально нереально, поэтому в стандартный blueprint minion мы закладываем одну итерацию против полного CI. После того как minion запушил изменение, мы прогоняем CI и автоматически применяем autofix к упавшим тестам. Если остались падения без автофикса, мы возвращаем их агентному узлу blueprint — и даём minion ещё одну попытку починить тест локально. После второго пуша и прогона CI ветка уходит к оператору-человеку на ручную проверку.
Почему только один-два раунда CI? Это баланс скорости и полноты: прогоны CI съедают токены, вычисления и время, а отдача от бесконечных полных циклов CI с LLM быстро падает. По нашим ощущениям, такая политика удачно балансирует между этими требованиями.
Канал в телеграм:
Вместо заключения
Minions — лишь один из способов, которым Stripe ускоряет инженеров с помощью ИИ, но, на наш взгляд, они хорошо показывают, как мы соединяем отраслевые концепции — обвязки агентов, MCP — с собственным набором внутренних инструментов и инфраструктуры, которые наши инженеры годами затачивали под продуктивность разработчиков.
Улучшаем ли мы документацию, среду разработки или циклы итерации — мы снова и снова убеждаемся: вложения в продуктивность живых разработчиков возвращаются дивидендами и в мире агентов.
Minions уже заметно изменили то, как делают софт в Stripe. Мы продолжаем их улучшать, встраивая самое свежее из индустрии и подгоняя под масштабы Stripe. А в паре со вкусом и опытом, выстраданными в боях за человеческий опыт разработки, это позволит довести minions до лучшей версии.
Первая часть статьи:
Автор: Alistair Gray. Дата: 19 февраля 2026 года.
Оригинал: stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2