Не третий вариант между agent и workflow
В Agent vs Workflow статический workflow известен разработчику заранее, а агент выбирает путь во время выполнения. Здесь уровни разделены:
- агент один раз проектирует task-specific workflow;
- детерминированный код исполняет эту схему;
- отдельные модельные вызовы решают ограниченные подзадачи.
Динамична сборка схемы, а не каждый переход. Поэтому приём не отменяет workflow: он переносит его авторство во время запуска.
Зачем выносить координацию в код
Если один оркестратор хранит план, результаты десятков исполнителей и состояние циклов в transcript, контекст становится общей памятью и быстро деградирует. Программа может хранить эти данные в переменных, файлах или типизированном state, передавая каждому агенту только нужный пакет (State Centric Execution).
Это даёт:
- fan-out с явным barrier перед синтезом;
- разные модели и budgets по ролям;
- возобновление после сбоя;
- рабочие деревья или иные изолированные области записи;
- наблюдаемые лимиты времени, стоимости и числа итераций.
Базовые формы
| Форма | Когда полезна | Обязательное условие |
|---|---|---|
| classify → act | разным классам входа нужны разные процедуры | классификация имеет fallback |
| fan-out → barrier → synthesize | независимые части большого корпуса | синтез ждёт объявленный набор результатов |
| generate → filter | можно дёшево создать много кандидатов | критерий фильтра задан извне |
| adversarial verification | цена пропущенной ошибки высока | verifier независим и имеет явную рубрику |
| tournament | кандидаты можно сравнивать попарно | стоимость сравнения оправдана разрывом качества |
| loop-until-done | прогресс измерим по состоянию | есть предел итераций и аварийный выход |
Эти формы можно комбинировать, но гибрид должен появляться из наблюдаемой зависимости, а не из желания сделать систему сложнее (Multi Agent Patterns).
Когда цена оправдана
Динамический harness уместен, когда одновременно присутствуют несколько признаков:
- задача длинная и структура выясняется после первичного анализа;
- есть много независимых или соревнующихся ветвей;
- промежуточные результаты имеют строгую схему;
- полезны разные роли, модели или контексты;
- нужно возобновление или повторное использование части результатов.
Для обычной правки кода, короткого поиска и заранее известного pipeline он почти всегда хуже: больше токенов, больше точек отказа и труднее восстановить причинность. Сначала проверяется один агент или статический workflow.
Три характерных отказа
Agentic laziness. Оркестратор преждевременно объявляет составную задачу завершённой — например, обработал 35 элементов из ожидаемых 50 и перешёл к синтезу. Лечится явным expected set/cardinality, учётом статуса каждого элемента и completion barrier, который не открывается по самоотчёту модели.
Self-preferential bias. Генератор оценивает собственные варианты или синтезатор принимает ближайший к своему первоначальному мнению. Лечится независимым verifier и внешними критериями.
Goal drift. После нескольких стадий локальные агенты оптимизируют промежуточные формулировки, а не исходную цель. Поэтому неизменяемые intent, ограничения и DoD передаются каждой критической роли, а итог сверяется именно с ними.
К ним добавляется инженерный отказ: параллельные агенты пишут в общий ресурс. Независимость контекстов не изолирует файловую систему; задачи с пересекающимися файлами выполняются последовательно или в отдельных worktree (Parallel Agent Dispatch).
По умолчанию ad hoc, но удачный экземпляр можно стабилизировать
Первый экземпляр привязан к исходной задаче, поэтому не становится универсальным активом только по факту успешного запуска. Сначала сохраняется переносимый шаблон решения: какие сигналы выбирают fan-out, где находится barrier, что считается прогрессом, какой fallback.
Если тот же workflow повторно проходит на сходных задачах, его можно зафиксировать, версионировать и распространять через skill или каталог workflows. Тогда он перестаёт быть чисто динамическим экспериментом и проходит обычные проверки reusable harness: объявленный интерфейс, версии зависимостей, regression corpus и владелец.
Связано с
- Agent Harness — исполняемый слой, в котором живёт программа координации
- Agent vs Workflow — почему динамически созданная схема всё равно остаётся workflow
- Multi Agent Patterns — доступные формы координации и их уязвимости
- Parallel Agent Dispatch — независимость, конфликты записи и цена переделки
- State Centric Execution — состояние процесса вне transcript