zymi framework proposes building AI agents like a dbt project with YAML and event sourcing

На Habr вышел разбор zymi — экспериментального фреймворка для сборки мультиагентных систем в духе dbt. Вместо ручной оркестрации и общего mutable state автор предлагает декларативные YAML-конфиги и event-sourced шину, где каждый шаг агента фиксируется как отдельное событие.

Как устроен zymi Идея zymi выросла из вполне практической боли.

Автор пришёл в агентную разработку из data engineering и попытался собирать типовые схемы на LangGraph, но быстро уткнулся в проблему общего изменяемого state: его нужно постоянно обновлять, отлаживать и разбирать через логи. В ответ появился другой подход — описывать не то, как агентам ходить по шагам, а то, что система должна сделать. Это прямая отсылка к dbt, где разработчик объявляет преобразования, а движок уже сам исполняет их в нужном порядке.

В zymi базовый проект раскладывается на знакомые сущности: агенты, инструменты, память, pipelines и общий файл project.yml. В демонстрационном примере есть два агента — исследователь и писатель, а сам пайплайн оформлен как DAG: пара шагов может стартовать параллельно, а следующие зависят от depends_on.

Инструменты тоже описываются декларативно, например как HTTP-вызовы с параметрами и ключами из переменных окружения. Автор утверждает, что именно это делает систему удобнее для LLM: модели заметно проще генерировать YAML по строгой схеме, чем писать хрупкий оркестрационный код.

• Агенты описываются YAML-файлами Инструменты можно подключать как HTTP-вызовы Пайплайны собираются в DAG с параллельными шагами * Запуск и наблюдение идут через CLI > «Генерация yaml по строгой json-схеме для моделей на порядок проще».

Зачем нужен event sourcing

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

В итоге получается не просто лог, а воспроизводимая история выполнения: можно посмотреть, какой шаг стартовал, какой инструмент был вызван, что агент попытался записать в память и где система потребовала подтверждение от человека. Эта схема опирается на свежую работу ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, которую автор называет одним из ключевых источников идей. Логика такая: агент не меняет состояние напрямую, а сначала выражает намерение что-то сделать.

Дальше это намерение проходит через монитор, который может разрешить действие, отклонить его или запросить approval. В примере из статьи именно так обрабатывается попытка записать итоговый отчёт в директорию вне разрешённого списка. Такой подход делает поведение агентов намного прозрачнее: команда видит не только результат, но и причину каждого шага.

Что дальше у проекта

Автор прямо пишет, что zymi пока находится в альфе и воспринимается как инструмент для прототипирования и экспериментов. При этом у проекта уже обозначен большой бэклог: переход на libsql с векторной памятью и edge-репликами, поддержка PostgreSQL как шины данных, декларативное подключение Python-инструментов, доработка проекций диалогов для идемпотентных перезапусков и стриминг ответов LLM. Отдельно автор хочет сравнить один и тот же агентный пайплайн на LangGraph и zymi, чтобы проверить, где потребуется меньше итераций и токенов.

Если этот эксперимент подтвердит гипотезу, zymi может оказаться не просто ещё одним «фреймворком для агентов», а попыткой перенести в agentic AI дисциплину data engineering: явные зависимости, воспроизводимость, проверяемые события и меньше ручной магии. Пока это скорее инженерный манифест, чем зрелая платформа, но именно такие проекты часто задают новый язык для обсуждения того, как должны выглядеть надёжные агентные системы, когда эксперименты начинают переходить в продакшен.

Что это значит

Рынок AI-агентов постепенно уходит от импровизированных скриптов к более строгим системам оркестрации. zymi интересен тем, что предлагает смотреть на агентов как на пайплайны данных: с декларативной сборкой, аудитом действий и контролем опасных операций. Для команд, которым важны воспроизводимость и наблюдаемость, это может стать заметной альтернативой привычным stateful-подходам.