Архитектурный аудит сбоящих мультиагентных конвейеров

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

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

Определите тип сбоя до смены стека

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

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

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

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

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

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

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

Хорошее описание инцидента называет нарушенный инвариант. Фраза «Агент B написал плохой код» почти ничего мне не говорит. Фраза «Два агента создали разные версии одной миграции после чтения разных снимков схемы» указывает на ошибки владения, контекста и последовательности. Более точная формулировка также подсказывает, какие данные конвейер должен сохранить при следующем запуске.

Конфликты слияния начинаются раньше, чем их замечает Git

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

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

Представьте изменение биллинга, разделенное между агентом API и агентом базы данных. Агент API решает, что status может принимать значения pending, paid или void, а агент базы данных использует cancelled вместо void. Они меняют разные файлы, проходят локальные тесты и сливаются без конфликта. Сбой возникает позже, когда рабочее событие содержит значение, которое потребитель не умеет обрабатывать. Ни один алгоритм слияния не способен угадать, какой словарь отражает принятое бизнес решение.

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

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

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

{
  "work_id": "billing-142",
  "owner": "agent-api",
  "decisions": ["invoice-status-contract"],
  "write_scope": ["api/invoices", "schemas/invoice.json"],
  "depends_on": ["tax-rules@7f31c2"],
  "acceptance": ["contract-tests", "migration-check"]
}

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

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

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

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

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

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

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

{
  "context_id": "ctx_01J9M6",
  "work_id": "billing-142",
  "source_commit": "7f31c2",
  "instruction_rev": "review-v12",
  "retrieval_snapshot": "kb-2026-07-27T09:15Z",
  "toolset_rev": "tools-v8",
  "predecessors": ["plan:sha256:8c2a..."],
  "model_profile": "code-large-temp0"
}

Передавайте этот идентификатор в журналы, метаданные артефактов, экраны проверки и записи о повторах. Тогда несогласованный ответ можно исследовать сравнением двух манифестов. Без идентификатора команда будет по памяти спорить о поведении модели.

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

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

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

Циклы повторов обнаруживают потерянные границы состояния

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

В статье AWS Builders' Library «Timeouts, retries, and backoff with jitter» повторы названы эгоистичными, потому что повтор расходует дополнительную мощность сервера ради повышения шанса одного запроса на успех. Статья также советует выполнять повторы на одном уровне стека, а не умножать попытки на каждом уровне. Мультиагентным конвейерам нужна та же дисциплина с дополнительным условием: попытка может оставить долговечные артефакты рассуждения и внешние побочные эффекты.

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

Опишите попытку явными состояниями, например queued, running, waiting_review, accepted, rejected и failed_retryable. Конечное состояние должно включать код причины. Произвольный текст может объяснить инцидент человеку, но машине нужна ограниченная причина вроде context_unavailable, tool_timeout, contract_failed или review_rejected, чтобы выбрать следующее действие.

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

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

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

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

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

Пропускная способность людей ограничивает конвейер

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

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

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

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

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

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

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

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

Четыре проверки показывают, нужен ли сначала аудит

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

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

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

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

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

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

Архитектурный аудит следует за данными

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

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

Запись событий должна иметь структуру, достаточную для этой работы. Как минимум каждое событие должно включать event_id, work_id, attempt_id, agent_id, context_id, artifact_refs, state_before, state_after, reason_code и временную метку. События побочных эффектов также требуют ключ идемпотентности и ссылку на результат во внешней системе.

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

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

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

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

В рамках моего Team & AI Audit я сначала применяю этот подход к инженерной системе и за пять рабочих дней нахожу экономию не менее $50,000 в год, иначе аудит стоимостью $5,000 проводится бесплатно. Обещание не меняет технический стандарт: каждую экономию нужно связать с наблюдаемой работой, предлагаемым изменением и способом проверить результат.

Добавляйте оркестрацию только после укрепления границ

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

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

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

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

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

Каждый принятый результат должен быть объясним

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

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

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

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