Пам’ять ШІ-агентів і dreaming: чому ШІ знову все забув

Я натрапив на відео про пам’ять ШІ-агентів і захотів розібрати його докладніше. Назва обіцяє навчання, поки ми спимо: Learning while you sleep: Beyond memory to dreaming. Але мене тут зачепила цілком робоча проблема: ти вже пояснив помічнику, як треба робити, виправив його, отримав нормальний результат. Починаєш нову розмову - і знову пояснюєш те саме.

В одній розмові агент враховує зауваження. В іншій може повернутися до попереднього варіанта. Додаєш більше інструкцій - поступово отримуєш документ, у якому вже самому складно знайти потрібне правило. А якщо з цим контекстом працюють кілька агентів, виникає ще й питання: хто туди що записав і чому інші мають цьому довіряти?

Саме про це розповідає Lamis Mukta з Anthropic у виступі на AI Native DevCon. Вона проходить шлях від звичайного файла з інструкціями до окремого процесу, який переглядає досвід агентів і наводить лад у їхній пам’яті. Цей процес називається dreaming.

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

Відео, з якого все почалося

Lamis Mukta - Learning while you sleep: Beyond memory to dreaming. Відео англійською, приблизно 32 хвилини разом із запитаннями. Відкрити на YouTube.

Якщо хочеться одразу перейти до конкретної частини:

Сильніша модель не знає, як працює саме ваша команда

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

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

Нова модель може загалом бути розумнішою. Ваша локальна домовленість від цього не стає їй відомою.

Для мене це важлива відправна точка. Частину проблем із помічником ми намагаємося розв’язати вибором кращої моделі, хоча потрібна інформація просто не потрапила до її робочого контексту. Або потрапила колись, але не збереглася до наступної задачі.

У виступі це розкладається на три обмеження:

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

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

Контекст і пам’ять - різні речі

Тут варто одразу домовитися про слова.

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

Зберегти щось у пам’яті ще недостатньо. Треба також знайти потрібний запис, завантажити його в доречний момент і зрозуміти, чи він досі актуальний.

Тобто папка з тисячею нотаток сама собою не розв’язує проблему. Якщо агент не знаходить потрібне правило або читає застарілу версію, користі від самого факту збереження небагато.

Мені здається, саме цей перехід легко пропустити: ми питаємо, чи є у помічника пам’ять, хоча не менш важливо, як він нею користується і хто підтримує її в порядку.

Від одного файла до пам’яті, яку агент веде сам

У частині про еволюцію пам’яті Lamis описує кілька підходів. Я б не сприймав їх як обов’язкові сходинки, де кожна наступна повністю скасовує попередню. У них різні завдання, і вони можуть працювати разом.

Один файл із головними правилами

Перший варіант - CLAUDE.md: звичайний Markdown-файл із домовленостями, орієнтирами в проєкті та вподобаннями. За словами спікерки, такий простий підхід виявився дуже ефективним.

Це легко зрозуміти. На початку роботи агент одразу бачить важливі правила, замість того щоб щоразу відновлювати їх із ваших виправлень.

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

Інструменти для читання й запису пам’яті

Наступна ідея - дати агенту можливість самому вирішувати, що варто зберегти, коли прочитати попередні записи і коли їх оновити.

Це вже змінює розподіл роботи. Людині не потрібно вручну формулювати кожну нотатку. Агент може помітити корисну деталь під час виконання задачі й записати її для майбутнього.

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

Навички для докладних процедур

Окремо спікерка говорить про skills, тобто навички: інструкції для певних процедур. Наприклад, коли важливо дотриматися визначеного порядку підготовки матеріалу або перевірки результату.

Корисна ідея тут - поступове завантаження подробиць. Агент спочатку бачить короткий опис навички й читає повну інструкцію, якщо вона потрібна для роботи.

У відео є хороша аналогія з книжковою полицею. Не потрібно читати всі книжки перед кожною розмовою. Спочатку дивишся на назви, а потім береш ту, яка зараз потрібна.

Так само й з інструкціями. Процедура може бути докладною, але не зобов’язана постійно займати місце в контексті кожної задачі.

Пам’ять як звичайні файли

