Aixle Flow: open source harness для coding-агентов

8 ноября 2026

Aixle Flow - open source платформа для запуска coding-агентов по задачам. Лицензия Apache 2.0, можно поставить на свою инфраструктуру или взять managed-версию. Репозиторий открыли в августе 2026 года, проект молодой и быстро меняется. Попробовать его мне посоветовал друг из команды разработки.

Что это за проект

Агент в терминале хорошо работает на ноутбуке одного разработчика. Уже в средней организации такая модель не масштабируется:

• Каждый собирает свой процесс заново. Как ставить задачу агенту, где лежат инструкции, как проверять результат, когда открывать PR - каждый разработчик и каждая команда изобретают это сами, и работающий процесс одной команды не переходит к другой.
• Всё держится на соглашениях. Согласованность обеспечивают договорённости: формат CLAUDE.md, набор skills, правила веток и ревью. Чем больше людей, тем больше соглашений и тем чаще они расходятся.
• Процесс привязан к личной подписке. Если у разработчика кончился лимит, сломался логин или он ушёл в отпуск, его часть работы с агентом останавливается. Подхватить её без него не получится: процесс жил в его терминале.
• Автоматизациям всё равно нужна инфраструктура. Как только агент должен запускаться без человека (по расписанию, по webhook, из трекера) или в облаке, локального терминала уже не хватает. Нужно место, где он запускается, хранит логины и секреты и отдаёт результат.

Flow строят как общую среду, где над одними задачами работают инженеры, бизнес и агенты. В основе - доска и workflow. Шаг процесса уходит агенту или человеку по правилам, которые задала команда. Между шагами работа передаётся вместе с контекстом запуска, поэтому следующий участник видит, что уже сделано. Там, где нужно решение человека, процесс останавливается на подтверждение. Ход работы, результаты и стоимость видны всем участникам проекта без доступа к чьему-то терминалу. Процесс может быть и не про код: в демо на сайте проекта workflow собирает еженедельный отчёт по Google Analytics и публикует его в артефакты.

Технически это выглядит так. Событие запускает workflow: карточка попала в колонку, сработало расписание, пришёл webhook, сообщение в Slack или изменение в трекере. Каждый шаг агента - сессия в отдельном контейнере. Статус, файлы и стоимость возвращаются туда, откуда пришла задача: в карточку, в тред или в issue трекера.

Сам агент не меняется: внутри контейнера работает тот же CLI, что и локально. Меняется всё вокруг него:

Локальный агент	Агент во Flow
Запускает человек из терминала	Запускает событие или кнопка Run
Окружение разработчика	Чистый контейнер на каждую сессию
Инструкции в CLAUDE.md, AGENTS.md и в голове	Роль агента, workflow и карточка хранятся отдельно
История в терминале	Логи, артефакты, токены и стоимость по сессии
Решения принимаются в чате	Approve, retry или skip на шаге, CI gates
Видит только тот, кто запустил	Видит вся команда проекта

Для меня harness - это всё вокруг модели: инструкции, инструменты, среда, проверки и точки, где решает человек. Локально я собираю его сам из CLAUDE.md, skills и скриптов. Flow даёт те же части как общие сущности для команды.

Модель

Компании, проекты и профили устроены как в любом таск-трекере: участники, права, доска задач. Агенты, процессы, репозитории и секреты принадлежат проекту, а сессии работают на логинах конкретного человека в CLI-агентах. Своё у Flow - агенты, workflow, триггеры и gates.

Агент - это роль плюс исполнитель. Роль описывает, кто агент, как он общается и каких правил держится. Исполнитель - конкретный CLI, который работает в контейнере. Одну роль можно запускать на разных CLI.

Workflow - это процесс из шагов. Шаги идут по очереди или параллельно, если не зависят друг от друга. Каждый шаг - отдельная сессия агента в отдельном контейнере с одним основным результатом. Внутри шага можно завести чеклист: агент отмечает пункты по мере работы, всё это происходит в том же контейнере.

Между шагами контекст передаётся только через артефакты. Следующий шаг не видит ни разговора агента, ни его рассуждений, ни рабочей копии, ни установленных пакетов предыдущего шага. Ему достаются только файлы, которые предыдущий шаг сохранил как результат, и короткие заметки о том, чем шаг закончился. Всё, что не записано в артефакт, для следующего шага не существует.

Поэтому процесс нужно строить вокруг артефактов:

