Графова інженерія: створення понад 1000 циклів агентів з одного промпту

Наступник Loop Engineering та робочий процес, який запускає ваші агенти в 10 разів ширше...

Більшість людей, які будують багатокрокового агента, отримують пряму лінію

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

Ось що майже ніхто не перевіряє:

половині цих кроків ніколи не потрібно було чекати

Вони просто стоять у черзі, одне завдання за раз, поки контекстне вікно не заповниться, і агент не забуде, що він робив

• Це було не повільно, тому що модель була слабкою
• Це було повільно, тому що ви намалювали лінію там, де робота була графом

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

П'ять кроків. До Кроку 2 ви вже побудуєте один -

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

до альфи - підпишіться на мій Substack, щоб отримувати більше свіжої альфи ↓

https://substack.com/@0xcodila

Розділ 0 - Що таке графічна інженерія насправді

Місяць тому поле говорило про цикли.

Пітер Штайнбергер вловив це дев'ятьма словами:

https://x.com/steipete/status/2078277297791189132

Цикл - це один крок покращення:

спробувати щось → перевірити результат → скоригувати → повторити

Це атом: один агент, який повторює одну річ

(Якщо ви читали мою статтю Loop Engineering, це вона)

https://x.com/0xCodila/status/2072329149520232639

Але в одиночного циклу є відома вада - команда підтримки прив'язує цикл зворотного зв'язку до одного показника: відсоток вирішення заявок

Число зростає місяцями, а задоволеність падає. Бот навчився швидко закривати заявки замість того, щоб їх вирішувати

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

Відповідь не в кращому циклі. Відповідь у графі циклів - мережі, де цикли спостерігають і коригують один одного

Для агентів це означає одне:

Перестаньте писати одного агента, який робить все лінійно - спроектуйте

форму

роботи - що виконується перед чим, що виконується одночасно, що чекає.

Вузли виконують мислення. Ребра переносять результати

І Claude Code випустив інструменти для створення цього безпосередньо: динамічні робочі процеси

Крок 1 - Побачте ребра, яких немає

Граф має дві частини:

• Вузол - це одна одиниця роботи: один агент, одне завдання, один вхід, один вихід
• Ребро - це залежність: вихід цього вузла живить вхід того вузла

Помилка, яку роблять всі, - це сприймати "а потім" як ребро.

"Підсумуй цей файл

а потім

скажи мені погоду"

Погода не читає підсумок.

Це два незалежних завдання, які лінійний скрипт поєднує без причини. Кожне чекає на інше без потреби

Звичка, з якої все починається:

Для кожного "а потім" запитайте - чи наступний крок насправді читає результат попереднього?

• Якщо так → справжнє ребро. Зберігайте порядок.
• Якщо ні → не ребро. Очікування марне. Запустіть їх паралельно.

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

Саме цю незалежність ви будете використовувати в решті цього посібника

Ваш звичайний агент "зроби A, потім B, потім C" - це вже граф - просто найсумніший: єдиний ланцюг, де якщо C зупиняється, D ніколи не відбувається.

Крок 2 - Побудуйте свій перший граф (від початку до кінця)

Досить теорії. Побудуйте один і подивіться, як він працює.

Перед початком:

• Claude Code v2.1.154+ (перевірте за допомогою claude --version)
• Платний план. На Max, Team або Enterprise робочі процеси увімкнені за замовчуванням. На Pro увімкніть рядок Динамічні робочі процеси в /config

1. Відкрийте знайомий репозиторій.

Справжній, щоб результат мав значення.

2. Вставте цей запит (від Anthropic):

1Створіть робочий процес для аудиту кожного файлу маршрутів у src/routes/
2на предмет відсутніх перевірок автентифікації. Запустіть одного агента на файл, потім запустіть
3незалежного верифікатора для кожного результату перед створенням звіту.
4Проаналізуйте максимум 20 файлів для початку.

Замініть src/routes/ на шлях, де знаходяться ваші файли. Рядок "макс 20" зробить ваш перший запуск дешевим.

3. Спостерігайте, як загоряється "робочий процес".

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

4. Схваліть план.

Claude Code пише скрипт-оркестратор на JavaScript і спочатку показує фази. Прочитайте їх, оберіть "Так, запустити."

5. Дозвольте флоту працювати.

Один агент на файл, паралельно, поки ваш сеанс залишається вільним.

Введіть /workflows, щоб спостерігати за цим у реальному часі: обсяг, розгалуження, перевірка, синтез.

6. Прочитайте єдину відповідь.

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

Це граф.

Дюжина агентів з одного речення.

Про твердження про "нуль токенів", яке ви почуєте

Координаційний скрипт - це код

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

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

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

• Зробіть це своїм

Коли запуск буде вдалим, натисніть s.

Це зберігається в ~/.claude/workflows, готове до повторного запуску за назвою

Тепер змініть завдання та збережіть форму. Замініть "відсутніх перевірок автентифікації" на "необроблені проміси" або "функції довші за 100 рядків"

Наскільки це масштабується (назва статті)

Один робочий процес може розгалужуватися на 1 000 агентів, причому до 16 можуть працювати одночасно

Ось звідки походить "1000+ циклів в одному вікні" - не метафора, а фактична стеля функції

• І масштаб є суттю Тисяча агентів означає завдання, яке жоден окремий контекст ніколи не зміг би вмістити - ціла кодова база, перевірена за один раз, міграція, яка торкається кожного файлу, пошук, який запускає тисячу ракурсів паралельно