Далі - каталог із файлами, які агент може шукати, читати, редагувати й упорядковувати. У виступі згадуються Markdown, Bash і grep: зрозумілий текст та звичайні засоби роботи з файловою системою.

Для мене тут головне - можливість вибірково знаходити інформацію. Пам’ять може бути значно більшою за те, що треба прочитати для одного конкретного завдання.

Як я розділив би ці ролі:

Що зберігаємо	Для чого це потрібно	Приклад
Постійні правила	Задати базові вимоги до роботи	Мова матеріалів, обмеження, домовленості
Докладні процедури	Повторювати певний процес у потрібному порядку	Підготовка статті, перевірка змін
Накопичені знання	Не втрачати корисний досвід	Причина попередньої помилки, перевірений спосіб виконання задачі
Тимчасові робочі нотатки	Допомогти з поточною роботою	Проміжні висновки та незавершені перевірки

Це моя практична схема за мотивами виступу. Вона допомагає не складати всі види інформації в один нескінченний файл.

Три речі, які варто забрати вже на цьому етапі

Приблизно на 08:21 спікерка підсумовує попередню частину.

Формат має бути зрозумілим людині. Markdown зручний тим, що можна відкрити запис і прочитати, чого саме агент навчився. Це також спрощує перевірку й виправлення.

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

Агенту потрібна самостійність у веденні нотаток. Він може помічати корисні деталі без окремої команди людини на кожен запис.

Останній пункт я б читав разом із наступною частиною виступу. Самостійність ще не означає, що будь-якому агенту варто дозволити змінювати будь-яку спільну інструкцію.

Один агент і команда агентів - різні умови роботи

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

Двоє одночасно змінили один запис. Хтось записав неправильний висновок. Тимчасове спостереження стало загальним правилом. Інструкція застаріла, але ніхто не знає, хто її додав і на чому вона ґрунтувалася.

Особливо неприємний сценарій: один агент зробив хибний висновок, записав його до спільної пам’яті, а решта почала використовувати цей запис як перевірене знання.

У частині про масштабування Lamis називає кілька властивостей, які потрібні такій системі.

Історія змін і походження запису

Має бути зрозуміло, хто змінив пам’ять, коли це сталося і з якої сесії виникло оновлення. Якщо нове правило погіршило роботу, потрібна можливість повернути попередній стан.

Мені тут важливе саме походження. Запис «роби так» і запис «роби так, тому що в цих задачах попередній варіант дав таку помилку» мають різну цінність для перевірки.

Захист від одночасного перезаписування

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

По суті: не можна мовчки записати свою версію поверх чужого оновлення, яке ти ще не бачив.

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

Різні права для різних рівнів пам’яті

Є загальні правила організації, командні знання й особисті робочі нотатки агента. Не обов’язково давати однаковий доступ до всього.

Загальні домовленості можна дозволити читати, але обмежити їх зміну. Власний робочий блокнот агент може редагувати самостійно.

Можливість забрати накопичений контекст із собою

Окрема думка у виступі - переносимість. Якщо команда витрачає час на підготовку й перевірку знань, важливо мати змогу використовувати їх у різних системах.

Я б поставив це питання ще до вибору складної інфраструктури: чи зможемо ми отримати свою пам’ять у зрозумілому вигляді, перевірити її та перенести, якщо зміниться інструмент?

Чому агент не може просто сам підтримувати пам’ять у порядку

Усе, що описано вище, ще не розв’язує одну проблему. Агент веде нотатки під час роботи, але його головна задача - виконати ваше доручення.

У цій частині відео спікерка пояснює обмеження такого підходу.

По-перше, агент розподіляє ресурси між поточною задачею і користю для майбутніх сесій. Скільки часу витратити на відповідь зараз, а скільки - на впорядкування пам’яті? Це окрема задача, яка конкурує з основною.

По-друге, він бачить переважно свою сесію. Повторювана помилка може бути очевидною людині, яка переглянула десять розмов. Для агента в новій сесії вона може виглядати як окремий випадок.

По-третє, записи старіють. З’являються суперечності й дублікати. Контекст, який учора допомагав, сьогодні може направляти роботу не туди.

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

