Агентная ОС на Claude Code за 3 шага

Шаг 1. Мозг

Сначала памяти нужна форма. Просто свалить файлы в папку мало: агент захлебнётся, листая сотни разрозненных заметок без понимания, как они связаны. Связка Graphify + Obsidian решает это. Obsidian держит твои заметки как обычный Markdown на диске, а Graphify сшивает их в граф: узлы и связи между ними. Claude ходит по этому графу как по карте города, а не как по случайной стопке бумаг.

Зачем именно граф, а не плоская папка. Граф хранит не только что записано, но и как одно относится к другому: проект тянет за собой клиента, клиент тянет встречи, встречи тянут решения. Агент видит контекст целиком и достаёт ровно то, что нужно под задачу, вместо того чтобы перечитывать всё подряд.

Главное здесь — никакой отдельной базы данных поднимать не нужно. Граф лежит локально, рядом с твоими заметками, в обычных файлах. Это и есть мозг ОС: память, по которой агент ориентируется. Поднял Obsidian, накидал заметки, прогнал Graphify — мозг готов, дальше его подхватит сборка.

Шаг 2. Сборка

Мозг есть, теперь нужна оболочка. Агент-фреймворк по команде собирает дашборд-ОС с аналитикой, подключённой к твоим данным. Ты не пишешь интерфейс руками: задаёшь, что хочешь видеть, фреймворк генерит панель и выводит метрики. Дальше схема простая: ты смотришь, он отгружает.

Работа идёт командами. Три базовых, которых хватает на сборку рабочего центра:

/init    развернуть каркас ОС и подтянуть граф памяти из Шага 1
/plan    описать дашборд: какие метрики, источники и виджеты нужны
/apply   собрать интерфейс и подключить его к твоим данным

/init разворачивает каркас и цепляет память из Шага 1: с этого момента агент уже знает твой контекст. /plan — это бриф. Перечисляешь, какие данные и метрики нужны на панели: финансы, задачи, почта, проекты, что угодно. Фреймворк показывает план дашборда до того, как что-то собрать, чтобы ты поправил его на словах, а не разгребал готовый интерфейс.

/apply собирает дашборд и подключает его к источникам через MCP-серверы. После этого центр живой: данные подтягиваются сами, метрики обновляются, ты только наблюдаешь и правишь то, что хочешь поменять, той же командой /plan → /apply. Захотел новый виджет — описал, применил, готово. Никакого кода между тобой и результатом.

Шаг 3. Запуск 24/7

ОС собрана. Осталось решить, где она живёт. Тут развилка из двух путей, и оба рабочие: разница только в том, нужна ли тебе круглосуточная работа без включённого ноутбука.

Локальный запуск — это быстрый старт без лишних настроек: одна команда, и центр работает на твоей машине. Когда нужна непрерывная работа, отправляешь код в GitHub и поднимаешь на Railway. Центр становится доступен 24/7 и принимает задачи в любое время, даже когда ноутбук закрыт.

# Локально — быстрый старт на своей машине
npm run os

# 24/7 — деплой в облако
git push                 # отправить ОС в GitHub
railway up               # поднять сервис на Railway
# центр работает круглосуточно, ноутбук можно закрыть

Удобный гибрид: разрабатываешь и тестируешь локально, а как только всё устаканилось — пушишь в облако и забываешь. Та же ОС, тот же граф памяти, просто теперь она не зависит от того, включён ли твой компьютер.

Бонус: клонируй под клиента

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

• clone — копируешь репозиторий ОС под нового клиента.
• ключи — вставляешь его ключи и доступы в .env: почта, банк, задачи, что нужно подключить.
• run — запускаешь, и у клиента свой командный центр со своим графом памяти.

git clone <repo> client-acme        # копия ОС под клиента
cd client-acme
cp .env.example .env                # вставить ключи клиента
railway up                          # развернуть его центр

Под каждого клиента форкаешь отдельную копию: своя память, свои данные, свой дашборд, всё изолировано. Один скелет — сколько угодно развёрнутых центров. Меняется только содержимое .env и граф памяти, код остаётся тем же. Так личный проект превращается в повторяемую услугу.

Чеклист и грабли

Прежде чем считать ОС готовой, прогони её по короткому чеклисту:

• Граф памяти подтянулся. Спроси агента что-то из своих заметок и сверь ответ с фактами. Если выдумывает — память не подключилась.
• Дашборд тянет живые данные. Метрики должны меняться сами, а не быть зашитыми заглушками.
• Доступы ограничены. Агент видит только то, что ты разрешил в .env, а не весь диск.
• 24/7-копия пережила перезапуск. Перезапусти сервис на Railway и проверь, что память и задачи на месте.

И типичные грабли, на которых спотыкаются чаще всего:

• Свалка вместо графа. Сотни заметок без связей — агент тонет. Сначала структура в Obsidian, потом Graphify, потом сборка.
• Полный доступ агенту «чтобы не возиться». Был реальный случай, когда агент снёс кодовую базу. Давай ровно те права, что нужны под задачу.
• Ключи в репозитории. .env в .gitignore, иначе доступы клиента уедут в публичный GitHub вместе с пушем.
• Локально и забыл. Если центр нужен круглосуточно, а живёт на ноутбуке — он встанет, как только ты закроешь крышку. Для 24/7 нужен облачный путь.

Кейсы из сообщества

Это не теория. Люди уже собирают такие ОС на Claude Code и выкладывают результаты. Три реальных кейса, каждый закрывает один из шагов гайда.

Ресурсы и ссылки

Все инструменты из гайда — официальные ссылки и репозитории: