Мне тут идея пришла в ходе новостей начала 2026 года, очень много появилось опен-сорс решений которые позволяют вести локальные разработки и быть просто помощниками в любую минуту - что захотелось создать что-то своё, родное, работающее.

Настольные AI-агенты с графическим интерфейсом

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

Что есть на рынке

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

• https://github.com/different-ai/openwork
• https://github.com/accomplish-ai/openwork
• https://github.com/ComposioHQ/open-claude-cowork
• https://github.com/DevAgentForge/Claude-Cowork
• https://github.com/openkursar/hello-halo
• https://github.com/vakovalskii/LocalDesk/
• https://github.com/block/goose
• https://github.com/Codeblockz/localwork-hero
• https://github.com/OpenAgentPlatform/Dive

Общий функционал

Настольное приложение

• Нативное десктопное приложение (Electron, Tauri)
• Кроссплатформенность (Windows, macOS, Linux)

Чат-интерфейс

• Текстовый ввод сообщений
• Стриминг ответов (по токенам)
• История диалогов (сессии)
• Множественные чат-сессии

Инструменты (Tools)

Все проекты поддерживают вызов инструментов (function calling):

• Файловые операции: чтение, запись, поиск, редактирование файлов
• Выполнение команд: shell команды, терминал
• Веб-инструменты: поиск, чтение страниц, рендеринг JS-страниц
• Код-исполнение: безопасное выполнение JavaScript/WASM
• Управление задачами: todo-списки, планирование

🤖 AI-интеграции

• Поддержка множества провайдеров (OpenAI, Anthropic, Ollama, локальные модели)
• Возможность использовать свои API ключи
• Поддержка локальных моделей (vLLM, Ollama, llama.cpp)
• Переключение между моделями в интерфейсе

🔐 Безопасность

• Пользовательское одобрение перед выполнением опасных операций
• Песочницы для файловых операций
• Лимитирование доступа к файловой системе

📊 Визуализация

• Отображение прогресса выполнения задач
• Визуализация вызова инструментов (вход/выход)
• Предпросмотр создаваемых файлов
• Дашборды и панели управления

Сильные стороны каждого проекта

Чего бы хотел я в новом продукте

Почему новый? Потому что все описанное выше не подходит под мою задуманную архитектуру, если не заложить что-то в начале - то потом вы хрен когда к этому подойдете

Требования проекта — Desktop AI Assistant с Task Scheduler

🏗️ АРХИТЕКТУРА

Режим работы

Server+Client (Standalone) — полный стек локально на одной машине. Backend API + GUI вместе. Единственный режим на старте.

Технологический стек

Архитектурные компоненты

┌────────────────────────────────────────────────────────────┐
│                    ELECTRON FRONTEND                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │  Chat UI │  │ Planner  │  │  Diff UI │  │  Pipeline│    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
└───────┼─────────────┼─────────────┼─────────────┼──────────┘
        │ Socket.IO   │             │             │
        ▼             ▼             ▼             ▼
┌────────────────────────────────────────────────────────────┐
│                   BACKEND API (Hono)                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │          HTTP Routes + Socket.IO Handler            │   │
│  └─────────────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌────────────────────────────────────────────────────────────┐
│                    TASK SCHEDULER (BullMQ)                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │   Queue  │  │  Worker  │  │  Events  │  │   Retry  │    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
└───────┼─────────────┼─────────────┼─────────────┼──────────┘
        │             │             │             │
        ▼             ▼             ▼             ▼
┌────────────────────────────────────────────────────────────┐
│                     TASK EXECUTION LAYER                   │
│  ┌──────────────────────────────────────────────────────┐  │
│  │                    AGENT SYSTEM                      │  │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  │  │
│  │  │ Coding  │  │Research │  │ Planning│  │Summary  │  │  │
│  │  │  Agent  │  │  Agent  │  │  Agent  │  │  Agent  │  │  │
│  │  └─────────┘  └─────────┘  └─────────┘  └─────────┘  │  │
│  └──────────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────────┐  │
│  │                  SESSION MANAGER                     │  │
│  │  - Сессии изолированы                                │  │
│  │  - Под-сессии создаются динамически                  │  │
│  │  - Контекст сохраняется                              │  │
│  └──────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────┘
        │            │            │            │
        ▼            ▼            ▼            ▼