• у каждого шага есть явный результат: спецификация, отчёт, patch, PR, скриншоты;
• следующий шаг в инструкциях получает ссылку на этот результат и работает от него, а не от пересказа задачи;
• то, что должно жить в одном окружении (поднятое приложение, установленные зависимости, рабочая копия с правками), остаётся пунктами чеклиста внутри одного шага, а не дробится на отдельные шаги.

Триггеры запускают процесс, gates его придерживают. Запустить workflow можно перемещением карточки в колонку, кнопкой Run, по расписанию, через webhook, сообщением в Slack или событием из трекера. Gate задерживает процесс, пока не выполнено условие: подтверждение человека на шаге (Approve, Retry или Skip) или зелёный CI.

Результат возвращается туда, откуда пришла задача. Статус и комментарии появляются в карточке, файлы сохраняются в артефактах, логи, токены и стоимость видны по каждой сессии.

Агент получает собранный контекст: свою роль, инструкции шага, описание карточки и список доступных инструментов. Репозиторий уже склонирован в контейнер. Пушить агент может только в этот репозиторий и только по короткоживущему токену.

Архитектура

Flow написан на Rails, интерфейс на React через Inertia. Архитектура классическая для Rails: PostgreSQL хранит всё состояние (проекты, задачи, процессы, сессии, настройки), фоновые задачи идут через очередь в той же базе, Redis отвечает за кэш и обновления интерфейса в реальном времени.

Браузер ──▶ Rails ──▶ PostgreSQL
              │
              └──▶ Temporal ──▶ контейнер с агентом
                                     │
                                     └──▶ логи, токены, результаты ──▶ обратно в Rails

Temporal

Temporal - open source платформа для долгих процессов, которые должны дойти до конца, даже если по дороге упали сервер, сеть или сам процесс. Сами разработчики называют это durable execution: процесс сохраняет своё состояние и продолжает работу после сбоя.

Из чего состоит:

• Сервер Temporal с базой данных. Это супервизор: он хранит историю каждого запуска, раздаёт задания и следит за таймаутами.
• Worker - процесс приложения, который выполняет код. Во Flow он запущен отдельно от веб-приложения.
• Workflow - описание процесса обычным кодом: сделай это, дождись того, потом сделай третье.
• Activity - любое действие с внешним миром: создать контейнер, запустить сессию, сохранить результат.

Как это работает:

• История вместо состояния в памяти. Сервер записывает каждое событие запуска: какая операция запланирована, чем закончилась, какой пришёл сигнал, какой сработал таймер. Если worker упал, новый worker прогоняет код процесса заново по этой истории. Результаты завершённых операций берутся из истории и повторно не выполняются.
• Код процесса должен быть детерминированным. При повторном прогоне он обязан принять те же решения, иначе история не сойдётся. Всё недетерминированное (время, случайность, сеть, файлы) выносится в activity.
• Activity повторяются автоматически по заданной политике повторов. Поэтому activity должны быть идемпотентными: Temporal гарантирует, что результат операции будет учтён один раз, но сама операция может выполниться несколько раз, в том числе частично. Например, worker создал контейнер и упал, не успев отчитаться: при повторе создание контейнера не должно породить второй.
• Таймауты и heartbeat. У каждой activity есть время на выполнение. Долгие операции периодически отправляют серверу heartbeat, и по нему сервер отличает «работает долго» от «зависло».
• Сигналы и таймеры. В работающий процесс можно отправить сигнал, например «человек нажал Approve». Процесс может ждать сигнала или таймера часами и днями, не занимая worker.

Во Flow на Temporal работают три процесса:

• жизненный цикл контейнера: скачать образ, создать контейнер, запустить сессию, собрать результаты, убрать контейнер;
• проход по шагам workflow с учётом зависимостей, повторов и подтверждений (подтверждение на шаге - это сигнал в работающий процесс);
• запуски по расписанию.

Чего Temporal не делает:

• Не сохраняет то, что внутри контейнера. Если контейнер умер, всё, что агент в нём поставил, пропало, и шаг начинается заново в новом контейнере. Надёжность процесса и сохранность рабочего окружения - разные вещи.
• Не связывает свою историю с базой приложения одной транзакцией. Запись в PostgreSQL, старт процесса в Temporal и создание контейнера - три отдельных действия. Поэтому во Flow есть повторная доставка запусков, которые записаны в базу, но не дошли до Temporal, и сверка, которая приводит запись о сессии и реальный контейнер к одному состоянию.

