Hugging Face опублікували гайд під назвою «Funes» — покроковий рецепт, як дати кодовому агенту персистентну памʼять, яку контролює сам розробник, а не вендор моделі. За даними Hugging Face, ідея проста: замість того, щоб покладатися на «памʼять» від Anthropic, OpenAI чи Cursor — чорну скриньку, яку можна вимкнути чи змінити одним апдейтом продукту, — розробник тримає історію рішень, контексту й прогресу в файлах, які сам зберігає, версіонує і читає.

Назва «Funes» — ймовірно, відсилання до оповідання Хорхе Луїса Борхеса «Фунес, дивовижна памʼять», де герой не забуває нічого і саме через це парадоксально не здатний мислити абстрактно. Для кодового агента проблема дзеркальна: без жодної памʼяті він щоразу починає з нуля, а з чужою, непрозорою памʼяттю — залежить від того, що вендор вирішив запамʼятати і показати.

Для тих, хто будує довготривалих агентів поверх відкритих інструментів — LangChain, власних CLI-обгорток, agent SDK — це різниця між «орендованою» і «власною» довготривалою памʼяттю. Hugging Face останнім часом активно експериментує на стику агентів і коду — раніше компанія навчила код-модель малювати акварелі через RL, — і гайд про памʼять логічно продовжує цю лінію.

Що саме пропонує гайд Hugging Face?

Ключова теза — памʼять агента має бути таким самим артефактом проєкту, як код чи тести: файлом або набором файлів у репозиторії, які агент читає на старті сесії і дописує по ходу роботи. Сама ідея не нова — Claude Code вже давно використовує CLAUDE.md, Cursor — .cursor/rules, — але Hugging Face формалізують підхід як окрему дисципліну: що саме записувати, коли перезаписувати, а коли просто дописувати, і як не дати файлу памʼяті розповзтися до нечитабельного стану.

Головна відмінність від вбудованої памʼяті продуктів — контроль. Файл лежить у git-репозиторії розробника, його видно в diff, його можна відкотити, змерджити чи скопіювати в інший інструмент. Якщо завтра команда перейде з Claude Code на іншого агента, памʼять переїде разом із кодом — а не залишиться замкненою всередині одного вендора.

Чим це відрізняється від памʼяті, яку вже дають Claude чи Cursor?

Вбудовані механізми памʼяті в комерційних агентах вирішують ту саму проблему, але з протилежного боку контролю. Вендор визначає формат, ліміти розміру, коли памʼять оновлюється автоматично і що саме туди потрапляє — розробник здебільшого бачить лише результат. Підхід, який описують Hugging Face, переносить ці рішення на бік розробника: він сам вирішує гранулярність (одна памʼять на проєкт чи на модуль), формат (Markdown, YAML, окремі файли за темами) і момент запису.

Ціна такого контролю — ручна дисципліна: ніхто не прибере за агентом застарілі записи автоматично, і без чіткого протоколу файл памʼяті швидко перетворюється на смітник. Тому гайд, за словами Hugging Face, концентрується не на технології зберігання (звичайні файли впораються), а на процесі — коли й що саме варто фіксувати.

Кому і навіщо це потрібно на практиці?

Найбільше виграють команди, що будують агентів для довгих, багатоденних задач — рефакторингів, міграцій, роботи над одним репозиторієм тижнями. Без персистентної памʼяті кожна нова сесія агента — це втрата контексту про те, які підходи вже пробували, чому відхилили якийсь варіант, які частини кодової бази чутливі.

Для тих, хто просто користується Claude Code чи Cursor «з коробки», підхід Hugging Face менш критичний — там памʼять уже вбудована. Але навіть у цьому разі ідея тримати ключові рішення проєкту в читабельному файлі, який переживає будь-яку сесію, працює як дешева страховка від vendor lock-in.

Висновок AiiN

Наша теза: памʼять агента стає інфраструктурним рішенням, а не фічею продукту, — і команди, які усвідомлять це раніше за інших, отримають перевагу в переговорах про ціну й вибір моделі, бо не будуть заручниками одного вендора. Хто вже зараз тримає контекст агента у власних файлах, а не в закритій памʼяті провайдера, той може будь-якої миті мігрувати між дешевшими відкритими моделями і топовими — без переписування накопиченого контексту з нуля.

Чим памʼять агента відрізняється від контекстного вікна?

Контекстне вікно — це обʼєм тексту, який модель бачить в одному запиті, і воно очищається між сесіями. Персистентна памʼять, навпаки, зберігається на диску між сесіями і підвантажується в контекст вибірково — лише те, що агент вирішив запамʼятати.

Чи потрібна для цього окрема база даних?

Ні: підхід, описаний Hugging Face, свідомо використовує прості файли в репозиторії, а не векторну базу чи окремий сервіс — це знижує поріг входу і робить памʼять такою ж переглядабельною, як звичайний код.