Замена мультиагентного конвейера разработки одним агентом

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

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

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

По умолчанию нужен один агент, пока параллелизм не окупится

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

Дополнительные агенты окупаются, когда части работы можно выполнять независимо и объединять почти без интерпретации. Например, можно генерировать клиенты для несвязанных API, обновлять изолированные пакеты с отдельными наборами тестов или изучать несколько внешних спецификаций до начала реализации. Исполнителям нужны разные области записи, точные форматы результата и один владелец слияния. Если два исполнителя могут изменить одну абстракцию или зависят от открытий друг друга, работа остается последовательной, даже когда среда запускает оба процесса одновременно.

Инженерный разбор мультиагентной исследовательской системы Anthropic проводит ту же границу на примере другой нагрузки. Система хорошо справлялась с исследованием вширь, где субагенты могли изучать независимые направления в отдельных окнах контекста. Авторы также сообщают, что мультиагентная система тратила примерно в 15 раз больше токенов, чем обычный диалог, и прямо указывают, что большинство задач разработки хуже поддается распараллеливанию: агентам приходится делить контекст и учитывать зависимости. Это число не прогнозирует стоимость вашего решения. Оно показывает, что параллельная мощность имеет заметную цену и должна давать результат, который один агент не получит с тем же качеством.

Перед добавлением исполнителя примените простой фильтр. Можете ли вы описать его задачу без фразы «согласуй с другим агентом», может ли он работать в отдельном файле или рабочем дереве и способен ли владелец принять результат с помощью детерминированной проверки? Если хотя бы один ответ отрицательный, оставьте работу у владельца. Название роли само по себе не требует отдельного агента.

Считайте оркестрацию измеримым налогом

Стоимость оркестрации складывается из дополнительного времени, расхода модели, повторных попыток и внимания человека, которые появляются из-за разделения работы. Записывайте ее для всего запуска. Дешевый вызов модели ничего не дает, если инженер двадцать минут выясняет, что агент-ревьюер проверял устаревший патч.

Минимально полезная трассировка выглядит как журнал с полями, разделенными табуляцией. Каждый агент и каждая детерминированная проверка дописывают в него строку. Заголовок должен оставаться неизменным:

run_id	stage	agent	started_at	finished_at	status	input_artifact	output_artifact

Используйте статусы ok, failed, retry и superseded. В полях артефактов храните неизменяемые идентификаторы коммитов, хеши патчей или имена файлов с результатами, а не описания вроде «последняя ветка». С таким журналом частоту сбоев передачи покажет обычная команда оболочки:

awk -F '\t' '$2 == "handoff" {total += 1} $2 == "handoff" && $6 != "ok" {bad += 1} END {printf "handoff_failure_rate=%.3f\n", total ? bad / total : 0}' runs.tsv

На выходе будет одно поле в машиночитаемом формате, например handoff_failure_rate=0.125. Это только пример формата, значение возьмется из вашего журнала. Аналогичными запросами считайте полное время, повторные проверки и промежуток от сбоя до возобновления полезной работы. Не просите модель оценивать собственную координацию, если среда исполнения может записать события напрямую.

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

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

Сбои передачи указывают на потерянное владение

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

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

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

Документация OpenAI Agents SDK проводит полезное различие между передачей управления и вызовом агента как инструмента. При передаче специалист принимает управление. В схеме с менеджером управляющий агент сохраняет владение и вызывает специалиста ради ограниченного результата. Конвейеры разработки часто используют передачу там, где достаточно вызова инструмента: можно попросить специалиста изучить миграцию или предложить тесты, а затем дать исходному владельцу встроить ответ в решение. Одно это изменение владения убирает целый класс ошибок из-за устаревшего состояния.

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

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

Повторные проверки выдают мнимый параллелизм

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

Записывайте проверки по отпечатку команды, входному артефакту и хешу результата. Два запуска одной тестовой команды для одного коммита считаются дубликатами, если среда и цель не различаются. Явно помечайте цель: обратная связь автору, приемочный барьер, проверка безопасности или подтверждение нестабильного теста. Тогда необходимый финальный барьер не попадет в отходы.

Команды чаще всего оправдывают дублирование необходимостью ревью. Независимый ревьюер способен найти ошибки, но второй универсальный агент с той же моделью, тем же видом репозитория и запросом из того же семейства может повторить рассуждение автора, а не проверить его. Независимость дает другой проверочный критерий или узкая инструкция, а не новое имя процесса. Детерминированные проверки стиля, типов, модулей, интеграции и правил держите вне агента-разработчика. Специалиста вызывайте там, где суждение дает новые основания, например для проверки обратной совместимости миграции базы данных.

