Допълнителна Памет за Coding и Autonomous Agents (anti soft vendor lock-in)

coolice

Owner
Агентът ви забравя. Не постепенно, а напълно, в момента, в който сесията приключи. Всичко, което е научил за вашата кодова база, вашите предпочитания, трите мъртви пътища, които вече е изследвал, за да ви спести усилия. Утре той започва отново като непознат, който просто е много добър в четенето.


В продължение на две години рефлексният отговор винаги е бил „дайте му по-голям прозорец (контекст).“ Прозорецът е работна повърхност (бюрото). Паметта е шкафът зад гърба ви. Купуването на по-голямо бюро не ви осигурява архив. Без шкаф всяка сутрин пренареждате бюрото от нулата — и плащате отново за същото подреждане.


Това седмица трендваха две repository – с различни автори, от различни страни, под различни лицензи, на различни езици, без никаква връзка между тях. Едното идва от голяма платформена компания с зад гърба си и статия в VLDB 2026. Другото е проект на един разработчик с README, по-дълъг от първите глави на повечето книги. Те решават точно една и съща задача и се разминават в почти всичко. И двата обаче насочват към една и съща, по-неприятна истина: паметта на кодинг агента вече е soft vendor lock-in. Не твърд — не ви заключват файла, не ви криптират репото. Мек: сменяте инструмента и губите човека, който вече знае къде стърчат коловете.


Моделите са почти взаимозаменяеми. Харнесът — Cursor, Claude Code, Codex, OpenCode — също започва да се комодитизира. Това, което не се пренася с един export, е натрупаното: защо онзи PR беше отхвърлен, че не пипате legacy/billing, че „тъмният режим“ е предпочитание, а не каприз, че третият подход към миграцията вече е мъртъв. Без да извлечете тази памет, новият агент не е „същият агент на друга платформа“. Той е стажант с отлични оценки и нулева институционална памет.


Две философии за един и същ шкаф​


OpenViking-trending.png


OpenViking третира контекста като база данни: виртуална файлова система под viking://, в която агентът навигира с ls, tree и find, вместо да пита черна кутия от вектори. Всеки запис се пише в три нива — абстракт от ~100 токена, обобщение от ~2K и пълно описание. И ето най-добрата идея в двете репозитория: всяка директория носи собствените си .abstract и .overview, така че агентът може да прецени релевантността, преди да прочете какъвто и да е пълен файл. Библиотека с картотечен каталог на всеки рафт.


Механизмът за търсене намира директорията с най-висок резултат и навлиза по-дълбоко в нея, „за да стигнат резултатите в пълния си контекст“. Всеки въпрос запазва траекторията на претърсване — можете да я проследите отново, ако някой резултат изглежда грешен. Памет, ресурси и умения живеят в едно адресно пространство. Има интеграции към Claude Code, Cursor, Codex, OpenCode, MCP. Има хартия (VikingMem) и амбиция за „контекстна база“ в корпоративен смисъл.

OpenViking.png

Цената на тази мощ е формат и стек. AGPL, собствен URI, слоеве, индекс, сървър. Преносимостта е възможна — това е отворен проект — но не е „отвори папката в Obsidian и grep-ни“. Ако утре смените агента без да изнесете viking:// слоя, новият инструмент няма да наследи нито предпочитанията, нито траекториите, нито душата (soul.md) на стария. Ще наследи само кода. Кодът никога не е бил целият контекст.



ai-memory.png


ai-memory (и близките му братовчеди като llm-wiki-memory) третира контекста като обикновен текст: „Уикито е обикновен markdown в git repository — с него може да се прави grep, отваря в Obsidian, архивира с rsync.“ Няма векторна база за гледане. Няма церемония write_note. Hooks се записват подкани, tool call-ове и граници на сесии. В края на сесията наблюденията се компилират в страници — в духа на Karpathy: compile, don’t retrieve raw logs.

Напускате Claude Code по средата на задачата, отваряте Codex в същата директория часове по-късно — следващият агент вижда блок „къде спряхме“, преди първия промпт.



Това е друга теория за lock-in. Ако източникът на истина е markdown + git, смяната на агента е смяна на четец, не на архив. Можете да diff-нете какво е „научил“ агентът. Можете да отхвърлите урок. Можете да клонирате уикито на друг лаптоп без да молите платформата за export. Слабостта е обратната на OpenViking: по-малко йерархична навигация, по-малко гарантирана икономия на токени чрез L0/L1/L2, повече доверие, че агентът ще прочете правилното парче текст в правилния момент.


Защо това е lock-in, макар да изглежда като удобство​


Класическият vendor lock-in беше схема, API, лиценз. Тук заключването е асиметрия на знанието. Агентът, който е минал с вас през три неуспешни рефакторинга, струва повече от агента с по-добър бенчмарк. Платформите го знаят. Вградената памет на харнеса е най-лесният бутон и най-скъпият дълг: живее в техния формат, в тяхната сесия, понякога дори в техния сървърен compaction, който друг модел не може да прочете.