┌────────────────────────────────────────────────────────────┐
│                    INTEGRATION LAYER                       │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌────────────┐     │
│  │   LLM   │  │   MCP   │  │  Tools  │  │  Index     │     │
│  │Provider │  │Servers  │  │Executor │  │  Engine    │     │
│  │         │  │         │  │         │  │(flexsearch)│     │
│  └─────────┘  └─────────┘  └─────────┘  └────────────┘     │
└────────────────────────────────────────────────────────────┘

⚡ ФУНКЦИОНАЛ

1. ПЛАНИРОВЩИК ЗАДАЧ (CORE SYSTEM)

2. ЧАТ-СИСТЕМА

3. СИСТЕМА СЕССИЙ

4. AGENT СИСТЕМА

5. ФАЙЛОВЫЕ ОПЕРАЦИИ

6. ПАЙПЛАЙНЫ РАЗРАБОТКИ

7. ЛОГИРОВАНИЕ ОШИБОК

8. ВЕБ-ИНСТРУМЕНТЫ

9. LLM ИНТЕГРАЦИИ

10. MCP ИНТЕГРАЦИИ

11. ПРОФИЛИ И НАСТРОЙКИ

12. ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ

ФУНКЦИИ - зачем и почему

1. Backend API — Hono

Что: Фреймворк для REST API и WebSocket сервера.

Зачем: Быстрый и простой API сервер для связи между Electron frontend и backend логикой.

Как сделать: Использовать Hono — минималистичный, быстрый, TypeScript-friendly фреймворк с маленьким размером.

2. Task Scheduler — BullMQ

Что: Готовое решение для планирования и выполнения задач.

Зачем: Не изобретать велосипед — уже решены очереди, приоритеты, повторы, события.

Как сделать: BullMQ на базе Redis или in-memory очереди для локального режима. Поддерживает приоритеты, зависимости, повторы, события.

3. WebSocket — Socket.IO

Что: Дизайн WebSocket соединения для реального времени.

Зачем: Двусторонняя связь для стриминга ответов, событий задач, уведомлений.

Как сделать: Использовать Socket.IO для автоматического управления подключениями, комнатами, фоллбэком.

4. Task Schema and Validation — Zod

Что: Схема задачи и валидация параметров.

Зачем: Структурированное хранение задач, проверка корректности данных, типизация.

Как сделать: Определить TypeScript интерфейс для задачи. Использовать Zod для валидации.

5. Task Dependency Graph

Что: Граф зависимостей между задачами.

Зачем: Выполнение задач в правильном порядке, определение параллельных задач.

Как сделать: Использовать dependencies: string[] массив с ID родительских задач. Планировщик проверяет завершение всех зависимостей перед запуском задачи.

6. Task Stop/Cancellation Mechanism

Что: Механизм остановки и отмены задач.

Зачем: Кнопка “Стоп” должна корректно останавливать все задачи сессии.

Как сделать: Добавить флаг stopped: boolean в сессию. Планировщик проверяет флаг перед запуском новых задач. Выполняющиеся задачи получают событие stop через EventEmitter.

7. Task Result Aggregation

Что: Агрегация результатов от множества задач.

Зачем: Когда параллельные задачи завершены — нужно собрать их результаты для финальной задачи.

Как сделать: Задача-агрегатор ожидает завершения всех зависимых задач, считывает их результаты из базы, объединяет и передаёт финальному агенту.

8. Parallel Questioning System

Что: Система параллельного задания вопросов пользователю.

Зачем: Пока агент работает, пользователь должен иметь возможность отвечать на уточняющие вопросы параллельно.

Как сделать: Создавать отдельный тип задачи question с options: string[]. Отправлять через Socket.IO как событие session:question. UI отображает список вопросов. Ответы сохраняются и используются агентами.

9. Diff Storage and Display

Что: Хранение и отображение diff файлов.

Зачем: После сессии пользователь должен видеть все изменения и иметь возможность откатить.

Как сделать: При каждом изменении файла создавать запись {sessionId, filePath, before, after, timestamp}. Использовать библиотеку diff для отображения изменений в UI.

10. Session State Machine

Что: Машина состояний для сессии.

Зачем: Отслеживание жизненного цикла сессии.

Как сделать: Использовать паттерн State Machine с состояниями: idle, running, paused, stopped, completed. Переходы управляются событиями.

11. Task Priority System

Что: Приоритеты задач.

Зачем: Критически важные задачи выполняются первыми, менее важные — позже.