Конвейер, который запускает все проверки после каждого исполнителя, создает еще и очередь. Самый медленный набор тестов становится барьером между зависимыми этапами, а следующие агенты могут повторить его после небольших правок. Исполнителям достаточно целевых тестов для обратной связи. Полную приемочную последовательность запускайте один раз для коммита-кандидата, которым владеет интегратор. Если поздняя правка сделала коммит неактуальным, журнал должен объяснять новый запуск барьера.

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

Не удаляйте проверку только потому, что команда уже запускалась. Удаляйте повторное выполнение для идентичного состояния. Финальный детерминированный барьер все еще нужен, даже если автор раньше прогонял тот же набор: результат барьера привязан к точному артефакту, который вы собираетесь выпускать.

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

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

Храните рядом с запуском короткий журнал решений, а не пересказ агента в прозе. Каждая запись должна содержать решение, основание, затронутый артефакт, отклоненный вариант и условие отмены решения. Например:

decision: keep the legacy response field for this release
evidence: integration fixture billing_v1 expects the field
affected_artifact: src/billing/response.ts
rejected_alternative: remove the field with the new endpoint
invalidate_when: billing_v1 fixture and consumer are retired

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

Измеряйте время восстановления контекста напрямую. Отметьте первое действие с инструментом после передачи и первое действие, которое меняет или проверяет артефакт-кандидат. Чтение файлов, поиск, повторное чтение задачи и поиск тестов между этими событиями относятся к восстановлению. Некоторое погружение неизбежно, но у якобы специализированного исполнителя оно должно оставаться ограниченным.

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

Один агент тоже способен потерять контекст после сжатия или долгого запуска. Решение состоит в контрольных точках, а не в автоматическом размножении агентов. На естественных границах сохраняйте цель задачи, текущий артефакт, пройденные и упавшие проверки, открытый вопрос и следующее действие. Возобновляйте работу того же владельца из этого состояния. Добавляйте агента, лишь когда отдельное окно контекста позволяет выполнить независимую работу, а не прикрывает слабую дисциплину памяти.

Важно различать емкость контекста и его непрерывность. Дополнительные агенты увеличивают емкость, потому что могут одновременно изучить больше материалов. Непрерывность снижается, потому что через каждую границу приходится переносить смысл. Задачам разработки, которые затрагивают одну связанную конструкцию, обычно нужнее непрерывность.

Время восстановления определяет пригодность конвейера

Время восстановления начинается, когда этап перестает продуктивно двигаться, и заканчивается, когда работа возобновляется от известного исправного артефакта. Включайте обнаружение, диагностику, откат или ремонт, восстановление контекста и ожидание в очереди. Конвейер может сбоить редко и все равно быть непригодным для рабочей среды, если каждый сбой останавливает несколько агентов и вынуждает начать заново.

В производственном разборе Anthropic сказано, что ошибки агентов с состоянием накапливаются, поэтому исследовательской системе понадобились долговечное исполнение, контрольные точки, повторные попытки и возобновление вместо перезапуска. Для разработки действует тот же принцип, но здесь есть сильный примитив контрольной точки: неизменяемый коммит вместе с внешним состоянием запуска. Если конвейер не знает, какой коммит читал и менял каждый агент, восстановление начинается с археологии.

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

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

Начните с такой минимальной политики восстановления:

owner: implementer
checkpoint: immutable_commit
retry:
  transient_tool_failure: 1
  semantic_failure: 0
resume_requires:
  - failed_stage
  - input_artifact
  - last_valid_artifact
  - gate_output

Политика не позволяет оркестратору перезапустить весь граф из-за сбоя одного исполнителя. Она также запрещает агенту восстановления менять неизвестное рабочее дерево. Подстройте число попыток под стоимость и идемпотентность инструментов, но не прячьте смысловые повторы.

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

Прогоните одни задачи двумя способами

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

Не ограничивайтесь аккуратными успешными примерами. Добавьте задачу с неоднозначным требованием, исходно падающим тестом, изменением нескольких файлов, сгенерированным артефактом и отказом инструмента. Поведение при восстановлении отличает рабочую конструкцию от демонстрации.

Для каждого запуска соблюдайте эту последовательность:

