Abstract
ИИ секретарь должен представлять функционал реального секретаря.
Примерный список его возможностей:
-
Ведение заметок через обычную коммуникацию
-
Планирование мероприятий
-
Напоминания
-
Управление списком дел и туду листами
Architecture:
ИИ секретарь будет строится на модульной архитектуре. По-факту он представляет собой обычного ии агента с возможностью подключать и настраивать определенные модули. Некоторые модули могут зависеть от других модулей. Так например модуль связанный с календарем может зависеть от модуля памяти, а модуль для синхронизации с Google Calendar будет зависеть от модуля календаря
Module API design
Есть два пути.
Первый – все модули пишутся на расте.
Плюсы такого подхода: простота разработки апи и его идиоматичность.
Минусы: все модули должны быть жестко прописаны на этапе компиляции проекта, нет возможности динамически загружать плагины
Второй – сделать rust независимое апи. Например используя скриптовый язык, но лучше сделав кросс-яызыковый api. Например через web-хуки и http запросы, ну или для ускорения api использовать свой межпроцессный протокол
Есть один истинный путь
Модули не являются частью ядра ИИ-секретаря. Они запускаются как отдельные процессы и работают в формате микросервисов. Ядро здесь выполняет роль шины для обмена данными и гейта к нейросети.
Общение между модулями идет через специальное Module API на базе gRPC. У такого подхода есть несколько значимых плюсов:
-
Языковая независимость: писать модули можно на чем угодно, хотя в приоритете, конечно, Святой Rust.
-
Масштабируемость: в теории это позволит разносить модули по разным серверам.
-
Отказоустойчивость: если один модуль упадет или запаникует (АААА RUST КОД В ПАНИКЕ ААААА), система выживет - ядро просто перезапустит упавший процесс.
Память в этой архитектуре также вынесена в отдельный модуль.