14 мин

9.7K

Я не программист: когда-то давно я учил веб-разработку, понимаю базовые вещи про HTML, CSS, JavaScript, файлы, папки и GitHub, но профессионально разработкой не занимаюсь.

При этом потребность систематизировать знания и дела у меня была давно.

Личные заметки, рабочие задачи, бизнес-проекты, документы, идеи, планы, договорённости — на первый взгляд это разные вещи. Но на более глубоком уровне почти всё сводится к одному циклу:

• получить информацию;

• понять, что в ней важно;

• сохранить её так, чтобы потом найти;

• связать с уже известным;

• применить в нужный момент.

Если этот цикл не выстроен, информация начинает оседать где попало: в чатах, заметках, письмах, документах, голове, скриншотах, закладках и случайных файлах.

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

GTD: сильная идея, тяжёлое обслуживание

Когда я думал об этом проекте, я всё время возвращался к Getting Things Done.

Методику GTD описал Дэвид Аллен в книге Getting Things Done, которая впервые вышла в 2001 году. В ней была очень правильная мысль: не надо держать всё в голове. Нужно иметь внешний контур:

• входящую корзину;

• понятные списки;

• контексты;

• проекты;

• следующие действия;

• регулярный обзор.

Идея сильная. Проблема была в реализации.

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

Потом появились компьютеры, интернет-сервисы, синхронизация с телефоном, приложения для заметок и задач. Evernote, Notion, Obsidian, Todoist, Apple Notes и десятки других вариантов сделали работу с информацией намного удобнее.

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

• читать документы и заметки;

• выделять главное;

• решать, куда положить заметку;

• связывать её с другими заметками;

• следить, что не устарело;

• возвращаться к обзору.

То есть система могла быть прекрасной, но её нужно было вручную обслуживать.

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

Сначала я пытался смотреть на это через уже привычные AI-инструменты: обычный ChatGPT, Custom GPTs, Gemini Gems, Claude Projects, skills и большие промпты. Они помогают, но постепенно стало ясно, что мне нужен не просто чат и не просто папка с заметками.

Мне нужен был личный AI-агент, который:

• помнит правила работы;

• не теряет контекст между чатами;

• аккуратно работает с файлами;

• помогает вести базу знаний;

• умеет разбирать документы;

• не смешивает разные проекты;

• хранит данные у меня на компьютере;

• может быть перенесён на другую модель или другой инструмент.

В GTD-систему можно поселить умную прослойку

Для меня главный сдвиг именно здесь.

Раньше система управления знаниями и делами была пассивной. Она могла быть очень продуманной, но всё равно ждала, что человек сам откроет нужную папку, прочитает документ, выделит главное, решит, куда это положить, руками обновит заметку и потом ещё вспомнит вернуться к обзору.

Теперь между человеком и такой системой появляется AI-агент.

Можно сказать чуть образно: в GTD-систему можно поселить очень сильного помощника, который берёт на себя большую часть рутины.

Он может:

• принять новую мысль голосом или текстом;

• прочитать большой документ;

• разобрать расшифровку видео или встречи;

• выделить главное;

• предложить, куда положить новую информацию;

• найти связанные заметки;

• заметить противоречия;

• предложить обновление правил или проекта;

• проверить, что изменение не ломает структуру;

• спросить подтверждение перед записью;

• в конце сессии напомнить, что из разговора стоит сохранить.

То, на что раньше можно было потратить вечер, теперь часто превращается в диалог: объяснил задачу, дал материал, получил структуру, проверил предложение, подтвердил запись.

При этом агент не просто “раскладывает заметки”. Если ему объяснить роль и границы, он начинает работать внутри конкретного контекста: как помощник по бизнесу, как ассистент в продажах, как редактор, как исследователь, как личный секретарь.

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

Чат — это ещё не второй мозг

Обычный веб-чат хорош, пока задача маленькая.

Но если вы работаете с чем-то долго, начинаются знакомые проблемы:

• контекст теряется;

• правила приходится повторять;

• важные решения остаются в истории чата;

• промпт разрастается;

• данные проекта смешиваются с инструкциями агента;

• непонятно, что уже сохранено, а что осталось только в переписке.