Изоляция на уровне контейнеров

Каждая сессия идёт в чистом контейнере из заранее собранного образа. Внутри только склонированный репозиторий, входные файлы и инструкции. По окончании Flow забирает результаты, а контейнер удаляет. Локально контейнеры запускаются в Docker, в проде - в Kubernetes, логика одна и та же.

Модель та же, что в CI/CD: job в чистом окружении из образа, результат в артефактах, следующему шагу передаются только артефакты, логи и статус видны всем. Разница в том, что внутри job работает не скрипт, а агент, который исследует задачу и пишет код. Его результат проверяется так же, как результат любой другой стадии: по артефактам, логам и статусу CI, а не по переписке в чате.

Отсюда и требования те же, что к CI. Образ должен содержать всё нужное для сборки и тестов проекта, секреты передаются только на время запуска. Что агент поставит внутри сессии, не переживёт её.

CLI-агенты

Сейчас поддерживаются семь CLI: Claude Code, Codex, Cursor CLI, Gemini CLI, Antigravity CLI, Grok CLI и Kiro CLI. Под каждый собран свой образ на общей базе. Каждый человек один раз логинится в нужные CLI через терминал в браузере, Flow хранит логин в зашифрованном виде.

Под каждый CLI есть адаптер. Он знает:

• где CLI хранит логин;
• как сгенерировать для него конфиг и подключить MCP-серверы;
• как запустить сессию;
• откуда взять расход токенов: из телеметрии, из лога HTTP-запросов или из вывода самого CLI.

Workflow от CLI не зависит, исполнитель выбирается на шаге. Чтобы добавить новый CLI, нужны запись в общем реестре runtimes, каталог с Dockerfile образа, адаптер с командами запуска и пара строк в настройках и интерфейсе. CI, локальная сборка и деплой подхватывают новый runtime из реестра сами.

Flow как MCP-сервер

Flow сам является MCP-сервером. Агенты в контейнерах ходят в него по ключу сессии за карточками, комментариями и инструментами доски. Человек подключает тот же сервер к своему локальному агенту по личному токену.

Я настраивал весь проект именно так, из локального Codex. В интерфейс почти не заходил и в нём не путался. Через MCP я создал агентов, собрал workflow и доску, привязал workflow к колонке, читал историю запусков и логи сессий. Процесс я описывал словами, агент переводил описание в сущности Flow и сохранял их. Когда результат запуска не устраивал, тот же агент читал логи и предлагал, что поменять в инструкциях.

Внутри Flow для этого есть свой агент, Aixle Builder. Это интерактивная сессия на странице проекта с теми же инструментами, что у личного MCP, но привязанными к этому проекту. Рядом с терминалом видно, как собираются workflow и доска. Если не хочется подключать внешнего агента, можно настраивать проект через него.

Как настроить

Установка

На хосте нужны только Docker и git. Ruby и Node не нужны, всё работает в контейнерах. По документации Flow одному разработчику хватает 8 GB памяти, выделенной Docker.

git clone https://github.com/AixleHQ/flow.git && cd flow
cp .env.example .env.development
make setup   # образы, зависимости, база, начальные данные
make up      # web, worker, PostgreSQL, Redis, Temporal, Traefik

После make up сервисы поднимаются на отдельных портах, по умолчанию только на 127.0.0.1:

Сервис	Порт
Веб-интерфейс и API	4000
MCP-сервер	4002
Temporal (gRPC)	7233
Интерфейс Temporal с историей процессов	8080
Traefik: HTTP, HTTPS, dashboard	80, 443, 8090

Все порты переопределяются переменными окружения, так что рядом можно поднять вторую копию стека. Для корпоративного облака порты прячутся за доменами. Публичный адрес приложения задаёт DOMAIN, от него строятся адрес личного MCP и адреса для webhooks GitHub, GitLab, Jira и остальных. Терминалы агентских сессий Flow советует отдавать с отдельного домена через TRAEFIK_HTTP_BASE, например flow.example.com для приложения и t.example.com для контейнеров: так содержимое контейнера не работает с правами пользователя в основном приложении. В проде то же самое разворачивается в Kubernetes, где Traefik маршрутизирует трафик к подам сессий (справочник по конфигурации).

Подключение репозитория

Интеграции подключаются на странице Integrations проекта. Поддерживаются:

