Что показывает процесс создания агента за 10 минут о реальной архитектуре

Что показало сотрудничество с LangGraph, Deep Agents и TrueForge о концепциях абстракции, управления и реальном поведении агентов.

При создании DEVIN значительная часть усилий была направлена на работу, которая никогда не становится видимой при простом использовании ИИ-агента.

Подключение компонентов 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 как отдельными инструментами.

Настоящим результатом стало понимание того, как компоненты системы агентов связаны друг с другом.

ZTrueForge показал, насколько быстро эти же компоненты могут быть скрыты от вида.

И использование этого инструмента выявило обратную сторону такой удобности:

Инфраструктура может исчезнуть из рабочего процесса, при этом поведение не исчезает вместе с ней.

Кто-то всё равно должен контролировать это поведение.

Кто-то всё ещё должен увидеть, как это работает на практике.

Кто-то всё ещё должен оценить, эффективно ли это функционирует.

И кто-то всё ещё должен решить, что изменить в случае сбоя.

Эту ответственность лучше сохранить у себя, а не передавать другим.

Куда движется архитектура агентов

Этот опыт также меняет подход к более широкому пониманию развития агентных систем.

Эта область прошла через несколько этапов:

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

и на каждом этапе инфраструктура, необходимая для их работы, становится всё проще в получении.

Самым важным слоем в будущем, согласно этому взгляду, является инфраструктура, обеспечивающая работу модели.

Речь идёт не только о первоначальных возможностях модели, но и о системе, которая обеспечивает её:

контекст, инструменты, выполнение, разрешения, оркестрация, память, наблюдаемость, оценка и управление.

По мере совершенствования моделей качество самой модели уже не будет единственным определяющим фактором.

Вопрос, который стоит задавать в инженерном плане, будет всё чаще звучать так:

Какая среда создана вокруг модели, и насколько можно управлять её поведением?

Это, пожалуй, главный урок, полученный при создании DEVIN и последующей сборке агента за десять минут.

Чем проще становится создание агента, тем важнее становится понимание всего, что его окружает.