Можно пытаться решить это через Custom GPTs, Gemini Gems, Claude Projects, skills, большие системные промпты или отдельные заметки. Это помогает, но не решает главный вопрос:

где живёт ваш агент и кому принадлежат его знания?

Мне хотелось, чтобы агент жил не в настройках конкретного сервиса, а в обычной папке на моём компьютере.

LLM уже умная. Ей не хватает вашей памяти

Современные LLM уже умеют очень многое:

• рассуждать;

• писать;

• сравнивать;

• выделять главное;

• анализировать документы;

• строить планы;

• готовить тексты, таблицы, презентации и черновики.

Но есть фундаментальная проблема: модель не знает ваш полный контекст.

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

В один промпт невозможно нормально положить всю историю проекта, все документы, все решения, все договорённости, все исключения и все нюансы. Даже если контекстное окно большое, вы сами в моменте не вспомните всё, что нужно приложить к вопросу.

Получается странная ситуация: двигатель очень мощный, но каждый раз ему не хватает карты местности.

Файловая база знаний решает не проблему “интеллекта” модели. Она решает проблему устойчивого контекста.

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

Уже после того, как я пришёл к этой идее практически, я увидел похожую мысль у Андрея Карпати вокруг LLM Wiki: LLM становится намного полезнее, когда рядом с ней есть редактируемая база контекста. Для меня это было скорее подтверждением направления, чем исходной точкой.

Идея: дать агенту локальную файловую память

В какой-то момент я пришёл к простой конструкции:

Codex app + Markdown-файлы + Obsidian

Codex app выступает как рабочий AI-агент.
Markdown-файлы становятся телом памяти.
Obsidian нужен человеку для просмотра структуры, чтения, навигации и графа связей.

Примерная схема:

Пользователь -> Codex -> Agent Core -> Project Layer -> Markdown-файлы -> Obsidian

Вместо “магической памяти” получается обычная папка, которую можно:

• открыть руками;

• читать без AI;

• перенести;

• положить в Git;

• подключить к другому инструменту;

• не отдавать внешнему сервису.

Agent Core и Project Layer

Главная архитектурная идея такая:

один Agent Core -> много Project Layers

Agent Core — это то, как агент работает:

• как он стартует;

• каким правилам доверяет;

• как читает файлы;

• как предлагает изменения;

• как работает с источниками;

• как ведёт records;

• как проверяет структуру;

• что нельзя делать без подтверждения.

Project Layer — это то, с чем агент работает:

• компания;

• роль;

• исследование;

• личный проект;

• здоровье;

• спорт;

• обучение;

• корпоративные документы;

• продукт;

• клиентская база;

• любой другой контекст.

Agent Core загружается всегда. Project Layer выбирается отдельно.

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

Почему пришлось разделить агента и проекты

Изначально всё было проще: я собирал агента сразу под конкретный проект.

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

Но если просто копировать всю папку целиком, начинаются проблемы:

• проектные данные смешиваются между собой;

• в контекст попадает лишняя информация;

• расходуются лишние токены;

• приватные данные сложнее отделить от общих правил;

• несколько копий агентского ядра начинают развиваться по-разному;

• улучшение, найденное в одном агенте, не попадает автоматически в другие.

Так появилась мысль: постоянной должна быть не “роль агента”, а его способ работы.

Agent Core отвечает за универсальные вещи:

• как агент стартует;

• как он выбирает проект;

• как читает файлы;

• как предлагает изменения;

• как проверяет конфликтующие данные;

• как сохраняет решения;

• как работает с records;

• как не лезет туда, куда ему не разрешили.

А роль начинается уже в Project Layer. В одном проекте агент может быть помощником в работе/бизнесу, в другом — личным секретарём, в третьем — ассистентом по обучению, в четвёртом — помощником по здоровью или спорту.

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

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

Каждый диалог становится обучающим семинаром

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

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

Обычный чат это потеряет. Максимум — останется в истории переписки.

Локальный агент может сделать иначе:

1. заметить важную мысль;

2. классифицировать её;

3. предложить, куда сохранить;

4. показать конкретный текст;

5. дождаться подтверждения;

6. записать в нужный файл;

7. обновить журнал;

8. проверить, что структура не сломалась.

