Я пришёл в разработку агентов из дата-инженерии, и, в очередной раз собирая типовую структуру на LangGraph, заскучал по декларативному подходу — тому самому, который хорошо знаком по dbt. Там вы описываете, что хотите сделать с данными, а не как. Это навело меня на мысль: а почему бы не создать фреймворк для агентов, предлагающий такой же принцип?

Особенно раздражал мутабельный State в мультиагентных системах на LangGraph. Он быстро превращается в неуправляемую свалку в памяти, требует аккуратного обновления, а при ошибках — ручного поиска проблем через принты. Возможно, я что-то делаю не так, но для меня это — постоянная трата внимания. В поисках решения я познакомился с event-driven, а затем — event-sourced архитектурой. Ключевым источником стала научная работа «ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering» (Brito dos Santos Filho, 2026). На её основе я создал свой фреймворк — zymi. Расскажу обо всём по порядку.

Фреймворк написан на Rust — его преимущества, думаю, не нужно лишний раз перечислять. Разработка велась с помощью Claude Code. Можно по-разному относиться к вайб-кодингу и генерации кода, но я понял одну важную вещь: если хочешь создать что-то актуальное, другого выбора нет. Я начал проект в разгар шумихи вокруг OpenClaw, а сейчас пишу эту статью, отдавая команды Claude Code со своего iPhone. Если бы писал всё сам, закончил бы только при бесплатном и повсеместно доступном AGI — то есть, никогда.

Из-за скорости разработки возникло и название. Сначала проект назывался zumi — отсылка к «зумису» у собак, когда они внезапно начинают носиться по дому. Но уже на второй неделе появилось приложение с эмпатичным AI-питомцем под тем же именем. Я поменял одну букву, чтобы избежать путаницы.

Декларативность

Суть dbt — в том, что движок берёт на себя всю логику выполнения. Вы декларируете желаемое: пишете SQL и YAML-конфиги, а dbt сам решает, как это реализовать. Я пошёл по тому же пути.

Установка zymi:

Инициализация встроенного примера — агента-исследователя:

Структура проекта по умолчанию:

Пайплайн состоит из двух агентов — исследователя и писателя. Вот как они описываются:

Так выглядит описание инструмента для поиска в интернете, например, через Tavily:

Агенты собираются в единый пайплайн:

Готово — простая мультиагентная система создана. Её можно сразу запустить из консоли:

Помимо удобства и скорости — субъективных факторов — есть и более важное преимущество: генеративные модели отлично генерируют код, но YAML по строгой JSON-схеме даётся им ещё проще. У меня запланирован эксперимент: попросить Claude и Codex создать один и тот же пайплайн на LangGraph и на zymi. Ставлю на то, что zymi потребует меньше итераций и токенов.

Декларативный конфиг — только внешний интерфейс. Под капотом zymi отличается от LangGraph: вместо общего мутабельного состояния всё общение строится через единую шину данных.

Event-sourced архитектура

В zymi каждое событие — это иммутабельная запись в БД с hash-chain верификацией. Все взаимодействия происходят через события в шине данных. Коннекторы, агенты и инструменты читают и пишут в эту шину — она является единственным источником правды. В результате получается не просто лог, а криптографически связанная цепочка всех действий агента. Это делает каждый запуск из коробки прослеживаемым и воспроизводимым.

Зачем нужна криптография? Можно провести аналогию с dbt: лог событий — это lineage (как в dbt docs), а намерения и их верификация — уверенность в корректности (как в dbt test).

Теперь мы знаем не только что сделал агент, но и почему. Вместо прямого изменения состояния агент выражает намерение. Это намерение записывается в шину, откуда его получает монитор. На основе своих правил он решает — можно ли выполнить действие или стоит запросить подтверждение у пользователя. Например, в событиях 49–50 видно, как монитор заблокировал запись в директорию за пределами разрешённой и запросил подтверждение у человека.

Посмотреть лог запуска

Заключение

zymi пока сыроват — это альфа-версия, но он уже может помочь в прототипировании и экспериментах с агентами. В бэклоге — много идей:

• Переезд на libsql — векторная память, нативная асинхронность и edge-реплики
• Поддержка PostgreSQL в качестве шины данных
• Добавление Python-инструментов в декларативном режиме
• Реализация проекций диалогов для идемпотентных перезапусков
• Стриминг ответов LLM и многое другое

Интересно, найдёт ли дата-инженерный подход отклик в мире AI-агентов. Буду рад любой обратной связи — заходите в комментарии и репозиторий проекта.

И да пребудет с вами иммутабельность!

Я пришел в разработку агентов из дата инженерии, и в очередной раз занимаясь сборкой типовой структуры на LangGraph я заскучал по декларативному подходу, хорошо многим знакомому по dbt - там ты описываешьчтоты хочешь сделать с данными, а некак. И тогда у меня появилась мысль - а почему бы не собрать свой фреймворк для агентов, который даст тот же подход.

