Памʼять AI без смітника: що залишати в сесії, vault і skill

ai · 2026-10-12

AI-агент не має памʼятати все. Якщо кожну відповідь, тимчасову гіпотезу й разовий лог складати в один «memory.md», через місяць пошук почне повертати суперечності, а контекст — зайвий шум. Надійніша модель має три рівні:

сесія — поточна задача, її припущення, відкриті файли та незавершені дії;
vault — підтверджені рішення, дослідження, домовленості й короткі handoff-записи;
інструкція або skill — правило чи процедура, яку потрібно відтворювати однаково.

Це не три назви для одного сховища. Це різні терміни життя й різні вимоги до якості даних.

Як це вирішують Claude, Codex і OpenCode

У Claude Code memory явно розділено два механізми: CLAUDE.md/AGENTS.md містять написані людиною правила, а Auto Memory накопичує засвоєні уподобання й контекст. Обидва завантажуються на початку розмови, але документація застерігає: це контекст для моделі, а не примусова політика. Для блокування дії потрібен hook. Практичний висновок: рішення «завжди запускай перевірку» не варто залишати лише в автоматичній памʼяті.

Codex CLI робить акцент на продовженні збережених чатів і командному керуванні робочим циклом; окремо екосистема Codex використовує AGENTS.md, skills і plugins. Сесія зручна для повернення до незавершеної задачі; skill — для повторюваної процедури; plugin — для підключення зовнішнього інструмента або даних. Це хороша межа: історія розмови зберігає робочий стан, але не повинна ставати єдиним довідником про архітектуру проєкту.

В OpenCode AGENTS.md створюється для розуміння структури проєкту, а Plan mode обмежує зміни під час аналізу. Окремі skills і agents дають адресні процедури та різні межі інструментів; для довідкових каталогів є explicit reference boundary, але звичайні дозволи інструментів усе одно діють. Отже, довгий список процедур не треба вбудовувати в кожну сесію: його краще зробити адресним skill.

Усі три підходи сходяться в одному: постійні правила мають бути короткими й версіонованими, процедури — повторно використовуваними, а робочі деталі — локальними для задачі. Відмінність у механіці не скасовує цього поділу.

Робоче правило для OpenClaw

Перед записом нового фрагмента поставте три питання:

Чи потрібен цей факт після завершення поточної задачі?
Чи має він змінювати поведінку агента в майбутньому?
Чи можна перевірити його джерело й дату?

Відповіді ведуть у різні місця:

Відповідь	Куди писати	Приклад
Ні, це лише стан поточної роботи	Сесія або handoff	«Залишилося перевірити третій варіант»
Так, це знання або рішення	Vault	«Для staging обрали окремий namespace через…»
Так, це повторювана дія	Skill або інструкція	«Перед публікацією запусти validator і build»

Handoff має бути коротким і придатним для читання без усього діалогу:

---
date: 2026-10-12
status: active
---

## Стан
- Мета: перевірити ротацію ключів у тестовому середовищі.
- Підтверджено: новий ключ приймається сервісом.
- Не підтверджено: відкликання старого ключа.

## Наступні дії
1. Запустити перевірку відкликання.
2. Зберегти результат у decision-note, якщо тест пройде.

## Обмеження
- Не змінювати production.
- Не записувати значення ключів у нотатку.

Такий запис не прикидається остаточним знанням. Після перевірки його або закривають, або перетворюють на коротке рішення з посиланням на докази.

Чотири практичні схеми

1. Vault як відфільтрований журнал рішень

Зберігайте в Obsidian або іншому Markdown-vault не весь діалог, а сторінки типу decision, research, bug і session. Для кожної сторінки потрібні дата, статус, джерела й одна теза в описі. Додайте індекс каталогу, щоб агент спочатку знаходив карту знань, а не перечитував усі документи.

У OpenClaw це дає простий playbook: на старті знайти релевантну сторінку; під час роботи не редагувати сирий журнал; після підтвердження оновити одну канонічну сторінку та її індекс. Перевага — менше дублювання. Недолік — потрібен окремий крок редактури, інакше vault швидко стане архівом припущень.

2. Інструкція — для інваріантів, skill — для алгоритму

У AGENTS.md або SOUL.md залишайте лише те, що має діяти майже завжди: мову відповіді, межі доступу, заборону секретів, обовʼязкову перевірку результату. Послідовність із пʼяти кроків винесіть у skill із чіткою умовою запуску.

Наприклад, інструкція може вимагати «не публікувати без перевірки», а skill описує, як саме прочитати frontmatter, запустити validator, виконати збірку й сформувати receipt. Так агент не отримує великий процедурний текст у кожній сесії, але може завантажити його тоді, коли задача справді про публікацію.

3. Розділіть Telegram-вхід і робочих агентів

Для бота з кількома ролями корисно мати один агент-розподільник, який приймає повідомлення й створює короткий handoff, та окремих агентів для дослідження, коду або публікації. У кожного — власний workspace, session store і дозвільна політика; спільним лишається лише відібраний vault або папка з опублікованими рішеннями.

У моделі multi-agent OpenClaw агент охоплює workspace, auth-профілі та історію сесій, а binding маршрутизує канал до потрібного агента. Не варто вважати, що додавання другого агента автоматично розділить глобальне сховище plugin-а: межу памʼяті треба налаштувати явно.

Схематично конфігурація має виглядати так:

{
  "agents": {
    "defaults": { "skills": ["shared-safe-baseline"] },
    "entries": {
      "router": {
        "workspace": "workspace-router",
        "skills": ["route-and-handoff"]
      },
      "research": {
        "workspace": "workspace-research",
        "skills": ["research-and-cite"],
        "tools": { "write": false }
      },
      "publisher": {
        "workspace": "workspace-publisher",
        "skills": ["validate-and-publish"]
      }
    }
  }
}

Це зменшує blast radius, але збільшує кількість handoff-ів і ризик розходження копій. Для маленької системи один агент із вузькими skills простіший; ізоляція виправдана, коли ролі мають різні канали, секрети або право запису.

4. Незвичний, але корисний патерн: memory compiler

Замість дозволяти кожному агенту довільно дописувати памʼять, зробіть окремий нічний процес-компілятор. Він читає завершені handoff-и, знаходить повтори й суперечності, готує невеликий diff до канонічних сторінок, а опублікувати його може лише validator або людина.

Мінімальний контракт такого процесу:

input:
  - completed session handoffs
  - source links
output:
  - proposed markdown diff
  - duplicate candidates
  - claims_without_source
policy:
  - never overwrite canonical decisions automatically
  - never copy secrets or raw credentials
  - reject notes without date and status

Це дорожче за «запамʼятовуй усе»: додає затримку, окремий job і чергу конфліктів. Зате памʼять стає reviewable артефактом, а не прихованою поведінкою моделі. Для технічних рішень, доступів і production-процедур такий trade-off зазвичай виправданий.

Перевірка якості памʼяті

Раз на тиждень проганяйте короткий аудит:

чи має кожна канонічна сторінка дату й джерело;
чи немає двох активних сторінок про одне рішення;
чи не перетворилася інструкція на довідник із випадковими деталями;
чи може новий агент виконати процедуру лише за skill і посиланнями;
чи відповідають межі workspace, session store і Telegram binding потрібному рівню ізоляції.

Найкраща памʼять AI — не найбільша. Вона має бути короткою, адресною, перевіреною й достатньо відокремленою, щоб помилка в одному шарі не переписала всі інші.