Тип	Сервисы	Что даёт проекту
Хостинг кода	GitHub, GitLab, Bitbucket, Azure DevOps	Клонирование репозиториев в сессию, работа с PR, CI gates по проверкам и пайплайнам
Трекеры	Jira, Linear, YouTrack, GitHub Projects, Azure Boards	Запуск workflow по событиям задач, инструменты для чтения и изменения задач
Чаты	Slack, Microsoft Teams	Запуск workflow из сообщения, статус запуска в треде
Удалённые среды	Coder	Рабочие машины, которые агент может взять, использовать и вернуть

Подключение во всех случаях устроено одинаково. Интеграция принадлежит компании и подключается либо ко всей компании, либо к одному проекту. Репозитории из подключённого хостинга добавляются в проект, а workflow или шаг выбирает, какие из них клонировать в контейнер. События из внешних сервисов приходят во Flow через webhooks, и каждый endpoint проверяет отправителя своим способом: подписью, секретом или токеном. Инструменты других сервисов (Notion, Sentry и подобные) подключаются не как интеграции, а как MCP-серверы проекта.

Для GitHub есть два варианта подключения. GitHub App - основной вариант для прода: он получает webhooks, но ему нужен адрес, до которого GitHub может достучаться. Personal access token подходит для локальной установки: ничего не нужно настраивать, а результаты CI Flow узнаёт опросом. Подробности по каждому провайдеру - в документации по интеграциям.

От прав подключения зависит, что агент сможет сделать в репозитории. Чтобы агент создавал ветки и PR, нужны права на запись. Внутри контейнера git push и gh получают короткоживущий токен только на этот репозиторий, и в контейнере он не сохраняется.

Логины в CLI

Каждый человек один раз логинится в нужные CLI в разделе Profile, через терминал в браузере. Flow сохраняет логин в зашифрованном виде и подкладывает его в контейнер на время сессии. Сессии работают на логине человека, поэтому и расход по подписке или API-ключу тоже его.

Подключение личного MCP

В Profile → MCP Flow выдаёт личный токен amcp_…. Токен показывается один раз. Дальше сервер добавляется в локального агента:

# Claude Code
claude mcp add flow --transport http http://localhost:4000/mcp \
  --header "Authorization: Bearer amcp_…"

# Codex читает токен только из переменной окружения
export FLOW_MCP_TOKEN="amcp_…"
codex mcp add flow --url http://localhost:4000/mcp --bearer-token-env-var FLOW_MCP_TOKEN

Сервер регистрируется в клиенте под именем flow, его инструменты видны как mcp__flow__list_projects и так далее. Codex читает токен из переменной окружения при каждом старте сервера, поэтому export по документации нужно держать в профиле shell. Для Cursor на той же странице есть кнопка установки, для остальных клиентов - готовый JSON. У токена ровно те права, что у его владельца.

Первый проект

Минимальный набор для первого запуска:

1. Проект и доска. Можно взять готовый шаблон колонок или собрать свою доску.
2. Репозиторий, подключённый к проекту.
3. Агент: роль и правила работы с кодом.
4. Workflow: шаги, инструкции, ожидаемые результаты.
5. Привязка workflow к колонке. Для начала лучше ручной запуск, тогда перемещение карточки само ничего не тратит.

Всё это я сделал через MCP из Codex: описывал словами, что нужно, а агент создавал сущности. То же самое можно сделать в интерфейсе или через встроенный Aixle Builder.

Как использовать

Что предлагает Flow

Flow предлагает разложить по доске полный SDLC, от проектирования до релиза. В шаблоне для команды разработки колонки такие:

Backlog → Tech Design → Implementation → Code Review → QA → Ready for Release → Done

Есть и подробный шаблон на 19 колонок, где отдельно выделены продуктовый дизайн, его ревью и приёмка пользователем.

У каждой колонки есть описание её смысла, и оно попадает в контекст агента: так агент понимает, что в этой команде значит «Code Review». К каждой колонке привязывается свой workflow. Стадии передают результат друг другу через комментарии в карточке: tech design, отчёт ревью, отчёт QA. Для спецификаций и реализации можно подключить BMAD с готовыми навыками.

В их же документации есть правило, как подбирать процесс по размеру изменения:

Изменение	Процесс
Небольшой понятный фикс	Одна сессия: короткая спецификация, реализация, тесты
Средняя фича	Спецификация, реализация с тестами, ревью
Крупное или чувствительное	Плюс архитектура и отдельное независимое ревью

