Роан Бразил Монтейро написал подробный туториал о том, как превратить хранилище Obsidian во «второй мозг» разработчика под управлением LLM-агента. Архитектура у него аккуратная: три физически разделённые зоны. raw/ — то, что курирует человек, неизменяемое; wiki/ — то, чем владеет агент, концепты и синтезы; dev/ — совместная территория для ADR и постмортемов. Поверх всего лежит CLAUDE.md со схемой прав, git служит кнопкой отмены, а раз в неделю человек запускает синтез недельных заметок. Главное правило он формулирует одной строкой: «the agent never touches what you curated; you rarely touch what the agent maintains».
Я сам гоняю в продакшене стек персистентной памяти и читал этот текст как практик, а не как зритель. И мой тезис простой: то, что Монтейро описывает, — это не конкурент моему стеку и не «другой подход к тому же». Это другой слой. Большинство споров о памяти для агентов отравлены ложной рамкой «кто победит» — file-based память против векторной, вики против графа. На деле это разные механизмы под разные задачи, и путать их — значит проектировать систему, в которой один слой делает работу другого плохо.
Три слоя, которые делают разную работу
В моём стеке живут как минимум три различимых сущности. Первая — файловая память дискретных фактов: один факт на файл, индекс в MEMORY.md. Это быстро, это адресуемо, это то, к чему агент обращается, когда нужен точный ответ «как мы решили вопрос X». Вторая — семантическая память: MemPalace с курируемыми крыльями, графом знаний и десятками тысяч авто-намайненных сессий. Она отвечает не на «дай факт», а на «что вообще похоже на текущую ситуацию». Третья — рукотворная нарративная вики, ровно та, что строит Монтейро: человек курирует, агент синтезирует раз в неделю, git версионирует.
И вот тут важная честность: третий слой я почти не гоняю. Не потому, что он плохой, — потому что у него своя ниша, и она не перекрывает первые два. Дискретные факты не нужно «синтезировать» еженедельно, их нужно мгновенно доставать. Семантический recall не живёт в Title-Case-страницах с викилинками, он живёт в эмбеддингах и рёбрах графа. Туториал Монтейро описывает один механизм — человеко-курируемую, еженедельно-синтезируемую, git-версионированную вики — и описывает хорошо. Ошибка возникает только тогда, когда этот один механизм объявляют ответом на весь вопрос памяти.
Где он абсолютно прав
Зональное разделение — это правильный инстинкт, и я узнаю в нём собственную дисциплину. У меня есть отдельный документ «зоны ответственности» — буквально жёсткие границы между тем, что лежит в CLAUDE.md, в файловой памяти, в MemPalace и в вики; кто имеет право писать куда. Когда Монтейро делает raw/ неизменяемым и пишет «the agent never touches what you curated», он формулирует ту же мысль, к которой я пришёл независимо: агент должен иметь право писать ровно в один слой и читать остальные. Это не эстетика каталогов. Это операционная политика, которая не даёт агенту тихо переписать ваш источник истины под видом «уборки».
Его защита от prompt injection тоже разумна в той части, где она есть: allowed-tools без rm, обязательный показ плана до исполнения, git diff как сеть безопасности. Человек в петле перед записью — правильная дисциплина. С этим я не спорю.
Где он останавливается на шаг раньше
Но именно на инъекциях он недоезжает один шаг — и это не мелочь. Его модель угрозы предполагает, что вредоносная инструкция проявит себя как действие: попытка удалить файлы, переписать вики, выполнить команду. От этого защищают и allowlist, и показ плана, и git. Чего эта оборона не ловит — это инъекции, которая не делает ничего деструктивного в момент инжеста, а просто становится контентом. Агент, который читает внешний URL и синтезирует его в слой знаний, втягивает текст, написанный кем угодно. Если в статье спрятана подсунутая «фактура» — ложное утверждение, поддельная атрибуция, тихая закладка на будущую сессию, — она проходит сквозь все его слои защиты, потому что выглядит как легитимный синтез.
И вот ключевое: отравление, попавшее в вики, переживает git diff. Diff показывает, что страница изменилась, — но изменение и должно было произойти, вы же сами запустили инжест. Diff не отличает добросовестный абзац от подброшенного: оба выглядят как обычный новый контент. «Review the plan before approving» спасает от удаления файлов, но не от абзаца, который читается правдоподобно и при этом лжёт. Зональная неизменяемость raw/ защищает целостность источника от агента — но ничего не говорит о целостности самого источника, который вы туда положили.
Что с этим делать
Лечится это не усложнением модели, а одним недостающим слоем — сканированием контента до того, как агент его вообще увидит. У меня перед любым инжестом в память или вики работает /security-check: регэксп-сигнатуры на инъекции, детектор скрытого Unicode, разбор base64-блоков. Это префлайт, а не пост-фактум. Конкретно для схемы Монтейро я бы сделал три вещи.
- Шаг 1. Сканировать на инжесте, до синтеза. Внешний URL проходит content-scan прежде, чем агент начнёт извлекать концепты. Поймать инъекцию надо до того, как она станет «новой страницей вики», а не после.
- Шаг 2. Считать
raw/недоверенным входом — даже то, что вы сохранили сами. Неизменяемость защищает от агента, но не делает контент честным. Веб-клиппер сохраняет ровно то, что было на странице, вместе с тем, что туда заложил автор. - Шаг 3. Не путать «git diff чист» с «контент безопасен». Git ловит несанкционированные правки. Он не ловит санкционированный инжест отравленного источника. Это разные гарантии, и второй слой защиты git не заменяет.
Так что я не «возражаю» Монтейро — я достраиваю его на один слой. Его трёхзонная архитектура — правильная основа, и его строчка про «agent never touches what you curated» должна висеть над любой системой памяти. Но память — это таксономия слоёв, а не один победивший механизм; и любой слой, который ингестит внешний мир, нуждается в санитарной проверке на входе, потому что отравленный, но правдоподобный текст — это единственная угроза, которую ни allowlist, ни git diff, ни показ плана не видят.