Платформа ИИ-агентов: агенты планируют, пишут и проверяют — слияния и действия на проде утверждает человек
Своя платформа, где ИИ-агенты превращают задачу в проверенный pull request. Независимая модель-ревьюер (LLM-судья) держит качество, приватный RAG даёт агентам память проектов, действия на проде проходят через утверждение человеком.
~40сервисов на одном сервере (масштаб, не оценка качества)
27Bлокальная модель на одной видеокарте, ~80 ток/с после A/B
PR onlyИзменения попадают в main только через pull request с оценкой судьи; действия на проде — через карточки подтверждения
Разработка с ИИ-агентами под контролем: независимая проверка и решение человека
Задача
ИИ-помощник в чате пишет код быстро, но без памяти о проекте, без независимой проверки и без журнала; нужен процесс, которому можно доверить рабочие системы.
Сделал
Собрал свою платформу: агенты планируют и пишут код, отдельная модель-проверяющий оценивает результат, в основную ветку изменение попадает только через запрос на слияние, который принимаю я; действия на рабочих серверах — только после моего подтверждения.
Стало
Это моя ежедневная рабочая среда для рабочих проектов.
Контекст и масштаб
Моя ежедневная рабочая среда с 2025 года для клиентских и собственных проектов. Работает на одном домашнем сервере с RTX 3090 Ti плюс облачные модели.
Задача
ИИ-кодинг в чате быстрый, но ненадёжный: нет памяти между проектами, нет независимой проверки, нет журнала, а чувствительный код уходит в облако.
Анализ и альтернативы
Только облачные агенты (быстро, но код и данные уходят за периметр) или только локальные модели (приватно, но слабее на сложном). Выбрано: гибрид — локальная модель для рутины, облачные для настройки и сложных задач.
Архитектура
Люди
Владелец / ревьюер
Система
Пульт и API ядраPython · MCP
Исполнители агентовplanner · coder · judge
Приватный RAGPostgreSQL · pgvector · bge-m3
Локальная LLMllama.cpp · Qwen 27B · RTX 3090 Ti
Git-сервер и CIForgejo · protected main
Внешние системы
Облачные LLM
Telegram (утверждения)
Основные потоки данных
Задача → планировщик (с контекстом проекта из RAG) → кодер → тесты → оценка судьи → pull request.
По правилу проекта main меняется только через pull request, которые сливает владелец.
Действия на боевых серверах запрашиваются карточками и выполняются только после подтверждения владельцем.
Ключевые решения и компромиссы
Судья отдельно от автора. Работу проверяет другая модель в отдельном контексте; пороги фиксируются до прогона и не подгоняются под результат.
Модель меняется только после A/B. Перед сменой локальной модели сравниваю скорость, знания и агентные задачи; последняя смена дала ~80 против ~43 ток/с и 29/30 на наборе знаний.
Чинить инструкции, а не сессии. Ошибка агента превращается в правило в инструкциях проекта или в навыке, чтобы следующий запуск её не повторил.
Что сделано
Роли агентов, архитектурные решения в ADR; handoff-файлы, чтобы работа переживала лимиты контекста.
Pull request в собственном Forgejo; тесты и оценка судьи до ревью человеком.
Приватный RAG по всем проектам, MCP-инструменты ядра платформы, утверждения и уведомления в Telegram.
Результат
Один человек может делать работу масштаба платформы через агентный процесс: pull request с оценкой судьи, утверждение человеком слияний и действий на проде.
Что сделал бы иначе
Однажды два агента в одном репозитории одновременно перезаписали файлы друг друга; теперь параллельная работа идёт в отдельных ветках или worktree.