Расскажите о себе и сути проекта?

Я делаю декларативный AI framework для создания AI агентов. Сейчас с появлением ллмок как грибы после дождя стали появляться AI агенты, пока сыроватенькие, но очень быстро становятся все лучше и лучше.
Я хочу стандартизировать подход к их разработке - определить манифесты как кубернетесе, которые бы определяли компоненты декларативно, вне зависимости от языка, чтобы описать схему работы агента и дальше уже делать реализацию.

То есть агент представляет из себя граф, а компоненты его описываются в yaml (как, например, kind: Deployment в k8s) с кастомным CE DSL, который определяет логику перехода по этому графу. Итого не нужно писать зубодробительные conditional edges
Ну там еще разные фишки есть
Вот тут мой интро блог - https://www.liman-ai.dev/blog/2025-07-30_intro, но я рекомендую сначала этот пост почитать - в блоге все такие англицкие буквы и суховато

Как появилась идея? Что вдохновило?

Последнее время я делал AI агентов, и из раза в раз приходилось одно и то же. Изначально я выносил просто промпты в yaml, потом добавлял свою абстракцию.
В основном я писал без какого-то фреймворка, либо с LangGraph (python). Но мне очень не понравилось как такие решения поддерживать и отсутствие некого стандарта. И я о нем думал последний год, наблюдая что происходит на рынке.
Весной ко мне пришел один заказчик, который захотел сделать AI чат для своего бека (админки), чтобы менеджеры могли писать, что они хотят, а агент делал - мол "включи этому пользователю такую-то настроку". Вместо кликания по UI. В итоге в рамках реализации я подумал - ну вот OpenAPI спецификация есть, почему из коробки ее не пропарсить и не сделать нужные tools, которые потом скормить LLMке. По-моему киллер-фича, подключаешь апи бекенда за пару часов.
Тут я написал пост об этом в деталях как это работает сейчас в Лимане - https://www.liman-ai.dev/blog/2025-08-17_simple_openapi

Что вошло в прототип и сколько времени на него было потрачено?

Начал я где-то в середине июня, ну лето работаю над этим. Смотрел на проект по темпу более оптимистично. На самом деле делать фреймворки оказалось крайне тяжело, потому что нет понимания, что ты хочешь получить в итоге. То есть полет фантазии максимальный, и это проблема. В бизнесе есть четкая цель, во фрейморке, в начале, ее нет. Ты пытаешься увидеть абстракцию в тумане фантазий. Это сильно замедлило, например Executor (сущность, которая обходит граф) я раза 3 передизайнивал

Сейчас в прототипе есть:

• Поддержка yaml деклараций, она парсится и создается новая нода или компонент
• Multilanguage поддержка для промптов из коробки
• Интеграция с OpenAPI - спецификация парсится, из нее создается Liman ToolNode спецификация, которая в свою очередь через jsonschema отдается в ллмку
• Частично интегрирован Otel (метрики и трейсы)
• Сделан дизайн аутентификации и частично реализован. Когда нода исполняется, она исполняется node actor'ом, который действует как некий service account с лимитированным скоупом, и он может запрашивать нужные credentials (behind the hood)
• CE DSL, возможность в yaml описывать условия, которые обсчитываются в рантайме - для определения следующих нод, или подходящего service account'а, и тд
• Создан дизайн Plugin системы, я хочу расширять манифесты через систему плагинов, дабы добавлять новые спеки, или расширять предыдущие. Например auth так и сделана, сейчас делаю MCP плагин. Аля k8s CRD
• Создан Executor, такая умная штука, которая умеет обходить граф, позволяет форкаться и параллельно выполнять тулы, суспендиться, и возобновлять работу, когда получает контроль обратно. Но я задумал несколько слоев фрейморка, подразумевается, что если нужна большая гибкость, то можно по своему делать. Сейчас Execution Model выглядит пока так:

Agent(stateless) -> Executor(stateful) -> NodeActor(stateful) -> Node(stateless)
немножко устаревшую штуку вы можете прочитать тут
https://www.liman-ai.dev/docs/poc#execution-model

Какой технологический стек вы использовали? Почему?