В шаблоне это описывается циклом:

CAPTURE -> CLASSIFY -> PROPOSE -> APPROVE -> APPLY -> LOG -> LINT

То есть агент не пишет в базу знаний самовольно. Он предлагает изменения, а пользователь подтверждает.

В конце длинной сессии можно сделать Session Close Review: агент проходит по разговору и предлагает, что из него стоит сохранить, а что не имеет будущей ценности.

Это очень похоже на GTD weekly review, только часть рутины берёт на себя LLM.

Входящая корзина, но с помощником

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

Здесь логика похожая, но роль “разборщика” частично берёт на себя агент.

Вы можете дать ему:

• заметку голосом;

• длинный документ;

• PDF;

• Word-файл;

• Excel-таблицу;

• изображение;

• расшифровку видео;

• корпоративный стандарт;

• инструкцию;

• выгрузку;

• ссылку на сайт, если разрешаете интернет.

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

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

Почему LLM особенно хорошо подходит для этого

Если посмотреть на первые сильные применения LLM, одно из главных — это работа с большими массивами текста.

LLM умеет:

• читать длинное;

• выделять главное;

• сжимать без потери смысла;

• объяснять проще;

• строить структуру;

• сравнивать версии;

• находить противоречия;

• превращать поток текста в список действий.

Именно это нужно для второго мозга.

Большинство людей не страдают от того, что у них нет ещё одного приложения для заметок. Они страдают от того, что заметки, документы, планы, ссылки, идеи и задачи не превращаются в живую систему.

LLM может стать не просто генератором текста, а обслуживающим механизмом этой системы.

Личный помощник, которого можно обучать

Я всё больше думаю об этом не как о “папке с промптами”, а как о личном помощнике, которого можно обучать.

Но обучение здесь не в смысле fine-tuning модели.

Обучение происходит через файлы:

• уточнили правило — записали в Agent Core;

• добавили проект — создали Project Layer;

• разобрали документ — пополнили knowledge pages;

• приняли решение — зафиксировали decision;

• нашли устойчивый факт — предложили record;

• завершили сессию — сохранили важные итоги.

Постепенно у агента появляется всё более полная картина проекта.

Он уже не отвечает “из воздуха”. Он может пойти в нужный файл, прочитать контекст, найти источник, свериться с roadmaps, посмотреть pending items и только потом отвечать.

Качество ответа растёт не потому, что модель стала другой, а потому что у неё появился нормальный рабочий контекст.

Это может работать и для компаний

Такая схема полезна не только одному человеку.

Компания тоже может собрать свой project layer:

• продукты;

• регламенты;

• инструкции;

• стандарты продаж;

• коммерческие материалы;

• презентации;

• CRM-описания;

• база знаний;

• процессы;

• исследования;

• типовые ответы;

• внутренние правила.

Тогда агент перестаёт быть универсальным чатиком и становится помощником, который понимает конкретную организацию.

Он может быстрее готовить материалы, анализировать документы, собирать презентации, находить противоречия и помогать сотрудникам ориентироваться в корпоративных знаниях.

Главное — не смешивать данные компании с общими правилами агента и не отдавать всё бездумно внешним сервисам.

Данные должны принадлежать пользователю

Для меня это принципиальный момент.

Если всё хранится внутри облачного сервиса, то пользователь зависит от конкретной платформы:

• изменились условия;

• закончилась подписка;

• поменялась модель;

• закрылся продукт;

• экспорт неудобный;

• перенос невозможен или болезненен.

А если база знаний — это Markdown-файлы на компьютере, ситуация другая.

Файлы ваши. Папки ваши. История ваша. Структура ваша.

Сегодня можно работать через Codex.
Завтра попробовать Claude Code.
Послезавтра подключить Antigravity или другой agentic IDE.
Позже — Obsidian AI-плагин или локальную модель.

Инструменты могут меняться, но знания остаются в переносимом виде.

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

Как когда-то разные устройства пришли к USB-C, так и агентам понадобится понятный способ работать с пользовательской памятью.

Почему это до сих пор удивляет

Возможно, для людей, которые глубоко следят за AI-инструментами, всё это уже не выглядит революцией. Карпати написал про LLM Wiki, многие экспериментируют с агентами, заметками, RAG, локальными базами знаний и IDE для AI.