1. Зафиксируйте входную задачу, коммит репозитория, манифест среды и приемочные команды.
2. Запустите журнал до того, как первый агент прочитает задачу, и назначайте неизменяемые идентификаторы артефактов при каждой смене владельца.
3. Остановитесь, когда кандидат пройдет те же финальные проверки или исчерпает одинаковый лимит времени и вмешательств.
4. Попросите ревьюера, который не знает тип запуска, оценить корректность, границы изменений и понятность.
5. Сравните медианы и худшие случаи восстановления по типам задач, затем изучите трассировки, которые объясняют разницу.

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

Вариант с одним агентом должен сохранить инструменты и барьеры. Удаление агентов не означает, что одна модель обязана импровизировать во всех дисциплинах. Дайте владельцу поиск по репозиторию, команды целевых тестов, изолированное рабочее дерево, хранилище контрольных точек и возможность вызывать узких специалистов для ограниченных вопросов. Оставьте тот же финальный приемочный контур.

Повторите запуски достаточно раз, чтобы отделить устойчивую закономерность от одного странного пути модели, но не ждите статистического ритуала, прежде чем исправить очевидный дефект границы. Если трассировки снова и снова показывают, что ревьюер открывает те же файлы и исправляет устаревшие предпосылки, уже можно объединить владение автора и ревьюера для этого типа задач.

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

Несколько агентов нужны для действительно независимой работы

Несколько агентов полезны, когда декомпозиция дает результаты, которые можно оценить независимо. Широкий обзор кодовой базы, раздельное обновление пакетов, независимая генерация тестов для фиксированного интерфейса и изучение несвязанных руководств поставщиков подходят под это условие. Координатор должен объединять артефакты, а не примирять конкурирующие трактовки одной меняющейся конструкции.

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

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

Вызывайте специалистов как инструменты, если экспертиза нужна в узкой области. Главный агент может попросить специалиста по безопасности изучить изменение авторизации, специалиста по базам данных оценить совместимость миграции, а специалиста по тестам предложить пропущенные случаи. Возвращайте владельцу структурированный вывод вместо передачи всей задачи. Так сохраняется единая история решений и появляется дополнительный взгляд.

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

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

Уберите конвейер, но сохраните контроль

Удаляйте по одной границе между агентами. Начните с передачи, у которой самое долгое исправление или больше всего повторного погружения, затем поручите предыдущему владельцу выполнить следующий этап. Его приемочную проверку оставьте без изменений. Так вы поймете, добавляла ли граница новые доказательства или одну церемонию.

Перенесите инструкции до удаления компонентов среды исполнения. Запросы ревьюеров могут содержать полезные правила репозитория, ограничения выпуска и тестовые команды. Стабильные правила внесите в версионируемые указания проекта, машинно проверяемые правила закодируйте в приемочном контуре, а редкое суждение превратите в вызов специалиста. Не вставляйте все запросы ролей в одно огромное системное сообщение.

Сохраняйте разделение там, где оно защищает рабочую среду. Агент-разработчик не должен незаметно одобрять чувствительные действия развертывания лишь потому, что владеет реализацией. Человеческие одобрения, защищенные ветки, границы учетных данных, разрешения на развертывание и детерминированные проверки правил не зависят от числа агентов. Один агент с широкими и неконтролируемыми полномочиями устроен проще, но не безопаснее.

Используйте конфигурацию миграции, которая явно задает владение и барьеры:

mode: single_owner
owner: coding_agent
specialists:
  security_review: on_request
  migration_review: on_request
gates:
  feedback:
    - targeted_tests
  acceptance:
    - full_tests
    - lint
    - policy
artifacts:
  candidate: immutable_commit
  decisions: run_decisions.yaml

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

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

На oleg.is я использую Team & AI Audit, чтобы сопоставить роли агентов, передачи, стоимость инструментов и фонд оплаты разработки с наблюдаемой работой по выпуску продукта, а затем рекомендую изменения команды. Но архитектурное решение должно быть понятным и без этой услуги: ваша трассировка обязана показывать, где параллелизм окупается, а где одна задача просто размазывается по нескольким контекстам.

Выигрывает самая простая схема с нужной скоростью

Сохраняйте оркестрацию, когда независимые исполнители параллельно создают принимаемые артефакты и восстанавливаются, не блокируя друг друга. Заменяйте ее, когда исправление передач, повторные проверки, восстановление контекста и выход из сбоев съедают время, которое будто бы экономят параллельные вызовы. Эти сигналы надежнее мнений о современности команды агентов.

Не сравнивайте зрелый конвейер с небрежным одиночным запросом. Сравнивайте его с одним хорошо оснащенным владельцем в изолированном рабочем пространстве, с контрольными точками, инструментами специалистов и теми же приемочными барьерами. Только этот вариант дает честное сравнение.

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

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