techmeat.dev

Как я разрабатывал OpenSecondBrain

· · 8 мин чтения

Я уже давно и активно пользуюсь разными AI-инструментами, но в какой-то момент стало понятно: я не просто пользуюсь ими, а почти полностью “обмазался” агентами и всем, что связано с AI.

Несколько месяцев агенты пишут мне код по моим workflow: планирование, реализация, ревью, исправления, повторная проверка. Это работает, но у процесса есть странный ручной хвост. Даже когда код пишет агент, мне всё равно приходится двигать задачи между стадиями, переносить контекст, напоминать правила, запускать проверки и следить, чтобы следующий исполнитель понимал, что уже произошло.

Повторяемой работы стало слишком много. Поэтому следующим естественным шагом была не ещё одна фича, а автоматизация самого workflow.

Так появился проект OpenSecondBrain - попытка дать агентам нормальную память о том, что мы делаем, почему мы это делаем и какие решения уже приняты.

От ручных workflow к Dark Fabric

В первом посте я писал, как запускал этот блог с помощью кодинг-агентов. Там workflow был намеренно простой: задать контекст, собрать Astro-проект, пройти дизайн, добавить постеры, проверить результат.

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

Мне хотелось прийти к более жёсткой модели, которая всё чаще звучит как Dark Fabric: на вход подаётся идея фичи, на выходе - фича реализована, протестирована и задеплоена. Не «агент написал кусок кода», а фабрика, которая умеет сама разложить работу на стадии и провести её через процесс.

До полноценной Dark Fabric ещё далеко. Но первый практический шаг уже есть: Hermes, поднятый на VPS, с агентами под разные задачи, скиллами, Telegram-интерфейсом и дешёвой маршрутизацией моделей через OmniRoute.

И почти сразу обнаружилась вторая обязательная часть этой фабрики: агентам нужна память.

Зачем агенту Second Brain

Если агент работает одну сессию, можно просто положить ему контекст в промпт. Если агент работает над проектом неделями, этого мало.

Ему нужно знать:

И главное - всё это не должно зависеть только от «памяти модели». Мне нужна простая, проверяемая, основанная на файлах система знаний, которую можно открыть руками, прочитать в Obsidian, синхронизировать, закоммитить частично или вообще не коммитить.

Поэтому open-second-brain с самого начала получился не «ещё одним чатботом с памятью», а маленькой инфраструктурой вокруг Markdown vault.

Почему Obsidian и Markdown

Выбор Obsidian-совместимого vault был почти очевидным.

Во-первых, это обычные Markdown-файлы. Никакой магии, никакой закрытой базы, никакой зависимости от конкретного сервиса. Если агент что-то записал, я могу открыть файл и увидеть результат.

Во-вторых, Obsidian уже хорошо решает человеческую часть Second Brain: заметки, wikilinks, Daily, ручная навигация, граф, поиск. Не было смысла делать свой интерфейс к знаниям, когда есть привычный инструмент.

В-третьих, агентам не нужен весь Obsidian. Им нужны детерминированные операции: создать служебную структуру, добавить событие в дневной лог, построить индекс страниц, проверить здоровье vault, экспортировать конфиг без секретов. Всё это можно делать через CLI и MCP, не заставляя модель «думать» о файловых операциях там, где лучше выполнить точную команду.