Плюс, самое нелюбимое для меня в мультиагентных системах на LangGraph это мутабельный State. Он быстро превращается в неконтролируемую свалку в оперативной памяти, его надо каждый раз аккуратно обновлять, а когда что-то работает не так как хочется - принтовать и выискивать косяки. Возможно, я просто что-то делаю не так, но для меня такие штуки это всегда про дополнительную трату внимания. В поисках решения данной проблемы я и познакомился с применением архитектуры event driven в мультиагентных системах, а дальше - event sourced. Основным источником знаний по данной архитектуре выступила свежая научная работа«ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering» (Brito dos Santos Filho, 2026). В итоге я написал свой фреймворк - zymi. Но обо всем по порядку.

Фреймворк написан на Rust - думаю нет смысла лишний раз рассказывать про его преимущества. Сразу обозначу - разработка велась с Claude Code. Можно по-разному относиться к вайбкодингу и генерации кода, но я за время разработки понял одну очень важную мысль - если ты хочешь разработать что-то актуальное, то у тебя нет других вариантов. Я начал работу над проектом в самый разгар шумихи вокруг OpenClaw, а сейчас пишу эту статью параллельно давая команды Claude Code со своего айфона. Писал бы сам - закончил бы при бесплатном и всем доступном AGI (ну то есть никогда).

Из-за всей этой скорости вокруг случилось и название проекта - изначально оно было zumi, отсылка к собачьему зумис, когда пёс вдруг начинает носиться по квартире без остановки - но где-то на второй неделе вышло приложение с эмпатичным AI питомцем с таким же названием. Я решил поменять одну букву, чтобы не было путаницы.

Декларативность

Весь кайф уже упомянутого dbt заключается как раз в том, что движок полностью забирает на себя все вопросы насчет того, как сделать то, что тебе хочется. Ты декларируешь желание - оформляешь yaml, пишешь SQL и dbt сам прогоняет все необходимые тебе преобразования. Я решил пойти по такому же пути.

Установка zymi

И инициализируем встроенный пример проекта агента-исследователя:

Структурно дефолтный проект выглядит следующим образом:

Данный пайплайн состоит из всего двух агентов - исследователя и писателя. Вот так они оформляются:

Вот так оформляется инструмент для поиска в интернете, например, с использованием Tavily

После чего агентов можно собрать в единый пайплайн

Собственно всё - простенькая мультиагентная система готова. Можем её тут же запустить через консоль:

Кроме удобства и скорости - что индивидуально, конечно - это дает гораздо более важное преимущество для современного мира: генеративные модели прекрасно справляются с генерацией кода, но генерация yaml, да ещё по строгой json схеме, эта задача для них на порядок проще. У меня запланирован эксперимент, о котором я напишу в следующей статье - попрошу Claude/Codex сгенерировать один и тот же пайплайн на LangGraph и на zymi, и запустить его. Ставлю на то, что zymi потребует меньше итераций и токенов.

Но декларативный конфиг - это только внешний интерфейс. Под капотом zymi тоже отличается от того же LangGraph - вместо общего стейта, который мутируется агентами, всё общение построено на единой шине данных.

Event sourced архитектура

В zymi каждое событие - это иммутабельная запись в БД с hash-chain верификацией. Все взаимодействия строятся на таких событиях - записях в шине данных. Все коннекторы, агенты, инструменты пишут и читают эту шину, она является единственным источником правды в системе. В итоге, мы получаем не просто лог, а криптографически связанную цепочку всех действий агента. Это позволяет из коробки делать каждый запуск прослеживаемым и воспроизводимым.

Зачем нам тут криптография? Можно провести аналогию как раз с dbt: лог событий даёт нам lineage - dbt docs; намерения и верификация дают уверенность в корректности этого лога - dbt test.

Благодаря этому, мы всегда знаем не только что агент сделал, но и почему - вместо того, чтобы напрямую что-то изменять они выражают намерение это сделать. Это намерение также пишется в шину данных откуда его получает монитор - и уже он, на базе своих требований, решает можно ли это выполнить или может надо спросить пользователя. И в самом конце, события 49-50, как раз можно увидеть как монитор засомневался стоит ли разрешать запись в директорию за пределами разрешенных и позвал человека.

Посмотреть лог запуска

Заключение

Конечно zymi еще сырой - это только альфа, но он уже готов помогать прототипировать и экспериментировать с агентами. У проекта большой бэклог:

1. Переезд на libsql - векторная память, нативная асинхронщина и edge-реплики
2. Доработка возможности подключения PostgreSQL как шины данных
3. Реализация возможности добавления python-инструментов в декларативном режиме,
4. Доработка проекций диалогов для идемпотентных перезапусков
5. Стриминг ответов LLM И много чего ещё.

Мне интересно посмотреть, найдет ли этот дата инженерный подход отклик в современном мире AI агентов. Буду рад любой обратной связи - залетайте в комментарии и врепозиторий проекта(ставить звёзды, конечно).

И да пребудет с вами иммутабельность!