Що таке dreaming і чому тут узагалі згадується сон

Dreaming - це окремий фоновий процес, який аналізує досвід агентів і покращує їхню пам’ять.

На вході він отримує поточну пам’ять і записи робочих сесій. На виході формує пропозиції: що перевірити, що додати, що прибрати, які записи об’єднати й як краще організувати знання.

Назва відсилає до переробки досвіду між періодами активної роботи. У показаній архітектурі це пакетна асинхронна обробка з власними ресурсами. Її можна відокремити від виконання основних задач.

Важливо правильно зрозуміти, що саме тут змінюється. Показаний механізм працює із зовнішньою пам’яттю. У цій схемі немає опису перенавчання ваг базової моделі. Агент у наступній сесії отримує якісніший контекст і завдяки цьому може працювати краще.

Тобто слово «навчання» тут варто читати через конкретний механізм: зберегли досвід, переглянули висновки, оновили знання, використали їх у наступній роботі.

Які проблеми може побачити такий розбір

У відео є кілька зрозумілих прикладів.

Перший - учні масово помиляються в темі, якої взагалі немає в навчальній програмі. Якщо перенести це на агентів, у пам’яті може просто бракувати потрібного знання.

Другий - усі розв’язують задачу з однаковою помилкою через налаштування калькулятора: використовують радіани там, де потрібні градуси. Для агента схожа причина може ховатися в неправильному виклику або налаштуванні інструмента.

Тому dreaming аналізує не лише репліки розмови. Спікерка окремо звертає увагу на виклики інструментів та їхні метадані. Іноді причина поганого результату добре видна саме там.

Третій приклад - спільне правило стилю. У різних сесіях агенти постійно роблять те, що організація просить прибрати з текстів.

Це мені особливо зрозуміло на прикладі тире. Я можу вказати: використовуй ось такий знак «-». Якщо потім знову виправляю те саме, корисно перевірити, де зберігається правило, чи воно завантажується і чи немає іншої інструкції, яка йому суперечить.

Останній висновок уже мій. Не кожну повторну помилку треба лікувати додаванням ще одного абзацу. Іноді проблема в тому, що потрібне правило вже є, але система не використовує його в потрібний момент.

Як виглядає один прохід dreaming

У частині про архітектуру показана схема з оркестратором і підпорядкованими агентами.

Послідовність приблизно така:

Береться поточне сховище пам’яті.
Створюється його копія для підготовки оновлень.
Записи окремих сесій передаються підпорядкованим агентам для аналізу.
Вони переглядають досвід і працюють із вихідним сховищем.
Оркестратор зводить результати й визначає закономірності, які виправдовують зміну пам’яті.
Людина отримує пропозиції та може прийняти або відхилити їх.

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

Умовний приклад такого результату:

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

Це вигаданий приклад формату, а не цитата з відео. Він показує різницю між довільною новою нотаткою та зміною, яку можна перевірити за конкретними випадками.

Два способи оновлення пам’яті працюють разом

Звичайні записи під час сесії залишаються корисними. Агент помітив щось важливе - зберіг, і вже наступна задача може від цього виграти.

Dreaming додає інший рівень: перегляд досвіду кількох сесій із ширшим оглядом і виділеними ресурсами.

Під час виконання задачі	Під час фонового розбору
Агент бачить свою поточну роботу	Процес аналізує кілька сесій
Зберігає корисні деталі по ходу	Шукає повторювані закономірності
Ділить увагу між задачею й нотатками	Має окрему задачу покращити пам’ять
Може швидко допомогти наступній сесії	Може усунути спільну причину повторних помилок

Мені така схема зрозуміла й без прив’язки до ШІ. Є робота, під час якої виникає досвід. А є окремий час, коли цей досвід переглядають і змінюють правила роботи.

До красивих відсотків у презентації в мене є питання

На слайді про результати використання пам’яті наведено відгуки: на 97% менше помилок при першому виконанні, на 27% нижча вартість, на 34% менша затримка. В іншому відгуку йдеться про прискорення перевірки документів на 30%.

