Чему меня научили два месяца с легковесным локальным AI-агентом

openLight вырос из Telegram-бота для Raspberry Pi в легковесный операционный слой для личной инфраструктуры: VPS, Mac mini, Raspberry Pi и других always-on машин. Главный вывод автора — для таких систем полезнее deterministic-first подход, чем автономный AI-агент с широкими правами.

Проект всё ещё остаётся маленьким: Go-бинарь около 25 МБ, один YAML-конфиг и SQLite. Но за два месяца архитектура ушла от простой схемы slash-команда → regex → Ollama к каскаду, где сначала работают slash-команды, aliases, нормализация, rule-based parsing и semantic mapping, а локальная LLM подключается только если детерминированные слои не справились.

openLight управляет сервисами через общий runtime для Telegram-бота и CLI: один registry, router, auth и набор skill’ов. Пользователь может нажать Restart, Logs, Status или Ignore прямо в Telegram-алерте, а под капотом вызывается тот же безопасный skill path, что и при ручной команде, с тем же allowlist, audit и logging path.

Ключевая граница безопасности здесь — skill’ы в Go-коде, а не уверенность модели. LLM выступает классификатором намерения, SQLite хранит watch’и, incidents, history, settings и skill calls, а локальной Qwen 0.5B на Raspberry Pi хватает для routing/classification без облачных моделей.

Коротко

  • openLight позиционируется как операционный слой для personal infrastructure, а не AI-ассистент общего назначения.
  • Маршрутизация стала deterministic-first: LLM вызывается только после slash-команд, aliases, нормализации и rule-based parsing.
  • Telegram-алерты с кнопками используют тот же skill path, что и ручные команды, без отдельного режима автоматизации.
  • Безопасность строится вокруг allowlist и skill’ов в Go-коде: модель выбирает intent, но не получает самостоятельных привилегий.
  • SQLite, один Go-бинарь и локальная Qwen 0.5B оказались достаточны для watch’ей, incidents и классификации команд.

FAQ

Зачем openLight использует Telegram как основной интерфейс для управления домашними серверами и VPS?

Автору важен сценарий быстрого действия с телефона: увидеть alert, нажать Restart, Logs, Status или Ignore и не открывать ноутбук.

Чем deterministic-first routing отличается от обычного AI-agent подхода с tool calling?

Сначала запрос пытаются обработать правилами, aliases и semantic mapping. LLM подключается только как fallback и помогает выбрать intent, а не выполняет произвольные действия.

Почему автор считает skill’ы главной границей безопасности в openLight?

Действие возможно только если оно уже реализовано как skill и прошло allowlist-проверки. Модель не является носителем привилегий и не получает свободный shell.

Читайте также

  1. Самохостный AI-агент на почте, systemd и LLM
  2. Тестируем MVP в 4 раза быстрее: как нейросети изменили жизнь предпринимателей
  3. От RAG-прототипа к агенту в продакшн: путь по метрикам, а не по моде
  4. Память на миллион токенов, а толку ноль: как ИИ-агента спасали от «тупости»
  5. Конец бесплатного кремния: как Google AI Studio превратилась из рая для инженеров в симулятор смены аккаунтов
Ключевые инсайты из новости (по версии ChatGPT)
  • Deterministic-first routing для локальных AI-агентов: Для инфраструктурных команд полезно строить AI-агента так, чтобы LLM была не первым, а последним слоем маршрутизации. Сначала должны отрабатывать slash-команды, aliases, нормализация, rule-based parsing и semantic mapping, а модель подключается только как fallback для выбора intent.
    [AI-агенты и автоматизация инфраструктуры]
Для получения полного доступа оформите подписку PubMag PRO.
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Инсайты автоматически генерируются с помощью искусственного интеллекта на основе текста статьи.
← Назад в лентуЧитать оригинал →
✈️ Подписывайтесь на мой Telegram-канал — там еще больше интересного про AdTech, MarTech, AI и многое другое!