История экспериментов с Personal OS:
(1) первый эксперимент с Git+Obsidian - 8 февраля 2026
(2) Описание структуры Personal OS - 27 февраля
(3) сравнение с LLM Wiki Karpathy - 5 апреля
(4) субличность Марка - 23 Мая
Эксперимент 12. Yggdrasil
В Personal OS набралось полторы тысячи документов. Вчера я cнёс почти все из репы и перенес на сервер.
Новый сервер - это самописный файловый сервер с отслеживанием версий. Он выполняет почти все мои хотелки из прошлого (кроме типизированных документов, ибо больше не важно)
Основные различия по сравнению с git + Obsidian:
(1) не нужно чехарды с git командами при работе.
(2) в отличие от Notion и аналогов - изменения глобально версионированы (а не по файлам отдельно). Можно откатить изменение агента, даже если он поменял тысячу файлов в разных workspaces одновременно
(3) у всех участников поиск работает одинаково
(4) оно сразу заточено под одновременную работу нескольких человек с их агентами над общими материалами.
Под капотом - golang + SQLite + CAS + MCP API 2.0 + CLI (ставится сразу в системную папку для Codex-a) + Borg Backup на удаленный сервер.
Первые впечатления - стало проще работать с файлами. Можно отправить агента завести себе workspace, не задумываясь про git push/pull итп. И можно не держать в голове текущее состояние git папок при работе. Если агент сказал, что сохранил транскрипт разговора с выжимкой, значит он уже лежит там и доступен всем. Про конфликты от одновременной работы можно не беспокоиться, откаты изменений есть.
Но в минус - агенты находят документы быстрее, но стали дольше копошиться с их изменением. Оказывается, когда файлы лежат где-то там, их нельзя так просто взять и изменить.
У Sol 6.1 уходило 6 c половиной минут на то, чтобы отработать такой запрос:
> hey, capture that latest exchange with Aigiz into Bragi (continuing our last conversation)...
(Под капотом Марк должен подключиться к серверу, найти нужный workspace, понять принципы организации capture/distill/arks, подшить куда надо, немного перелопачивая файл на 70kb, собрать изменение и смерджить его)
Поэтому пришлось поставить ряд экспериментов в поиске tool calling интерфейса, который бы позволил кодексу решать эту RAG задачу быстрее.
Самое забавное, что этот интерфейс оказался питоном. Вместо того, чтобы тягать файлы c сервера туда-сюда (удачи со случаем, когда мы делаем replace по папке), агент пишет маленький скрипт, который отправляется на сервер и в изолированной песочнице работает с изменениями в рамках сессии там.
То есть не нужно мучаться с придумыванием оптимальных инструментов для MCP/API/CLI, когда можно сказать “писать питон вот сюда, вот тебе описание SDK”.
В итоге теперь аналогичная задача выполняется Sol 6.1 без лишних танцев с бубнами за три с половиной минуты. Причем половина времени тратится на RAG задачи, а вторая - на написание текста.
Заодно я смог выкинуть из MCP API и CLI все инструменты и команды кроме двух -
start (начать новую сессию/commit и получить в контекст описание текущего SDK) и run (запустить питон на сервере).В общем, если у вас у какой-то AI Native системы получается сложный интерфейс с кучей API-шек и инструментов - попробуйте просто дать агентам Python, благо инструментов для этого есть море, от jails до Firecracker VM.
Ваш, @llm_under_hood 🤗