Що розкриває про справжню архітектуру 10-хвилинний процес створення агента

Що дозволило дізнатися під час роботи з LangGraph, Deep Agents та TrueForge про абстракцію, керування та справжню поведінку агентів.

Під час створення DEVIN значна частина зусиль пішла на роботу, яка ніколи не стає видимою, коли хтось просто використовує AI-агента.

Підключення Deep Agents.

Налаштування Daytona як середовища сандбоксу.

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

Забезпечення взаємодії всіх цих елементів.

Прогрес був повільним.

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

Не лише сама модель.

Усе, що її оточує.

Час виконання.

Інструменти.

Середовище сандбоксу.

Шар оркестрації.

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

Потім з’явився хакатон, а разом із ним — TrueForge.

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

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

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

І, чесно кажучи, це було вражаюче.

Саме так має відчуватися хороша абстракція.

Але компроміс, прихований у цій простоті, ще не був очевидним.

Агент за 10 хвилин

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

TrueForge піклувався про супутню інфраструктуру, залишаючи основну роботу з опису того, що саме має робити агент, визначенню навички.

Це справді потужна абстракція.

Додавані MCP були видимими.

Інструменти також були видимими.

Файл SKILL.md також був видимий.

Усе здавалося зрозумілим та простим для аналізу.

Тож звичка користуватися ним залишилась.

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

Проблемою не було те, що можна перевірити.

Проблемою було де саме знаходиться архітектура.

Одна навичка сама по собі не є архітектурою

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

Це означає, що один файл SKILL.md може по суті визначати значну частину структури поведінки агента.

                    Root Agent
                   /          \
                  /            \
            Researcher        Coder
                /                \
               /                  \
          Searcher              Tester

Просте повідомлення основному агенту на кшталт: «Ось ваші інструменти, створіть будь-які підагенти, які вам потрібні, та самостійно все вирішуйте», — це не те саме, що проектування системи.

Насправді важливо безпосередньо визначити архітектуру:

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

Саме ця відмінність почала ставати помітною.

При роботі з підходом Deep Agents архітектуру потрібно свідомо будувати.

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

Ця залежність значно тісніше пов’язує поведінку всієї системи з базовою моделлю.

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

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

Та сама файлова структура навичок.

Ті самі інструменти.

Різна кінцева поведінка.

На папері архітектура не змінилась.

Змінилася лише інтерпретація цієї архітектури моделлю.

Саме ця прогалина ускладнила можливість повної довіри до цього підходу.

Робота над AEGIS посилила цю турботу

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

Агент мав досліджувати випадки застрягання циклу подій Node.js.

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

На початковому етапі етап перевірки полягав переважно у формулюванні вказівок для моделі щодо дій, приблизно таких:

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

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

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

Модель виконує міркування.

Система здійснює вимірювання.

Перевіряючий здійснює виклик.

Цей досвід призвів до принципу, який тепер широко застосовується у проектуванні агентів:

Якщо щось неможливо спостерігати, його неможливо належним чином протестувати. Якщо його неможливо протестувати, його неможливо оцінити. А якщо його неможливо оцінити, його неможливо надійно покращити.

Саме тому важлива архітектура.

Не тому, що діаграма з більшою кількістю клітинок та стрілок є за своєю суттю кращою.

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

„Це працює“ проти „Я розумію, чому це працює“

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

Обидва можуть виконати поставлене завдання.

Обидва можуть чудово виглядати під час прямої демонстрації.

Справжній випробування настає, коли щось йде не так.

У разі одного типу агента можна відстежити точний шлях виконання:

Root Agent
    ↓
Researcher
    ↓
Search Tool
    ↓
Result
    ↓
Root Agent
    ↓
Coder
    ↓
Sandbox

Кожну точку прийняття рішень можна перевірити та проаналізувати:

Чому сталося саме це крок?

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

Коли це спрацьовує, все здається надзвичайно простим.

Коли це зазнає невдачі, відповісти на запитання щодо виправлення помилок стає набагато складніше:

Чи була невдача спричинена моделлю, інструкціями, логікою делегування, наданим контекстом чи архітектурою, яку модель створила самостійно?

Цей другий сценарій — це набагато складніша проблема для роз’яснення.

І саме цього навчив TrueForge

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

Робота з нею змінює це уявлення. Виявляється, інфраструктура — це лише половина виклику.

Інфраструктуру можна абстрагувати.

Поведінку складно абстрагувати.

Платформа може надати сандбокс.

Вона може надати MCP.

Вона може надати механізм стрімінгу.

Вона може надати весь середовище виконання.

Проте, якщо ви створюєте агента, чиї дії справді мають значення, вам все одно доведеться самостійно відповісти на деякі запитання:

Який компонент приймає які рішення?

Що дозволено робити?

Де саме відбувається делегування?

Який у вас рівень прозорості щодо цього процесу?

Що ви насправді можете виміряти чи оцінити?

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

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

Скільки часу потрібно, щоб зрозуміти, чому це провалилося?

Створення агента за десять хвилин — справді вражаючий досягнення.

Але ще корисніше запитання, яке стає важливішим за цю швидкість:

Скільки часу потрібно, щоб зрозуміти, чому це провалилося?

У середовищах виробництва не цінують успішну першу демонстрацію.

За що вони карають — це за десятий провал.

Інструмент, який повертає щось несподіване.

Слабша основна модель.

Агент, який передає роботу тоді, коли цього не слід.

Агент, який не передає роботу тоді, коли це потрібно.

Агент, який оголошує «Зроблено»,

хоча насправді нічого не було виконано.

Саме тут і проявляється користь архітектури.

Що насправді було засвоєно

Якщо роздумувати над проектом DEVIN, справжнім результатом не стало опанування Deep Agents, Daytona чи Ingest як окремих інструментів.

Це було розуміння того, як компоненти системи агентів пов’язані між собою.

TrueForge продемонстрував, наскільки швидко ці ж компоненти можна приховати від видимості.

А їх використання показало інший бік цієї зручності:

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

Хтось все одно має керувати цією поведінкою.

Хтось все ще мусить спостерігати за його роботою на практиці.

Хтось все ще мусить оцінити, чи воно працює ефективно.

І хтось все ще мусить вирішити, що потрібно змінити у разі невдачі.

Цю відповідальність краще тримати під контролем, а не передавати іншим.

Куди рухається архітектура агентів

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

Ця галузь пройшла кілька етапів:

моделі → інструменти → MCP → агенти → глибокі агенти

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

На думку авторів, найважливішим елементом у майбутньому є інфраструктура, яка оточує модель.

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

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

У міру покращення моделей сама лише якість моделі більше не буде вирішальним фактором.

Інженерне питання, яке варто поставити, буде все частіше звучати так:

Яке середовище створено навколо моделі, і наскільки можна впливати на її поведінку?

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

Чим простіше стає створення агента, тим важливішим стає розуміння всього, що його оточує.