В Ivy Tendril задача (issue) из GitHub превращается в pull request через строго определенную последовательность этапов: задача поступает во входящие (Inbox) через вебхук, агент формирует черновик плана, разработчик проверяет и утверждает его, агент исполняет план в изолированном git worktree, выполняется автоматическая верификация, разработчик просматривает получившийся diff, и агент открывает pull request. Человек вмешивается ровно в двух точках: при утверждении плана и при утверждении diff. Все остальные действия автономно выполняются агентами, при этом через конвейер одновременно может проходить множество задач. В этой статье мы проследим путь одного тикета через все стадии.
Жизненный цикл в деталях
Ivy называет этот рабочий процесс программной фабрикой (software factory): это жестко заданная цепочка этапов, на которых агенты выполняют рутинную работу, а разработчики оценивают результаты на строго зафиксированных контрольных точках. Ниже перечислены этапы, действующие лица и критерии перехода. Полное справочное руководство доступно в документации по жизненному циклу.
| Этап | Исполнитель | Критерий завершения |
|---|---|---|
| Inbox | Агент (вебхук) | Задача сохранена с названием, описанием, метками и ссылкой |
| Draft plan | Агент (CreatePlan) | Сформирован черновик плана с целью, границами, списком файлов и шагами верификации |
| Plan review, точка 1 | Человек | Разработчик утверждает план (при необходимости добавив примечания или запросив правки) |
| Execute | Агент (ExecutePlan) | Агент отчитывается об успешном завершении плана в своем worktree |
| Verify | Агент | Тесты и линтер пройдены, итоговый diff готов к проверке (шлюзы верификации) |
| Diff review, точка 2 | Человек | Разработчик утверждает diff |
| Pull request | Агент (CreatePr) | В репозитории GitHub создан pull request для ветки плана через Pull Requests REST API |
| Слияние и очистка | Человек мерджит, агент убирает | Worktree удаляется, а полученные знания сохраняются в долговременную память |
От задачи к утвержденному плану
Поступление задачи
Пользователь заводит issue #418 в репозитории проекта: «Export to CSV drops rows with commas in the description field». Интеграция с GitHub пересылает ее в Inbox приложения Tendril посредством вебхука. На этом этапе ничего не запускается. Inbox — это очередь входящих заявок, и только разработчик решает, какие из них переводить в планы. Отчеты об ошибках из сервиса jam.dev поступают точно так же.
CreatePlan формирует черновик плана
Разработчик выбирает задачу и нажимает «Create plan». Promptware CreatePlan изучает текст задачи, контекстную память о репозитории и релевантный исходный код, после чего составляет черновик. Типичный черновик содержит цель, перечень файлов под изменение (src/export/csv.ts и соответствующий тест), архитектурный подход (экранирование полей, содержащих разделитель, в соответствии с RFC 4180) и шаги верификации (добавить тест с запятой в поле описания, прогнать существующие тесты экспорта). Созданный черновик отображается в разделе Drafts.
Контрольная точка 1: Разработчик проверяет план
Это первая из двух точек контроля с участием человека. Разработчик вычитывает черновик и находит недочет: план предлагает экранировать кавычками только поле описания, тогда как та же ошибка проявится на любых других текстовых колонках. Вместо ручного переписывания всего плана разработчик выделяет спорный фрагмент и вставляет замечание: «Apply the quoting to all string columns, not just description». Promptware UpdatePlan переписывает план с учетом директивы, и обновленная версия возвращается на повторную оценку.
Если черновику не хватает деталей, разработчик может нажать ExpandPlan. Если по комментариям видно, что тикет по факту скрывает две самостоятельные задачи — например, локальное исправление бага и отдельную миграцию модуля экспорта на стороннюю библиотеку CSV, — SplitPlan разобьет его на два независимых плана. Когда разработчик удовлетворен, он подтверждает согласование (Approve). С этого момента план становится техническим заданием на исполнение, и агенту больше не требуется переосмысливать исходный issue.
Исполнение и верификация
ExecutePlan работает в изолированном worktree
После утверждения Tendril создает для плана выделенный git worktree в отдельной ветке и запускает внутри него выбранного агента. Разработчик выбирает исполнителя для каждого плана: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode или любого другого CLI-агента. Пайплайн остается одинаковым вне зависимости от того, какой агент назначен на задачу.
Использование worktree критически важно, так как другие планы выполняются одновременно. У каждого плана есть собственный рабочий каталог и ветка, благодаря чему незавершенные правки одного агента не могут поломать соседний процесс, а главная ветка (main) остается нетронутой до финального ревью. Подробно технические предпосылки такого решения описаны в статье Git worktrees для параллельных ИИ-агентов.
Пока агент пишет код, экран Jobs транслирует его терминальный вывод и вызовы инструментов: прочитанные файлы, выполненные bash-команды, статус тестов, а также расход токенов и затраты в долларах. Разработчик может следить за ходом работы либо переключиться на ревью другого плана. При включенном туннеле Cloudflare Quick Tunnel тот же поток событий доступен с мобильного телефона.
Прохождение верификации
Когда агент сообщает о выполнении плана, в worktree автоматически запускается верификация: набор тестов и линтер, а сформированный diff компонуется для ревью. Результаты группируются на экране Review по трем вкладкам: tests, lint и diff. Любой упавший тест или предупреждение линтера становятся очевидны еще до того, как человек потратит время на чтение кода. В тарифах Pro и Enterprise также доступен импорт отчетов валидации из внешней системы CI. Обоснование, почему верификация должна быть строгим шлюзом, а не рекомендацией, приведено в статье Шлюзы верификации для кода, созданного ИИ.
Ревью, pull request и очистка
Контрольная точка 2: Разработчик проверяет diff
Это вторая контрольная точка с участием человека. В разделе Review разработчик изучает diff бок о бок с исходным планом и отчетом автоматической проверки. В случае с задачей #418 diff изменяет src/export/csv.ts, добавляет вспомогательную функцию экранирования кавычек и расширяет файл тестов тремя сценариями: запятая, кавычка и перенос строки внутри поля данных. Все тесты пройдены, линтер чист. Разработчик одобряет diff.
Если результат не устраивает, разработчик отклоняет diff, дополняет план недостающими требованиями и перезапускает исполнение. Без этого явного утверждения ни один коммит не попадет в GitHub.
CreatePr открывает pull request
Promptware CreatePr создает pull request из рабочей ветки плана. Далее вступает в силу привычный для команды регламент код-ревью и слияния на стороне GitHub. Вкладка Pull Requests в Tendril отображает актуальный статус всех открытых PR, запущенных через платформу.
После слияния
Как только PR сливается, Tendril удаляет соответствующий worktree. Затем promptware ExecutePlan заносит полученные технические инсайты в долговременную память. Для данного тикета фиксируется запись: «The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export». Любой последующий план, затрагивающий модуль экспорта, прочитает эту подсказку до начала работы.
Вся процедура для задачи такого масштаба занимает считанные минуты процессорного времени агента и два коротких раунда человеческой валидации. По опыту команды Ivy, внедрение этого пайплайна позволило нарастить темп с 10 до более чем 100 pull request'ов в день без малейшего ослабления контроля на двух ключевых этапах.
С чего начать
Установите Tendril, подключите интеграцию с GitHub для получения задач в Inbox и проведите один тикет через всю цепочку с одним агентом перед тем, как переходить к параллельной работе.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
На Windows выполните irm https://cdn.ivy.app/install-tendril.ps1 | iex. Бесплатная версия с открытым исходным кодом под лицензией Functional Source License включает весь жизненный цикл. Тарифы Pro и Enterprise добавляют совместную командную работу, импорт результатов из CI и развертывание on-premise.
Часто задаваемые вопросы
Может ли агент пропустить проверку человеком при мелких правках?
Нет. Две контрольные точки обязательны для абсолютно каждого плана. Даже исправление в одну строчку проходит этапы согласования плана и утверждения diff, как и любая масштабная задача. Небольшие планы просто требуют значительно меньше времени на просмотр.
Что происходит, если два параллельных плана правят один и тот же файл?
Поскольку каждый план изолирован в собственном worktree и своей ветке, в процессе работы коллизий не возникает. Конфликт проявится только при слиянии (merge) или перебазировании (rebase) второго pull request'а и будет разрешен штатными средствами Git. Грамотная декомпозиция задач по модулям сводит вероятность таких ситуаций к минимуму.
Обязательно ли задача должна поступать из GitHub?
Нет. План можно создать из произвольного текстового описания, отчета об ошибке из jam.dev, через CLI, REST API или сервер MCP. Вебхук GitHub — это лишь одна из удобных точек входа во входящие задачи.
Начало работы с Ivy Tendril
Готовы к параллельной оркестрации агентов на профессиональном уровне?
- Изучить исходный код: Посетите репозиторий Ivy Tendril на GitHub (Open Source).
- Читать документацию: Ознакомьтесь с руководствами по интеграции на tendril.ivy.app.
- Запланировать консультацию: Напишите на renco@ivy.app для 30-минутной архитектурной сессии.