Обмеження в 16 одночасних просто означає, що флот рухається хвилями, пережовуючи всю тисячу без вашого нагляду за жодним

Почніть з 20, щоб побачити, як поводиться запуск і скільки він коштує - потім розширюйтеся - тому що це стеля, проти якої ніхто інший не будує

Крок 3 - Частина, яка насправді ламається

Ви побудували граф. Ось де справжні розвалюються.

Два збої мають найбільше значення

• Збій перший: граф погоджується сам із собою

Коли агент перевіряє власну роботу, він ставиться до себе поблажливо. Моделі надають перевагу власним виходам

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

Уловка, яку ніхто не називає: верифікатору потрібен чистий контекст

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

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

Отже, верифікатор - це новий вузол - Власний контекст - Перевірка реального сигналу - не "чи сказав агент, що це зроблено", а "чи тест насправді проходить"

• Збій другий: агенти заважають один одному

Це не гіпотетично

Коли команда Bun вперше розгалузила великий порт на багатьох агентів, запуск провалився операційно , і агенти використовували спільні git-команди в одному робочому просторі та перезаписували один одного

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

Це справжній урок паралелізму - два агенти, які пишуть один файл, змагаються

Перш ніж розгалужуватися, дайте відповідь на три питання:

• Де працює кожен агент?
• Як об'єднуються результати?
• Що станеться, коли двоє не погоджуються?

Граф без такого плану не масштабується - Він зазнає невдачі швидше

Крок 4 - Шість графів, які варто побудувати цього тижня

Метод: знайдіть справжні ребра → розгалузьте → перевірте на незалежному контексті → ізолюйте виконавців

///

Кожен з них має ту саму форму, спрямовану на нове завдання. Змініть рядок завдання і вперед:

• Безпекова перевірка - один агент на файл, який шукає відсутню автентифікацію, верифікатор, що підтверджує кожне влучення (той, який ви побудували)
• Цитований звіт з /deep-research - вже працює: розбиває ваше запитання на ракурси, шукає паралельно, агенти спростовують один одного перед написанням
• Порт модуля - файл за файлом, тести як шлюз, невдачі повертаються назад
• Змагальний огляд diff - маршрутизований за розміром: невелика зміна → один прохід; велика → повний паралельний аудит
• Заплановане сканування екосистеми - збережіть один раз, запускайте повторно за назвою
• Розвідка невідомого розміру - пошукові агенти запускаються паралельно, кожен результат перевіряється на все, що вже бачили, цикл повторюється, поки два раунди не знайдуть нічого нового

///

Як виглядає стеляhttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/

Порт Bun з Zig на Rust працював саме на цьому механізмі.

Близько 50 робочих процесів, пік до 64 агентів паралельно. Приблизно 535 000 рядків Zig перетворено на понад мільйон рядків Rust за 11 днів.

Це також коштувало близько $165 000 використання. Потрібна була людина, яка б проєктувала та контролювала все це

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

Масштаб реальний. Так само як і ціна, і нагляд

Крок 5 - Якорі, які тримають граф чесним

Сама по собі топологія не купує правди

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

Графу потрібні якорі: вузли, які неможливо оскаржити

• Тести, які насправді виконалися - не "мають пройти", пройшли
• Верифікатор на основі доказів, а не відчуттів
• Застиглі правила, які агентам ніколи не дозволяється налаштовувати - тому що вони є тими, що оптимізатор послабив би

Граф настільки чесний, наскільки чесні речі в ньому, які відмовляються рухатися

Коли граф є неправильним вибором

Більшість завдань - це не графи. Використання графа, коли він не потрібен, просто спалює гроші та додає способи зазнати невдачі.

Пропустіть граф, коли:

• Завдання мале або ізольоване. Додавання функції, виправлення одного бага. Робочий процес тут - це чисті накладні витрати - один агент швидший і дешевший.
• Потрібен жорсткий нагляд. Якщо ви хочете читати та схвалювати кожен крок, перш ніж виконається наступний, весь сенс графа (робота на широкому фронті без вас) працює проти вас.
• Ви ще не знаєте, що шукаєте. Дослідницька робота потребує одного агента, яким ви можете керувати, а не флоту, прив'язаного до плану до того, як ви зрозумієте проблему.
• Кроки справді залежать один від одного. Якщо кожен крок читає результат попереднього, це справжній ланцюг. Паралелізму немає за що вхопитися. Нав'язування графа суто послідовному завданню просто додає координаційних витрат без прискорення.

Підказка - це Крок 1. Якщо ви не можете знайти два блоки без стрілки між ними, графа будувати немає. Це цикл, і цикл - це нормально.

Граф - це інструмент для ширини - незалежної роботи, виконаної одночасно

Коли робота не є широкою, лінія ніколи не була проблемою...

Зміна парадигми

Автор запитів ставить питання. Архітектор малює граф.

Лінійний агент ніколи не був стелею.

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

Як тільки ви побачите вузли та ребра, ви перестанете просити агента робити більше і почнете просити граф робити це ширше:

• Розгалужуйтеся там, де робота незалежна
• Блокуйте ребра там, де важлива впевненість
• Фіксуйте вузли, які містять істину

Більшість людей продовжуватимуть ставити кроки в чергу.

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

Намалюйте граф. Залишайтеся архітектором.

Почніть з передумови:

Loop Engineering

- єдиний цикл, на якому це побудовано

@0xCodila