Русский перевод

Инженерия графов: что это такое, когда применять и когда не стоит

1 — Откуда всё это вообще взялось

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

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

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

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

2 — Что такое граф на самом деле

Граф — это всего лишь наглядно нарисованный план работы вашего ИИ. Он отвечает на два вопроса: какие задачи должны быть выполнены и какая задача должна дождаться какой.

В нём всего две части. Если правильно их понять, большая часть путаницы исчезает.

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

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

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

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

▸ КОНТРАКТ УЗЛА
ЗАДАЧА: исследовать цены одного конкурента (одна задача и ничего больше)
ВХОД:   { competitor: "name", url: "https://..." }   ← передаётся явно, не предполагается
ВЫХОД:  { price: number, plan: string, source: url, date: "YYYY-MM-DD" }
СХЕМА:  проверяется принудительно. Свободный текст отклоняется, запуск повторяется
ЗАЧЕМ:  определённый выход позволяет следующему узлу прочитать результат
        без человека посередине. Именно это позволяет соединять узлы.

3 — Тест, который находит ложные рёбра

Посмотрите на AI-процесс, которым пользуетесь сегодня, и пройдите его шаг за шагом. На каждом шаге задавайте один вопрос: действительно ли этому шагу нужен результат предыдущего?

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

Возьмём простой пример: «проверить файл А на ошибки, затем проверить файл Б на ошибки». Это выглядит как последовательность, но проверка файла Б никогда не обращается к результату проверки файла А. Задачи идут одна за другой только потому, что вы ввели их именно в таком порядке. Запустите их параллельно — и всё завершится за время более медленной из двух проверок, а не за сумму их длительности.

Почти в любом нарисованном процессе обнаружатся два-три таких ложных ребра. Каждое из них — время, которое вы выбрасываете просто так.

4 — Ваша нынешняя схема уже является графом

Когда вы даёте агенту инструкцию «сделай А, потом Б, потом В, потом Г», технически вы уже построили граф. Просто самый унылый из возможных: одну прямую цепочку, где в каждый узел входит одна стрелка и из него выходит одна стрелка.

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

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

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

Узким местом никогда не была модель. Им была нарисованная вами линия.

5 — Единственный окупающийся паттерн: ромб

Вам не нужна сотня фигур. Понаблюдайте за любой серьёзной агентной системой — и будете постоянно видеть одну и ту же картину. Работа разделяется, несколько исполнителей параллельно исследуют свои направления, кто-то проверяет найденное, а затем всё снова сходится в один ответ.

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

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

Исследовательская функция внутри Claude работает в продакшене именно так. Ведущий намечает направления, исполнители параллельно собирают материал, находки проходят проверку, и только после этого вы получаете единый отчёт. Научившись видеть ромб, вы перестанете спрашивать: «Как заставить агента сделать больше шагов?» — и начнёте спрашивать: «Где разделение и где объединение?» Масштабируется именно второй вопрос.

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

// граф исследования рынка — ромб, который Claude пишет по слову "workflow"

const angles = [
  "цены по сравнению с 3 главными конкурентами",
  "на что жалуются покупатели в отзывах",
  "каких функций не хватает в этой категории",
  "куда движется рынок в ближайшие 12 месяцев",
];

// РАЗВЕТВЛЕНИЕ — по исследователю на направление, все работают одновременно
const raw = await parallel(
  angles.map(a => () => agent({
    task: `исследуй: ${a}. Для каждого утверждения нужны URL источника и дата.`,
    schema: Finding,        // проверяемый результат, а не свободный текст
    model: "cheap",         // рутинный узел → дешёвая модель
  }))
);

// ОТБОР — обычный код, без модели и токенов
const findings = dedupeBySource(raw.flat().filter(Boolean));

// ПРОВЕРКА — СВЕЖИЙ скептик для каждой находки пытается её опровергнуть
const survivors = await parallel(
  findings.map(f => () => agent({
    task: "попытайся опровергнуть это. Верни keep | drop и объяснение.",
    input: f,
    freshContext: true,     // никогда не используем чат исследователя повторно
    model: "strong",        // узел с суждением → сильная модель
  }))
).then(v => findings.filter((_, i) => v[i].verdict === "keep"));

// СИНТЕЗ — один агент пишет ответ только из того, что прошло проверку
return agent({ task: "единый отчёт с ранжированием по уверенности и источниками.",
               input: survivors, model: "strong" });

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

6 — Вся хитрость в проверяющем

Теперь о части, которую пропускают почти все, хотя именно она отделяет настоящий граф от дорогой игрушки.

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

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

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

Но есть одна деталь, которую почти никто не называет: проверяющему нужен чистый контекст.

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

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

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

▸ УЗЕЛ-ВЕРИФИКАТОР
ВХОД:     одна находка исполнителя (только находка, никогда не его чат)
КОНТЕКСТ: свежий и пустой. Верификатор не видел работу, которую оценивает
ПРОВЕРКИ: три скептика работают параллельно, каждый задаёт свой вопрос
  1. Это верно?      → действительно ли утверждение выдерживает проверку
  2. Это актуально?  → свежий ли источник, не устарел ли он
  3. Источник реален?→ ведёт ли ссылка к подтверждающему материалу
