Большинство людей всё ещё использует Claude Code как очень дорогого стажёра.
Они дают ему одну задачу, ждут одного ответа, а затем вручную решают, что делать дальше.
Но команды, которые получают максимальную выгоду от ИИ, строят нечто большее похожее на небольшую распределённую систему.
Один агент определяет область проблемы.
Пять более дешёвых агентов ищут параллельно.
Детерминированный скрипт удаляет дубликаты.
Три скептически настроенных агента пытаются опровергнуть находки.
Одна модель высшего уровня выносит окончательное суждение.
Это и есть графовая инженерия.
Прежде чем продолжить:
Сохраните это руководство в закладки, чтобы возвращаться к паттернам графов, когда начнёте строить собственные рабочие процессы Claude.
Подписывайтесь
@Gyome1_ -
Я разбираю Claude Code, AI-агентов и системы, которые превращают одну модель в надёжный инженерный процесс.
Я потратил недели, изучая реальные архитектуры агентов, диаграммы рабочих процессов и производственные паттерны, чтобы перестроить графовую инженерию в одно практическое руководство.
Вместо того чтобы писать более длинный промпт, вы проектируете путь, по которому информация проходит через систему:
линейно → разветвление → свёртка → проверка → синтез
Каждый агент становится узлом с ограниченной задачей. Каждое ребро переносит структурированные данные. Маршрутизаторы решают, какая ветвь выполняется. Верификаторы отвергают слабые результаты. Циклы продолжаются, пока граф перестаёт находить что-то новое.
Важный сдвиг в том, что Claude Code больше не должен вести себя как один интеллект, работающий по огромному списку задач.
Он может генерировать код оркестрации, порождать флот специализированных под-агентов, направлять их выходные данные через разные модели и собирать финальный результат только после того, как доказательства прошли проверку.
Базовые паттерны не новы. Инженеры-программисты десятилетиями использовали DAG, конвейеры, барьеры, MapReduce и распределённые рабочие процессы.
Что изменилось — так это то, что теперь находится внутри каждого узла.
Узел может искать в репозитории, проверять миграцию, оспаривать архитектурное решение, анализировать сбои тестов или синтезировать пятьдесят независимых находок в один цитируемый отчёт.
Это руководство разбирает всю систему от простейшего линейного агента до бриллиантовых графов, узлов-маршрутизаторов, групп состязательных верификаторов, сходящихся циклов, многоуровневых моделей и динамических рабочих процессов, генерируемых прямо внутри Claude Code.
К концу вы сможете взглянуть на большую задачу и перестать спрашивать:
«Какой промпт мне написать?»
1. ГРАФОВАЯ ИНЖЕНЕРИЯ НАЧИНАЕТСЯ СО СЧЁТА
Графовую инженерию часто представляют как способ запускать больше агентов.
Но такая формулировка упускает самое дорогое.
Вы можете запустить двадцать агентов Claude против одного репозитория и получить двадцать пересекающихся отчётов, повторяющийся контекст, противоречивые выводы и гораздо больший счёт за API.
Полезный граф контролирует, где происходят вычисления, какая модель обрабатывает каждое решение и как неопределённые находки движутся по рабочему процессу.
Представьте, что вы просите Claude Code подготовить производственную миграцию:
Проверь репозиторий, найди все зависимости, предложи миграцию, выяви риски, проверь план и напиши итоговую сводку.
Внутри одного промпта это становится длинным непрозрачным процессом. Claude ищет по кодовой базе, сохраняет находки в контексте, проектирует миграцию, проверяет собственный план и создаёт финальный отчёт.
Когда отчёт оказывается неудачным, источник ошибки трудно найти. Claude мог пропустить файл, неправильно понять зависимость, потерять более раннюю деталь или принять слабое предположение во время проверки.
Каждый этап также может выполняться на одной и той же дорогой модели, даже если части задачи включают простое извлечение или сортировку.
Графовая инженерия вскрывает этот рабочий процесс и даёт каждому решению видимое место.
Ветви проверки выполняются одновременно, потому что используют одну и ту же ограниченную задачу и не зависят от выходных данных друг друга.
Их результаты встречаются на этапе свёртки, где дубликаты исчезают, а доказательства сжимаются в меньший набор данных.
Затем маршрутизатор считывает степень серьёзности. Обычные изменения проходят через лёгкую проверку. Высокорисковые находки получают более глубокий анализ от нескольких независимых рецензентов, прежде чем попасть к финальной модели.
В результате получается рабочий процесс, где задержка, стоимость модели, размер контекста и глубина проверки контролируются через структуру графа.
Узел должен принимать одно решение
Полезный узел имеет ограниченную ответственность.
Найди все вызовы устаревшего API. Классифицируй каждый риск миграции как низкий, средний или высокий. Проверь план отката на случаи сбоя.
Каждому узлу нужны чёткий вход, определённый выход и ограниченная область принятия решений.
Узел, который ищет в репозитории, оценивает бизнес-влияние, проектирует исправление и пишет рекомендацию, всё ещё содержит несколько скрытых этапов. Отладка остаётся сложной, потому что промежуточные рассуждения погребены внутри одного вызова модели.
Меньшие границы показывают, где в систему поступили доказательства и где их значение изменилось.
Ребро должно переносить доказательства
Ребро представляет данные, необходимые следующему узлу.
Сканер может возвращать предсказуемый объект:
1{2 "file": "src/auth/session.ts",3 "lines": [84, 119],4 "dependency": "legacySessionClient",5 "confidence": 0.94,6 "evidence": "Both call sites depend on the deprecated refresh method."7}
Классификатор рисков теперь получает те же поля для каждой находки. Он может отклонить неполные результаты, сгруппировать связанные файлы и направить неопределённые доказательства на повторную проверку.
Схемы уменьшают дрейф интерпретации между узлами. Свободные абзацы вынуждают каждый последующий агент реконструировать смысл предыдущего. Через несколько этапов небольшие неоднозначности могут изменить окончательный вывод.
Структурированный вывод сохраняет стабильность доказательств при их движении по графу.
Некоторые узлы — это обычный код
Предположим, восемь поисковых агентов вернули восемьдесят находок.
Рабочий процесс должен объединить массивы, отбросить пустые ответы, удалить дубликаты и отсортировать оставшиеся элементы.
У этих операций есть детерминированные ответы:
1const uniqueFindings = [2 ...new Map(3 results4 .flatMap(batch => batch ?? [])5 .map(item => [`${item.file}:${item.lines.join("-")}`, item])6 ).values()7];
Преобразование на JavaScript обрабатывает это мгновенно и выдает одинаковый результат при каждом запуске. Отправка той же задачи другой модели добавляет затраты токенов и создаёт ещё одно место, где доказательства могут исчезнуть.
Модельные узлы должны быть вокруг поиска, классификации, сравнения, рецензирования и синтеза. Код может обрабатывать валидацию, дедупликацию, сортировку, явные правила маршрутизации и другие предсказуемые преобразования.
Это разделение становится основой графа.
Каждый вызов модели должен соответствовать решению, которое действительно требует суждения.
2. БРИЛЛИАНТ: КАК РЕАЛЬНЫЕ ГРАФЫ АГЕНТОВ ПЕРЕМЕЩАЮТ РАБОТУ
Большинство серьёзных графов агентов в итоге принимают одну и ту же форму.
Задача начинается с одной общей области, разделяется на несколько независимых исполнителей, ждёт их выходных данных, сжимает доказательства и передаёт результат в финальное решение.
Эта форма — бриллиант.
Левая сторона — это разветвление.
Средняя точка, где встречаются все ветви, — это барьер.
Правая сторона — это свёртка.
Этот паттерн появляется повсюду, как только задача становится слишком большой для одного контекстного окна.
Аудит репозитория можно разделить по подсистемам. Рыночный отчёт — по источникам. Исследовательская задача — по гипотезам. Проверка миграции — по использованию API, изменениям в базе данных, рискам развёртывания и покрытию тестами.
Каждый исполнитель получает ту же область с более узким заданием.
Затем граф ждёт, пока вернётся достаточно полезных доказательств.
Разветвление должно создавать независимую работу
Ветвь принадлежит разветвлению, когда она может начать с общего входа и выдать полезный результат, не читая выходные данные другой ветви.
Для аудита безопасности разделение может выглядеть так:
Claude Code может запускать эти вызовы конкурентно с помощью примитива барьера, такого как parallel()
1const findings = await parallel(2 checks.map(check => async () => {3 return agent({4 task: check.task,5 context: auditScope,6 schema: FINDING_SCHEMA7 });8 })9);
Оркестрация остаётся на обычном JavaScript. Каждая ветвь получает ограниченную задачу и возвращает проверенный объект.
Результат приходит как коллекция выходных данных, которые можно отфильтровать, проверить и передать на следующий этап.
Большое разветвление всё ещё должно иметь причину для каждой ветви.
Разделение одного расплывчатого задания на двенадцать почти идентичных агентов часто приводит к повторяющимся находкам с немного разными формулировками. Полезный параллелизм исходит из разных источников, перспектив, областей кода или гипотез.
Барьер создаёт точку принятия решения
Барьер приостанавливает следующий этап, пока не завершатся требуемые ветви.
Эта пауза важна, потому что некоторые решения зависят от полного набора.
Узел ранжирования не может определить самую важную уязвимость, пока половина репозитория всё ещё проверяется. Модель синтеза не может написать полный план миграции, пока проверка развёртывания ещё выполняется.
На барьере граф имеет возможность проверить состояние выполнения:
1const completed = findings.filter(Boolean);23if (completed.length < MIN_REQUIRED_RESULTS) {4 throw new Error("Insufficient audit coverage");5}
Здесь частичные сбои становятся видимыми.
Исполнитель может выйти по таймауту, вернуть некорректные данные или не найти ничего. Фильтрация нулевых значений позволяет продолжить выполнение, но в производственных рабочих процессах обычно нужна более чёткая политика:
- сколько успешных ветвей требуется;
- какие ветви обязательны;
- нужно ли повторить сбойный узел;
- следует ли пометить финальный результат как неполный.
Барьер, таким образом, является частью модели надёжности, а не просто механизмом синхронизации.
Свёртка перед синтезом
После разветвления граф может содержать десятки пересекающихся находок.
Отправка всех их напрямую в модель высшего уровня создаёт большой контекст, повторяет одни и те же доказательства и затрудняет различение важных деталей.
Этап свёртки подготавливает доказательства.
Часть свёртки может выполняться в коде:
1const unique = deduplicateByKey(2 completed.flatMap(result => result.findings),3 finding => `${finding.file}:${finding.line}:${finding.type}`4);
Следующий уровень может потребовать суждения:
1const curated = await agent({2 task: `3 Сгруппируй связанные находки.4 Сохрани все ссылки на файлы и строки.5 Отранжируй каждую группу по операционному влиянию.6 Верни самые сильные доказательства для каждого вывода.7 `,8 input: unique,9 schema: CURATED_FINDINGS_SCHEMA10});
Свёртка контролирует, что попадает в финальную модель.
Хороший свёртчик удаляет повторения, сохраняя доказательства. Агрессивный свёртчик может сжать несколько различных рисков в одно расплывчатое резюме и стереть детали, необходимые для проверки.
Самый безопасный паттерн сохраняет связь между каждым сжатым утверждением и его исходными элементами.
1{2 "risk": "Session refresh may fail after migration",3 "severity": "high",4 "sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],5 "evidence": [6 "Three services call the deprecated refresh method",7 "No fallback path exists",8 "Integration coverage is missing"9 ]10}
Теперь узел синтеза получает меньший набор данных, не теряя прослеживаемости.
3. НАДЁЖНОСТЬ — ЧАСТЬ ГРАФА
Граф может завершиться быстро и всё равно выдать плохой ответ.
Как только несколько агентов начинают искать, классифицировать и проверять одну и ту же задачу, главной проблемой становится контроль.
Системе нужны правила для решения, какие находки заслуживают более глубокой работы, какие выходные данные следует отклонить и когда рабочий процесс достаточно поискал.
Маршрутизация по риску
Узел-маршрутизатор читает структурированный вывод и выбирает следующую ветвь.
Классификация может поступать от модели, в то время как сама ветвь остаётся явной в коде.
1const route =2 finding.severity === "high"3 ? runFullAudit(finding)4 : runQuickReview(finding);
Это позволяет сосредоточить дорогую проверку на находках с реальным влиянием.
Полезный маршрутизатор опирается на поля, которые граф может проверить: серьёзность, уверенность, затронутые системы, финансовые риски или наличие отсутствующих доказательств.
Добавьте независимую проверку
Один агент, проверяющий собственный вывод, проносит те же предположения через оба этапа.
Более сильный граф отправляет важные находки нескольким рецензентам с разными заданиями.
Рецензенты не должны получать инструкции улучшить исходный ответ. Их задача — искать причины, по которым он может быть неполным или неверным.
Граф может требовать согласия перед тем, как находка двинется дальше:
1const accepted = votes.filter(vote => vote.approve).length >= 2;
Изолируйте агентов, которые меняют код
Параллельные агенты, пишущие код, могут мешать друг другу, когда редактируют одну и ту же рабочую директорию.
Один агент может перезаписать файл, пока другой его читает. Тесты могут выполняться на смеси несвязанных изменений.
Git worktrees дают каждой ветви свою собственную копию репозитория.
1main repository2 │3 ├→ worktree/auth-fix4 ├→ worktree/db-migration5 └→ worktree/test-repair
Каждый агент может изменять файлы и запускать тесты в своём окружении. Позже узел сравнивает патчи, проверяет конфликты и выбирает, что нужно смержить.
Это превращает изоляцию в часть графа, а не в ручной шаг очистки.
Позвольте обнаружению сходиться
Некоторые задачи невозможно выполнить за один проход.
Аудит репозитория может обнаружить зависимость, ведущую к другому пакету. Этот пакет может раскрыть ещё один участок вызова. Графу нужен контролируемый способ продолжить поиск, не повторяя всё, что уже было найдено.
1const seen = new Set();2let dryRounds = 0;34while (dryRounds < 2) {5 const findings = await discoverNext([...seen]);6 const fresh = findings.filter(item => !seen.has(item.id));78 fresh.forEach(item => seen.add(item.id));9 dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;10}
Важная деталь — дедупликация относительно каждого ранее увиденного элемента.
Дедупликация только относительно подтверждённых находок позволяет отклонённым или неопределённым элементам вернуться на следующем проходе и снова потреблять ту же работу.
Цикл останавливается после нескольких «сухих» раундов, фиксированного бюджета или максимального количества итераций. Производственные графы обычно нуждаются во всех трёх.
Сопоставьте модель с узлом
Каждому узлу не нужна самая сильная доступная модель.
Извлечение, базовая классификация и узкие поиски часто могут выполняться на более быстром уровне. Архитектурный обзор, состязательная проверка и финальный синтез могут оправдать более сильную модель.
Многоуровневость моделей становится ещё одним свойством графа.
Бюджет определяется количеством запущенных узлов, частотой повторения циклов, объёмом контекста, пересекающего каждое ребро, и тем, какая модель обрабатывает каждый этап.
Граф с двадцатью дешёвыми поисковыми вызовами всё равно может стоить дороже одного сильного вызова. Архитектура нуждается в бюджете токенов до того, как ей понадобится ещё одна ветвь.
Знайте, когда остановиться
Маленькие задачи редко нуждаются в маршрутизаторах, группах голосования, worktree и циклах сходимости.
Накладные расходы графа включают код оркестрации, схемы, повторные попытки, логирование, промежуточное хранение и большее количество состояний сбоя для отладки.
Линейный рабочий процесс обычно достаточен, когда одна модель может удержать релевантный контекст, задача имеет мало независимых ветвей и стоимость неверного ответа низка.
Графовая инженерия становится полезной, когда задача приобретает параллельную работу, дорогие решения, большие наборы доказательств или значительные требования к проверке.
Полный рабочий процесс в итоге может выглядеть так:
Ценность заключается в том, чтобы сделать движение работы видимым.
Каждый узел имеет ограниченную ответственность. Каждое ребро переносит структурированные доказательства. Каждая ветвь имеет причину для существования. Каждый цикл имеет условие остановки.
В этот момент Claude Code больше не работает по одной длинной инструкции.
Он выполняет спроектированную систему.