Затова „просто смени агента“ е илюзия, ако не сте извлекли паметта. Ще запазите репото. Ще загубите:

  • предпочитанията (стил, забранени директории, любими команди);
  • отрицателното знание (какво не работи — най-скъпото знание);
  • траекториите (защо решението изглежда така, а не иначе);
  • handoff-а („къде спряхме“ не е README).

Новият агент ще прочете кода блестящо и ще предложи отново Път №2 — този, който миналата седмица вече е бил мъртъв. Вие ще платите отново за откритието. Това не е „леко търкане при миграция“. Това е институционална амнезия с абонамент.


Soft е, защото никой не ви спира. Можете да тръгнете. Просто тръгвате голи.


Какво следва от представянето на тези две repositories​


Двата проекта не се състезават кой е „по-умен RAG“. Състезават се кой притежава формата на спомена.

OpenViking казва: споменът е управляван обект — слоеве, URI, наблюдаема траектория, споделяне между много агенти през една база.
ai-memory казва: споменът е файл, който човекът също притежава — иначе агентът ви държи като заложници чрез удобство.


И двете са по-добри от „по-голям контекстен прозорец“. Нито едното не ви спасява автоматично от lock-in. Спасява ви само ако паметта е извън харнеса и можете да я вземете със себе си: export, markdown, git, документиран schema, не „работи само в нашия IDE“.


Правилото е просто и неудобно. Ако не можете един следобед да извадите това, което агентът знае за вас, и да го поддадете на друг агент без ръчно преразказване — не сте собственик на паметта. Наели сте я. А наетата памет е най-мекият и най-лепкав lock-in, който инструментите за код са произвели досега.


Утре агентът пак ще забрави сесията. Въпросът вече не е дали ще забрави. Въпросът е дали забравянето е ваш избор — или бизнес модел на платформата, която не иска да тръгнете с архива под мишница.


Личен опит:​


Преди две седмици се сблъсках с проблема с паметта по принцип не ми беше направило голямо впечатление понеже Hermes Agent държи Memory.md с 2000 токена и периодично изпразва неща който смята че не са важни Но при едно поредно почистване забрави мини проект който не бях сейвнал като скил защото се ползваше рядко и в текущата сесия взе да го мисли отначало затова отворих документацията пргледах какво се предлага като опции ...

Накрая стигнах до OpenViking и Hindsight

При OpenViking ме грабна L0, L1, L2 дизайна, при Hindsight част от спецификациите но имаше лаг като го тесвах и останах с викинга вече почвам трета седмица не мисля да го сменям - пасна


До днес не бях го мислил, понеже не кодя много (предимно пускам дребни неща) че при Coding Agents паметта е още по важна и че всъщност е вид soft vendor lock-in. Ако си смените харнеса от Codex или от Cloud Code, на OpenCode или на новия трендващ DeepSeek Harnes или някой друг, ще ви се струва различно или даже прекалено различно и ще ви тегли на обратно...

Затова като минимум без да спорим коя архитектура е по-добра. свалете си поне ai-memory който прави 100% портабъл .md и кажете на агента да обходи всички стари сесии и да генерира памет за тях... най малкото вие сте я създали тази памет защо да се ползва само да обогатява агента за който си плащате една торба пари на месец a да не си я имате запазена при вас...

Оделно че може да подобри поведението на Coding Agent-а ви... За Autonomous Agent аз съм много доволен....


Поста ми от 7 август
Предистория:
Вчера си разширявах паметта на Hermes агентa и измежду Local опциите стигнах накрая до избор между OpenViking и Hindsight (защо разширявах паметта и защо избрах OpenViking е за друга тема една) но на кратко



OpenViking – Peers + Multi-tenant

  • Има ясна йерархия: account → user → peer
  • Peer = отделна „личност“ / роля / партньор в рамките на един user.
  • Можеш да имаш различни peers (напр. „coding-assistant“, „personal-coach“, „research-agent“) с отделни memories и resources, но споделен account-level контекст.
  • Много удобно за множество агенти / личности, които споделят част от знанието, но имат собствена история и стил.
  • Multi-tenant е вграден (account isolation + роли ROOT/ADMIN/USER).
Hindsight – Banks + Tags + Mental Models

  • Основна единица е Bank (memory bank).
  • Препоръчително: един bank на user / project / persona.
  • Вътре в bank можеш да използваш tags (напр. user:123, shared, persona:coder) за фина изолация.
  • Mental Models = предварително изчислени „личности“ или стратегии (напр. „как говори този user“, „как решаваме задачи в този проект“).
  • Много гъвкаво за multi-agent системи: можеш да имаш shared bank + private banks + hybrid.
  • По-силен при различни поведенчески профили и evolving opinions.
Обобщение за multiple personality:

  • Ако искаш ясни, изолирани личности с възможност за споделяне на ресурси → OpenViking (Peers) е по-елегантен.
  • Ако искаш различни личности, които учат и формират собствени opinions/beliefsHindsight (Banks + Mental Models) е по-мощен.
😭🤣😅

 
Последно редактирано:

Горе