Це заявлені результати з презентації. У самому виступі немає достатнього опису вибірки, методики порівняння та умов, щоб переносити ці цифри на будь-який інший проєкт.

Є ще одна важлива деталь: слайд з’являється до пояснення dreaming. Тому я б не приписував усі наведені покращення саме цьому фоновому процесу.

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

Сам dreaming також потребує ресурсів. Спікерка пояснює можливу користь зменшенням наступних помилок і повторних спроб. Але готового розрахунку, який доводить окупність для будь-якої системи, у відео немає.

Що мені сподобалося в запитаннях із залу

Після основної частини розмова стає ще практичнішою.

Перше запитання - про готове корпоративне рішення. У відповідь Lamis пов’язує описану архітектуру з пам’яттю та dreaming у Claude Managed Agents. Це згадка про реалізацію у виступі; вибір конкретного сервісу й поточні умови його використання - окреме питання.

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

Для мене практичний висновок такий: можливість прочитати окрему сесію ще не означає, що її зміст можна перетворити на знання, доступне всій команді. Права мають зберігатися і під час узагальнення.

Третє запитання мені, мабуть, найближче: чи не винаходимо ми заново бази даних, коли додаємо версії, контроль одночасних змін та історію?

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

Я з цим погоджуюся. Наявність мовної моделі не прибирає потреби в історії змін, доступах і перевірці стану даних перед записом.

З чого я б почав у невеликому робочому процесі

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

Спершу - короткі постійні правила. Мова, стиль, важливі обмеження, основні домовленості. Те, що справді потрібно регулярно, а не весь архів попередніх розмов.

Потім - окремі інструкції для повторюваних процедур. Якщо стаття щоразу проходить однакові етапи підготовки й перевірки, цей порядок можна описати один раз і підключати за потреби.

Далі - місце для накопиченого досвіду. У записі має бути зрозуміло, чого він стосується, звідки взявся і за яких умов корисний. Тимчасове спостереження не варто одразу робити постійним загальним правилом.

Після цього - перегляд кількох завершених задач разом. Можна почати вручну. Де повторюється те саме виправлення? Якого знання бракувало? Чи була причина у виклику інструмента? Які старі інструкції вже заважають?

І лише тоді - автоматизація такого перегляду. Коли зрозуміло, які саме пропозиції потрібні, як їх перевіряти і куди зберігати результат.

Я б також узяв кілька схожих задач і порівняв поведінку до та після зміни пам’яті. Якщо з’явився новий файл, але повторних виправлень не поменшало, треба розбиратися далі. Сам факт запису ще нічого не доводить.

Де я бачу головне обмеження

Часто повторювана поведінка не обов’язково правильна. Якщо агент багато разів зробив те саме невдале припущення, фоновий аналіз може побачити закономірність. Але це ще не підстава зберегти її як правило.

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

Я б також не ставив знак рівності між скороченням і покращенням пам’яті. Після невдалого узагальнення легко втратити умову, за якої порада була правильною. Замість корисного пояснення залишиться короткий категоричний запис, який агент застосує не там.

Тому для мене хороша пам’ять - це записи, яким можна довіряти в конкретних умовах і які можна перевірити та виправити. Їхня кількість сама собою мало про що говорить.

Що я забираю з цього виступу

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

Найкорисніша для мене ідея dreaming - виділити окремий процес для розбору накопиченого досвіду. Помічник виконує задачі, а хтось або щось регулярно переглядає, чого ці задачі навчили і що варто змінити в інструкціях.

Але почати можна значно простіше: перевірити, де лежать ваші правила, чи знаходить їх агент, чи не суперечать вони одне одному і чи переходять виправлення в наступну роботу.

Якщо після цього нова схожа задача потребує менше повторних пояснень, значить пам’ять уже приносить користь. Саме такого результату я б і хотів від робочого ШІ-помічника.

В основі розбору - виступ Lamis Mukta на AI Native DevCon. Сторінка спікерки й опис доповіді на сайті організаторів. Таймкоди ведуть до повної версії відео на YouTube. Приклади, практичний порядок дій та оцінки в тексті - моє осмислення матеріалу.

Чому ШІ знову все забув: пам’ять агентів і dreaming на практиці