Практичний посібник із трьох рівнів, які люди постійно плутають
Більшість людей говорять про AI-агенти як про щось єдине.
Але це не так.
Коли агент виходить за межі демонстраційної іграшки й починає працювати з файлами, API, документами, клієнтами або продуктивним кодом, ви вже не просто «даєте підказки моделі».
Ви проектуєте систему.
І в цій системі три ідеї постійно плутають:
- Інженерія оболонки агента
- Інженерія циклу
- Інженерія графа
Всі вони розташовані навколо однієї моделі.
Всі вони впливають на надійність.
І так, усі вони можуть містити цикли.
Але вони вирішують різні проблеми.
Якщо ви їх переплутаєте, то налагоджуватимете не той рівень.
Відповідь за 30 секунд
Ось чиста версія:
- Інженерія оболонки створює середовище навколо моделі
- Інженерія циклу проєктує повторюваний цикл роботи та зворотного зв'язку
- Інженерія графа робить топологію робочого процесу явною
Хороша ментальна модель:
Середовище → Зворотний зв'язок → Потік
- Оболонка надає моделі інструменти, пам'ять, контроль і робочий простір
- Цикл визначає, як робота повторюється, перевіряється та покращується
- Граф визначає, який крок дозволено виконати наступним
Ось у чому різниця.
Чому ці терміни важливі зараз
Сировинна модель не може виконувати реальну роботу сама по собі.
Вона не може:
- підтримувати стан проєкту між сеансами
- безпечно викликати інструменти
- переглядати браузер
- забезпечувати дотримання прав доступу
- повторювати невдалу роботу
- перевіряти якість результатів
- маршрутизувати завдання між спеціалістами
- зупинятися в потрібний момент
Усе це забезпечує система навколо неї.
У міру дорослішання агентного програмного забезпечення виникає практичний стек:
- Оболонка надає моделі робочі умови
- Цикли роблять роботу повторюваною та перевіреною
- Граф робить складні робочі процеси явними та керованими
Як тільки ви побачите ці окремі рівні, багато плутанини в архітектурі AI зникне.
Що зазвичай включає серйозна оболонка
- Введення контексту
Що модель бачить перед тим, як діяти:
- інструкції
- отримані знання
- стан розмови
- пам'ять
- політики
- правила, специфічні для завдання
- Поверхні дій
Що модель може робити:
- виклики API
- дії в браузері
- команди терміналу
- виконання коду
- інструменти MCP
- бази даних
- власні функції
- Збереження стану
Що зберігається з часом:
- файли
- контрольні точки
- стан сеансу
- журнали прогресу
- історія git
- довгострокова пам'ять
- Керування виконанням
Як керується запуск:
- повтори
- тайм-аути
- бюджети
- вибір моделі
- створення під-агентів
- ворота затвердження
- Безпека та управління
Що забезпечує безпеку системи:
- права з мінімальними привілеями
- ізоляція
- білі списки
- обробка секретів
- схвалення людиною
- Спостережуваність
Що дозволяє налагоджувати систему:
- трасування
- входи та виходи інструментів
- переходи станів
- затримка
- вартість
- результати оцінювання
Чому важлива інженерія оболонки
Дві команди можуть використовувати одну й ту саму модель і отримувати абсолютно різні результати.
Чому?
Тому що одна команда дає моделі:
- чисті інструменти
- стабільний стан
- структуровану пам'ять
- чіткі дозволи
- спостережуване виконання
А інша дає:
- розпливчасту підказку
- неохайні інструменти
- зашумлений контекст
- відсутність пам'яті
- відсутність перевірки
Модель може бути однаковою.
Робочі умови — ні.
Інженерія оболонки важлива щоразу, коли агент:
- не може отримати доступ до потрібної можливості
- втрачає контекст між сеансами
- діє непослідовно в різних середовищах
- не підлягає аудиту
- має занадто багато дозволів
- не може чисто відновитися після переривання
Якщо модель не може працювати надійно, перше, на що варто звернути увагу, — це оболонка.
2. Інженерія циклу
Що це таке
Кожен агент, який використовує інструменти, уже має вбудований крихітний цикл:
- викликати модель
- спостерігати за результатом
- запускати інструменти
- подавати спостереження назад
- повторювати, доки не завершено
Інженерія циклу починається, коли ви навмисно проєктуєте додаткові цикли навколо цієї поведінки.
Не просто «спитати ще раз».
Не просто «повторити».
А справжня система роботи та зворотного зв'язку.
Анатомія хорошого циклу
Тригер
Що запускає новий цикл?
- запит користувача
- невдалий тест
- новий документ
- запланований запуск
- вебхук
- зворотний зв'язок від оцінювача
Мета
Якої конкретної умови ми намагаємося досягти?
Не «продовжувати покращувати».
Справжня ціль.
Стан
Що потрібно знати наступному циклу?
- поточний чернетка
- попередня спроба
- результати інструментів
- помилки
- статус прогресу
Політика дій
Що агенту дозволено робити?
- редагувати
- делегувати
- викликати інструменти
- витрачати токени
- записувати файли
- відкривати PR
Докази
Як ми дізнаємося, чи спрацювало?
- тести
- перевірка схеми
- цитати
- відмінності (diff)
- метрики
- схвалення рецензента
Зворотний зв'язок
Що саме не вдалося?
Зворотний зв'язок має бути компактним і дієвим.
Правило зупинки
Коли це закінчується?
- успіх
- тайм-аут
- вичерпаний бюджет
- досягнуто максимальної кількості повторів
- непереборна помилка
- ескалація людині
Найважливіший принцип в інженерії циклу
**Не повторюйте на основі впевненості.
Повторюйте на основі доказів.**
«Агент каже, що завершено» — це не умова зупинки.
Справжня умова зупинки виглядає приблизно так:
- тести пройшли
- схема валідна
- цитати підтверджені
- рецензент схвалив
- перевірка політики чиста
Ось що таке інженерія циклу.
Чому інженерія циклу — це не просто інженерія підказок
Підказка вказує моделі, що робити під час виклику.
Цикл визначає, що система робить після виклику.
Це включає:
- як перевіряються результати
- як реагувати на невдачу
- як зберігається прогрес
- як приймається рішення продовжувати
- як завершується
Підказка покращує відповідь.
Цикл покращує процес.
Це зовсім інша інженерна проблема.
3. Інженерія графа
Що це таке
Інженерія графа робить структуру робочого процесу явною.
Вона відповідає на інше запитання:
Не просто «що агенту робити?» А «що дозволено виконати наступним?»
В інженерії графа:
- кроки — це вузли
- переходи — це ребра
- розгалуження явне
- паралельна робота явна
- з'єднання явні
- повтори явні
- людські переривання явні
Граф стає картою керування системою.
Що насправді проєктують інженери графа
Межі вузлів
Що належить:
- детермінованій функції
- виклику LLM
- спеціалізованому агенту
- етапу перевірки людиною
Схема стану
Що кожен вузол може читати або записувати.
Умови маршрутизації
Які докази переміщують завдання:
- вперед
- назад
- вбік
- до ескалації
Конкурентність
Що може виконуватися паралельно, а що має чекати.
Цикли та виходи
Де дозволені повтори, скільки дозволено та як вони зупиняються.
Довговічність
Де відбуваються контрольні точки та як робочий процес відновлюється після переривання.
Коли графи варті того
Графи корисні, коли процес включає:
- значуще розгалуження
- затвердження
- передачу спеціалістам
- паралельну роботу
- шляхи відновлення
- багатокрокові робочі процеси з явними точками контролю
Вони менш корисні, коли завдання просто:
«Дайте одному агенту кілька інструментів і дозвольте йому працювати.»
У такому випадку може вистачити надійної оболонки та кількох циклів.
Граф додає ясності, але також додає структури.
Занадто багато структури занадто рано може зробити систему крихкою.
Як три рівні працюють разом
Припустимо, ви створюєте агента для дослідження та публікації.
Він має:
- визначити тему
- зібрати джерела
- відфільтрувати цитати
- підготувати чернетку звіту
- пройти юридичну перевірку
- опублікувати лише після затвердження
Ось як відображаються рівні:
Оболонка
Надає:
- доступ до браузера
- інструменти пошуку
- файловий робочий простір
- пам'ять
- цитати
- затвердження
- трасування
- маршрутизацію моделі
Цикл
Обробляє:
- повторне отримання джерел, коли докази слабкі
- виправлення помилок цитування
- запуск перевірок оцінювача
- оновлення роботи, коли ринок змінюється
Граф
Контролює шлях:
- визначення теми
- дослідження
- фільтрація
- синтез
- написання чернетки
- рецензування
- публікація
З людським воротами перед випуском.
Ось чому три рівні не є взаємозамінними.
Вони працюють разом, але це не одне й те саме.
Діагностуйте несправність, перш ніж вибирати виправлення
Ось практичне правило:
Якщо агент не може працювати, виправте оболонку
Приклади:
- відсутній доступ до інструменту
- застарілий стан
- слабка пам'ять
- погані дозволи
- відсутність спостережуваності
Якщо агент майже працює, але ненадійний, виправте цикл
Приклади:
- перший чернетка близький, але слабкий
- успіх непослідовний
- повтори некеровані
- немає доказів завершення
Якщо сам процес складний, виправте граф
Приклади:
- багато спеціалістів
- затвердження
- логіка розгалуження
- паралельні шляхи
- структуровані передачі
Поширені помилки
1. Побудова графа занадто рано
Команди часто діаграмують величезний робочий процес, перш ніж побачити, як робота насправді поводиться.
Кращий підхід:
- почати з простішої оболонки
- зібрати траси
- знайти стабільні патерни
- формалізувати лише те, що заслуговує на контроль
2. Дозвіл одній і тій самій моделі писати та оцінювати без запобіжників
Саморецензія може допомогти, але вона має ті самі сліпі зони.
Краще:
- використовувати детерміновані перевірки, де можливо
- окремий контекст рецензента
- зовнішні оцінювачі
- схвалення людиною для дій із високим впливом
3. Використання «продовжуй намагатися» як циклу
Це не дизайн циклу.
Це неконтрольований витік витрат.
Кожен цикл потребує:
- вимірної мети
- реальних доказів
- лімітів повторів
- правил ескалації
4. Ставлення до оболонки як до шухляди для сміття
Більше інструментів не означає автоматично кращих агентів.
Занадто багато інструментів створюють:
- помилки вибору
- зашумлений контекст
- слабку надійність
- ширшу поверхню ризику
Хороша оболонка не перевантажена.
Вона точна.
5. Звинувачення моделі в помилках оркестрації
Модель не може компенсувати:
- зламані API
- застарілий стан
- відсутні умови виходу
- нечіткі схеми інструментів
- невидимі режими збоїв
Виправте рівень, який володіє помилкою.
Простий контрольний список для виробництва
Оболонка
- Чи вузькі та документовані інструменти?
- Чи стан довговічний?
- Чи дозволи з мінімальними привілеями?
- Чи можуть оператори призупинити, перевірити та відновити?
- Чи траси видимі?
Цикл
- Які докази підтверджують успіх?
- Який зворотний зв'язок повертається при невдачі?
- Скільки повторів дозволено?
- Яке правило зупинки?
- Що відбувається, коли бюджет вичерпано?
Граф
- Які шляхи мають бути детермінованими?
- Що може виконуватися паралельно?
- Де знаходяться людські ворота?
- Який стан є спільним?
- Де починаються шляхи відновлення?
Оцінювання
- Чи можете ви відтворити реальні траси?
- Чи можете ви порівняти версії?
- Чи можете ви приписати покращення реальній зміні?
Операції
- Чи відстежуєте ви вартість?
- затримку?
- частоту збоїв?
- частоту втручань?
- успішність завдань у виробництві?
Найпростіший спосіб запам'ятати різницю
Якщо ви запам'ятаєте лише одне, запам'ятайте це:
- Інженерія оболонки робить модель операційною
- Інженерія циклу робить роботу ітеративною та перевіреною
- Інженерія графа робить шлях виконання явним і керованим
Жоден не замінює інші.
Ідеальний граф не врятує слабку оболонку.
Сильна оболонка все одно витрачатиме гроші без хороших циклів.
А чисті цикли стають важкими для керування, коли розгалуження та затвердження залишаються прихованими в ад-хок коді.
Надійні агенти з'являються, коли всі три рівні спроєктовані навмисно.
Це фактичний стек архітектури.
Остаточний висновок
Люди продовжують говорити про AI-агенти так, ніби прорив — це модель.
У виробництві це рідко є справжнім диференціатором.
Диференціатор — це система навколо моделі:
- оболонка, яка дозволяє їй працювати
- цикли, які дозволяють їй покращуватися
- граф, який дозволяє їй працювати під контролем
Ось як іграшкові агенти стають реальними системами.
Якщо ви дочитали до цього місця:
- ЗАКЛАДІТЬ ЦЕ В ЗАКЛАДКИ.
- Підпишіться на @LunarResearcher
- Підпишіться на мій Substack
- Підпишіться на мій Приватний Telegram-канал