Как сделать: Приоритет шкала 1-3, где 1 — высокий, 2 — средний, 3 — низкий. По умолчанию 3. Планировщик сортирует задачи по приоритету.

12. Task Timeout and Retry

Что: Таймауты и повторы для задач.

Зачем: Задачи не висят вечно, при сбоях — повторная попытка.

Как сделать: Пользователь настраивает timeout: number и retryCount: number. Планировщик отменяет задачу по таймауту. При ошибке — создаёт новую задачу с retryCount + 1 (до лимита).

13. Task Context Passing

Что: Передача контекста между задачами.

Зачем: Подзадачи должны иметь доступ к результатам родительских задач.

Как сделать: Добавить context: any в задачу. Планировщик копирует контекст родительской задачи в дочерние. Результаты задач добавляются в контекст.

14. File Watching and Hooks

Что: Наблюдение за файлами и хуки при изменениях.

Зачем: Автоматические действия при изменении файлов.

Как сделать: Использовать chokidar для наблюдения. Хуки конфигурируются пользователем. При изменении → создаётся задача хука.

15. Recent Folders List

Что: Список прошлых открываемых папок.

Зачем: Быстрый доступ к недавним проектам.

Как сделать: Хранить список путей в настройках пользователя. Отображать в UI при создании чата.

16. Project Indexing Strategy — flexsearch

Что: Стратегия индексирования файлов проекта.

Зачем: Быстрый поиск без полного сканирования каждый раз. LLM может ставить задачи для поиска.

Как сделать: Использовать flexsearch для полнотекстового поиска. Индекс обновляется при изменении файлов. LLM создаёт задачу поиска → flexsearch находит → возвращает результат → LLM продолжает.

17. LLM Context Management

Что: Управление контекстом LLM.

Зачем: Контекст ограничен, нужно эффективно его использовать.

Как сделать: Система сжатия контекста, ранжирование по релевантности, удаление устаревших сообщений.

18. Agent Communication Protocol

Что: Протокол коммуникации между агентами.

Зачем: Агенты должны понимать друг друга и координировать действия.

Как сделать: Стандартизировать формат сообщений между агентами через задачи: {from, to, type, payload, timestamp}.

19. Configuration Management

Что: Управление конфигурациями приложения.

Зачем: Разные профили (global, user, workspace), разные настройки для разных папок. Подготовка к будущему remote режиму.

Как сделать: Хранить конфиги в JSON файлах с иерархией: global > user > workspace. API для чтения/записи.

20. Database Schema Design

Что: Схема базы данных SQLite.

Зачем: Чёткая структура для хранения сессий, задач, профилей, логов.

Как сделать: Спроектировать таблицы: sessions, tasks, files, diffs, logs, settings. Использовать миграции.

21. Task Visualization

Что: Визуализация дерева задач.

Зачем: Пользователь видит что происходит, какие задачи выполняются, их зависимости.

Как сделать: Использовать библиотеку dagre или react-flow для отрисовки графа задач в UI.

22. Task Execution History (Debug Mode)

Что: История выполнения задач в debug режиме.

Зачем: Отладка, анализ производительности, повторное использование.

Как сделать: При включённом debug режиме сохранять логи выполнения каждой задачи: {taskId, startTime, endTime, duration, steps, logs}.

26. Auto-save for Work

Что: Автосохранение работы.

Зачем: Не потерять данные при краше.

Как сделать: Периодическое сохранение состояния сессии в базу каждые N секунд или после каждой задачи.

27. Task Caching

Что: Кеширование результатов задач.

Зачем: Избегать повторного выполнения одинаковых задач.

Как сделать: Хеш параметров задачи → результат. Проверять кеш перед выполнением.

28. Performance Monitoring (Debug Mode)

Что: Лёгкий мониторинг производительности в debug режиме.

Зачем: Определение bottleneck-ов, оптимизация.

Как сделать: При включённом debug режиме собирать метрики: время выполнения задач, размер ответов, использование памяти. Простые графики в UI.

29. Error Recovery Logging

Что: Логирование стратегий восстановления после ошибок.

Зачем: Анализ ошибок, определение проблемных мест.

Как сделать: Сохранять попытки восстановления и их результаты в логах для последующего анализа.

30. User Feedback Collection — Issues

Что: Ссылка на GitHub Issues для обратной связи.

Зачем: Понять что нравится/не нравится, улучшать продукт.

Как сделать: Добавить в меню ссылку на репозиторий для создания issues.