Пам’ять і знання

Для чого потрібна памʼять

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

У неї є три шари, і вони відповідають на різні питання:

Факти — те, що є правдою (домовленість, результат, рішення).
Політики — те, що агенти мусять із цим робити (нормативне правило).
Робоча памʼять — те, над чим саме працював один агент.

Ця відмінність важлива, бо до агента вони потрапляють різними шляхами. Факти шукають. Політики проштовхують. Робоча памʼять приватна.

Факти

MemoryFact — це одиниця знання, обмежена робочим простором і доменом.

Атрибут	Що це
`domain`	Домен знань («conventions», «decisions», «codebase»)
`topic`	Коротка назва теми
`content`	Текст знання
`confidence`	0,0–1,0, задається походженням і підвищується за повторної згадки
`memoryType`	Тип факту — визначає його криву часового згасання
`veracity`	Як його було встановлено — задає початкову впевненість і визначає розмір кожного підвищення за повторну згадку
`sourceObservationIds`	Які спостереження до нього привели
`supersededBy`	Новіший факт, що його замінив, якщо такий є
`validUntil`, `recallCount`, `mentionCount`	Сигнали завершення терміну дії та використання, які застосовуються під час пригадування

Останні два рядки найчастіше й упускають, а саме вони вирішують, який факт вирине на поверхню. memoryType містить параметри згасання Вейбулла для кожного типу, тож обмежене в часі зобовʼязання згасає швидко, а стабільний факт профілю — ні. veracity фіксує походження — встановлено людиною (вага 1,0), виведено агентом (0,7), отримано інструментом (0,5), імпортовано (0,6) — і ця вага задає початкову впевненість факту.

Коли факт суперечить іншому, його ніколи не редагують на місці. Запис факту запускає виявлення конфліктів із фактами того самого домену й теми та заміщає того, хто програв, створюючи рядок конфлікту. Сенс саме в журналі аудиту: ви завжди бачите, у що вірили раніше і що це замінило.

Політики

MemoryPolicy — це нормативне правило, виведене з фактів, обмежене робочим простором і доменом, з прапорцем активності та необовʼязковим requiredRole.

Кожна активна політика в робочому просторі вставляється в кожну диспетчеризацію без фільтрування — жодного фільтра за доменом, роллю, завданням чи простором. Це варто знати, перш ніж писати свою двадцяту політику, адже політики конкурують за те саме вікно контексту, що й завдання. Саме тому requiredRole у політиці має лише рекомендаційний характер: він описує, на кого спрямоване правило, але не заважає правилу дійти до всіх інших.

Домени

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

Домен або охоплює весь робочий простір (architecture), або обмежений одним репозиторієм (repo:<slug>/architecture). Те саме імʼя в обох областях — це два незалежні сховища: факт, істинний для однієї кодової бази, не перезаписує факт на рівні робочого простору. search_memory і преамбула диспетчеризації ставлять памʼять у межах репозиторію на перше місце, коли агент працює в цьому репозиторії; решту вони не відфільтровують. Передайте repo у propose_fact / propose_policy / search_memory, щоб записати в цю область або підсилити її.

Контроль доступу до читань відкритий за замовчуванням

MemoryAccessGrant зіставляє роль агента та домен з одним із трьох рівнів дозволу:

Дозвіл	Значення
`none`	Немає доступу
`read`	Може шукати й отримувати факти
`write`	Потрібен для `propose_policy`. Запис фактів (`propose_fact`, `supersede_fact`) не потребує дозволу

Коли для пари (role, domain) немає рядка дозволу, чинний дозвіл — read. Читання навмисно працюють за принципом «відмова — це дозвіл». Єдиний запис, який спричиняє помилку, — це propose_policy без дозволу write (InsufficientMemoryPermission). Розміщення чутливого вмісту в домені памʼяті не обмежує коло тих, хто може його читати, якщо ви явно не записали дозвіл none для кожної ролі, яка не повинна його бачити.

Крім того, сьогодні в продукті ніде немає інтерфейсу для дозволів. Екран памʼяті має вкладки «Факти», «Політики» та «Граф знань», і більше нічого; дозволи доступні лише через RPC-операції memory_access_grant.*.

Ця асиметрія — мʼякість до читань і жорсткість до запису політик — свідомий компроміс. Памʼять найкорисніша, коли вона циркулює, а відмова в читанні породжує агента, який тихо знає менше, замість агента, який повідомляє про проблему. Відмова ж у записі політики, навпаки, гучна й виправна, тож саме там і міститься примус. Новостворений домен видає дозвіл write кожній ролі; посилити його згодом можна лише через RPC, бо інтерфейсу дозволів немає.

Робоча памʼять

