Обновлено 26 июля 2026 года. Материал подготовлен редакцией AI рассвет на основе первичных технических источников и исходной X Article.
Graph Engineering, или графовая инженерия ИИ-агентов, — это проектирование работы одного или нескольких агентов как исполняемого графа: узлы выполняют ограниченные задачи, рёбра передают данные и задают реальные зависимости, проверки отсеивают ошибки, а внешние сигналы подтверждают результат. Подход нужен не для любого промпта. Он окупается, когда задачу можно разделить минимум на два независимых потока, запустить их параллельно и затем контролируемо объединить.
Главное преимущество графа — не «больше интеллекта», а управляемая ширина: меньше лишнего ожидания, отдельные контексты, явные контракты и видимая точка отказа. Главный риск — принять внутреннее согласие агентов за истину. Поэтому хороший граф опирается на тесты, документы, транзакции, экспертное одобрение и другие внешние якоря, а также имеет лимиты времени, стоимости и числа попыток.
Коротко: сначала нарисуйте текущий процесс, удалите ложные рёбра, выделите критический путь, задайте каждому узлу вход и структурированный выход, добавьте независимую проверку и только после этого увеличивайте число агентов.
Содержание
- Почему все заговорили о Graph Engineering
- Что такое граф ИИ-агентов
- Graph Engineering, loop engineering и prompt engineering
- Тест ложного ребра
- Критический путь: откуда берётся ускорение
- Паттерн diamond: fan-out, reduce, verify, synthesize
- Контракт узла
- Почему исполнитель не должен проверять сам себя
- Внешние якоря истины
- Где графы ломаются
- Когда граф не нужен
- Наблюдаемость и управление стоимостью
- Кейс Bun: 64 агента и цена экстремального параллелизма
- Как построить первый граф за 7 шагов
- Три готовые спецификации
- Как выбрать инструмент
- FAQ
- Итог
Почему все заговорили о Graph Engineering
В июле 2026 года новый термин разошёлся после короткой реплики разработчика Питера Штайнбергера о переходе от loops к graphs. Анатоли Копадзе развил идею в большой X Article о Graph Engineering: объяснил узлы и рёбра, предложил «тест ложного ребра», показал diamond-паттерн и предупредил о стоимости агентских флотов.
Название свежее, но инженерная основа не нова. Графы зависимостей десятилетиями применяются в компиляторах, планировщиках, ETL, CI/CD и системах управления бизнес-процессами. Новизна 2026 года в другом: LLM-агенты стали достаточно самостоятельными, чтобы быть исполнителями отдельных узлов, а инструменты оркестрации научились создавать и координировать такие узлы динамически.
Anthropic описывала те же строительные блоки раньше: prompt chaining, routing, parallelization, orchestrator-workers и evaluator-optimizer. В официальном руководстве Building Effective AI Agents компания рекомендует добавлять сложность только тогда, когда она измеримо улучшает результат. Microsoft Agent Framework, в свою очередь, прямо определяет workflow как систему, которая связывает исполнителей и рёбра в направленный граф.
Поэтому Graph Engineering полезно понимать не как новую магию и не как замену циклам. Это удобное название для дисциплины, которая делает явными:
- декомпозицию задачи;
- зависимости и параллелизм;
- формат передачи состояния;
- роли исполнителей и проверяющих;
- внешние критерии истины;
- повторные попытки и условия остановки;
- бюджет, права доступа и человеческие шлюзы.
Что такое граф ИИ-агентов
Граф состоит из узлов и рёбер.
Узел — одна ограниченная работа. Например: собрать официальные цены конкурента, проверить ссылку, выполнить тесты, классифицировать обращение или написать раздел отчёта.
Ребро — зависимость, по которой от одного узла к другому передаётся результат или управляющий сигнал. Если узел B не может начаться без выхода A, между ними есть ребро A → B. Если B не использует результат A, последовательность может быть привычкой, а не зависимостью.
На практике полезно добавить ещё четыре понятия:
| Понятие | Что означает | Пример |
|---|---|---|
| Состояние | данные конкретного запуска | список найденных документов и их даты |
| Условие перехода | правило выбора следующего ребра | если confidence ниже 0,8 — отправить на перепроверку |
| Шлюз | автоматическое или человеческое решение | публикация только после одобрения редактора |
| Якорь | внешний проверяемый сигнал | HTTP 200, прошедший тест, запись в CRM, банковская транзакция |
Не каждый граф является DAG. DAG — directed acyclic graph, направленный ациклический граф без возврата к прежнему узлу. Он подходит для конечного pipeline: исследование → brief → черновик → аудит → публикация. Если результат проверки возвращается исполнителю на исправление, появляется цикл. Производственный workflow часто сочетает DAG верхнего уровня и локальные циклы внутри отдельных этапов.
Можно использовать одного и того же провайдера LLM во всех узлах и всё равно получить граф. И наоборот, десять агентов в одном общем чате не обязательно образуют хороший граф: без явных контрактов, изоляции и переходов это может быть одна длинная беседа с несколькими голосами.
Graph Engineering, loop engineering и prompt engineering
Эти подходы отвечают на разные вопросы и не отменяют друг друга.
| Уровень | Главный вопрос | Единица проектирования | Когда полезен |
|---|---|---|---|
| Prompt engineering | как сформулировать одну инструкцию | промпт | ограниченный единичный ответ |
| Context engineering | какие данные и правила дать модели | контекст | сложная задача в одной сессии |
| Loop engineering | как повторять действие до критерия готовности | цикл «действие → проверка → коррекция» | один изменяемый артефакт или открытый поиск |
| Graph Engineering | какие работы зависят друг от друга и кто их проверяет | сеть узлов, рёбер и шлюзов | широкий процесс с параллельными ветвями |
Цикл хорошо решает задачу «продолжай исправлять код, пока тесты не пройдут». Граф нужен, когда одновременно проверяются backend, frontend, безопасность и документация, а затем результаты сходятся в общий release decision.
Внутри графа почти всегда остаются циклы. Исследователь может повторять поиск, пока не найдёт два независимых первичных источника. Кодер может исправлять реализацию по результатам тестов. Проверяющий может вернуть находку на повторную работу. Graph Engineering определяет, как несколько таких контуров связаны, где они могут работать параллельно и на каком условии останавливаются.
Тест ложного ребра
Самый практичный тезис исходной статьи Анатоли Копадзе — проверить каждую последовательную пару вопросом:
Нужен ли следующему шагу фактический результат предыдущего?
Если нужен, ребро настоящее. Если нет, ожидание, вероятно, искусственное.
Предположим, процесс сформулирован так:
- проверить файл A на уязвимости;
- проверить файл B на уязвимости;
- проверить файл C на уязвимости;
- собрать отчёт.
Проверки A, B и C не используют результаты друг друга. Между ними нет рёбер; они могут стартовать одновременно. Реальные рёбра ведут от каждой проверки к узлу объединения.
Но тест нельзя применять только к промптам. Два узла могут не обмениваться текстом и всё равно зависеть друг от друга через общий ресурс.
| Скрытая зависимость | Что может случиться | Правильное решение |
|---|---|---|
| один файл или ветка Git | перезапись изменений | отдельные worktree или последовательный merge |
| общий rate limit API | каскад 429 и повторов | глобальный семафор и backoff |
| одна запись в базе | race condition | транзакция, блокировка или очередь |
| общий денежный лимит | непредсказуемый перерасход | централизованный budget gate |
| зависимый бизнес-инвариант | два локально верных решения конфликтуют | общий контракт и интеграционный тест |
Поэтому расширенный тест звучит так: использует ли следующий узел результат, изменяемое состояние, лимит или ресурс предыдущего? Если да, зависимость реальна, даже если данные не передаются в сообщении.
Критический путь: откуда берётся ускорение
Граф не делает каждый узел быстрее. Он сокращает общее wall-clock time за счёт параллелизма.
Для линейной цепочки время примерно равно сумме длительностей:
Tlinear = T1 + T2 + ... + Tn
Для идеального параллельного слоя время приближается к самому медленному узлу плюс накладные расходы:
Tlayer ≈ max(T1, T2, ... Tn) + Toverhead
Общее время графа определяется критическим путём — самой длинной по времени цепочкой реальных зависимостей. Именно её надо оптимизировать первой.
Рассмотрим Estimated-сценарий, а не измеренный benchmark. Четыре исследования занимают по 60, 80, 90 и 120 секунд, проверка — 40 секунд, синтез — 60 секунд.
- линейный запуск:
60 + 80 + 90 + 120 + 40 + 60 = 450 секунд; - параллельные исследования:
max(60, 80, 90, 120) + 40 + 60 = 220 секунд; - теоретическое ускорение: примерно
2,05×без учёта оркестрационных накладных расходов.
Обещание ускорить любые 40 шагов с пяти минут до пятнадцати секунд некорректно без профилирования. Если 35 шагов действительно зависят друг от друга, граф почти не поможет. Если независимы 35, но внешний API допускает лишь пять одновременных запросов, предел задаст rate limit. Граф показывает потенциальный параллелизм, а не отменяет физические ограничения.
Паттерн diamond: fan-out, reduce, verify, synthesize
Базовая форма полезного графа похожа на ромб:
PLAN → FAN-OUT → REDUCE → VERIFY → SYNTHESIZE → HUMAN GATE
Plan
Оркестратор разбивает цель на независимые углы. Для исследования рынка это могут быть спрос, конкуренты, цены, регулирование и технологические ограничения. Углы должны быть взаимно различимыми; пять одинаковых запросов создают дорогое голосование, а не широкое исследование.
Fan-out
Рабочие узлы запускаются параллельно. Каждый получает минимально необходимый контекст, собственную роль и структурированный формат ответа. Такой подход уменьшает взаимное заражение предположениями и не переполняет основную сессию сырыми данными.
Reduce
Дедупликацию, сортировку, подсчёт и проверку схемы лучше выполнять обычным кодом, если для операции не требуется суждение. LLM не нужна, чтобы удалить точные дубликаты URL, проверить обязательные поля или посчитать число результатов.
Verify
Отдельный узел пытается опровергнуть находку: открывает источник, сверяет дату, проверяет соответствие цитируемому тезису. Для кода таким узлом может быть тест runner или статический анализатор. Для финансов — сверка с системой учёта. Для контента — фактчекер с доступом к первоисточникам.
Synthesize
Финальный агент получает не весь сырой поток, а проверенные и нормализованные результаты. Его задача — собрать единый ответ, не добавляя неподтверждённых фактов.
Human gate
Человек подтверждает рискованное действие: публикацию, платёж, изменение production, отправку клиенту, удаление данных или юридически значимое решение. Автоматизация подготовки не означает автоматизацию последней ответственности.
Контракт узла
Узел становится соединяемым, когда имеет контракт. Минимальный контракт отвечает на девять вопросов.
| Поле | Вопрос |
|---|---|
| Job | какую одну работу выполняет узел? |
| Input | какие поля получает и откуда? |
| Output | какую схему обязан вернуть? |
| Tools | к каким инструментам и данным имеет доступ? |
| Success | что считается успехом? |
| Timeout | сколько времени разрешено? |
| Retry | какие ошибки повторять и сколько раз? |
| Side effects | что узел может изменить? |
| Evidence | какой внешний сигнал прикладывается? |
Пример узла исследования цены:
| Поле | Значение |
|---|---|
| Job | получить публичную цену одного тарифа |
| Input | competitor, official_url, currency |
| Output | price, period, currency, source_url, checked_at, confidence |
| Tools | браузер, только чтение |
| Success | цена и период найдены на официальной странице |
| Timeout | 90 секунд |
| Retry | один повтор при сетевой ошибке |
| Side effects | отсутствуют |
| Evidence | URL страницы и дата проверки |
Свободный текст остаётся полезным внутри узла, но на ребро лучше выпускать типизированный объект. Если поле отсутствует, оркестратор может повторить узел или пометить результат неполным. Если на ребро передаётся «стена текста», следующий агент вынужден заново угадывать структуру, и граф теряет детерминизм.
Для узлов с побочными эффектами нужна идемпотентность: повтор не должен дважды списывать деньги, создавать дубликат заказа или отправлять одно письмо. Обычно применяют idempotency key, уникальный run ID, проверку текущего состояния и журнал совершённых действий.
Почему исполнитель не должен проверять сам себя
Разделение исполнителя и проверяющего снижает риск, но формулировка «они никогда не должны делить контекст» слишком абсолютна. Проблема не в самом факте передачи контекста, а в коррелированной ошибке: проверяющий принимает исходные допущения исполнителя и оценивает правдоподобие вместо результата.
Практическое правило:
- проверяющий не получает скрытое рассуждение и историю убеждения исполнителя;
- получает проверяемый артефакт, критерии и минимальные необходимые исходные данные;
- самостоятельно вызывает инструменты и открывает источники;
- по возможности использует другой prompt, роль или модель;
- возвращает доказательство, а не только
PASS.
Для текста полезны три независимые линзы:
- Correct — соответствует ли утверждение источнику?
- Current — актуальны ли дата, версия и цена?
- Credible — первичный ли это источник и существует ли он?
Большинство голосов не превращает мнение в факт. Три LLM могут одинаково ошибиться. Поэтому verifier должен опираться на внешний сигнал: открыть URL, выполнить тест, воспроизвести расчёт, сравнить запись с системой-источником.
Внешние якоря истины
Граф может быть идеально согласован и полностью неверен. Это происходит, когда все узлы проверяют отчёты, созданные тем же контуром.
Якорь истины — сигнал вне рассуждений модели, который нельзя улучшить красивой формулировкой.
| Область | Слабая проверка | Сильный якорь |
|---|---|---|
| Код | «реализация выглядит верно» | тест реально выполнен, exit code 0 |
| SEO | «ключи естественно встроены» | валидный HTML, canonical, schema и публичный HTTP 200 |
| Продажи | «лид квалифицирован» | клиент подтвердил потребность или оплатил |
| Финансы | «суммы сходятся в отчёте агента» | сверка с банком и учётной системой |
| Поддержка | «ответ должен помочь» | тикет закрыт без повторного обращения в заданный период |
| Исследование | «источник авторитетный» | первичный документ содержит конкретный тезис |
Часть ограничений должна быть неизменяемой для оптимизатора: запрет публиковать без человека, потолок расходов, перечень недоступных секретов, запрет менять тесты ради зелёного результата. Если агент может ослабить критерий, по которому его оценивают, он способен оптимизировать метрику вместо цели.
Именно поэтому при внедрении ИИ в бизнес-процессы сначала фиксируют границы и показатель результата, а уже потом выбирают модель и оркестратор.
Где графы ломаются
1. Коллапс контекста на fan-in
Тысяча рабочих узлов может произвести больше текста, чем способен принять финальный синтезатор. Решение — иерархическое объединение: разбить результаты на пакеты, нормализовать каждый, создать промежуточные summaries и только затем выполнить финальный merge. Сырые доказательства сохраняются отдельно и доступны по ссылкам.
2. Ложная независимость
Агенты работают в одном каталоге, обновляют одну запись или конкурируют за лимит API. Решение — изоляция workspaces, ownership файлов, транзакции, очереди и глобальные ограничители параллелизма.
3. Тихая потеря узла
Один из 200 workers падает, но финальный отчёт выглядит завершённым. Merge должен знать expected_count, received_count, список пропусков и политику полноты. Если обязательный узел не вернулся, система не имеет права назвать набор полным.
4. Каскад повторов
При временной ошибке 50 узлов одновременно делают три retry и усиливают перегрузку. Нужны exponential backoff, jitter, общий circuit breaker и ограничение числа одновременных попыток.
5. Неконтролируемый цикл
Verifier возвращает работу на исправление, но критерий успеха недостижим или расплывчат. Обязательны max_iterations, deadline, лимит стоимости и состояние NEEDS_HUMAN.
6. Размывание состояния
Разные узлы используют разные версии исходных данных. Нужны immutable snapshot, версия schema, timestamp и lineage: какой вход породил конкретный выход.
7. Ошибка на стыке
Каждый узел локально проходит проверку, но итоговая система не работает. Контракты дополняют интеграционными и end-to-end тестами. Качество частей не гарантирует качество композиции.
8. Prompt injection через источники
Исследователь читает веб-страницу, содержащую инструкции для агента. Внешний контент надо считать данными, а не командами; инструменты, сеть и секреты ограничивать по принципу наименьших привилегий. Anthropic отдельно подчёркивает важность sandboxing и изоляции файловой системы и сети.
9. Автоматизация неверной цели
Граф идеально оптимизирует число обработанных тикетов, но ухудшает удовлетворённость клиентов. Метрики должны включать качество исхода, стоимость ошибки и негативные guardrail-метрики.
Когда граф не нужен
Graph Engineering создаёт накладные расходы: orchestration code, схемы, хранилище состояния, трассировку, retries, разрешение конфликтов и дополнительный расход токенов.
Оставьте один агент или простой цикл, если:
- задача мала и изолирована;
- все шаги действительно последовательны;
- вы ещё исследуете проблему и часто меняете направление;
- нет объективного критерия качества;
- стоимость координации выше времени ручной работы;
- каждый этап требует человеческого решения;
- данных недостаточно для стабильного контракта.
Используйте граф, если:
- есть минимум две независимые ветви;
- один контекст не вмещает задачу;
- нужны разные роли или права доступа;
- результат можно автоматически проверить;
- пропуск отдельной ветви должен быть обнаружен;
- важны audit trail и воспроизводимость;
- выигрыш времени или качества покрывает дополнительную стоимость.
| Ситуация | Рекомендуемая форма |
|---|---|
| исправить один небольшой баг | один агент + тест |
| улучшать текст до редакционной оценки | evaluator-optimizer loop |
| проверить 100 независимых файлов | fan-out → verify → merge |
| исследовать неизвестную проблему | orchestrator-workers с лимитом |
| провести платёж | детерминированный workflow + human gate |
| подготовить отчёт из пяти источников | diamond graph |
Наблюдаемость и управление стоимостью
Без трассировки граф превращается в дорогой чёрный ящик. Для каждого запуска сохраняйте:
run_id, цель и версию графа;- входной snapshot и владельца запуска;
- старт, конец и latency каждого узла;
- выбранную модель и число токенов;
- стоимость узла и всего run;
- число retry и причина отказа;
- версию prompt и output schema;
- переходы по рёбрам;
- expected/received counts на merge;
- доказательства verifier;
- человеческие решения;
- финальный статус: success, partial, failed, cancelled.
Полезны четыре бюджета:
- Concurrency cap — максимум одновременных узлов.
- Token/cost cap — потолок токенов или денег на run.
- Time cap — общий deadline и timeout узла.
- Iteration cap — максимум возвратов в цикл.
Параллелизм уменьшает календарное время, но обычно не уменьшает объём работы. Иногда расход даже растёт из-за повторов и проверки. Экономически граф оправдан, когда стоимость сокращённого времени, большей полноты или меньшего риска выше дополнительного inference cost и стоимости поддержки оркестрации.
Маршрутизация моделей помогает: дешёвая модель — для классификации и извлечения по строгой схеме, сильная — для неоднозначного суждения и синтеза, обычный код — для детерминированных операций. Подробнее о контроле inference cost мы писали в материале как контролировать расходы на LLM.
Кейс Bun: 64 агента и цена экстремального параллелизма
Самый заметный пример июля 2026 года — перенос JavaScript runtime Bun с Zig на Rust. В официальном разборе Bun описан проект, где около 535 496 строк Zig переносились при помощи примерно 50 динамических workflows, до 64 экземпляров Claude работали параллельно, а работа заняла 11 дней. До merge было использовано 5,9 млрд uncached input tokens, 690 млн output tokens и 72 млрд cached input token reads; эквивалент по API-прайсу оценён примерно в $165 000.
Этот кейс нельзя пересказывать как «64 агента сами переписали миллион строк». Важные условия:
- исходная система уже имела поведение, которое надо было сохранить;
- существовал большой набор тестов и более миллиона assertions;
- компилятор Rust и тесты давали внешний сигнал;
- работа была подготовлена инструкциями и соглашениями портирования;
- человек проектировал workflow, наблюдал за ним и разбирал сбои;
- механический перенос отличается от создания продукта с неопределёнными требованиями;
- качество и объём AI-кода вызвали публичную профессиональную критику.
Перенос показателен не числом агентов, а ролью harness. Когда задача разбита на файлы, компилятор быстро возвращает ошибки, тесты фиксируют поведение, а workers изолированы, широкий граф может резко сократить wall-clock time. Без этих якорей 64 агента масштабируют не производительность, а неопределённость.
Дополнительные технические детали, включая статистику токенов, тестовый контур и ограничения переноса, приведены в первичном разборе команды Bun по ссылке выше.
Как построить первый граф за 7 шагов
Шаг 1. Выберите один измеримый процесс
Не начинайте с «автоматизировать маркетинг». Возьмите конечный артефакт: сравнительный отчёт по пяти конкурентам, аудит двадцати route-файлов или черновик статьи с проверенными источниками.
Зафиксируйте baseline: сколько занимает процесс, сколько стоит, где возникают ошибки. Без baseline нельзя доказать, что граф полезен.
Шаг 2. Нарисуйте текущую цепочку
Запишите каждый шаг глаголом и существительным: «собрать запросы», «открыть документы», «проверить даты», «сгруппировать выводы». Не назначайте агентов заранее.
Шаг 3. Проведите аудит рёбер
Для каждой пары спросите, нужен ли результат, состояние, ресурс или лимит предыдущего шага. Независимые узлы поместите в один параллельный слой. Отдельно отметьте скрытые зависимости.
Шаг 4. Выделите критический путь
Оцените latency узлов и найдите самую длинную зависимую цепочку. Не распараллеливайте всё подряд: сначала устраните задержки на критическом пути.
Шаг 5. Напишите контракты
Определите input/output schema, инструменты, права, timeout, retry, критерий успеха и evidence. Один узел — одна работа. Если описание содержит пять независимых глаголов, разделите его.
Шаг 6. Добавьте verifier и human gate
Verifier получает артефакт и проверяемые критерии в свежем рабочем контексте. Рискованные side effects остаются за человеческим подтверждением.
Шаг 7. Запустите ограниченный пилот
Поставьте cap: например, 5 workers, 20 объектов, 2 retry, 15 минут и фиксированный бюджет. Сравните latency, cost, completeness и error rate с baseline. Расширяйте граф только после выигрыша на малом масштабе.
Правило пилота AI рассвет: сначала один процесс, один владелец, один внешний критерий успеха и один безопасный путь остановки.
Три готовые спецификации
Ниже не магические промпты, а компактные технические задания. Их нужно адаптировать к инструменту и правам доступа.
1. Исследовательский граф
| Поле | Спецификация |
|---|---|
| Goal | подготовить decision-grade исследование по вопросу |
| Fan-out | 5 непересекающихся углов, один researcher на угол |
| Contract | каждый тезис: claim, source_url, source_type, date, confidence |
| Reduce | удалить дубли URL и сгруппировать одинаковые claims обычным кодом |
| Verify | независимо открыть источник и попытаться опровергнуть claim |
| Fan-in | объединить только подтверждённые тезисы, сохранив ссылки |
| Gate | человек утверждает выводы перед внешней отправкой |
| Caps | 5 workers, 2 retry, 30 минут, фиксированный budget |
2. SEO-граф
| Поле | Спецификация |
|---|---|
| Goal | подготовить publish-ready статью по теме |
| Fan-out | keyword intent, SERP, competitors, content gaps |
| Merge | brief с единой структурой и source plan |
| Draft | один writer создаёт связный черновик |
| Verify | ссылки, даты, числовые claims, title promise, schema |
| Audit | CORE-EEAT gate: SHIP/FIX/BLOCK |
| Gate | публикация разрешена только после SHIP и человека |
| Evidence | публичная страница отвечает 200 и содержит H1 |
Именно так устроен текущий seo-pipeline-v2: он связывает исследование, написание, GEO-оптимизацию, метаданные, schema и аудит, но не разрешает публикацию при FIX или BLOCK.
3. Аудит репозитория
| Поле | Спецификация |
|---|---|
| Goal | найти route-файлы без проверки авторизации |
| Discovery | детерминированно перечислить файлы |
| Fan-out | один read-only reviewer на файл в изолированном контексте |
| Output | file, route, auth_check, evidence_lines, severity |
| Verify | отдельный reviewer подтверждает находку |
| Merge | сверить expected и received file count |
| Side effects | никаких правок |
| Gate | человек выбирает исправления |
Такой граф безопаснее запроса «найди и исправь всю безопасность»: сначала он собирает проверяемый отчёт, а изменение кода становится отдельным контролируемым запуском.
Как выбрать инструмент
Graph Engineering — архитектурный подход, а не конкретный продукт. Начать можно с обычного скрипта и очереди задач.
| Уровень | Подходит | Ограничение |
|---|---|---|
| Один скрипт + API LLM | пилот, фиксированный DAG | состояние и retries придётся реализовать |
| Claude Code subagents / agent teams | исследование и работа с репозиторием | нужны sandbox, worktree и контроль прав |
| Microsoft Agent Framework / AutoGen GraphFlow | типизированные многоагентные workflow | дополнительная инфраструктура и learning curve |
| LangGraph и аналогичные runtime | stateful graphs, ветвления, checkpoints | риск преждевременной сложности |
| Temporal, Airflow, Dagster + LLM nodes | критичные бизнес-процессы и mature ops | LLM-специфику надо добавить самостоятельно |
При выборе смотрите не на красивый canvas, а на возможности:
- durable state и resume после сбоя;
- type/schema validation;
- retries, timeouts и cancellation;
- human-in-the-loop;
- concurrency и rate limits;
- tracing и cost attribution;
- secrets и role-based access;
- sandbox/workspace isolation;
- версионирование графа и промптов;
- экспорт данных без vendor lock-in.
Если компания только знакомится с агентами, полезно сначала понять, где ИИ-агенты дают бизнес-эффект, а где остаются хайпом. Оркестратор не исправит плохо выбранный процесс.
FAQ
Что такое Graph Engineering простыми словами?
Это проектирование работы ИИ как карты зависимостей. Узлы выполняют отдельные задачи, рёбра передают результаты, независимые ветви идут параллельно, проверки и люди контролируют переходы.
Чем граф ИИ-агентов отличается от обычной цепочки?
Цепочка — частный случай графа, где каждый шаг ждёт предыдущий. Полноценный граф удаляет ложные зависимости, допускает ветвления, параллельные узлы, циклы исправления и несколько точек объединения.
Graph Engineering заменяет loop engineering?
Нет. Loop engineering управляет повторением одной работы до критерия готовности. Graph Engineering соединяет несколько работ и циклов. В производственной системе они обычно используются вместе.
Обязательно ли использовать несколько моделей?
Нет. Разные узлы могут вызывать одну модель с разными ролями и контекстами. Разделение моделей полезно для стоимости и снижения коррелированных ошибок, но структура графа определяется зависимостями, а не брендами LLM.
Почему проверяющему нужен отдельный контекст?
Чтобы он не наследовал убеждения исполнителя и заново проверял артефакт по критериям. Ему всё равно нужны исходные данные и доказательства, но не история самооправдания worker-узла.
Всегда ли несколько проверяющих надёжнее одного?
Нет. Несколько LLM могут повторить одну ошибку. Надёжность появляется, когда проверка использует разные методы и внешние якоря: тест, первичный документ, транзакцию или решение эксперта.
Как понять, что задачу стоит распараллелить?
Найдите минимум два шага, которым не нужны результаты и изменяемые ресурсы друг друга. Затем проверьте, что стоимость координации ниже ожидаемого выигрыша времени или качества.
Сколько агентов запускать?
Начните с 3–5 workers и жёсткого бюджета. Оптимальное число ограничивают реальная ширина задачи, rate limits, способность verifier обработать поток и стоимость. 64 агента из кейса Bun — экстремальный, а не стартовый ориентир.
Как не переполнить контекст при объединении?
Используйте иерархический fan-in: нормализуйте результаты, объединяйте их пакетами, создавайте промежуточные summaries, а сырые доказательства храните отдельно с адресуемыми ссылками.
Можно ли дать графу право публиковать или менять production?
Технически можно, но для высокорисковых действий безопаснее обязательный human gate, минимальные права, staging, журналирование и обратимый deployment. Подготовка результата и его необратимый выпуск — разные узлы.
Какие метрики показывают, что граф окупается?
Сравнивайте с baseline: end-to-end latency, cost per successful run, completeness, долю ошибок, число ручных вмешательств и стоимость инцидентов. Ускорение без качества и контроля расходов не является успехом.
Итог
Graph Engineering — полезное имя для давно знакомой, но резко актуализировавшейся работы: проектировать не один «умный промпт», а систему зависимостей, контрактов, проверок и прав.
У графа три настоящих преимущества:
- независимая работа выполняется параллельно;
- контекст и ответственность разделены по узлам;
- отказ, стоимость и доказательство результата становятся наблюдаемыми.
И три ограничения:
- граф увеличивает координационные и token costs;
- внутренняя согласованность не гарантирует истину;
- масштабирование без изоляции и якорей масштабирует ошибки.
Начните не с флота агентов и не с нового фреймворка. Нарисуйте текущий процесс. Для каждого ребра спросите, что именно по нему передаётся. Удалите ложные зависимости. Выделите критический путь. Задайте контракт одному узлу, добавьте независимый verifier и внешний критерий успеха. Затем запустите маленький ограниченный pilot.
Если он измеримо быстрее, полнее или надёжнее прежнего процесса, у вас появился граф, который стоит расширять. Если нет — простой цикл остаётся лучшим инженерным решением.