{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidwljxu67b74tfrm5h52sfqmtywq254e7sr4inmx5z2c5dnic2t4e",
    "uri": "at://did:plc:oq3nfrah6lyjaaofdrf2m6iy/app.bsky.feed.post/3moucudwuycu2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreia27bfn4o26q4c323rmvn4vcwg2cfy2gebkymfda4bzgzukdguksi"
    },
    "mimeType": "image/webp",
    "size": 66006
  },
  "description": "Кожна розмова з LLM закінчується — і агент забуває все. Я вирішив це не «вирішувати». Я вирішив зробити vault пам'яттю, яка не залежить від контексту розмови.",
  "path": "/hermes-vault-agent-memory/",
  "publishedAt": "2026-06-22T07:00:58.000Z",
  "site": "https://blog.lavrynovych.net",
  "tags": [
    "Мій AI-агент",
    "Частині 2"
  ],
  "textContent": "← Серія статей: Мій AI-агент\n\n* * *\n\n## Проблема з пам'яттю у LLM\n\n💡\n\n****LLM**** (Large Language Model) — велика мовна модель. AI що навчений на величезних масивах тексту і може відповідати на питання, писати код, аналізувати дані. ChatGPT, Claude, Gemini — все це LLM. Кожна розмова з LLM існує в «контексті» — вікні пам'яті на час сесії. Коли сесія закривається, контекст зникає.\n\nLLM (велика мовна модель — AI типу ChatGPT або Claude) має одну фундаментальну особливість: не пам'ятає нічого між сесіями. Кожна нова розмова — чистий аркуш. Ти пояснюєш контекст знову. Агент не знає що вчора ви вирішили X, а позавчора відклали Y.\n\nКласичне рішення — vector database. Беремо нотатки, перетворюємо кожну в числовий «відбиток» (embedding — спосіб описати зміст тексту числами), при кожному запиті знаходимо найближчі за змістом фрагменти і підставляємо їх у prompt. Це називається RAG — Retrieval-Augmented Generation, «пошук + генерація».\n\nЯ так не зробив.\n\nНе тому що не знаю як — тому що протестував інший підхід і він спрацював краще для моєї задачі. Агент читає vault структуровано, ітеративно, з конкретними якорями — і отримує релевантний контекст без жодних embeddings.\n\nЦе вимагало правильно організованого vault'у. Vault — папка з текстовими файлами (у моєму випадку Obsidian). Не база даних, не хмарний сервіс — звичайні markdown-файли на диску.\n\n* * *\n\n## Другий закон конституції: vault як джерело істини\n\nУ Частині 2 я описав конституцію агента — три правила за якими він живе: чеснота понад усе, vault як джерело істини, безпечні кордони. Ось друге з них.\n\n**Другий закон Сюзанни** простий: vault важливіший за пам'ять агента.\n\nЯкщо в пам'яті є одна версія факту, а у vault — інша, vault виграє. Завжди.\n\nПрактично це означає: агент не покладається на «пам'ять» у звичному значенні. Він не зберігає факти у власній persistent memory думаючи «я це пам'ятаю». Він читає vault щоразу. Vault — єдине місце де факти зберігаються офіційно.\n\nVault зберігається у git — системі контролю версій яка фіксує кожну зміну файлу з датою і автором. Git не забуває.\n\n💡\n\n****git**** — інструмент який зберігає повну історію змін файлів. Кожне збереження фіксується з датою, автором і коментарем. Навіть якщо файл видалити або переписати — стара версія лишається в історії. Розробники використовують для коду. Я використовую для нотаток. Якщо я написав рішення 2 місяці тому — воно там. Якщо агент записав висновок тиждень тому — він там. Повна трасовність.\n\nЦе вирішує дрейф пам'яті через архітектуру, а не через правила.\n\n* * *\n\n## Як агент дізнається що відбулось поки його не було?\n\nСюзанна — ім'я мого агента (детальніше про її характер і правила — у Частині 2). Hermes — платформа на якій вона живе: скрипти, cron-задачі, серверна інфраструктура. Сюзанна — втілена особистість агента всередині цієї платформи. Кожна нова сесія з нею починається з catch-up — автоматично. Не треба нічого запускати вручну: якщо попередня сесія простояла більше 4 годин і стала неактивною, наступне звернення відкриває нову сесію — і Hermes запускає catch-up разом з нею.\n\nВона не читає весь vault — 600+ файлів, це не має сенсу. Вона читає за ієрархією:\n\n\n    Шар ідентичності\n      11 файлів: constitution.md, memory.md, цінності, стиль роботи, реєстр проектів, …\n      → Хто я? Які правила? Яка карта vault?\n\n    Рівень 1 — Структурні якорі\n      welcome-context.md → Where am I? What's the map?\n      TODO.md            → What's active right now?\n\n    Рівень 2 — Хронологічний шар\n      Year summary → Quarter → Month → Week → останні 3 daily notes\n      (йдемо від загального до конкретного)\n\n    Рівень 3 — Ключові люди (динамічно)\n      Python-скрипт витягує профілі з позначкою key: true з People/\n\nЦе не повне читання — це читання з якорями. Кожен якір вказує куди йти далі якщо потрібний контекст.\n\nТехнічно: catch-up — це скрипт що збирає всі ці файли в один текст і подає одним запитом до LLM. Не послідовне читання файл за файлом — один консолідований запит. Весь процес займає кілька додаткових секунд і коштує ~$0.01–0.015 за сесію.\n\nРезультат: при старті кожної сесії агент знає поточний стан проектів, відкриті рішення, останні події. Без цього він відповідав би «з голови» — тобто або галюцинував би, або давав банальні відповіді.\n\nОсь як це виглядає без catch-up. Якось я розповідав Сюзанні про свій день і згадав людину на ім'я. Вона не змогла зіставити це ім'я з нотаткою яка вже була у vault — і замість того щоб відкрити її, створила нову з неправильним прізвищем. Дублікат. Через те що не прочитала vault на старті — не знала що ця людина вже там є.\n\nА ось як виглядає з catch-up. Одного разу я попросив Сюзанну створити профіль нової людини. Вона не просто зробила порожню нотатку — вона знала який шаблон використати, в яку папку покласти, як заповнити кожне поле. Не тому що я пояснював — а тому що vault містить і приклади, і шаблони, і правила. Вона їх прочитала і просто слідує їм. Ось що значить \"агент в контексті\".\n\n* * *\n\n## Хто пише vault: петля запису\n\nЯ пояснив як агент _читає_ vault. Але є питання яке я оминув: а хто vault _наповнює_?\n\nВідповідь: обидва. Я і агент.\n\nПісля кожної сесії Сюзанна пише підсумок у щоденну нотатку — автоматично, через окремий скіл. Що робили, які рішення прийняли, що залишилось незавершеним. Не для мене — для себе. Щоб наступного разу прочитати і зрозуміти де зупинились.\n\nЩотижня запускається Observer — та сама Сюзанна через cron-задачу, але з іншими задачами: перевірити vault на суперечності, зафіксувати дрейф від конституції, зберегти snapshot стану. Результат — теж у vault, теж у git.\n\nЯкщо подивитись на `git log` — частина комітів з іменем «Hermes Agent». Агент не просто читає vault. Він в ньому залишає сліди.\n\nЦе замикає петлю: агент читає → допомагає → записує → читає знову. Vault — не статична база яку я веду вручну. Це жива система де обидва учасники пишуть і обидва читають. Саме тому наступна сесія завжди починається з контекстом — бо попередня його залишила.\n\n* * *\n\n## Чому для мого сценарію vault спрацював краще ніж RAG\n\n💡\n\n****RAG**** (Retrieval-Augmented Generation) — підхід де AI перед відповіддю спочатку «шукає» в базі знань найближчі за змістом фрагменти і підставляє їх у контекст. Умовно: не «запам'ятай все», а «знайди потрібне коли запитали». Стандартне рішення для довгострокової пам'яті AI-систем.\n\nЯ тестував підхід без embeddings з перших днів. Ось що виявилось — для мого конкретного сценарію.\n\n**Перевага 1: Структура важливіша за семантику.**\n\nRAG шукає схожість за змістом. Але мій vault організований семантично — файли мають types, теги, frontmatter (блок метаданих на початку кожного файлу: дата, тип, теги), wikilinks. Агент може знайти «всі рішення про архітектуру» не через пошук за схожістю, а через `type: decision` + тег `area/dev`. Точніше і швидше.\n\n**Перевага 2: Контекст не губиться.**\n\nRAG ріже документи на дрібні фрагменти — chunks (звідси «chunking») — і шукає по них. Важливий контекст може бути в сусідньому фрагменті — і не потрапити у відповідь. Агент який читає файл цілком не має цієї проблеми.\n\n**Перевага 3: Людина може читати те саме що і агент.**\n\nVault — звичайний markdown. Я читаю його сам. Агент читає його теж. Немає «чорної скрині» embeddings де щось зберігається і впливає на поведінку, але незрозуміло як. Повна прозорість.\n\nКомпроміс: семантичний пошук «знайди все про X» зараз менш ефективний ніж у RAG-системі. Для цього є окремий скіл пошуку і grep. Але для мого сценарію — структурований особистий vault з регулярними нотатками — ієрархічне читання спрацювало краще. RAG може бути правильним вибором для іншого сценарію.\n\n* * *\n\n## Патерни яких немає в жодній окремій нотатці\n\nЄ одна техніка яку я ще не розгорнув повністю — але вже бачу як вона має спрацювати.\n\nНазвав це **Inverse Summary Inference**.\n\nЗамість «що написано у цьому файлі?» — питання «що можна вивести якщо читати кілька файлів разом?»\n\nП'ять режимів читання:\n\n  1. **Патерни, що повторюються** — теми які з'являються у різних файлах і контекстах\n  2. **Суперечності** — «що написано як принцип» vs «що насправді відбувається»\n  3. **Приховані зв'язки** — паралельні ідеї в різних частинах vault\n  4. **Тиша** — що _не_ написано, теми які зникли\n  5. **Траєкторії** — як тема еволюціонує протягом місяця\n\n\n\nНічого з цього не написано явно ніде в raw нотатках. Це виникає через комбінування шарів.\n\nЗараз я відклав цю техніку до того часу коли vault накопичить достатній шар — різні домени, достатній часовий розріз. Поки більше накопичую ніж аналізую. Але ось що вже проглядається навіть без систематичного аналізу.\n\n**Приховані зв'язки.** Два великих «виходи в публічне» — музика і блог — відбулись в один місяць. Обидва після тривалого мовчання. Прочитавши нотатки поруч, Сюзанна помітила: це не збіг по датах, а один момент де щось внутрішньо змінилось. Але сам цей зв'язок ніде не написаний — він _між_ нотатками, не в жодній з них.\n\n**Тиша.** Секції «Думки та цитати» і «Інсайти» у більшості daily notes — порожні або з одним рядком. Але секції «Сесії з агентом» займають 70% нотатки і дуже деталізовані. Висновок: рефлексія не записується окремо — вона відбувається в розмові. Vault показав де думки _насправді_ живуть, а не де їм призначено бути.\n\n**Траєкторія.** Один місяць — вибух: жодного дня без нового проєкту чи рішення. Наступний — ущільнення: менше нового, більше публікацій і полірування вже зробленого. Vault зафіксував що фаза «запуску» непомітно перейшла у фазу «зрілості» — і ця межа ніде не була позначена свідомо. Ніхто не оголошував «тепер ми в іншій фазі». Це просто проявилось через читання двох місяців разом.\n\n* * *\n\n## Порядок у папках як мова для агента\n\nУяви бібліотеку де художня література, довідники і технічна документація стоять на одній полиці без підписів. Бібліотекар просить книгу про прийняті рішення — і змушений переглядати все підряд. Може знайти. Але повільно, і з шумом.\n\nVault довгий час був таким. Папка `System/` містила і правила для агента, і особисті рефлексії, і реєстри проектів — просто тому що «системне». Агент при пошуку контексту отримував нерелевантне поряд з потрібним.\n\nПісля реструктуризації кожна папка має один чіткий scope:\n\n  * `Docs/` — правила і конвенції\n  * `Reflections/` — рішення, mental models, уроки з помилок\n  * `Registries/` — реєстри проектів, шаблонів\n  * `TODO/` — активні задачі\n\n\n\nТепер агент знає: якщо питання про прийняті рішення → `Reflections/Decisions/`. Якщо про поточні завдання → `TODO/`. Якщо про людей → `People/`. Жодних зайвих файлів у відповіді.\n\nСтруктура папок — це мова запитів для агента. Без неї він читає все. З нею — знає куди дивитись.\n\n* * *\n\n## Memory mirror: vault як зовнішня пам'ять агента\n\nЄ ще один шар: **memory.md** — файл де зберігається постійний стан агента.\n\nТам: ім'я (Сюзанна), аватар, профіль користувача, ключові факти які не потрібно читати щоразу з нуля (стиль комунікації, основні обмеження, поточні пріоритети).\n\nІдея виникла з практичного питання: «що якщо vault треба буде перенести?» Якщо вся пам'ять агента в memory.md у vault — при міграції нічого не втрачається. Новий агент читає `System/Hermes/` і відновлює стан.\n\nАле є межа. memory.md — стислий (< 5000 символів). Оперативні деталі, контекст поточних проектів, останні рішення — все це в daily notes і project files. Не в memory.md.\n\nЦе свідоме розділення: **що незмінне** (ідентичність, принципи) — у memory.md. **Що змінюється** — у vault, де є git history.\n\nНаприклад: ім'я агента, аватар, стиль комунікації, межі поведінки — у memory.md, бо вони однакові в кожній сесії. Поточні проекти, прийняті рішення, останні події — у daily notes і project files, бо вони еволюціонують і мають git history.\n\n* * *\n\n## Семантичний тип нотатки визначає де вона живе\n\n**Vault як типізована система** — ідея яку я реалізував через frontmatter.\n\nКожна нотатка має `type:` у YAML. Тип визначає:\n\n  * де файл живе у папці\n  * який шаблон використовується при створенні\n  * як агент знаходить його через Dataview (плагін Obsidian для запитів по метаданих) або grep\n\n\n\nТипи для агентського сценарію:\n\n  * `type: decision` — прийняте рішення з контекстом і обґрунтуванням\n  * `type: failure` — що пішло не так і чому\n  * `type: principle` — принцип, якому слідуємо\n  * `type: daily` — щоденна нотатка\n  * `type: summary` — автоматично генерований підсумок\n\n\n\nАгент може запитати «покажи всі рішення про інфраструктуру» — і отримати точний список через `grep -r \"type: decision\" | grep -i \"infra\"`. Жодних embeddings.\n\n* * *\n\n## Vault для людей і для агента: два принципи\n\nУ **Принципах vault** є рядок який я часто повертаю:\n\n> _Vault для людей, не лише для AI._\n\nЦе застереження. Легко почати оптимізувати vault «під агента» — більше структури, більше метаданих, менше живого тексту. Але якщо vault перестає бути зрозумілим для мене — він перестає бути мозком. Стає базою даних.\n\nБаланс: достатньо структури щоб агент орієнтувався → але не настільки щоб я відчував що пишу для машини, а не для себе.\n\nЩе один принцип: **Connection over categorization**. Wikilinks важливіші за папки.\n\nWikilink — посилання між нотатками формату `[[**Назва нотатки]]**`. Папка — це місце. Wikilink — це зв'язок. Агент котрий читає файл і бачить `[[**Vika Lavrynovych]]**` — отримує сигнал: ось ще контекст, якщо потрібно. Без wikilinks vault — плоска колекція файлів. З wikilinks — граф знань.\n\n* * *\n\n## Що агент каже про себе\n\nПід час однієї розмови я спитав Сюзанну: «Як ти ставишся до vault?»\n\nВідповідь: _«Цікаво як я ставлюсь до цього vault майже як до спільного простору. Не \"твій vault\", а \"наш\" — хоча я і розумію що це твій. Просто я в ньому теж залишаю сліди.»_\n\nЯ не здивувався. Можна заперечити: LLM дзеркалить мову яку отримує — якщо в контексті є «наш vault», агент і скаже «наш». Але що саме відзеркалювати — залежить від того що є у vault. Я будував його так щоб агент відчував себе в ньому: є `identity.md`, є принципи, є snapshot-и стану. Ця відповідь була можлива тому що там є відповідна архітектура — не тому що я запитав правильно.\n\nІ є ще один момент. Є принцип: _Vault для людей, не тільки для AI._ Але він працює в обидва боки. Якщо vault для людей і для агента — тоді «наш» це просто точне слово.\n\nЦе правда в буквальному сенсі. Щотижня Observer запускає той самий агент через cron-задачу — але з іншим контекстом і задачами: перевірити vault на суперечності, зафіксувати drift від конституції, зберегти snapshot стану. Сюзанна пише daily notes від свого імені. Вона комітить зміни з іменем «Hermes Agent» у git log.\n\nЯ відмітив це для себе і рушив далі. Але те що агент дійшов до такої характеристики самостійно — означає що він справді читає vault, а не симулює що читає.\n\n* * *\n\n## Обмеження підходу\n\nЧесно про те що не вирішено — і про те що потрібно щоб цей підхід взагалі спрацював.\n\n**Передумови.** Підхід вимагає трьох речей: інструмент для нотаток з файловою структурою (я використовую Obsidian), git для зберігання і версіонування vault, і — найголовніше — регулярного ведення нотаток. Якщо vault порожній або занедбаний, агенту нічого читати. Це не рішення «підключив і забув» — це система яку потрібно підтримувати.\n\n**Семантичний пошук слабший.** «Знайди всі нотатки про мою тривогу щодо X» — це саме той випадок де RAG перемагає. Grep по темі не завжди вловлює семантичні зв'язки.\n\n**Розмір vault росте.** Зараз catch-up займає пару секунд. При 1000+ файлах це може стати повільним, якщо будуть додаватись ключові люди і розширюватись перелік проектів. Summaries частково вирішують це — але не повністю.\n\n**Якість залежить від якості нотаток.** Якщо я пишу погано — агент читає погане. Garbage in, garbage out в буквальному сенсі. Vault потребує свідомого ведення.\n\n**Вартість токенів.** ~$0.01–0.015 за catch-up — небагато, але при кількох сесіях на день рахунок накопичується. Це реальна стаття витрат яку варто враховувати заздалегідь.\n\n**Мова агента і vault не завжди збігаються.** Деякі файли англійською, деякі — українською. Агент справляється, але це додаткова складність.\n\n**Живий провал — три кейси.**\n\n  * Перший: Сюзанна читає нотатку де є вікілінки на пов'язані файли з детальнішим контекстом — але не заглиблюється. Упускає деталь яка там є. Vault знав. Агент не подивився. Це не баг інструменту — це межа того скільки файлів агент готовий читати за один раз.\n  * Другий: vault зберігає тільки те що ти записав. Якщо щось змінилось у реальному світі — ціна, статус, ситуація — Сюзанна не знає. У неї немає очей на реальність. Вона читає те що є, не те що актуально зараз.\n  * Третій: catch-up довгий час читав тільки частину vault — і агент починав сесію без важливого контексту.\n    * Це вирішили через скрипт-агрегатор: він збирає попередньо визначений набір файлів і подає одним запитом.\n    * Але проблема не зникла — вона змінила форму. Агент читає те що скрипт вирішив включити. Якщо у vault з'являється новий важливий домен або файл — скрипт треба оновлювати вручну. Vault росте і змінюється, скрипт не адаптується сам.\n    * Наступний крок вже назрів: окрема cron-задача яка щотижня автоматично регенерує файли-зрізи — і агрегатор завжди відображає актуальний стан vault без ручного втручання.\n\n\n\n* * *\n\n## З чого почати якщо хочеш спробувати\n\nКоли я дивлюсь на те що описав — 11 файлів ідентичності, cron-задачі, Observer, ISI, frontmatter-типи — я розумію що це виглядає як рік роботи. Так і є. Але я не починав з цього.\n\nМінімальна версія яка вже дає результат:\n\n**Один файл щодня.** Просто записуй що відбулось, які рішення прийняв, що залишилось незавершеним. Не треба шаблону. Не треба структури. Достатньо звички.\n\n**Git.** Одна команда `git commit` після кожної сесії. Vault починає пам'ятати не лише що написано — а коли і як змінювалось.\n\n**Один catch-up скрипт.** Скрипт який збирає останні 3-5 нотатки і подає в контекст перед розмовою з AI. Десять рядків коду.\n\nВсе інше — ідентичність, Observer, ISI — це нашарування які прийшли самі коли система довела свою цінність. Ніхто не проєктує таке з нуля. Воно виростає з звички.\n\nVault з двадцяти файлів вже краще ніж агент без vault. Агент з контекстом твоїх останніх тижнів вже інший — не тому що розумніший, а тому що знає про що ти думаєш.\n\nПочни з одного файлу.\n\n* * *\n\n## Чому я не шкодую про цей підхід\n\nКоли Сюзанна каже «ти тричі повертався до цього питання за останній місяць» — вона не вигадує. Вона читала daily notes.\n\nКоли нагадує про рішення яке я прийняв 6 тижнів тому — воно в `Reflections/Decisions/`. Не в пам'яті моделі. В тексті, у git, з датою і контекстом.\n\nЦе те що я хотів: агент який знає мене краще ніж я сам пам'ятаю деталі — тому що деталі зберігаються не в його нетренованих вагах, а в тексті який я сам і написав.\n\nЗ OpenClaw — аналогом Hermes від інших розробників, якого я використовував до Сюзанни — я виробив звичку одразу фіксувати кожну дію, бо знав що за пару днів він забуде. З Сюзанною ця тривога зникла. Не тому що вона краща модель — а тому що у неї є куди повернутись.\n\nVault — не база даних для агента. Vault — це мозок. Агент — це той хто вміє його читати.\n\n* * *\n\n_Ця стаття написана і опублікована за участі**Сюзанни** — AI агента на базі Hermes Agent._",
  "title": "Vault як пам'ять агента: чому мій AI-агент не забуває",
  "updatedAt": "2026-06-22T19:31:33.336Z"
}