Я начал с питона и го, но потом го забросил и начал питонить. Моя идея была стандартизировать манифесты, а уже реализацию делать под разные языки - language agnostic, типа OpenAPI sdk. Изначально была идея оборачивать манифесты в protobuf и использовать их в разных языках, но я отказался от этой идеи из-за неудобства и сложности.
Питон я выбрал как базовый основной язык всех AI фреймворков, а GO - что нет конкурентов, а язык очень популярен в бекенде
В итоге сейчас основная реализация на python 3.10+, Pydantic, LangChain
Перевожу существующую кодовую базу на Typescript, там я для парсинга манифестов использую zod. Планирую к концу недели и typescript поддержать
Дальше буду смотреть, в планах Go и Java

Как вы запускались и искали первых пользователей?

Ну запуска особо еще и не было, потому что проект в ранней альфе, но я о нем начал рассказывать (например, вам))
Вообще я в маркетинг очень не очень, но прокачиваюсь, стараюсь
Я сделал два поста в период 3 недели на HN (просто ссылку), но внимания получил мало. Особенно меня расстроило, что не залетел блог пост про OpenAPI интеграцию
Опубликовал блог посты на ликендине, завел твитер - пока шатко валко.
Очень нужна обратная связь, adoption, кто-нибудь может посоветовать, как продвигать такие шткуи?

С какими самыми неожиданными трудностями пришлось столкнуться?

Я уже упоминал - это переписывание дизайна
Хочется чтобы было хорошо, а чтобы нехорошо не было. Это все ограничения. С такими ограничениями очень туго останавливать полет фантазии и приземляться
Ну и маркетинг, я человек непубличный, и мне некомфортно как-то о чем-то рассказывать, хочется чтоб само) но так не работает)

Сколько потратили и заработали? Есть идеи как это можно монетизировать?

Заработал ноль, потратил тоже ноль (только время)
Одна из целей, которую я хочу достичь с появлением стандарта - это создать маркетплейс агентов, или package manager, как угодно. То есть агенты можно будет дистрибутировать и подключать. И одна из моделей монитизации - это SaaS Cloud, где этот агент можно в клик запустить и подключить к своему сервису, такой серверлесс для агентов. Напрмер в supabase у тебя создается база, прокидывается тебе API, ты просто его подключаешь - а он работает, а создателю агента можно отдавать процент как в Apify за парсинг

Какие планы на будущее?

Надо сначала альфа зарелизить и побольше кейсов написать
Потом сделать liman.cloud с подборкой разных агентов на базе лиман.
Типа https://www.aitmpl.com/, только более code-first и production ready. Там я буду их сам в начале писать.
Из фич - надо подключить MCP, A2A, доработать авторизацию и стейт менеджмент
Зааплаиться в YC, написать знакомым скаутам из секвои и a16z, попробовать зарейзить. Но сначала нужен трекшн, кейсы, одобрение комьюнити

Нужны ли какие-то советы или помощь Клуба?

Было бы полезно послушать мнение, что думаете о проекте. Так же чтобы поделились своим опытом, проблемами, с которыми вы сталкивались, когда делали AI агентов.
Очень полезны будут маркетинг советы, потому что я тут ни бумбум - где листить, на чем акцент и тд. Мне кажется, что мой блог пост последний не залетел на HN, потому что я его сделал слишком техническим, а на Линкедине вообще в воскресенье запостил и в итоге получил в 2 раза меньше просмотров . Короче учусь на своих ошибках, но если подскажите как научиться быстрее - буду благодарен. Например, какие комьюинити на реддите мне стоит посмотреть, кто в теме?

Какой совет вы бы сами могли дать идущим по вашим стопам?

Никогда не опускайте руки - будет еще множество моментов, когда захочется опустить руки, а они уже буду опущены!
Ну а серьезно - just do it, коммуникация - это ключ, вылазьте из норки (хотя это я себе говорю)
Проекте никогда не будет окончательно готов (если не умер)

P.S.
Какой же кайф писать пост на русском языке.. Усилий ноль, одно удовольствие)
И спасибо Вастрику за шаблон поста, очень помогает структурировать мысли в что-то читаемое
Кстати, кто полностью прочитает, дайте фидбек по тексту, дабы следующие я писал лучше - вроде бы длинновато, ощущение