Повний посібник із графового інжинірингу для Claude Code

Більшість людей досі використовують Claude Code як дуже дорогого стажера.

Вони дають йому одне завдання, чекають на одну відповідь, а потім вручну вирішують, що робити далі.

Але команди, які отримують максимальну віддачу від AI, будують щось ближче до невеликої розподіленої системи.

Один агент окреслює проблему.

П'ять дешевших агентів шукають паралельно.

Детермінований скрипт видаляє дублікати.

Три скептичні агенти намагаються спростувати знахідки.

Одна топова модель приймає остаточне рішення.

Це і є графічна інженерія (Graph Engineering).

Перш ніж ви продовжите читати:

Збережіть цей посібник у закладках, щоб повернутися до шаблонів графів, коли почнете будувати власні робочі процеси з Claude Code.

Та підпишіться на

@Gyome1_ -

Я розбираю Claude Code, AI-агентів та системи, які перетворюють одну модель на надійний інженерний робочий процес.

Я провів тижні, аналізуючи реальні архітектури агентів, діаграми робочих процесів і виробничі шаблони, щоб перебудувати графічну інженерію в один практичний посібник.

Замість того, щоб писати довший промпт, ви проєктуєте шлях, яким інформація проходить через систему:

лінійний → розгалуження → зведення → перевірка → синтез

Кожен агент стає вузлом з обмеженим завданням. Кожне ребро несе структуровані дані. Маршрутизатори вирішують, яка гілка виконується. Верифікатори відхиляють слабкі результати. Цикли тривають, доки граф не перестає знаходити щось нове.

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

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

Базові шаблони не є новими. Інженери-програмісти використовують DAG, конвеєри, бар'єри, MapReduce та розподілені воркери десятиліттями.

Що змінилося, так це те, що тепер знаходиться всередині кожного вузла.

Вузол може шукати в репозиторії, аудитувати міграцію, ставити під сумнів архітектурне рішення, аналізувати тестові невдачі або синтезувати п'ятдесят незалежних висновків в один документований звіт.

Цей посібник розбиває всю систему від найпростішого лінійного агента до діамантових графів, вузлів-маршрутизаторів, панелей суперечливих верифікаторів, збіжних циклів, рівнів моделей та динамічних робочих процесів, що генеруються безпосередньо всередині Claude Code.

Наприкінці ви зможете, дивлячись на велике завдання, перестати запитувати:

"Який промпт мені написати?"

1. ГРАФІЧНА ІНЖЕНЕРІЯ ПОЧИНАЄТЬСЯ З РАХУНКУ

Графічну інженерію часто представляють як спосіб запускати більше агентів.

Таке формулювання пропускає найдорожчу частину.

Ви можете запустити двадцять агентів Claude Code проти одного репозиторію і отримати двадцять звітів, що перекриваються, повторюваний контекст, суперечливі висновки та набагато більший 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": "Обидва місця виклику залежать від застарілого методу refresh."
7}

Класифікатор ризиків тепер отримує ті самі поля для кожної знахідки. Він може відхиляти неповні результати, групувати пов'язані файли та направляти невизначені докази на інший розгляд.

Схеми зменшують дрейф інтерпретації між вузлами. Вільні абзаци змушують кожен наступний агент реконструювати значення попереднього. Через кілька етапів невеликі двозначності можуть змінити кінцевий висновок.

Структурований вихід зберігає докази стабільними під час їх руху через граф.

Деякі вузли — це звичайний код

Припустимо, вісім пошукових агентів повертають вісімдесят знахідок.

Робочому процесу потрібно об'єднати масиви, відкинути порожні відповіді, видалити дублікати та відсортувати решту.

Ці операції мають детерміновані відповіді:

1const uniqueFindings = [
2  ...new Map(
3    results
4      .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_SCHEMA
7    });
8  })
9);

Оркестрація залишається у звичайному JavaScript. Кожна гілка отримує обмежене завдання і повертає валідований об'єкт.

Результат приходить як колекція виходів, які можна фільтрувати, перевіряти та передавати в наступний етап.