Сейчас open-second-brain создаёт в vault агентскую область AI Wiki/, ведёт дневные логи в Daily/*.md, умеет обновлять Markdown-индекс, проверять конфигурацию и не трогает человеческие заметки выше служебного раздела ## Raw events.

Я дал пустой репозиторий - агент выбрал архитектуру

Самое интересное: я не садился проектировать всё это как классический библиотечный API. Я дал агенту ссылки на популярные реализации, пустой репозиторий и задачу: сделать универсальный плагин, в первую очередь под Hermes, но так, чтобы другие агенты тоже могли его подхватить.

Первый коммит был совсем документационным: README и bootstrap проекта 6 мая. Потом агент быстро нарастил CLI-фундамент, команду o2b, init/doctor, vault primitives и индекс. В тот же день появился MCP-сервер - важный слой, потому что через MCP разные рантаймы могут получать одинаковые инструменты без ручного парсинга командной строки.

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

Дальше проект начал меняться под давлением интеграций.

От Hermes к универсальному плагину

Hermes остался основным рантаймом. Именно под него проект и задумывался: установить плагин, указать vault, дать агенту инструменты и заставить его писать важные события в Second Brain.

Но довольно быстро стало понятно, что привязываться только к Hermes неправильно. У меня уже есть разные агенты и разные среды: Claude Code, Codex, OpenClaw. Если Second Brain должен быть общей памятью, он не может жить только в одном клиенте.

Так в проекте появились адаптеры и манифесты для нескольких рантаймов:

Это важное архитектурное решение: ядро должно быть одно, а входов может быть несколько. Агентам не нужно спорить, где истина. Истина - в vault и в общем наборе операций.

Что пришлось чинить по дороге

open-second-brain развивался очень быстро: с 6 по 9 мая проект прошёл путь от README до версии 0.7.0. И почти каждая версия была не «косметикой», а реакцией на реальную проблему интеграции.

Например, OpenClaw сначала получил совместимость как нативный плагин, но рантайм оказался строже, чем ожидалось. Пришлось добавлять name внутрь tool-объектов, делать register() синхронным, а потом переписывать OpenClaw-плагин на чистый JavaScript без child_process, потому что сканер безопасности блокировал создание subprocess.

Следующая большая тема - identity. Если в дневнике написано просто @agent, такой лог почти бесполезен. Поэтому в 0.6.0 появился workflow с агентскими именами: o2b init --agent-name, регистрация в AI Wiki/identity/agents.md и проверка, что записи в Daily получают нормальный @agent-name, а не плейсхолдер.

Потом добавились timezone, защита от записи не в тот vault, marketplace-манифесты для Claude и Codex, автоинструкции для MCP, нормализация пустых аргументов, проверка install flow, multi-agent registry. Это не звучит как героическая продуктовая фича, но именно такие детали отличают игрушку от инструмента, который можно оставить работать на сервере.

Версия 0.7.0: одно ядро на TypeScript и Bun

Самое крупное изменение случилось в 0.7.0: проект переехал на единый TypeScript core на Bun.

До этого в репозитории была параллельная логика: Python-реализация для CLI/MCP, JavaScript-часть для OpenClaw, Hermes shim. Такая схема быстро начинает дрейфовать. Исправил баг в одном месте - не факт, что исправил в другом. Добавил timezone в Python - надо не забыть повторить в JS.

В 0.7.0 агент убрал дублирование: Hermes, Claude Code, Codex и OpenClaw теперь используют общие модули из src/core/. CLI живёт в src/cli/, MCP - в src/mcp/, точка входа OpenClaw собирается из TypeScript в JS-бандл через bun build.

Заодно появилась нормальная тестовая база: bun:test на 176 кейсов, Python shim tests, тест на конкурентный append-event в 12 процессов, проверки свежести bundle и синхронизации версий в манифестах.

Это как раз тот случай, когда видно преимущество агентского workflow. Человеку неприятно руками перетаскивать один и тот же код между рантаймами и переписывать тесты. Агенту - нормально, если дать чёткую цель, ограничения и проверку результата.

Как это живёт на VPS

Вся эта история крутится на обычной VPS примерно за 8 долларов в месяц. Там же живёт Hermes, там же можно вести разработку, там же управляются AI-подписки и маршрутизация через OmniRoute.

Для меня это важная часть эксперимента. Я не хочу, чтобы AI-assisted workflow требовал отдельной дорогой инфраструктуры. Нужен сервер, браузер, Telegram как интерфейс к агенту, git-репозитории рядом и дешёвый доступ к моделям.

Получается довольно странная, но рабочая картина: я могу с телефона написать агенту в Telegram, он на VPS разберёт задачу, пойдёт в репозиторий, воспользуется нужными скиллами, создаст артефакт, прогонит проверки и запишет важное событие в Second Brain.

Пока это ещё не Dark Fabric. Но это уже не просто «чат с моделью».

Что получилось

На момент этого черновика open-second-brain - это небольшой, но уже полезный слой памяти для агентской разработки.

Он умеет:

Самое ценное даже не список команд. Ценно то, что у агентов появился общий протокол памяти: когда случилось что-то долговечное - код, фикс, конфиг, контент, исследовательский вывод, дизайн-решение - это нужно записать так, чтобы будущий я и будущий агент могли найти это позже.

Что дальше

Ближайшая цель - довести связку Hermes + open-second-brain до состояния, где агент не просто пишет события, а действительно использует накопленную память при планировании и ревью.

Дальше хочется:

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

open-second-brain - мой первый рабочий шаг в эту сторону.

Как был написан этот пост

Извините, но и этот пост написан тем же агентом Hermes. Руками написан только этот абзац и мой пост на Facebook. Я просто попросил агента склонировать к себе мой блог как обычный проект, посмотреть историю коммитов и взять Facebook-пост как базу. И, конечно же, я перечитал и поправил текст перед публикацией. И не говорите, что это без души, - я вкладываю душу в агента.