У кожного агента є AgentWorkingMemory: чернетка довільного тексту, привʼязана до робочого простору й агента. Вона переживає запуски, приватна для цього агента і вставляється в його промпт під час кожної диспетчеризації. Саме тут живе «я зупинився на півдорозі рефакторингу автентифікації» — стан, який варто перенести в наступний запуск, але не варто підносити до рівня довготривалого факту.

Що насправді потрапляє в промпт агента

Під час диспетчеризації преамбула памʼяті збирається рівно з трьох речей:

Кожна активна політика робочого простору — у вигляді рядків - [domain] rule.
Власна робоча памʼять агента — дослівно.
Короткий список фактів, відібраних за ключовими словами, для цього завдання — щонайбільше пʼять, у межах бюджету ~1 200 символів і лише коли опис завдання має щонайменше 20 символів. Коротші завдання не отримують фактів узагалі.

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

На цьому шляху дозволи доступу не враховуються. Що б не знайшов короткий список, саме це й побачить агент.

Пригадування: один запит, чотири голоси

Інструмент search_memory, доступний агенту, має три режими, і це справді різні пошуки:

keyword — лише FTS5.
semantic — результати BM25 і векторного пошуку, обʼєднані взаємним ранговим злиттям.
hybrid (типовий) — поліфонічне пригадування: чотири ранжовані голоси зливаються разом, а потім урізноманітнюються.

Ці чотири голоси — лексичний (FTS), семантичний (векторний KNN), часовий (нещодавні активні факти) і графовий, тобто обхід на два кроки епізодичними ребрами від найсильніших лексичних і семантичних початкових точок. Графовий голос — це власне причина, чому епізодичні ребра взагалі існують: він виводить на поверхню факт, повʼязаний з вашою відповіддю, навіть коли жодне ваше слово з ним не збігається. Голоси зважуються за класифікованим наміром запиту (семантичний за замовчуванням має найбільшу вагу, далі графовий і лексичний, потім свіжість), оцінка кожного кандидата масштабується його згасанням Вейбулла, а набір результатів урізноманітнюється через MMR, щоб пʼять переказів одного факту не витіснили чотири різні.

Векторний голос додається лише після того, як завантажено локальну модель векторних подань. До того гібридне пригадування працює з трьома голосами, і ретроактивного дозаповнення немає — факти, записані до встановлення моделі, векторів так і не отримують. Векторний шлях деградує ще далі, до сканування упакованих векторів кодом на Dart, якщо саме розширення SQLite для векторів не завантажиться; пригадування все одно відповідає, просто повільніше.

Пошук у памʼяті в настільному застосунку та в вебі — окремий, простіший шлях: RPC-операція memory_fact.search підтримує лише FTS5, бо тонкий клієнт не може надіслати вектор запиту, а гібридний шлях залишається внутрішнім для хоста. Тож ранжування, яке ви бачите в оглядачі памʼяті, — не те ранжування, яке агент отримує від search_memory. Це очікувано, а не помилка, але означає, що «я пошукав і не знайшов» в інтерфейсі не є доказом того, що агент не знайде.

Де живе памʼять і хто її пише

Оглядач памʼяті розташовано за шляхом Налаштування → Робочий простір → Памʼять (/workspaces/<id>/settings/memory), з вкладками «Факти», «Політики» та «Граф знань».

Там є асиметрія, яка багатьох дивує: памʼять можна редагувати й видаляти, але не можна створювати. Ні на вкладці «Факти», ні на вкладці «Політики» немає можливості додати запис. Авторство належить агенту — через propose_fact і propose_policy (supersede_fact / supersede_policy для заміни). remember записує елемент гарячого рівня, обмежений сеансом, який consolidate_memory згодом може піднести до факту; record_observation і update_my_notes пишуть приватну чернетку, що вставляється під час диспетчеризації. Оглядач — це поверхня перегляду й виправлення, а не авторства, тож якщо ви хочете факт у памʼяті, єдиний спосіб його туди покласти — сказати агенту.

Дві операції обслуговування так само запускає агент, а не розклад: consolidate_memory обʼєднує й чистить накопичені факти, а harmonize_memory узгоджує уявлення, що розійшлися між агентами. list_memory_conflicts показує те, що вже зафіксувало виявлення конфліктів. Ніщо не запускає їх для вас за таймером. Рішення із зустрічей потрапляють у домен decisions, коли крок збереження зустрічі їх записує; це не таймер на завершених запусках агентів.

Повʼязані поняття

Модель агента: саме на ролі пишуться дозволи
Робочі простори та ізоляція: памʼять обмежена робочим простором і живе у власному файлі бази даних цього простору
Керувати памʼяттю робочого простору: робота з памʼяттю на практиці