ПРОХОД:   сохранять находку, только если большинство скептиков её пропускает
ОТКАЗ:    удалить её до того, как она попадёт в итоговый ответ

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

7 — Где графы ломаются на самом деле

1. Коллапс контекста.
Разветвите работу на тысячу узлов, затем попытайтесь передать все тысячу результатов одному финальному шагу — и превысите окно контекста ещё до начала синтеза.

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

// послойное объединение — не вываливайте 1 000 сырых результатов в один шаг
const batches = chunk(results, 40);              // группы по 40
const summaries = await parallel(
  batches.map(b => () => agent({ task: "суммируй этот пакет", input: b }))
);
return agent({ task: "напиши ответ по сводкам", input: summaries });
// финальный шаг читает около 25 сводок, а не 1 000 сырых результатов

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

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

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

// изолируем исполнителей — никаких общих файлов и рабочего пространства
await parallel(files.map(f => () => agent({
  task: `выполни рефакторинг ${f}`,
  worktree: true,        // каждый агент работает в собственном git-worktree
})));
// они не могут перезаписывать работу друг друга, а результаты чисто объединяются
// правило: двум узлам, меняющим один файл, нужно ребро, а не параллельность

3. Тихий отказ узла.

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

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

// защита на объединении — ловим узел, который тихо умер
const results = (await parallel(jobs)).filter(Boolean);   // выпавшие узлы = null
if (results.length < jobs.length) {
  flag(`ВНИМАНИЕ: ${jobs.length - results.length} из ${jobs.length} узлов ничего не вернули`);
}
// никогда не синтезируйте частичный набор, называя отчёт полным

8 — А вам вообще нужен граф?

По традиции моих статей давайте честно разберёмся, кому всё это может пригодиться.

Граф даёт ширину. Он не улучшает качество суждения.

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

Не используйте граф, если:

• Задача маленькая или изолированная. Добавить одну функцию, исправить один баг. Координация создаст только накладные расходы, а один агент будет быстрее и дешевле.
• Вы хотите утверждать каждый шаг. Весь смысл графа в широкой автономной работе без вашего участия, поэтому короткий поводок ему мешает.
• Вы ещё не знаете, что именно ищете. Для исследовательской работы нужен один агент, которого можно направлять, а не флот, запертый внутри заранее заданного плана.
• Шаги действительно зависят друг от друга. Навязывание графа по-настоящему последовательной работе лишь повысит стоимость без ускорения.
• Проверка — тест ложного ребра. Если вы не можете найти две задачи, между которыми нет ребра, строить граф не из чего. Это цикл — и в цикле нет ничего плохого.

9 — Часть, которую никто не хочет слышать: якоря

Здесь есть более глубокая ловушка — и в ней заключается настоящий урок всего этого перехода.

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

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

Всё согласуется. Ничего не проверено.

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

Одна топология не покупает вам истину. Графу нужны якоря — узлы, с которыми невозможно спорить.

Тесты, которые действительно запускались и прошли, а не «должны пройти». Выручка, которая поступила на банковский счёт. Клиенты, которые действительно остались.

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

Граф честен лишь настолько, насколько честны неподвижные вещи внутри него.

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

10 — Соберите собственный граф в Claude Code

Хватит теории. Если вы решили, что граф вам подходит, или просто хотите попробовать, давайте его построим. Настоящий граф собирается за пару минут, потому что в Claude Code появился прямой инструмент для этого — динамические workflow.

Всё сводится к одному слову: workflow.

Добавьте его в промпт — и Claude перестанет идти по одной линейной последовательности шагов. Вместо этого он напишет короткий оркестрационный скрипт, а затем запустит скоординированный флот субагентов.

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

Откройте знакомый реальный репозиторий и вставьте следующее:

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: проверить каждый файл маршрутов в src/routes/ на отсутствие проверки авторизации

РАЗВЕТВЛЕНИЕ: по одному агенту на файл, все работают параллельно
ПРОВЕРКА:      независимый проверяющий для каждой находки, в свежем контексте
ЛИМИТ:         20 файлов в первом запуске
ПРИ ОШИБКЕ:    отметить любой файл, который не вернул результат; ничего не пропускать молча
ОТЧЁТ:         один объединённый список маршрутов без авторизации

(начните промпт со слова "workflow", чтобы Claude построил граф)

Запустите — и произойдёт следующее.

Сначала Claude сообщит, что собирает workflow вместо обычного ответа в чате, и покажет план до начала работы. Вы прочитаете его и утвердите.

Затем флот начнёт работу. По одному агенту на файл, все одновременно, а ваша основная сессия всё это время останется свободной.

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

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

