Своя агентная фабрика ПО: почти полный self-hosted

Когда облако — не вариант

Представьте: вы наняли AI-агента писать код за вас. Он генерирует pull request’ы, запускает CI, деплоит сервисы — круглосуточно, без кофе и sick leave. Звучит как мечта. Но потом вы смотрите на счёт за API, понимаете, что агент только что залил ваш GitHub-токен в сомнительный контейнер, и видите, что GitHub снова лежит.

Именно отсюда вырастает идея агентной фабрики программного обеспечения на собственной инфраструктуре: полный контроль над данными, отсутствие vendor lock-in, предсказуемая стоимость масштабирования — и настоящая изоляция агента от вашей продакшн-среды.

Джейк Сондерс (Jake Saunders) собрал именно такую систему и подробно описал её архитектуру. Разберём каждый слой — от сетевой изоляции до инструментов агента — и поймём, почему «почти» в названии не случайно.

Зачем вообще уходить от облака?

Self-hosted AI-агент-платформы запускают агентов на вашей собственной инфраструктуре, сохраняя данные на оборудовании, которое вы контролируете. Облачные агенты удобны, но требования к конфиденциальности и vendor lock-in делают их неприемлемыми для многих отраслей.

Есть три конкретных барьера, которые толкают команды к self-hosting:

1. Регуляторные ограничения. Для финтех, здравоохранения и госсектора регуляторные требования делают управляемые sandbox-сервисы неприемлемыми: когда агент обрабатывает финансовые данные клиентов или медицинские записи, эти данные не могут покидать ваш VPC без нарушения GDPR, HIPAA или SOC2.

2. Задержки. Real-time AI-приложения не могут позволить себе round-trip до внешних sandbox-сервисов. Когда агенту нужно выполнить код, 200–500 мс сетевой задержки до управляемого API разрушают диалоговый поток. Self-hosting sandbox на той же сети, что и LLM-инференс, снижает задержку выполнения почти до нуля.

3. Стоимость масштабирования. Управляемые провайдеры берут премиум за удобство. На начальных объёмах затраты приемлемы, но при росте до миллионов выполнений кода в месяц наценка становится неустойчивой.

Архитектура: из каких кубиков собрана фабрика

Вся система строится из нескольких слоёв. Вот общая схема потока задачи через фабрику:

graph TD
    A[Задача / Issue] --> B[Hermes — персональный ассистент]
    B --> C[OpenHands — coding agent]
    C --> D[Docker Sandbox — изолированная среда]
    D --> E[Forgejo — self-hosted Git + CI]
    E --> F[Coolify — деплой сервиса]
    F --> G[Pull Request / Живой сервис]
    G --> H[Человек: Review & Merge]
    H --> B

В агентной фабрике поток выглядит так: прояснение требований и сбор контекста → планирование реализации → генерация или модификация кода → валидация изменений → человеческий review → деплой через continuous delivery.

Важный принцип прост: агенты выполняют работу, а люди обеспечивают контрольные точки. Фабрика программного обеспечения — это не про удаление людей из процесса.

Слой 1: Изоляция — sandbox как основа безопасности

Самая критическая и недооцениваемая часть архитектуры.

AI-sandbox требует изоляции, выходящей за рамки стандартных контейнеров, для безопасного выполнения ненадёжного кода. Стандартные Docker-контейнеры используют общее ядро хоста, создавая уязвимости при запуске кода, сгенерированного LLM, который может содержать баги, галлюцинации или prompt-injection атаки.

Почему это не просто теория? Необходимость AI-agent sandbox стала очевидна в первые же дни после того, как Anthropic выпустил Claude Computer Use в публичную бету. Исследователь безопасности Йоханн Ребергер протестировал вредоносную страницу со скрытым prompt-injection пейлоадом: когда Claude зашёл на неё во время обычной задачи, он прочитал пейлоад, скачал бинарник с сервера атакующего, запустил chmod +x, выполнил его и подключился к C2-серверу.

Sandboxing агентов становится отдельной категорией, а не просто функцией фреймворка. Если вы строите агента сегодня, вам нужны: non-root контейнер, фильтрация сетевого egress, read-only монтирования и строгие таймауты для каждой задачи агента.

В случае фабрики Сондерса агент работает внутри Docker-контейнера с жёсткими сетевыми ограничениями. Реализуется default-deny политика egress, чтобы AI-агенты не могли эксфильтровать данные или сканировать внутренние сети. Нужны гранулярные контроли: какие sandbox’ы могут обращаться к внешним API, а какие остаются полностью air-gapped.

Слой 2: Инструменты — что именно запускает агент

Теперь о конкретном стеке, который склеивает систему.

Coolify — самодостаточный PaaS

Coolify — это клей, удерживающий всё вместе: self-hosted PaaS на Docker и Compose, который совершенствуется с каждым обновлением. Если вам нужны удобства Heroku или DigitalOcean App Platform на собственном железе — это лучший выбор.

Coolify поставляется с готовыми рецептами для самых популярных приложений. Postgres, Redis, Hermes, Forgejo и почти всё остальное доступно для деплоя в один клик.