Отдельный шаг они советуют заводить, только когда нужен отдельный результат, отдельное подтверждение или независимое ревью. Каждый шаг - новая сессия в новом контейнере, и это стоит времени и токенов.

Процесс для небольшого проекта

Для небольшого проекта полный SDLC избыточен. Для репозитория этого сайта (Rails, PostgreSQL, Hotwire, RSpec) я собрал процесс из доски на четыре колонки и двух workflow:

Backlog → В работе → На проверке → Готово

Задача → PR. Workflow привязан к колонке «В работе» с ручным запуском и проходит весь путь в одной сессии:

исследовать задачу
  → поднять приложение
  → воспроизвести проблему
  → исправить
  → тесты, линтер, проверка в браузере
  → ветка и PR
  → дождаться CI
  → карточку в «На проверке»

Агент пушит только в свою ветку. Если что-то не получилось, он открывает Draft PR и пишет причину в описании. При повторном запуске он продолжает существующий PR, а не создаёт новый.

Merge. Второй workflow я запускаю вручную после своего ревью. Перед merge он проверяет, что одобрен именно текущий коммит, что CI зелёный и что нет конфликтов.

Деплой - отдельный pipeline со своим шагом после merge.

Отдельные стадии tech design, ревью и QA для такого проекта не нужны. Каждая стадия - новый контейнер с повторной установкой зависимостей, и на небольших задачах эти накладные расходы больше, чем польза от разделения. Ревью делаю я сам на PR.

Как это выглядит в работе

Процесс я прогонял на разных задачах, в том числе намеренно с неполными и некорректными вводными: без шагов воспроизведения, с размытой формулировкой. Нужно было понять, что агент сделает, когда задача поставлена плохо: угадает и исправит не то или остановится и спросит. На размытой задаче он не стал гадать. Он записал в отчёт, какие места кода похожи на проблему, и задал вопрос на уточнение.

Разбирать результат удобно, всё лежит в одном месте:

• в карточке - статус, комментарии агента, ссылка на PR и коммит;
• в артефактах сессии - скриншоты до и после исправления, сценарий проверки и отчёт;
• в сессии - полный лог работы агента, токены и стоимость.

Чтобы понять, что произошло, не нужно заходить в контейнер или перечитывать терминал. Когда результат не устраивал, я правил инструкции workflow по логам и запускал снова.

Что сохраняется между сессиями

Образ переиспользуется, контейнер каждый раз новый:

Что	Сохраняется
То, что установлено при сборке образа	Да
То, что агент поставил внутри сессии	Нет
Результаты, которые забрал Flow	Да
Рабочая копия репозитория	Нет

Docker Compose проекта для агента не годится. В public-profile он собран под прод: фиксированные порты, сертификаты с хоста, нет dev- и test-зависимостей. К тому же Flow не поднимает Compose проекта, а доступ к Docker агенту штатно не передаётся. В моём случае рабочее решение - собрать образ под проект с Ruby, системными библиотеками и гемами. Пока его нет, агент ставит зависимости сам в каждой сессии, и на это уходит заметная часть времени.

Локальную папку агент не видит. Flow клонирует репозиторий из GitHub, поэтому всё незакоммиченное и незапушенное у меня на ноутбуке для него не существует.

Метрики

Небольшая задача проходит полную сессию примерно за 10 минут, средняя - примерно за 20 минут и 27.0M токенов. Сессии шли через Codex CLI v0.164.0 на GPT-6.1 sol. Это мои замеры на public-profile, не бенчмарк.

Flow показывает время, токены и стоимость по каждой сессии и сводно по проекту. В документации они советуют считать не сессию, а принятую задачу: складывать все сессии, повторы и перезапуски, которые понадобились, чтобы задачу приняли. Рядом с этим стоит считать, сколько раз задачу возвращали на доработку и сколько дефектов нашли после поставки. Токены ввода, вывода и кэша лучше держать раздельно: меньше токенов и меньше счёт - разные результаты.

Сколько это стоит по API

Расчёт для одной средней задачи на 27.0M токенов. Разбивки по типам токенов у меня нет, поэтому беру допущение, типичное для агентной сессии: 90% чтение из кэша (24.3M), 9% новый ввод (2.43M), 1% вывод (0.27M). Цены standard tier на ноябрь 2026 (OpenAI, Anthropic):

Как читать таблицу:

• Порядок важнее точной цифры. Моя средняя задача на GPT-6.1 sol стоила бы около $10 по API. Если контекст вырастет за 272K, цена почти удвоится.
• Доля кэша двигает цену сильнее всего. Новый ввод стоит в 20 раз дороже чтения из кэша. Поэтому повторная установка зависимостей и перезапуски сессий бьют по счёту сильнее, чем видно по числу токенов, и отлаженный образ экономит не только время.
• Модель выбирается на каждом шаге. Исследование и исправление можно оставить на sol, а прогон тестов, оформление PR и проверку перед merge отдать terra или luna, они дешевле в 2 и в 16 раз. Оценивать при этом нужно стоимость принятой задачи вместе с доработками, а не одной сессии.

Подписка или API

Многие компании пока продолжают работать на индивидуальных подписках разработчиков на CLI-агентов, и мы тоже. Пока подписочную модель можно утилизировать, это нужно делать: цена подписки фиксированная, а за те же сессии по API пришлось бы платить по таблице выше.

При коммерческом использовании через API один инженер, который отдаёт агенту 3-4 средние задачи в рабочий день, при 22 рабочих днях в месяц (66-88 задач) обошёлся бы на GPT-6.1 sol примерно в $660-880 в месяц, или $8-10.5 тыс. в год. Это нижняя граница. Если задачи сложнее (длиннее сессии, больше контекста, больше шагов и повторов), счёт по токенам растёт кратно, а на модели уровня astra та же нагрузка стоит уже $4-5.5 тыс. в месяц. На таком масштабе распределять модели по шагам обязательно: дорогая модель остаётся на исследовании и исправлении, а тесты, PR и проверка перед merge уходят на модели, которые дешевле в 2-16 раз. Плюс нужен отлаженный образ, чтобы не платить за повторную установку зависимостей в каждой сессии.

У подписки свой потолок. Сессии во Flow идут на логине конкретного человека, поэтому все параллельные запуски тратят один и тот же лимит. Параллельность упирается не в контейнеры, а в подписку: когда лимит кончился, следующие сессии ждут его сброса.

Где подходит

Flow лучше всего работает на задачах, где агент может долго действовать сам, а человек нужен в начале и в конце: поставить задачу и принять результат. Это задачи с понятными критериями приёмки и длинным циклом обратной связи, где результат всё равно проверяют не сразу: по PR, по отчёту, по CI.

На таких задачах проявляются свойства, которых нет у агента в терминале:

• Параллельность. Каждая карточка и каждая независимая ветка workflow идут в своём контейнере. Можно запустить несколько задач сразу и не следить ни за одной.
• Независимость. Сессии не делят окружение: упавшая или испорченная среда не задевает соседние задачи и не переходит на следующий запуск.
• Наглядность. Что запущено, на какой стадии, что сделал агент и сколько это стоило, видно на доске и в сессиях всей команде, а не только тому, кто запустил.
• Повторяемость. Процесс описан один раз в workflow. Каждая следующая задача проходит тот же путь с теми же проверками, и задачи можно сравнивать между собой.

Когда процесс повторяется, токены можно экономить двумя способами:

• Отлаженный образ. Пока в образе нет зависимостей проекта, агент в каждой сессии тратит время и токены на установку Ruby, гемов и базы. Если один раз собрать образ под проект, эта часть исчезнет из каждого запуска.
• Дешёвые модели на отдельных шагах. Модель и уровень рассуждений задаются на каждом шаге. Простые шаги можно отдать дешёвой модели, а дорогую оставить на исследование и исправление.

Где не подходит

Flow окупается, когда агент проходит сессию сам от начала до результата. На задачах с низкой автономностью агента, где нужно много остановок, он мешает:

• Задачи, где агент постоянно спрашивает, уточняет или ждёт решения. Каждая остановка - это либо подтверждение на шаге, пока контейнер висит и ждёт, либо новая сессия с повторной подготовкой среды. Локальный агент в терминале здесь быстрее: контекст и окружение уже на месте, ответ занимает секунды.
• Исследовательская работа, где критерии приёмки появляются по ходу и я сам ещё не знаю, что хочу получить.
• Задачи без критериев приёмки на карточке. Агент найдёт несколько кандидатов и остановится с вопросом. Это правильное поведение, но запуск потрачен.
• Работа, которая есть только локально. Flow видит только то, что запушено в репозиторий.
• Детерминированные операции. Если шаг однозначен, обычный скрипт или вызов API дешевле и надёжнее агента.