Інженерія графів для агентів кодування ШІ: контекст, контракти та виправлення.

„Інженерія графів“ останнім часом привертає багато уваги, і більшість пояснень стосуються графів, вузлів та DAG. Ці аспекти є важливими, але вони не відповідають на справжнє запитання, яке варто поставити: чому штучні інтелектуальні агенти для програмування раптово потребують інженерії графів?

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

Це спостереження призвело до створення невеликої дослідницької платформи під назвою ContractGraph. Наведений нижче опис відображає її ідеї, те, що спрацювало, а що не спрацювало. Її не створювали для конкуренції з існуючими платформами, і вона не прив’язана до певної моделі. Мета була вужчою: чи можна спроєктувати робочий процес так, щоб кожен крок мав чітку мету, чітко визначений контракт та детермінований спосіб визначення того, чи справді крок завершений?

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

Що означає інженерія графів

Інженерія графів — це практика розділення складного процесу, керованого ШІ, на невеликі одиниці виконання та їх з’єднання за допомогою чітких правил. Система, створена за принципами інженерії графів, зазвичай поєднує кілька одиниць виконання, чітке маршрутизування, спільний стан, процедури перевірки та надійну координацію.

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

Два питання, що лежать в основі дизайну

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

Перше: яку інформацію штучний інтелект має право вважати правдивою? Друге: як зрозуміти, що результат справді відповідає поставленій задачі після її виконання?

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

Контекст та контракти як будівельні блоки

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

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

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

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

Від ідеї до виконуваного графа

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

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

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

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

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

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

Тестування на більших та менших моделях

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

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

Це породило наступне запитання: чи може та сама архітектура графа все ще забезпечувати надійні робочі процеси на значно меншому та дешевшому моделі? У другому експерименті використовувався робочий процес генерації плану навчання, який виконувався за допомогою OpenCode з Big Pickle замість передової моделі. Механізми залишилися такими ж: робочий процес компілювався динамічно, генерувалися спеціалізовані вузли, кожен етап перевірявся детерміністично, несправності усувалися за потреби, а кінцевий результат отримувався через ту саму систему обробки.

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

Де виникли проблеми

Експеримент не показав, що інженерія графів запобігає збоям. Він показав, що інженерія графів робить збої видимими.

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

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

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

Чому валідація має бути детерміністичною

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

Саме тому кожен вузол у ContractGraph завершується детерміністичною перевіркою. Ніхто не запитує другу модель про думку щодо результату. Робочий процес перевіряє об’єктивні умови: чи має схема всі необхідні поля? Чи були задоволені залежності? Чи є потрібні артефакти, і чи правильно працюють посилання? Чи передав вузол усе те, що обіцяв його контракт? Це не суб’єктивні оцінки — кожна з них просто є істинною або хибною.

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

Чому додаткові зусилля можуть принести користь

Ще до цього експерименту розробник розглядав агентів для програмування на основі ШІ як невелику команду, а не як окремого асистента. Було звичайним, що Claude Code, Codex та OpenCode одночасно працювали над різними частинами одного репозиторію.

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

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

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

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

Яка насправді є вартість

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

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

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

Коли це варте зусиль

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

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

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

Заключні думки

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

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

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

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