Как я использую LLM

Как я использую LLM в домашних проектах и инфраструктуре: серверный запуск OpenCode, независимое ревью на MiniMax M3 и собственный AI-агент TaigaClaw для управления self-hosted сетапом.

Серверный OpenCode, отдельная модель на ревью и собственный агент для инфраструктуры — как я развёл LLM по ролям.

У меня есть несколько домашних проектов и небольшая, но разветвлённая домашняя инфраструктура, которая их обслуживает. Времени на всё это хватает только из свободного, а оно — штука непредсказуемая: могу оказаться за основным ноутом дома, могу с телефона в дороге, а могу вообще не рядом со своей техникой. Поэтому для меня LLM — это в первую очередь способ делегировать рутину и держать всё под контролем из каких угодно условий, а не только когда я сижу за привычным рабочим местом. В этом посте — конкретно о том, что и как я использую.

0. Какие модели и где

Базовый набор, на который я опираюсь каждый день:

  • GLM 5.2 — на годовой подписке. Мой основной «думающий» движок для задач, где важен стиль рассуждения и качество текста.
  • MiniMax M3 — вторая рабочая модель. Особенно хорошо показала себя в ревью и в задачах, где нужен «свежий взгляд» со стороны.

Но рынок моделей меняется быстро, и я не хочу привязываться к одной. Поэтому параллельно постоянно тестирую новинки, и для этого развёл два отдельных инструмента:

  • OpenCode GO — использую для теста open-source моделей. Поднимаю локально, подключаю модели, которые можно крутить у себя, и сравниваю их на своих реальных задачах.
  • OpenCode Zen — для теста платных моделей и их свежих версий. Когда выходит очередной Claude, GPT или обновление GLM — прогоняю через Zen на одном и том же наборе задач, чтобы видеть разницу не в маркетинговых бенчмарках, а в живой работе.

Принцип простой: не доверять бенчмаркам провайдера, а мерить на своих сценариях. Я, кстати, оцениваю модели не только как инженер — параллельно пишу книгу, и литературное качество текста для меня такой же критерий, как и умение писать код.

1. Код — OpenCode с серверным запуском

Для написания кода мой основной инструмент — OpenCode, и здесь ключевое решение не «какая модель внутри», а серверный режим запуска.

OpenCode крутится у меня постоянно на сервере (на Mac Studio) через opencode serve, а снаружи доступен через WebUI по HTTPS. Что это даёт на практике:

  • Я ставлю задачу и закрываю ноутбук. Агент продолжает работать на сервере — файлы правит, тесты гоняет, коммитит. Мне не нужно держать открытым терминал или не давать ноуту уснуть.
  • Мониторю с любого устройства. Зашёл с телефона в WebUI, увидел прогресс, подкорректировал задачу, ушёл дальше. Это именно то, что превращает LLM-ассистента из «игрушки на ноуте» в полноценного удалённого разработчика.
  • Задачи не зависят от моего присутствия. Можно вечером сформулировать крупную задачу, поставить на ночь, а утром забрать результат. Серверный контекст живёт сам по себе.

Именно серверный запуск, а не локальный клиент — это, на мой взгляд, самое недооценённое преимущество. Большинство людей пробуют LLM-кодинг в локальном TUI, сталкиваются с тем, что «процесс умер вместе с закрытой крышкой ноутбука», и разочаровываются. У меня этой проблемы просто нет.

2. Code Review — отдельный инструмент и другая модель

Для ревью кода я использую ocr (open code review) — отдельный инструмент, заточенный именно под задачу просмотра диффов и оценки изменений.

И здесь важный нюанс: для ревью я использую MiniMax M3, а не ту же модель, что пишет код.

Это не экономия и не случайность — это осознанный выбор. Когда код пишет одна модель, а ревьюит другая, получается эффект «независимого аудитора»:

  • Модель-автор и модель-ревьюер имеют разные слепые зоны. То, на что автор «замылился» (типичный паттерн, который она считает нормой), ревьюер из другой архитектуры замечает без проблем.
  • Разные модели по-разному взвешивают риски — где одна скажет «и так сойдёт», другая попросит обосновать. В среднем по больнице покрытие потенциальных проблем становится заметно шире.
  • Ревьюер не «привязан» к своему же коду — он не будет защищать то, что только что написал, потому что он этого не писал.

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

3. TaigaClaw — собственный агент для управления инфраструктурой

Третий, и в каком-то смысле главный, кейс — я написал свой AI-агент TaigaClaw. Это self-hosted система на Go, по сути — архитектура промптов и инструментов для AI-ассистента, которую я могу полностью контролировать.

TaigaClaw живёт на моём Debian-сервере, доступен через веб-интерфейс (webchat) и умеет, грубо говоря, всё то, чего не умеют «коробочные» ассистенты, потому что это мои инструменты под мою инфраструктуру.

Что внутри

  • Долговременная память с семантическим поиском. Агент помнит факты, решения, предпочтения между сессиями — не «с нуля» каждый раз, а с привязкой к контексту моих проектов.
  • Knowledge Graph на PostgreSQL. Сущности и связи между ними (серверы, проекты, технологии, люди) хранятся как граф — агент может рассуждать о связях, а не только подбирать слова.
  • Scratchpad — рабочая память на время задачи: промежуточные результаты, план, состояние многошаговых процессов.
  • Сабагенты. Можно делегировать подзадачу отдельному «специалисту» (исследователь, ревьюер, кодер) — каждый со своим контекстом и инструментами.
  • Навыки (skills) — переиспользуемые инструкции в Markdown, которые подгружаются по необходимости. Стандартизируют повторяющиеся операции: деплой, обновление, создание поддоменов.
  • Инструменты: выполнение shell-команд, работа с файлами, веб-поиск и чтение страниц, отправка email, планировщик задач по расписанию (cron + heartbeat).

И главное — для чего я его реально использую: управление домашней инфраструктурой. У меня довольно развесистый сетап:

  • Mac Studio — основной вычислительный узел, на нём крутится OpenCode, Docker-контейнеры (LiteLLM-прокси к моделям, Prometheus-стек мониторинга с Grafana, контейнеры моих проектов, PostgreSQL).
  • Debian-сервер — там живёт сам TaigaClaw.
  • NAS на Synology — хранилище и Gitea для репозиториев.
  • VPS — входная точка снаружи: Nginx-reverse-proxy, DNS, Headscale-координация mesh-сети между всеми узлами.

Всё это связано через Headscale (self-hosted аналог Tailscale), так что агенты и сервисы ходят друг к другу по приватной сети. И именно TaigaClaw этим всем управляет: я могу с телефона написать в веб-чат «проверь, почему упал контейнер X», «обнови LiteLLM до последнего релиза», «создай новый поддомен и настроь HTTPS» — и агент сам подключается по SSH, смотрит логи, выполняет действия, отчитывается. Не нужно держать в голове пароли, IP-адреса и последовательности команд — это знает агент.

По сути, TaigaClaw — это персональный DevOps-инженер, который знает мою инфраструктуру, помнит её историю и никогда не спит.

Итого

Мой сетап из трёх слоёв:

  • OpenCode с серверным запуском — пишет код, работает автономно, монитится с телефона.
  • ocr на MiniMax M3 — независимое ревью того, что написал код.
  • TaigaClaw — собственный агент, который управляет всей инфраструктурой и держит контекст.

Общий принцип, который я для себя сформулировал: не искать «одну лучшую модель», а разводить модели по ролям и всегда иметь серверный контур, который не зависит от того, открыт у меня ноут или нет. И, конечно, доверять, но проверять — разными моделями на разных этапах.