Но на бытовом уровне это всё равно ощущается как скачок.

Я много раз пытался навести порядок в заметках и документах. И каждый раз упирался не в отсутствие программы, а в стоимость обслуживания этой системы: нужно было читать, переносить, переименовывать, связывать, чистить, помнить, возвращаться.

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

Это похоже на момент, когда технология меняет масштаб привычного действия. Когда-то расстояние в сто километров было большим событием, потом появился транспорт, и тот же путь стал обычной поездкой. С AI-агентами происходит похожее: раньше разбор личной или рабочей базы знаний был тяжёлой ручной работой, а теперь начинает становиться нормальным диалоговым процессом.

Меня в этом удивляет не только “умность” модели. Удивляет то, что из обычных файлов, нескольких правил и дисциплины подтверждений получается рабочая система, которая реально снижает трение между мыслью и порядком.

Почему Codex

Я выбрал Codex не потому, что это единственный возможный вариант.

Просто он оказался самым практичным для моего текущего сценария.

Главный критерий был простой: мне хотелось получить доступ к максимально сильной из доступных мне LLM и при этом не упираться в лимиты через час работы.

Мне нужен был инструмент, который:

• работает с локальной папкой;

• умеет читать и менять файлы;

• может долго обсуждать структуру;

• помогает писать Markdown;

• не требует сразу строить backend;

• позволяет подключать мощные модели.

Claude Code тоже выглядит логичным вариантом, но на моей подписке лимитов Claude мне не хватало для многочасовой работы. В Codex я мог работать часами и практически не упирался в лимиты.

Если бы лимиты Claude не мешали, я бы, вероятно, начал именно с Claude Code или как минимум параллельно тестировал бы его глубже. Gemini / Antigravity тоже интересны как направление, но по моему текущему ощущению Gemini отвечает менее глубоко и более поверхностно, чем хотелось бы для такой задачи.

Другие варианты тоже есть: CLI-инструменты, локальные связки, плагины Obsidian, собственные скрипты. Но для непрофессионального пользователя это быстро становится сложнее. Codex оказался хорошей точкой входа: есть интерфейс, есть работа с файлами, есть мощная модель, есть возможность не смотреть на терминал, если не хочется.

Текущий сетап:

MacBook / macOS
Codex app
Obsidian
локальная папка с Markdown-файлами
GitHub для публикации чистого шаблона

Почему Obsidian

Obsidian здесь не управляет агентом. Он нужен человеку.

Через Obsidian удобно:

• читать Markdown-файлы;

• смотреть дерево папок;

• видеть граф связей;

• быстро переходить между страницами;

• понимать, где пусто;

• замечать изолированные разделы;

• вручную проверять, что база не превратилась в хаос.

Агент работает с файлами напрямую, а Obsidian даёт человеческий интерфейс к этой же структуре.

Так шаблон выглядит в Obsidian: слева дерево папок, справа граф связей между Markdown-файлами.

GitHub необязателен, Git полезен

Важно разделить две вещи: Git и GitHub.

GitHub нужен, если хочется опубликовать чистый шаблон или хранить репозиторий удалённо. Но для личной работы это необязательно.

Можно просто включить Git локально в папке проекта. Тогда появляется история изменений и возможность откатиться, даже если проект никуда не публикуется.

Для меня это хорошо ложится на идею безопасного агента. Если агент меняет файлы только после подтверждения, а Git сохраняет версии, риск потери информации становится ниже.

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

Что внутри шаблона

Упрощённая структура:

AGENTS.md
agent/
  model/
  protocols/
  records/
  roadmaps/
  work-plans/
  reference-sources.md

.agents/skills/

projects/
  _template/

raw/
logs/
output/
docs/
index.md

Ключевые идеи:

• AGENTS.md — главный файл правил;

• agent/ — постоянное ядро агента;

• .agents/skills/ — процедурные skills;

• projects/_template/ — шаблон проектного слоя;

• raw/ — исходники;

• logs/ — история действий;

• agent/records/ и projects/_template/records/ — строгие подтверждённые записи;

• output/ — временные результаты.