Велике розгалуження все ще потребує причини для кожної гілки.

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

Бар'єр створює точку прийняття рішень

Бар'єр призупиняє наступний етап, доки не завершаться необхідні гілки.

Ця пауза важлива, оскільки деякі рішення залежать від повного набору.

Вузол ранжирування не може визначити найважливішу вразливість, поки половина репозиторію все ще перевіряється. Модель синтезу не може написати повний план міграції, поки огляд розгортання все ще триває.

На бар'єрі граф має можливість перевірити стан виконання:

1const completed = findings.filter(Boolean);
2
3if (completed.length < MIN_REQUIRED_RESULTS) {
4  throw new Error("Недостатнє покриття аудиту");
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_SCHEMA
10});

Зведення контролює, що потрапляє до фінальної моделі.

Хороший зведник видаляє повторення, зберігаючи докази. Агресивний зведник може стиснути кілька різних ризиків в одне розпливчасте резюме і стерти деталі, необхідні для перевірки.

Найбезпечніший шаблон зберігає зв'язок між кожним зведеним твердженням та його вихідними елементами.

1{
2  "risk": "Оновлення сесії може не спрацювати після міграції",
3  "severity": "high",
4  "sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],
5  "evidence": [
6    "Три сервіси викликають застарілий метод refresh",
7    "Не існує шляху відкату",
8    "Відсутнє інтеграційне покриття"
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 repository
2      │
3      ├→ worktree/auth-fix
4      ├→ worktree/db-migration
5      └→ worktree/test-repair

Кожен агент може змінювати файли та запускати тести у власному середовищі. Пізніший вузол порівнює патчі, перевіряє конфлікти та вибирає, що слід об'єднати.

Це перетворює ізоляцію на частину графа, а не на ручний крок очищення.

Дозвольте дослідженню збігатися

Деякі завдання неможливо виконати за один прохід.

Аудит репозиторію може виявити залежність, яка вказує на інший пакет. Цей пакет може виявити інше місце виклику. Графу потрібен контрольований спосіб продовжувати пошук, не повторюючи все, що він уже бачив.

1const seen = new Set();
2let dryRounds = 0;
3
4while (dryRounds < 2) {
5  const findings = await discoverNext([...seen]);
6  const fresh = findings.filter(item => !seen.has(item.id));
7
8  fresh.forEach(item => seen.add(item.id));
9  dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;
10}

Важлива деталь — дедуплікація проти кожного раніше баченого елемента.

Дедуплікація лише проти підтверджених знахідок дозволяє відхиленим або невизначеним елементам повернутися на наступному проході та спожити ту саму роботу знову.

Цикл зупиняється після кількох сухих раундів, фіксованого бюджету або максимальної кількості ітерацій. Виробничі графи зазвичай потребують усіх трьох.

Підберіть модель до вузла

Не кожен вузол потребує найсильнішої доступної моделі.

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

Рівні моделей стають ще однією властивістю графа.

Бюджет визначається тим, скільки вузлів виконується, як часто повторюються цикли, скільки контексту перетинає кожне ребро і яка модель обробляє кожен етап.

Граф з двадцятьма дешевими пошуковими викликами все ще може коштувати більше, ніж один сильний виклик. Архітектурі потрібен бюджет токенів, перш ніж їй знадобиться ще одна гілка.

Знайте, коли зупинити малювання

Невеликі завдання рідко потребують маршрутизаторів, панелей голосування, worktrees та циклів збіжності.

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

Лінійний робочий процес зазвичай достатній, коли одна модель може вмістити відповідний контекст, завдання має мало незалежних гілок, а вартість неправильної відповіді є низькою.

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

Повний робочий процес зрештою може виглядати так:

Цінність полягає в тому, щоб зробити рух роботи видимим.

Кожен вузол має обмежену відповідальність. Кожне ребро несе структуровані докази. Кожна гілка має причину існувати. Кожен цикл має умову зупинки.

У цей момент Claude Code більше не працює за однією довгою інструкцією.

Він виконує спроєктовану систему.