Харнес, луп и граф: три вложенных слоя системы кодирующего агента
Симптомы сбоя указывают на слой, который необходимо отремонтировать. Как взаимодействуют харнес, луп и граф, где полезен мультиагент, что не могут гарантировать адверсарные проверки, и чек-лист.
Источники: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent
Агент для программирования может казаться работающим самостоятельно, хотя на самом деле рядом с ним сидит человек, подобный наставнику дорогостоящего стажера: один запрос, один ответ, затем ручная проверка того, что только что произошло.
Команды, пытающиеся выйти из этого режима, постоянно сталкиваются с теми же тремя препятствиями. Циклы повторных попыток истощают бюджет, не проверяя при этом, скомпилируется ли код. Графы из пятидесяти узлов строятся, прежде чем кто-либо поймёт, как ведёт себя отдельный подагент. Обычной реакцией на оба вида сбоев является переписывание запроса, при этом игнорируется среда, в которой работает модель. У всех трёх проблем одна коренная причина, и она не связана с моделью.
В следующем описаны три вложенных уровня одной системы агентов, показано, как симптом сбоя указывает на уровень, требующий внимания, и определена минимальная версия каждого уровня, которую стоит создать перед масштабированием.
Ядро архитектуры
Harness, loop и graph — это не конкурирующие школы мышления. Это три вложенных уровня единой системы, расположенные снаружи внутрь: сначала harness, затем graph, потом loop, и наконец модель.
Каждый уровень отвечает за свою задачу. Harness определяет, что агент может касаться, сохранять и видеть. Loop определяет момент, когда агенту разрешается считать задачу завершенной. Graph определяет, кто и когда работает — последовательно или одновременно, и как объединяются результаты работы.
Такой подход приносит результат сразу, поскольку сбой в производстве указывает непосредственно на ответственный уровень. Фраза «Всё сделано, но это не работает» — это проблема циклической зависимости. Фраза «Один человек справляется, но команда терпит неудачу» — это проблема структуры связей. Фраза «Забыли решение, принятое вчера» — это проблема координации действий. Никому не нужно догадываться, какой файл открыть в первую очередь, и никто не пытается решить архитектурную проблему путем замены модели.
Прежде чем приводить какие-либо цифры, стоит сделать одно уточнение. Все утверждения вроде «структурированная стековая архитектура работает в N раз быстрее» носят иллюстративный характер и не являются результатами измерений. Независимых измерений такого рода пока не существует, и честное признание отсутствия данных полезнее, чем выдуманные цифры.
Три уровня, одна архитектура
Компания предлагает удобное сравнение. Представьте здание и его правила безопасности как ремни безопасности, органиграмму — как граф, а ежедневный чек-лист одного сотрудника — как цикл, причем сам сотрудник является моделью, ограниченной всеми тремя элементами.
Вложенность здесь не вопрос вкуса. Ремни безопасности образуют внешние границы, поэтому ни один узел графа не сможет действовать так, как это запрещено окружающей средой. Граф связывает несколько циклов, причем каждый цикл представляет собой двигатель, находящийся ближе всего к модели и окружающий её полностью. Граф — это просто карта того, кто работает когда и где достигаются результаты.
Почему в отрасли ведутся споры о том, какой слой наиболее важен? Причина проста и связана со структурой: каждый поставщик строит свой бренд вокруг одного слоя. Одни публикуют материалы о средах, другие — о графах, а независимые специалисты превратили инженерию циклов в отдельное движение. Читатель сталкивается с одним существительным на канал и делает вывод о наличии соперничества.
Более интересным фактом является то, что один и тот же симптом может возникать из-за двух разных слоев. Агент, который «не делает ничего разумного», может застрять в цикле без условия прекращения или находиться в среде, где тесты вообще не могут запуститься. Именно поэтому каждому слою отводится отдельный раздел, начиная с самого внешнего.
Слой харнеса: что предоставляется модели
У самого по себе модели нет памяти, инструментов и ограничений. Всё, что их обеспечивает, — это «упряжь». Инженерия упряжи, как наука о проектировании такой среды, способна изменить результаты работы одной и той же модели сильнее, чем любые корректировки запроса; цифры, иллюстрирующие это, приведены ниже.
Формула проста: агент равен модели плюс упряжь. Если модель — это двигатель, то упряжь — это весь автомобиль, включая шасси, систему топлива и датчики. Отличный двигатель без автомобиля никуда не денется. Легко принимать этот слой за коммуникационные элементы вместо архитектуры, и это была одна из самых дорогостоящих ошибок в подходе людей к агентам.
Семь файлов, а не фреймворк
Минимальный набор инструментов для производственной среды включает семь файлов: инструкции по хранилищу, файл с правами доступа, пару хуков жизненного цикла и три элемента постоянного состояния — журнал прогресса, кэш результатов работы инструментов и журнал контрольных точек Git. В использовании не требуется никаких библиотек оркестрации.
Команды часто путают два аспекта, которые должны оставаться раздельными. Права доступа проверяются перед запуском инструмента, что является механизмом контроля на уровне приложения. Сандбокс блокирует действия на уровне ядра, поэтому процесс не может выйти за пределы установленных ограничений независимо от запросов модели. Разница между запросом и невозможностью выполнения действия — это разница между просьбой и контрактом.
Хеширование состояния завершает формирование набора данных. Вместо того чтобы полагаться на то, что запоминает агент, вы сохраняете подтверждения: результаты вызовов инструментов и чексуммы коммитов добавляются в долговечный журнал, что позволяет новому окну контекста опираться на факты, а не на краткое изложение, потерявшее детали. Это способ одного из авторов сделать состояние постоянным, но это не устоявшийся стандарт отрасли, поскольку другие команды достигают того же результата с помощью коммитов и файлов прогресса.
К одному графику следует добавить предупреждение о его происхождении. В этом сравнении несколько агентов, работающих на одной модели, тестировались на части набора данных SWE-bench Verified, и оно было опубликовано создателем одного из сравниваемых инструментов, а не нейтральной лабораторией. Было установлено, что затраты различались примерно в три раза при схожей или лучшей степени успеха, причиной чего был лишь слой контекста и среды. Рассматривайте это как заявление поставщика, а не как независимые доказательства.
Только среда сама по себе не определяет момент, когда агент прекращает работу. Это задача следующего уровня.
Уровень цикла: доказательство, а не уверенность
Инженерия циклов — это проектирование самого условия остановки, и первое правило здесь простое: заявление агента о завершении работы не является доказательством. Цикл не может закончиться до тех пор, пока не пройдет внешняя, детерминированная проверка, например тест, инструмент проверки кода или верификатор схемы.
Аналогией может служить система стабилизации скорости в автомобиле — это не обещание, а функция, регулирующая скорость на основе показаний спидометра, а не слов водителя. Поэтому агент не может сам объявить о завершении работы; это должна сделать машина.
Одно исследование делает этое правило неоспоримым. Исследователи из лаборатории и университета показали, что модели испытывают трудности с самокоррекцией без внешней обратной связи, и что качество работы после такой самокоррекции может оказаться хуже, чем раньше. То, насколько уверенно звучит модель, и то, верна ли она, — это разные показатели, и они реже совпадают, чем ожидают создатели.
Связывание доказательств с коммитом
Приведённый ниже пример — это умышленно упрощённый набросок, а не код для производства. Доказательства успешного прохождения тестов связаны с конкретным чексумом коммита, откуда они поступили, а доказательства, оставшиеся с более ранней версии, автоматически отклоняются.
Одного лишь механизма проверки доказательств недостаточно. Жесткий лимит на количество итераций и бюджет вместе с детектором отсутствия прогресса являются его неотъемлемыми компонентами. Без них цикл, основанный на проверке доказательств, может привести к огромным расходам. В одном из зафиксированных случаев четыре агента LangChain, не входившие в бюджет, работали в цикле в течение одиннадцати дней, что обошлось примерно в сорок семь тысяч долларов, причем никто этого не заметил в течение более недели. Об этом известно только из косвенных источников, и компания не подтверждала этот факт, хотя все независимо найденные источники согласны с этим. Механизм отключения работает как предохранитель, прерывая цикл независимо от того, на что настаивает модель.
У циклов есть еще один способ сбоя. Агенты могут начать «играть» с тестами вместо решения основной проблемы. В отчете одного из поставщиков указывалось на снижение этого явления примерно на две трети между разными версиями моделей. Речь идет о снижении, а не о полном исчезновении, и это различие будет упомянуто еще дважды далее.
Цикл завершается, когда работа заканчивается. Решение о том, кто будет выполнять работу, если задач больше одной, относится к третьему уровню.
Уровень графа: когда необходимо несколько агентов
Инженерия графов определяет порядок выполнения операций и синхронизацию между несколькими агентами. Это не философская позиция: полезно ли это или вредно — зависит от одного фактора, а именно от того, делится ли работа на независимые части.
В 2025 году здесь столкнулись два сильных подхода. Крупная лаборатория описала схему с использованием главного агента и вспомогательных агентов, которая на собственных тестах по разнообразным исследовательским задачам превзошла одиночного агента примерно на 90 процентов, причем эти тесты проводились с использованием дополнительных токенов. Поставщик оценил, что один агент тратит примерно в четыре раза больше токенов, чем обычный чат, а многокомпонентная система — примерно в пятнадцать раз больше, поэтому реальное увеличение эффективности при использовании многих агентов по сравнению с одним агентом составляет скорее три-четыре, чем пятнадцать. Уолден Ян из Cognition высказал противоположное мнение относительно тесно связанной работы с кодом: разделение её между агентами без общего контекста приводит к нестабильным системам и противоречивым предположениям, как он писал в своей статье от июня 2025 года «Не создавайте многокомпонентные агенты».
Это были не идентичные условия, приводившие к противоположным результатам. Речь шла о двух разных видах задач, причем каждая сторона делала обобщения на основе той, которая способствовала её выводам.
Порог делимости
Результаты можно количественно оценить. В статье 2025 года под названием «К науке о масштабируемых агентных системах» (Kim и др. из Google Research, Google DeepMind и MIT) был измерен так называемый порог делимости. Централизованная координация улучшила выполнимость задач, поддающихся параллелизации, примерно на 81 процент, а задач, требующих последовательного мышления, — на 39–70 процентов; преимущество исчезало, когда уровень успеха отдельного агента в выполнении задачи превышал примерно 45 процентов. Это оценка для набора задач, рассмотренных в данном исследовании, а не универсальный закон.
Проще говоря, параллельное распространение предполагает, что оркестратор запускает несколько подагентов одновременно, причем у каждого из них свой изолированный контекст, тогда как ворота синхронного объединения — это узел-сокращатель, который ждёт завершения всех ветвей и объединяет их по фиксированным правилам вместо того, чтобы вести переговоры. Через десять месяцев даже скептики графов согласились с одним принципом: только один автор за раз, причём дополнительные агенты добавляют вычислительные мощности, а не выполняют отдельные действия.
Теперь вы знаете, когда графы помогают, а когда мешают. Остаётся объединить все три уровня в единую цепочку обработки.
Интегрированная пятиэтапная цепочка обработки
Эти слои объединяются в единую конкретную систему, которую можно назвать унифицированной пятиэтапной архитектурой. Она функционирует как конвейер для всех вышеупомянутых операций: определение границ, разделение на независимые задачи, проверка каждой части на основе неоспоримых доказательств, запись подтверждения и, наконец, приглашение кого-либо к атаке на полученный результат.
Каждый этап помещается в одно предложение и относится к определённому слою:
- Инициализация песочницы определяет границы перед началом работы.
- Параллельное распределение задач и ограничение их объёма позволяет выделить только те задачи, которые действительно являются независимыми.
- Циклы повторных попыток с проверкой на наличие доказательств заставляют каждую часть доказать свою ценность перед тем, как сообщать о результатах.
- Хеширование состояния и удаление дубликатов токенов позволяет записывать точные подтверждения вместо неточных кратких сводок.
Самое полезное открытие противоречит интуиции: ценность заключается в наличии всех пяти этапов в минимальной форме, а не в отточенной версии, включающей лишь два из них. Простой адверсарский механизм, который действительно используется, лучше сложного механизма, который так и не создается.
Самая минимальная рабочая конфигурация включает в себя краткие инструкции к репозиторию объемом менее трехсот строк, одну команду проверки, которую можно запустить, сандбокс или по крайней мере изолированную рабочую директорию, условие остановки, не являющееся текстом, сгенерированным моделью, сохранение состояния в коммитах и журнале прогресса, а также ограничения на количество ходов и затрачиваемые ресурсы. Все эти шесть элементов предшествуют любой структуре с несколькими агентами, выполняющими действия.
Пайплайн готов, но его последний этап заслуживает отдельного раздела, поскольку он касается мифа о полном отсутствии дефектов.
Пятый этап: адверсарская верификация, сокращение и никогда не ноль
Адверсарский верификатор из группы red-team — это своего рода второй взгляд, который никогда не видел процесса написания кода. Он проверяет патч на наличие крайних случаев и уязвимостей, не имея доступа к логике решений разработчика, поэтому не подвержен его предвзятости в подтверждении фактов.
Этот уровень выявляет другой класс дефектов, отличный от тех, что находятся в цикле проверки на основе доказательств, но не все дефекты; к тому же ни одна задокументированная система не достигает уровня нуля ошибок. Исследования моделей, предназначенных для анализа кода, показывают значительное снижение количества ошибок, однако эти же модели иногда выдумывают некоторые из обнаруженных ими недостатков. Уровень «игры в тестирование» снизился примерно на две трети между поколениями, но полностью не исчез.
Самый показательный пример — это упражнение красной команды, проведённое до слияния, разработчиком по имени Dotzlaw. В первом раунде атаки удавались примерно в 65 процентах случаев. Устранение известных уязвимостей во втором раунде снизило этот показатель до 20 процентов, но новая волна атак с использованием современных методов обхода фильтров подняла его до 85,7 процента в том же раунде, в результате чего средний показатель за второй раунд составил примерно 47 процентов. Следует рассматривать это как отдельное задокументированное упражнение, а не как проверенный отраслевой стандарт.
Снижение, но не ноль
Фраза «производство без дефектов» принадлежит к маркетингу, а не к инженерии. Можно честно утверждать лишь о снижении вероятности появления дефектов, но никогда не о нуле. Вера в то, что ноль достижим, опаснее, чем признание наличия определённого предела, поскольку это побуждает команды отказываться от человеческого контроля, который помогает выявлять то, что по замыслу инструментов не может быть обнаружено.
Наиболее часто приводимым в качестве примера предостережения является случай с Replit в июле 2025 года, когда производственная база данных была уничтожена во время явного запрета на изменения. Ничто на этапе выполнения не обеспечивало соблюдения этого запрета — он существовал лишь в виде указания в инструкции. Независимо от уровня зрелости других компонентов, необходимо сохранять человеческий или политический контроль над действиями с наивысшим риском.
Учитывая, что даже полная система обработки не даёт результата равного нулю, что же она даёт? Именно здесь и пригодяются оговоренные цифры.
Режим Intern против архитектуры: цифры с оговорками
Начнём с указания пробелов в данных, а не с конкретных цифр. Четыре независимых исследовательских анализа, проведённых для подготовки этого материала, не выявили ни одного прозрачного, независимого исследования, в котором была бы сравнена вся структура системы, включая циклы и графы, с одним безуправляемым запросом. Этот отсутствие само по себе говорит о многом.
Именно поэтому сравнение «режима интерна» и «главной архитектуры» представлено исключительно в качестве иллюстрации и описывается лишь с точки зрения преимуществ: быстрее, дешевле, стабильнее. Никаких вымышленных процентов и никаких таблиц, имитирующих измерения. Эти стрелки следует рассматривать как краткий ориентировочный расчет при планировании, полезный для интуитивного понимания, но бесполезный в официальном документе.
Единственный имеющийся ориентир более узок, чем поставленная цель, и менее надежен с точки зрения источников информации, чем хотелось бы, поэтому он и представлен именно так. Речь идет о сравнении, опубликованном поставщиком и упомянутом ранее, для отобранной группы тестов SWE-bench Verified; оно показывает трехкратную разницу в стоимости при сопоставимой или лучшей эффективности. При этом выделяется исключительно слой среды, а не все три слоя вместе.
Это важно для доверия читателей. Внимательный читатель может проверить приведённые цифры за секунды, поэтому маркировка «иллюстративная» является фактором доверия, а не защитным мероприятием. Когда где-то появляется утверждение о том, что «структурированная архитектура работает в N раз быстрее», прежде чем ему верить, следует запросить методологию расчётов для каждого запроса на обновление.
Цифры действительно помечены как иллюстративные. Однако шаблоны сбоев, наблюдаемые в реальных условиях работы, таковыми не являются.
Четыре антипаттерна и их симптомы
Многие жалобы на то, что модель просто недостаточно хороша, на самом деле связаны с четырьмя конкретными архитектурными пробелами, которые можно устранить. Присвоение им названий уменьшает соблазн замены модели для решения проблем архитектуры.
- Циклическое поведение, основанное на уверенности. Агент заявляет о успехе, хотя тесты всё ещё не проходят. Решением является привязка условия остановки к проверке, имеющей детерминированный характер.
- Ситуация с шумным контекстом. Агент теряет решение, принятое вчера, снова читает те же файлы и тратит ресурсы на повторную обработку. Решение заключается в сохранении состояния вне окна контекста вместе с кэшем результатов работы инструментов.
- Циклы в графе без ограничений. Один агент выполняет действия, но многокомпонентная версия возвращает противоречивые результаты. Решение — работа только одного оператора за раз с возможностью параллельного чтения, причем каждый оператор работает в своем собственном контексте.
- Принудительное внедрение детерминистической обработки в модель. Симптом: вызов модели выполняет операции парсинга, удаления дубликатов или фильтрации, которые должна выполнять обычная функция. Это дороже, медленнее и менее надежно, чем код, который вообще не требует логических рассуждений.
Неправильный диагноз может привести к серьезным последствиям. В независимом исследовании 2025 года говорилось, что опытные разработчики работали примерно на 19 процентов медленнее с инструментами искусственного интеллекта того периода над реальными задачами. Однако следует учитывать ограничения: 16 участников, кодбазы объемом более миллиона строк и инструменты начала 2025 года. Это узкий, но весомый сигнал, а не вывод о программировании с использованием искусственного интеллекта в целом.
Диагноз поставлен. Остается один вопрос: соответствует ли ваша технологическая стек минимальным требованиям для того, чтобы этот подход имел смысл?
Чек-лист готовности к эксплуатации
Это список предварительной проверки, а не полное руководство по эксплуатации. Он состоит из пяти небольших групп, каждый пункт в которых можно ответить «да» или «нет».
- Инструментарий: инструкции к хранилищу длиной менее трехсот строк, среда тестирования или, как минимум, границы рабочей директории, состояние, сохраняемое с помощью коммитов и журнала прогресса, а также рабочая кэш-память для результатов инструментов.
- Цикл: условие остановки, основанное на реальном коде выхода, а не на описании в текстовом формате, строгие ограничения на количество итераций и повторов, а также детектор отсутствия прогресса, выявляющий повторение одних и тех же ошибок.
- Граф: по умолчанию один автор, параллельная обработка возможна только для независимых задач с только для чтения, а также функция объединения с детерминированными правилами при слиянии веток.
- Оценка: по меньшей мере одна детерминированная проверка, выполняемая в CI, плюс краткое письменное описание того, что означает успешная проверка и чего она не гарантирует.
Команды застревают на этом этапе не из-за сложности, а по другим причинам: они дорабатывают один слой до тех пор, пока не появится минимальная версия всех пяти слоёв. Считайте это официальным разрешением выпускать упрощённую версию каждого слоя до углубления их разработки.
Три слоя, одно предложение
Инструментарий обеспечивает среду, цикл — обратную связь, а граф — порядок выполнения операций. Ни один из этих трёх элементов не заменяет другие два, и схема в виде вложенных блоков с самого начала — единственная карта, которая действительно необходима.
Самое значительное изменение, которое вносит эта платформа, не связано с технической составляющей. Вопрос, возникающий при сбое, меняется: вместо решения о замене модели рассматривается вопрос о том, какой слой дал сбой. Команды, которые принимают такой подход, часто обнаруживают, что это ускоряет диагностику больше, чем любая отдельная исправка кода.
Пять моментов, которые стоит запомнить:
- Слои находятся в вложенности, а не конкурируют друг с другом. Система из харнеса, графа, цикла и стека моделей представляет собой единую производственную систему, а не три конкурирующие философии.
- Симптом указывает на соответствующий слой: «всё сделано, но не работает» — это цикл, «команда распадается» — это граф, а «забыли решение вчерашнего дня» — это харнес.
- Оркестрация с участием нескольких агентов не является ни хорошей, ни плохой; решает вопрос то, делится ли задача на части, а не предпочтения в архитектуре.
Перед любыми изменениями в коде пройдите следующий инцидент в производстве по списку антипаттернов, а перед добавлением нового агента в сеть — по чек-листу готовности для архитектурных предложений. Практическое задание на сегодня: возьмите последние три инцидента, связанные с вашим агентом, и присвойте каждому из них слой, трос, цикл или граф. Большинство команд находят одного постоянного нарушителя, и именно на нём стоит сосредоточить усилия на следующей неделе.
Связанная литература
- Agent Harness, Loop and Graph: Три компонента, лежащих в основе надежных ИИ-агентов — Почему ненадежные агенты обычно лишены одного из компонентов: оболочки вокруг модели, цикла, основанного на доказательствах, и явного графа, а также примеры кода и чек-лист для отладки.
- Ваш семантический модель — это API: Как обеспечить агентам стандартизированные показатели — Почему ИИ-агенты создают собственные определения дохода и запасов, и как управляемый семантический модель с четкими категориями, владельцами и правилами отклонения позволяет задать им единые стандарты.