Records — не мусорная память

Отдельная важная часть — records.

Сначала кажется, что надо просто сделать “память агента” и складывать туда всё подряд.

Но это быстро превращается в мусор.

Поэтому records — это только короткие подтверждённые записи:

• facts;

• events;

• decisions;

• principles.

Новая запись сначала попадает в _inbox/. Потом агент проверяет возможные дубли и конфликты. И только после подтверждения пользователя запись попадает в canonical records.

Это медленнее, чем автосохранение, зато намного безопаснее.

Что будет дальше

Если смотреть вперёд, следующий этап — агент, которому вы даёте не документы, а цель.

Не “вот тебе вся информация, разложи её”, а:

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

Частично это возможно уже сейчас. Агент может видеть data gaps, задавать вопросы, просить документы, предлагать структуру.

Но в будущем такие системы, вероятно, станут автономнее и сами будут:

• понимать, какой контекст им нужен;

• запрашивать недостающие источники;

• проверять противоречия;

• поддерживать порядок в базе знаний;

• помогать человеку делать регулярный обзор.

Пока я сознательно ограничился более простым режимом: агент предлагает, пользователь подтверждает.

Следующий практический слой развития для меня связан не с тем, чтобы сразу писать сложную платформу, а с тем, чтобы постепенно подключать возможности той среды, в которой агент уже работает. В Codex развиваются встроенные skills, есть механика automations для регулярных задач, есть возможности подключения приложений и внешних инструментов.

То есть путь развития выглядит не как “переписать всё с нуля”, а как постепенно добавлять агенту новые руки:

• регулярные проверки;

• автоматические обзоры;

• работу с внешними источниками;

• подключение нужных приложений;

• обработку документов;

• более удобный ingest;

• более строгие проверки базы знаний.

При этом сама файловая архитектура остаётся переносимой. Если в Claude Code, Antigravity, OpenClaw, Hermes или другой среде появятся более сильные инструменты, можно будет пробовать подключать тот же набор файлов туда. Мне интересно посмотреть, насколько хорошо такие среды смогут использовать уже собранную агентскую структуру, а не начинать каждый раз с пустого промпта.

Особенно мне интересны инструменты, которые развивают именно память и сохранение контекста. Для меня ключевой критерий — не только “сколько действий агент может выполнить”, а не теряется ли важная информация между сессиями и можно ли безопасно управлять тем, что попадает в долгосрочную память.

Ограничения

Это не готовый коммерческий продукт.

Это template.

И это не “агент” в максимально полном смысле слова.

У него пока нет собственной глубокой автономии, постоянного фонового процесса, подключённого набора бизнес-инструментов, автоматического доступа к API, базам данных, web search, MCP, локальным моделям, корпоративным хранилищам или сложной автоматизации.

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

Для меня это важное отличие. Я не пытаюсь продать идею, что папка с Markdown уже заменяет полноценную агентскую платформу. Но она даёт основу, на которую можно постепенно навешивать инструменты, не теряя контроль над данными.

Он задаёт файловую архитектуру и правила работы:

• где лежат инструкции;

• где лежат проекты;

• как сохраняются решения;

• как не потерять важное из чата;

• как не смешать приватные данные с публичным ядром;

• как дать LLM устойчивый контекст.

Для меня этого оказалось достаточно, чтобы обычный чат начал превращаться в локального агента.

Итог

GTD дал сильную идею: вынести дела и знания из головы во внешнюю систему.

Но десятилетиями человек сам обслуживал эту систему: читал, сортировал, переносил, связывал, переписывал и проверял.

LLM меняет именно это.

Теперь внешний мозг может быть не просто хранилищем, а активным помощником, который помогает себя поддерживать.

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

Так появился небольшой шаблон локального агента: codex-agent-core-template.

Это не фреймворк и не готовый SaaS-продукт. Это файловая архитектура: Codex app + локальные Markdown-файлы + Obsidian.

Код шаблона выложен на GitHub: codex-agent-core-template.

Если у вас есть Codex, локальная папка и немного дисциплины в правилах, у вас уже почти есть личный AI-агент с управляемой памятью.

Осталось дать ему структуру и не разрешать менять её без вашего подтверждения.