В продолжении вчерашнего поста про идею создать себе AI-ассистента на базе telegram+ n8n…Решил немного поделиться с вами к чему я пришел и где я продолбался.

👏 Скажу сразу у меня получилось собрать MVP. Из плюсов – оно работает и у меня уже есть какой-то базовый ассистент. Я могу в него голосом говорить, фотки документов отправлять (кстати надо добавить туда юриста) через телегу, могу сохранять ссылки, создавать события в календаре, есть финансовый консультант и даже DBA/Sysadmin/Sre и сетевик в одном лице =) И это ОФИГЕТЬ КАК УДОБНО!

Первым делом я выпилил selfhosted supabase (нафиг он нужон то был?!) и воткнул обычный postgres + vector extension. И теперь моей виртуалочке не так больно, а то load avarage в 178 это было жоска. Ну и прикрутил туда cloudbeaver, чтобы в базку ходить и запросики выполнять. Избыточно, но просто давно хотел посмотреть на веб-версию dbveaver.

✍️ Дальше нарисовал схемку бд со слоями памяти:

• conversations (рабочая память) – всё что я говорил и что отвечал ассистент. Используется для контекста текущего и прошлых разговоров. С вектором embedding можно семантически искать релевантные прошлые сообщения.

• user_rules(правила пользователя) – это для оркестратора. Если ассистенту сказали “Запомни, меня надо называть МОЙ ПОВЕЛИТЕЛЬ”, то он будет так обращаться. Еще для примера можно сказать “Запомни, всегда отвечай кратко”. Суть вы поняли – через эту штуку можно корректировать поведение.

• agent_memories(память конкретных агентов) – это отдельный слой, который ты спрашиваешь. Каждый агент (путешественник, финансист, айтишник и т.д.) хранит свои наблюдения о пользователе – например, психолог запомнит "у пользователя тревожность по поводу работы”.

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

☔️ Ну а теперь где я продолбался. И это (барабанная дробь …) single-hop архитектура. Я протупил в самом начале и теперь оркестратор выбирает одного агента и на этом цепочка заканчивается. Таким образом агенты изолированы – ни один из них не может вызвать другого.

Разберем на реальном примере: "Найди когда нам надо на прививку коту и создай запись в календаре". Orchestrator может выбрать только одного. Если выберет Ветеринара – тот ответит датой, но не создаст событие. Если выберет Календарь – у него нет знаний о прививках. А это явно не то что хочется получить в конце.

Система полностью stateless, нет multi-turn диалога. Если я попрошу создать в календаре событие – агент просто это сделает. Он не проверяет, свободно ли 15:00. По хорошему надо добавить (добавить List Events перед Create) и агент должен сказать: "В 15:00 занято, создать всё равно?". Принять следующее сообщение "да" / "нет" / "тогда в 16:00" в контексте этого вопроса и действовать от этого. Что бы это решить надо pending_actions табличку чтобы контекст не терялся. Ну и прикрутить какой то таймаут для контекста.

Короче, получается как в известном меме: “Миша, всё … – давай по новой” (с)

PS И ребят, если вам интересно что в итоге получится – пролайкате пост 😕, мне хочется понять, что небольшой перекос в продуктовые эксперименты вам тоже ок.

---
Telegram | Github | YouTube | Twitter