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

В последнее время «инженерия графов» привлекает много внимания, и большинство объяснений сосредоточены на графах, узлах и DAG. Эти аспекты действительно важны, но они не отвечают на тот вопрос, который действительно заслуживает внимания: зачем вообще ИИ-агентам, занимающимся программированием, понадобилась инженерия графов?

Разработчик, который несколько месяцев работал с такими инструментами, как Claude Code, а затем Codex, заметил определенную закономерность. Большинство задач по программированию проваливаются не потому, что модель не может писать код. Они проваливаются потому, что длительные рабочие процессы постепенно теряют свою структуру. Контекст выходит из синхронизации, требования забываются, результаты становится трудно проверять, и когда что-то идет не так, простым решением часто бывает перезапуск всей задачи.

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

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

Что означает инженерия графов

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

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

Два вопроса, лежащих в основе дизайна

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

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

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

Контекст и контракты как строительные блоки

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

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

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

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

От идеи до выполнимого графа

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

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

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

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

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

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

Тестирование на более крупных и меньших моделях

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

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

Это породило дополнительный вопрос: может ли та же архитектура графа обеспечить надежные рабочие процессы на гораздо более маленькой и дешевой модели? Во втором эксперименте использовался рабочий процесс генерации учебных планов, выполняемый с помощью OpenCode и Big Pickle вместо сложной модели. Механизмы оставались прежними: рабочий процесс компилировался динамически, генерировались специализированные узлы, каждый этап проверялся детерминированно, при необходимости устранялись сбои, и итоговый результат формировался в рамках той же системы обработки.

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

Где возникали сбои

Эксперимент не показал, что инжиниринг графа предотвращает сбои. Он показал, что инжиниринг графа делает сбои видимыми.

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

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

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

Почему валидация должна быть детерминистичной

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

Именно поэтому каждый узел в ContractGraph завершается детерминистической проверкой. Никто не запрашивает мнение второй модели относительно результата. Рабочий процесс проверяет объективные условия: есть ли в схеме все необходимые поля? Соблюдены ли зависимости? Присутствуют ли требуемые результаты, и корректно ли работают ссылки? Передал ли узел всё то, что обещал его контракт? Это не субъективные оценки — каждый из этих вопросов имеет только два ответа: «да» или «нет».

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

Почему дополнительные усилия могут окупиться

Ещё до этого эксперимента разработчик рассматривал ИИ-агентов для программирования как небольшую команду, а не как отдельного помощника. Было обычным делом, когда Claude Code, Codex и OpenCode одновременно работали над разными частями одного репозитория.

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

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

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

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

Какова настоящая стоимость

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

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

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

Когда это оправдано

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

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

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

Заключительные мысли

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

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

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

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