Ключевая магия: агент может создать сервис на любом поддомене, и маршрутизация + SSL настроятся автоматически. Одна и та же конфигурация покрывает весь инструментарий — Coolify, Hermes, Forgejo и Firecrawl живут на собственных локальных поддоменах.

Forgejo — замена GitHub

Почему не GitHub? Передавать боксу GitHub-токен прямо подрывает изоляцию. К тому же это не self-hosted решение, а его API и лимиты CI-минут не рассчитаны на масштаб новой фабрики ПО.

Forgejo — отличная self-hosted альтернатива. Docker Compose файл настраивает Forgejo и его runners; регистрация требует небольших дополнительных шагов, но хорошо задокументирована.

Hermes — мозг агента

Навык Forgejo Hermes даёт агенту полный контроль над инстансом. Hermes — это персональный ассистент в стиле OpenClaw с агентными возможностями.

Firecrawl — веб-доступ агента

Self-hosted Firecrawl даёт агенту значительно более удобный доступ к SERP-данным и веб-скрапингу в масштабе. Это критично, когда агенту нужно проверить документацию, найти примеры кода или изучить API — всё в рамках изолированной сети.

OpenHands — coding agent

OpenHands (ранее OpenDevin) — MIT-лицензированная, опенсорсная AI-платформа для разработки ПО с более чем 68 600 звёздами на GitHub. Она предоставляет автономных coding-агентов, способных редактировать файлы, запускать терминальные команды, просматривать веб и выполнять многошаговые задачи разработки — аналог Devin, но полностью опенсорсный и model-agnostic.

OpenHands заполняет критический пробел: это единственный model-agnostic вариант — пользователи могут запускать его с моделями Nous, DeepSeek, Qwen, Llama, Claude, GPT или даже локальными Ollama-моделями. Он также предоставляет Docker-sandboxed выполнение по умолчанию, multi-agent delegation и встроенную автоматизацию браузера.

Сравнение ключевых компонентов стека

Слой 3: Верификационный цикл и human-in-the-loop

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

Sandbox запускается, клонирует репозитории и уничтожается по завершении сессии. Coding agent выполняет работу внутри этого sandbox. Затем запускаются собственные проверки репозитория, а для пользовательских изменений — реальный браузер. Результат: один PR на каждый изменённый репозиторий с прикреплённым diff и доказательствами. Человек просматривает и мёрджит.

Это и есть «почти» в названии: последний шаг — человеческий review — намеренно оставлен людям. Не потому что агент не может нажать кнопку Merge, а потому что так спроектирована система безопасности.

# Пример Forgejo CI pipeline для агентной задачи
name: Agent Verification
on: [push]

jobs:
  verify:
    runs-on: self-hosted
    container:
      image: agent-sandbox:latest
      options: --network agent-isolated --read-only
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          pip install -r requirements.txt
          pytest --tb=short
      - name: Static analysis
        run: ruff check . && mypy .
      - name: Security scan
        run: bandit -r . -ll

Подводные камни и «почти» в названии

Честность — главное достоинство подхода Сондерса. Система действительно почти полностью self-hosted по нескольким причинам:

LLM-инференс. Если вы не запускаете локальную модель через Ollama или llama.cpp, запросы к Claude/GPT/Gemini всё равно уходят во внешний API. Для полного self-hosting нужна достаточно мощная локальная модель — сегодня это реально с Qwen2.5-Coder или Devstral.

Сложность настройки. Настройка Hermes и Firecrawl с правильными ключами в правильных местах — это серьёзная боль. Это честное признание: self-hosted stack требует значительно больше первоначальных усилий, чем подписка на облачный сервис.

Безопасность контейнеров. В январе 2024 года появился CVE-2024-21626 («Leaky Vessels») в runc, где WORKDIR с /proc/self/fd/ мог эксплуатировать утечки файловых дескрипторов для побега из контейнера. В ноябре 2025 добавились ещё три высокоопасные уязвимости runc с оценкой CVSS около 7+. Это означает регулярные обновления и мониторинг CVE.

Operational overhead. DIY-путь может потребовать 2–3 опытных infrastructure-инженеров, работающих 3–6 месяцев минимум, плюс текущее обслуживание.

Заключение: фабрика, которую вы контролируете

Агентная фабрика ПО на собственной инфраструктуре — это не хобби-проект параноика. Это зрелый архитектурный выбор для команд, которым важны безопасность данных, предсказуемые затраты и независимость от внешних платформ.

Стек Coolify + Forgejo + Hermes + OpenHands + Firecrawl решает реальную инженерную задачу: дать AI-агенту все инструменты разработчика, при этом не выпуская его за пределы контролируемой среды. OpenHands становится предпочтительной платформой для оценки LLM в роли coding-агентов; он MIT-лицензирован и работает с любым LLM — от Claude и OpenAI до опенсорсных Qwen и Devstral.

Главный урок: «почти» — это честно. Полностью замкнутый self-hosted стек с локальным LLM возможен, но требует дополнительных вычислительных ресурсов. Правильный компромисс зависит от ваших требований к безопасности, бюджета и команды.

Начните с одного агента, одного репозитория, одного CI-пайплайна. Поймите, где ваши узкие места. Потом масштабируйте фабрику.