🎯 О чём этот конспект: Разбор архитектуры кастомной операционной системы компании (Agentic OS), в которой автономные ИИ-агенты заменяют раздутый штат сотрудников. Автор на реальном примере портфеля из четырёх 7-значных SaaS-продуктов показывает переход от простых чатов в Telegram к собственной распределённой платформе оркестрации (OpsLayer), самохостингу инфраструктуры и интеграции агентов прямо в окружение Linux.
👤 Кому будет полезно: Вайбкодерам, техническим фаундерам, инди-хакерам и инженерам, которые хотят масштабировать свой софтверный бизнес за счёт AI-агентов без найма огромной команды и раздувания бюджета на SaaS-подписки.
✨ Что получите: Понимание архитектуры Agentic OS: от связки OpenClaw и кастомного харнеса (OpsLayer) с безопасным вызовом API до развёртывания распределённого кластера вычислений на Hetzner и кастомизации ОС силами самих AI-агентов.
1. Эволюция интерфейса управления агентами: от Telegram к архитектуре Харнеса
Контекст: Начальный этап работы с агентами через мессенджеры вроде Telegram выглядит привлекательно: можно надиктовать голосовое сообщение на прогулке, а бэкенд-агент стянет репозиторий на сервер и продолжит разработку. Однако по мере усложнения бизнес-процессов контекст перестаёт умещаться в один диалог. Сложные задачи занимают часы, передаются между специализированными агентами, спотыкаются о пайплайны проверок и требуют точечных решений человека. В результате Telegram превращается в сплошной поток спама из статусов и логов, в котором невозможно ориентироваться. Для реальной работы компании необходим выделенный оркестратор — интерфейсный и логический слой (Harness).
Тайминг: , , ,
Выгода: Устранение информационного шума, сохранение фокуса фаундера и переход от хаотичных переписок к структурированному трекингу задач с полным контекстом.
Как применить:
- Шаг 1: Разделение ролей агентов — OpenClaw / VPS] — Настройте узкоспециализированных агентов на удалённом сервере: агент-разработчик (занимается Git-репозиториями и dev-окружением), агент инфраструктуры (мониторит логи серверов и аномалии) и саппорт-агент (обрабатывает тикеты клиентов, поднимая историю платежей и чатов).
- Шаг 2: Вынос оркестрации из мессенджера — OpsLayer Architecture] — Спроектируйте уровень оркестрации (Harness), который агрегирует действия агентов: автоматический сбор логов, поиск аккаунта в Stripe и сравнение бага с предыдущими инцидентами до того, как задача попадёт к фаундеру.
- Шаг 3: Построение кроссплатформенного интерфейса — Electron / React Native] — Разверните десктопное (Electron) и мобильное (React Native) приложения для мониторинга: это обеспечивает доступ к управлению компанией из любой точки без использования сторонних мессенджеров.
Результат: Создана централизованная среда, где агенты работают автономно в фоне, передают артефакты между собой и обращаются к человеку только за финальным подтверждением.
2. Архитектура OpsLayer: Внутренняя ОС компании с контролем безопасности (HITL)
Контекст: Доверить ИИ-агентам прямое выполнение действий в боевой инфраструктуре — колоссальный риск утечки секретов и случайной поломки продакшена. Чтобы исключить человеческий фактор при оркестрации и при этом защитить бизнес, строится кастомная система (OpsLayer). Она сочетает в себе базу знаний, трекер задач и шлюз безопасности для внешних инструментов. Самое важное: агенты никогда не получают прямые API-ключи от внешних сервисов (Stripe, GitHub, Cloudflare), а взаимодействуют с внешним миром строго через контролируемые вызовы.
Тайминг: , ,
Выгода: Нулевой риск компрометации API-ключей, сокращение времени фаундера на рутинную оркестрацию и создание базы знаний, которая обучается на прошлых инцидентах.
Как применить:
- Шаг 1: Интеграция базы знаний и трекера — OpsLayer Core] — Создайте внутри платформы Notion-подобную wiki для внутренних стандартов и Linear-подобную канбан-доску, где агенты и люди ставят задачи, проверяют пул-реквесты и передают результаты друг другу.
- Шаг 2: Реализация Human-in-the-Loop (HITL) шлюза для API — Node.js / Go Gateway] — Изолируйте секреты от агентов с помощью проксирующего слоя. Агент лишь формирует JSON-полезную нагрузку для вызова метода, а система запрашивает ручной аппрув:
- Шаг 3: Делегирование разработки системы самим агентам — Self-improving System] — Не пишите код харнеса вручную. Формулируйте новые требования к функционалу системы агентам-кодерам, чтобы они сами расширяли компоненты OpsLayer и разворачивали апдейты.
Результат: Защищённая операционная среда компании, которая ежедневно дорабатывается самими агентами и исключает утечку секретов или несанкционированные финансовые списания.
3. Нативная среда на Linux: Внедрение Omakub (Omachi) и автономная настройка ОС
Контекст: Электрон-приложения и веб-дашборды выполняют свои задачи, но создают барьер между ИИ и рабочим пространством инженера. Использование подготовленного Linux-окружения на базе Arch Linux и тайлового оконного менеджера Hyprland (концепция Omakub / Omachi от DHH) открывает агентам прямой доступ к системным конфигам. Агент получает возможность управлять рабочими столами, горячими клавишами, перенаправлять фокус окон и динамически менять окружение, работая прямо внутри модифицируемой системы без участия человека.
Тайминг: , , ,
Выгода: Мгновенный отклик интерфейса за счёт тайлинга Hyprland, нативная интеграция инструментов разработки и возможность кастомизировать ОС текстовыми промптами через встроенного ИИ-агента.
Как применить:
- Шаг 1: Развёртывание базового окружения — Arch Linux + Hyprland] — Установите стандартизированное dev-окружение (подобное Omakub от DHH), настроенное на управление исключительно с клавиатуры без хаотичного перетаскивания окон мышью.
- Шаг 2: Подключение системного ИИ-агента — CLI / Codex Integration] — Подключите API-ключ или подписку к встроенному агенту операционной системы для управления конфигурационными файлами.
- Шаг 3: Автоматическая адаптация конфигов агентом — Hyprland Config] — Поручите агенту модифицировать правила окон и хоткеи, передав системный промпт:
# Промпт для агента внутри системы:
"Проанализируй текущий файл ~/.config/hypr/hyprland.conf.
Добавь шорткат [SUPER + SHIFT + O] для быстрого вызова OpsLayer.
Настрой правило окна: открывать терминал с логами фоновых агентов
на 3-м воркспейсе в режиме split-right с шириной 35%.
Перезагрузи конфигурацию Hyprland и подтверди статус."Результат: Рабочая станция полностью управляется с клавиатуры и моментально подстраивается агентом под текущие задачи без ручного копания в дотфайлах.
4. Масштабирование без раздувания штата: Собственное приватное облако вычислительных узлов
Контекст: При одновременной работе нескольких агентов-программистов, фоновых демонов и тяжёлых рендеров (Blender, Remotion для видео) ресурсы локальной машины быстро исчерпываются. Локальные очереди задач замедляют работу всей компании. Вместо найма новых людей или покупки дорогих изолированных SaaS-решений масштабирование бизнеса превращается в добавление новых физических или виртуальных серверов (в Hetzner / локальной сети) в единый кластер под управлением центрального управляющего слоя (Control Plane).
Тайминг: , , ,
Выгода: Экономия десятков тысяч долларов на подписках и фонде оплаты труда (ФОТ). Масштабирование мощности компании сводится к стоимости добавления вычислительного узла (Compute Node).
Как применить:
- Шаг 1: Развёртывание Control Plane — Hetzner VPS] — Настройте мастер-сервер на Hetzner, где хранятся контекст компании, общие базы данных, очереди задач и ядро OpsLayer.
- Шаг 2: Создание распределённой частной сети — WireGuard / Tailscale] — Объедините рабочие станции, локальные серверы и облачные VPS в защищённую приватную сеть, исключив публичный доступ к внутренним портам агентов.
- Шаг 3: Назначение ролей новым узлам — Omakub Node Configuration] — Подключите новую машину к сети и зарегистрируйте её в OpsLayer с явной ролью (например, сборка билдов, рендер медиа или выделенный запуск тяжёлых LLM):
node_config:
node_id: "compute-worker-eu-02"
provider: "hetzner-dedicated"
roles:
- "code_compilation"
- "remotion_video_render"
resources:
cpu_cores: 16
ram_gb: 64
gpu: "RTX-4090"
control_plane_endpoint: "https://control.internal.ops/api/v1/heartbeat"
assigned_agents:
- "agent_builder_prod"
- "agent_media_render"- Шаг 4: Серийный запуск компаний — System Inheritance] — При создании нового стартапа не создавайте инфраструктуру с нуля: клонируйте шаблон Agentic OS, подвязывайте вычислительные узлы и сохраняйте ядро из 1–2 человек, управляющих десятками агентов.
Результат: Масштабирование бизнеса без найма линейного персонала: любая нехватка мощности решается подключением дополнительного сервера, который сразу получает роль, рабочий контекст и приступает к задачам.
5. Борьба с прокрастинацией фаундера: Критерии эффективности внутренних инструментов
Контекст: Среди технических фаундеров распространена ловушка «бесконечной оптимизации инструментов»: недели уходят на полировку конфигов, настройку идеального дашборда в Notion или скриптов автоматизации, пока реальный бизнес стоит на месте. С появлением ИИ эта проблема усилилась, так как строить прототипы стало проще. Чтобы разработка Agentic OS не превратилась в самообман и избегание реальных бизнес-задач, внедряется жёсткий фильтр ценности любой внутренней доработки.
Тайминг: , , ,
Выгода: Защита от расфокусировки, сохранение фокуса на выручке и запуск только тех автоматизаций, которые напрямую приносят измеримый результат.
Как применить:
- Шаг 1: Проверка любой фичи по трём критериям — Evaluation Matrix] — Любое изменение операционной системы должно закрывать минимум один (а лучше все три) пункта:
- Объём (Capacity): Позволяет ли система делать физически больше работы за единицу времени?
- Качество (Quality): Делает ли это результат работы агентов качественнее (меньше галлюцинаций, передача контекста без потерь)?
- Удовольствие (Enjoyment): Становится ли ежедневный процесс работы фаундера приятнее и быстрее?
- Шаг 2: Тест на добавленную мощность — Daily Capacity Test] — Считайте доработку успешной только в том случае, если после подключения нового скрипта или сервера агент выдаёт готовые для ревью результаты (код, закрытые тикеты, видеорендеры) в тот же день без ручного вмешательства в процесс.
- Шаг 3: Финальный аудит делегирования — Если агент не может работать без постоянного контроля каждого шага в чате — система не готова. Возвращайте её на доработку харнеса, пока взаимодействие не сведётся к формуле: «Задача поставлена -> Агент выполнил по чек-листу -> Человек утвердил».
Результат: Фаундер инвестирует время только в ту инфраструктуру, которая реально освобождает часы работы и генерирует прибыль, отсекая бесполезное жонглирование конфигами.
Agentic OS на базе Omakub (Omachi) и OpenClaw: ответы на частые вопросы
В: Почему Telegram перестал подходить для управления агентами компании? О: Мессенджер удобен для быстрых голосовых команд на ходу, но непригоден для долгих задач. Когда процессы идут часами, переходят между разными агентами, натыкаются на ошибки тестов и требуют правок, лента Telegram заполняется сотнями сообщений. Теряется контекст, отсутствует наглядный статус задач и нет безопасного способа разделять права доступа к API.
В: Что такое OpsLayer и зачем строить собственный харнес (Harness)? О: Харнес — это программная обвязка вокруг языковых моделей (LLM). OpsLayer выполняет роль корпоративной памяти и интерфейса: передаёт агентам контекст компании, даёт им доступ к базам знаний и таскбордам, а главное — обеспечивает безопасное выполнение действий, перехватывая опасные вызовы API до подтверждения человеком.
В: Каким образом реализована безопасность API-ключей при работе с AI-агентами? О: Агентам не передаются «сырые» ключи от Stripe, серверов или баз данных. Агенты общаются исключительно через внутренний шлюз: они генерируют намерение (intent) и параметры вызова. Человек через интерфейс видит запрос, параметры и обоснование, после чего нажимает кнопку аппрува, и только тогда система отправляет запрос с боевым токеном.
В: Зачем использовать Omakub / Arch Linux вместо обычного веб-приложения или Electron? О: Нативная Linux-среда с тайловым оконным менеджером (Hyprland) работает быстрее, исключает возню с окнами через мышь и позволяет ИИ-агенту управлять системой напрямую. Агент может на лету переписать конфиги системы, хоткеи и правила окон, не выходя из рабочего контекста фаундера.
В: В чём заключается концепция «Private Company Cloud»? О: Вместо раздувания облачных счетов в закрытых экосистемах компания держит управляющий сервер (Control Plane) на собственном сервере (например, Hetzner) и объединяет машины в приватную сеть. Добавление мощностей сводится к установке Agentic OS на новый компьютер/сервер, который подключается к сети и сразу забирает из очереди задачи по своей специализации.
В: Как один фаундер может управлять несколькими SaaS-компаниями параллельно? О: За счёт тиражирования готовой Agentic OS. Новая компания не создаётся с чистого листа с покупкой десятка подписок: она сразу разворачивается внутри уже проверенной кодовой базы OpsLayer со всеми агентами, регламентами и пайплайнами, требуя лишь подключения вычислительных мощностей.
Agentic OS на базе Omakub (Omachi) и OpenClaw: инструменты и ссылки из видео
- OpenClaw — оркестратор и среда для запуска автономных ИИ-агентов — упомянут в видео
- Omakub (назван в видео Omachi / Ultramarine) — стандартизированное рабочее окружение на базе Arch Linux и Hyprland, созданное DHH — упомянут в видео
- Hyprland — динамический тайловый оконный менеджер для Wayland на Linux — упомянут в видео
- 37signals / Basecamp — компания Дэвида Хейнемейера Ханссона (DHH), популяризирующая уход из публичных облаков на собственное железо — упомянут в видео
- Hetzner — провайдер выделенных серверов и VPS для самохостинга инфраструктуры — упомянут в видео
- Remotion — фреймворк для программного создания и рендера видео с помощью React — упомянут в видео
- Blender — открытый пакет для создания 3D-графики и рендеринга — упомянут в видео
Конспект создан на основе видео «I'm Building an Agentic Operating System» канала Simon Høiberg. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=JjjecbwrioA