Обратите внимание на ограничение «20 файлов» в промпте. Оно удерживает стоимость первого запуска под контролем и намекает на то, о чём умалчивает почти каждая демонстрация: на счёт.

11 — Готовые графы, которые можно вставить прямо сейчас

Каждый из них — тот же ромб, направленный на другую задачу. Откройте Claude Code в реальной папке, замените текст в квадратных скобках своим и вставьте промпт. Слово workflow сообщает Claude, что нужно построить скоординированный флот, а не линейную последовательность шагов. Оставляйте за собой последнее «да» перед тем, как что-либо будет выпущено наружу.

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

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: исследование уровня принятия решения по вопросу [ваш вопрос]

РАЗВЕТВЛЕНИЕ: разделить на 5 разных направлений, по исследователю на каждое, параллельно
ПРАВИЛО:      для каждой находки нужны ссылка на источник и дата
ПРОВЕРКА:     скептик атакует каждую находку и пытается опровергнуть; провалившиеся удалить
ОБЪЕДИНЕНИЕ:  собрать выжившие находки в единый отчёт с ранжированием по уверенности
СОХРАНИТЬ:    research-report.md, затем показать главные выводы
ЧЕЛОВЕК:      после этого ничего не менять без моего разрешения

(начните промпт со слова "workflow", чтобы Claude построил граф)

Машина SEO-контента. За один запуск пишет готовый к ранжированию черновик и никогда не публикует его без вас.

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: один готовый к ранжированию черновик на тему [тема]

ПАРАЛЛЕЛЬНЫЕ ЗАДАЧИ (запустить одновременно):
  1. что рассматривают страницы, которые сейчас занимают верхние позиции
  2. какие реальные вопросы люди задают по этой теме
  3. что упускают страницы из топа
ОБЪЕДИНЕНИЕ: свести три результата в структуру, затем написать полный черновик
ПРОВЕРКА:     фактчекер отмечает каждое утверждение без источника
СОХРАНИТЬ:    в drafts/, список отмеченных утверждений поместить сверху
ЧЕЛОВЕК:      ничего не публиковать

(начните промпт со слова "workflow", чтобы Claude построил граф)

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

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: полный комплект запуска для [продукт], аудитория — [аудитория]

ПАРАЛЛЕЛЬНЫЕ ЗАДАЧИ (исследование, запустить одновременно):
  1. описать покупателя и точные слова, которыми он пользуется
  2. определить, где эти покупатели проводят время онлайн
  3. собрать способы, которыми к ним обращаются конкуренты
ОБЪЕДИНЕНИЕ: одностраничный документ с позиционированием
ЧЕЛОВЕК:      остановиться и показать документ до начала написания материалов
ПАРАЛЛЕЛЬНЫЕ ЗАДАЧИ (написание на основе документа):
  1. текст лендинга
  2. публикации на неделю запуска
  3. набор сообщений для аутрича
ПРОВЕРКА:     сверить каждый материал с позиционированием, отметить отклонения
СОХРАНИТЬ:    в launch-kit/, после этого ничего не менять без моего разрешения

(начните промпт со слова "workflow", чтобы Claude построил граф)

Массовый рефакторинг всего репозитория. Охват, который не поместится ни в один контекст.

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: найти каждую функцию длиннее 100 строк и предложить для неё рефакторинг

РАЗВЕТВЛЕНИЕ: по одному агенту на файл, параллельно
ПРОВЕРКА:      независимый проверяющий для каждого предложения, свежий контекст
ДЕДУПЛИКАЦИЯ:  сравнивать предложения со всем, что уже найдено
ЛИМИТ:         50 файлов в первом запуске
ОТЧЁТ:         указать, сколько файлов вернулось, чтобы ничто не отказало молча

(начните промпт со слова "workflow", чтобы Claude построил граф)

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

▸ СПЕЦИФИКАЦИЯ ГРАФА
ЦЕЛЬ: найти в репозитории [уязвимости / сломанную обработку ошибок / мёртвый код]

РАЗВЕТВЛЕНИЕ: запустить поисковых агентов параллельно
ДЕДУПЛИКАЦИЯ:  сравнивать каждую новую находку со всеми уже обнаруженными
ПРОВЕРКА:      независимый проверяющий для выживших находок
ЦИКЛ:          продолжать, пока два раунда подряд не найдут ничего нового
ЛИМИТ:         жёсткое ограничение общего числа агентов, чтобы процесс не убежал
ОТЧЁТ:         итоговый список с ранжированием по серьёзности

(начните промпт со слова "workflow", чтобы Claude построил граф)

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

12 — Стоимость и контроль

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

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

Процесс включал около 50 workflow, в каждом одновременно работало до 64 агентов.

Но он также стоил примерно 165 000 долларов вычислительных расходов, требовал человека, который проектировал систему и наблюдал за ней, и вызвал серьёзную критику: возможно ли вообще безопасно проверить такой объём кода, написанного ИИ.

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

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

13 — Что всё это значит лично для вас

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

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

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

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

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