Пояснення пам’яті агента: робоча, епізодична, семантична та процедурна
Агент двічі виправляв ту саму помилку, тому що ніщо не зберігало результат. Пам’ять агента — робоча, епізодична, семантична та процедурна: що вона містить, як вона зазнає невдач.
Джерела: **Agent Memory Explained: Working, Episodic, Semantic & Procedural**
Один із агентів для програмування колись виправив ту саму помилку двічі поспіль під час одних сеансів. Йому ніхто цього не наказував, і з моделлю не було жодних проблем.
Під час першого сеансу агент взяв на обробку заявку BUG-142, виявив причину несправності у порядку виконання міграцій, змінив код, запустив тести інтеграції та спостерігав за їх успішним проходженням. Потім сеанс завершився.
Перед наступним сеансом система видала історію розмов, щоб знизити витрати на токени. Це був розумний вибір, адже повторне відтворення все більшого обсягу тексту коштує грошей, збільшує затримки та ускладнює формулювання запитів. Але зник не лише цей текст. Результати успішних тестів зберігалися лише у старому вікні контексту. Не було жодної записки про те, що помилка виправлена, а система відстеження завдань все ще відображала BUG-142 як нерозв’язану.
Отже, розпочалася друга сесія: був знайдений відкритий тикет, і було зроблено те, що від нього вимагалося. Було проведено розслідування, досягнуто того самого висновку та застосовано ту саму корекцію.
Модель не забула, як вирішувати цю проблему. Система не змогла зберегти інформацію про те, що проблема вже вирішена.
Ця невдача змушує переосмислити звичайне запитання. Замість того, щоб питати, як надати агенту пам’ять, потрібно з’ясувати, яка інформація мала б зберегтися після завершення сесії. Відповідь на це запитання призводить до чотирьох окремих завдань:
- Робоча пам’ять: завдання, яке виконується наразі.
- Епізодична пам’ять: що сталось та коли.
- Семантична пам’ять: те, що вважається істиною.
- Процедурна пам’ять: як слід виконувати дії.
Пам’ять — це не єдине поняття. Вона виконує принаймні чотири функції, і більшість помилок у роботі пам’яті виникають через їхнє плутання. Цей підхід запозичений з когнітивної науки та використовується у дослідженнях на кшталт CoALA (Cognitive Architectures for Language Agents), які описують мовні агенти через модульну пам’ять, структуровані дії та процес прийняття рішень.
Перш ніж розглядати ці чотири аспекти окремо, потрібно відокремити від самої пам’яті ще два елементи: вікно контексту та авторитетний стан додатку.
Вікно контексту — це робоча поверхня
Контекст — це все, що модель може бачити під час одного виклику для отримання результату. Зазвичай це включає системні інструкції, визначення інструментів, нещодавні повідомлення, отримані документи, файли, які перебувають у процесі редагування, результати роботи інструментів та поточний план. Це активна робоча зона агента.
Це також тимчасово. Коли сесія закінчується, розмова стискається або старі повідомлення видаляються, щоб відповідати ліміту токенів, і контент зникає, якщо лише додаток навмисно не збереже його в іншому місці. Модель не має приватних спогадів про попередні запити. Або додаток знову вводить цю інформацію, або під’єднує модель до зовнішнього сховища.
Ось чому велике вікно контексту не є довгостроковою пам’яттю. Більше вікно контексту — це більша робоча поверхня, а не шухляда. Більше матеріалу залишається видимим під час роботи агента, але коли поверхня очищується, все з неї зникає, якщо тільки щось спочатку не збере важливі частини.
У цьому випадку ефективне рішення залишилося на робочій поверхні, і ніщо не сприяло його підвищенню пріоритету. Проте збереження всього тексту розмови не було б рішенням, оскільки була проігнорована ще одна важлива особливість.
Пам’ять — це не поточна істина системи
Порівняйте два твердження. Одне — це запис у пам’яті: «BUG-142 було виправлено під час вчорашньої сесії». Інше — це стан додатку: у полі статусу замовлення вказано COMPLETED.
Вони пов’язані, але є різними типами даних. Перший — це історичний запис про те, що якась подія відбулася. Другий — це поточне джерело істини для системи відстеження. Пам’ять фіксує те, що сталося, тоді як стан — те, що існує у цю мить.
Ця прогалина має значення, тому що спогади можуть ставати застарілими, залишатися неповними або виявлятися некоректними. Уявіть, що агент знаходить запис про те, що BUG-142 все ще відкритий. Цей запис міг бути правильним на момент написання, проте він нічого не свідчить про ситуацію сьогодні. Перш ніж діяти на його основі, агент повинен звернутися до системи відстеження, переглянути репозиторій, запустити відповідні тести або спробувати відтворити проблему. Знайдений спогад — це твердження про минуле, а не доказ про сьогодення.
Спочаткова проблема зазнала двох невдач. Не було збережено жодних корисних записів про завершення виправлень, а статус завдання так і не оновлювався. Тепер, коли це з’ясовано, ми можемо визначити, що саме агенту потрібно було зберегти.
Робоча пам’ять: поточне завдання
Робоча пам’ять зберігає те, що необхідно агенту для виконання поточного завдання, та ще дещо. Для BUG-142 це може включати саме завдання, поточну гіпотезу (таблиця залежностей ініціалізується занадто пізно), поточний крок (виконати набір інструментів для інтеграції), останні спостереження (три тести міграції провалилися) та файли, які ведуться до змін.
Вона відповідає на практичні запитання: яка мета? Який крок зараз виконується? Що повернув останній виклик інструменту? Які файли змінилися? Що ще залишилося незавершеним?
На практиці вона знаходиться у запиті, у об’єкті стану агента, у контрольному пункті робочого процесу чи у сховищі сеансу з коротким терміном існування. Це тимчасовий елемент, пов’язаний з одним завданням, і він не призначений для тривалого запису всього, чого навчився система. Опис короткострокової пам’яті в IBM схожий: це нещодавня інформація, яка використовується для негайних рішень та підтримки континуїтету розмови.
Робоча пам’ять також відрізняється від трьох інших типів. Епізодична, семантична та процедурна пам’ять можуть зберігатися протягом кількох сеансів, тоді як робоча пам’ять описує все те, що є активним у цю мить, незалежно від того, чи знаходиться це у поточному фокусі уваги, чи зберігається поблизу.
Її короткий термін існування — це не недолік. Як тільки завдання виконано, рідко буває причина зберігати кожну проміжну гіпотезу, написану частину тексту, невдалий запит або покинуту ідею. Проблеми виникають тоді, коли важливий результат існує лише тут. У цьому випадку зникли дві речі: результат проходження тесту та факт усунення BUG-142. Система сприймала значущий результат як тимчасовий простір для запису.
Робоча пам’ять допомагає у виконанні завдань. Вона ніколи не повинна бути єдиним записом завершеної роботи.
Епізодична пам’ять: запис подій
Епізодична пам’ять зберігає конкретний досвід. Епізод — це більше, ніж просто факт. Він відбувся у певній ситуації, зазвичай із часом, дією та результатом.
Для BUG-142 корисний епізод можна описати у вигляді короткого структурованого запису:
- Подія: BUG-142 виник під час ініціалізації міграцій.
- Контекст: таблиця залежностей не була доступна під час запуску сервісу.
- Дія: змінено порядок виконання міграцій.
- Результат: тести інтеграції пройдені.
- Доказ: коміт a7f43d2.
- Час: 8 вересня 2026 року, 14:20.
Такий запис повідомляє майбутнього агента про те, що ця ситуація вже траплялась раніше. Це допомагає уникнути повторної роботи, надає приклади та показує, які попередні спроби були ефективними, а які — ні. CoALA розділяє епізодичну та семантичну пам’ять, оскільки запис досвіду виконує іншу функцію, ніж узагальнені знання.
Епізод також не є тим самим, що й історія чату. Транскрипція може містити сотні повідомлень, результати роботи інструментів, припущення, корекції та повтори. Необхідно провести чітку межу між первинним журналом подій, наприклад, фразою «Мабуть, нам варто перевірити порядок ініціалізації», та стислим описом епізоду: переупорядкування ініціалізації залежностей вирішило проблему BUG-142, а тести пройшли успішно після коміту a7f43d2. Другий варіант набагато легше знаходити та значно корисніший під час виконання наступних завдань.
Епізодична пам’ять також може давати збої двома способами. Система може зберегти дію, але втратити її результат. Простий запис на кшталт „Намаганося: змінено порядок міграції“ залишає майбутнього агента у невизначеності щодо того, чи варто спробувати знову. Або ж агент може отримати інформацію про успішне виконання дії, яка сталась шість місяців тому, після змін у архітектурі. Епізодична пам’ять зберігає минуле та не описує сьогодення, саме тому кожен епізод має містити інформацію про час, контекст, докази та результат.
Семантична пам’ять: що знає агент
Епізод фіксує те, що сталось. Семантична пам’ять фіксує те, що було засвоєно з цього епізоду.
Епізод BUG-142 може стати джерелом корисної інформації, яку можна використовувати знову: сервіс міграції потребує наявності таблиці залежностей перед початком ініціалізації. Це вже не стосується лише однієї сесії виправлення помилок — це загальне твердження щодо системи.
Типові елементи включають інформацію про те, яку базу даних використовує сервіс, ліміт швидкості API, правило про те, що ідентифікатори клієнтів не повинні потрапляти до журналів, архітектурну схему репозиторію, уподобання користувача щодо стислих технічних відповідей та вимогу до сценаріїв міграції щодо збереження зворотної сумісності. Семантична пам’ять охоплює факти, концепції, обмеження, взаємозв’язки та уподобання. Вона зазвичай має тривалий термін існування, але мусить залишатися підлягною коригуванню, оскільки факти та уподобання змінюються.
Різниця між семантичною та епізодичною пам’яттю є тонкою, але варто її пам’ятати. Епізодична версія описує, що BUG-142 стався вчора через відсутність таблиці залежностей під час запуску. Семантична версія пояснює, що для ініціалізації спочатку мусить існувати ця таблиця. Одна пам’ять зберігає сам досвід, інша — уроки, які з нього можна зробити.
Його характерною проблемою є застарілість інформації. Припустимо, команда згодом впровадить новий механізм ініціалізації, який більше не буде залежати від таблиці. Якщо система пам’яті просто додасть новий факт, агент може отримати обидва варіанти: один стверджує, що таблиця має існувати спочатку, а інший — що це вже не має значення. Тепер у пам’яті є інформація без чіткості. Застарілий факт може бути гіршим, ніж його відсутність, адже агент буде діяти на основі нього з упевненістю.
Тож семантична пам’ять потребує шляху корекції, з відповідями на кілька запитань. Хтось має контролювати оновлення фактів. Вона потребує іменованого джерела та дати останньої перевірки. Коли з’являється новіша версія, стару слід позначити як замінену, а потім або видалити, або зберегти як історію. Це належить до справжньої інженерії пам’яті. Наразі суть у тому, що семантична пам’ять зберігає повторно використовувані знання, а не просто запис події.
Процедурна пам’ять: як виконується робота
Процедурна пам’ять вказує агенту, як виконати завдання. Вона містить навички, процеси роботи, правила функціонування та методи, які можна повторювати.
На основі проблеми команда може розробити процедуру: перед запуском ініціалізації міграції перевірити наявність таблиці залежностей; запустити тести інтеграції міграції; зафіксувати результат; оновити систему відстеження завдань; додати посилання на зміни; підтвердити, що проблема більше не виникає.
Це не є фактом, хоча випливає з нього. Семантичним фактом є те, що таблиця має існувати перед ініціалізацією. Процедурним правилом є перевірка її наявності перед ініціалізацією. Семантична пам’ять визначає, що є істиною, а процедурна пам’ять — що потрібно робити. Інші приклади: скасування невдалого розгортання, розслідування проблеми з оплатою, які тести мають пройти перед закриттям багу, як переглядати запит на зміни, коли потрібно просити людське схвалення та який інструмент слід використати перед роботою з продакшн-даними.
Імплементації варіюються від чітких інструкцій та версійованих посібників до упакованих навичок, визначень робочих процесів, простого коду чи шаблонів, набутих через практику. CoALA надає процедурам окреме місце в пам’яті агента, пов’язане як із можливостями моделі, так і з прямим кодом агента.
Через це процедури слід версіонувати як програмне забезпечення, а не накопичувати як історію розмов. Якщо організація змінює свій процес розгортання, агент не повинен брати п’ять старих процедур та намагатися здогадатися, яка з них є актуальною. Усе, що працює в умовах продакшну, має вказувати, хто є власником, яка це версія, з якого часу вона діє, що вона охоплює, що її замінює та як ви знаєте, що вона все ще працює.
У цьому інциденті без процедури призвело до проблеми. Агент виправив код, але жодне правило не вимагало перетворити цей успіх на оновлений стан додатку. Відсутнім було не відтворення всієї розмови, а постійна інструкція на кшталт: як тільки тести пройдуть, запишіть результат та закрийте заявку. Це і є прогалина в процедурах.
Один баг, п’ять формулювань
Таксономію найлегше побачити, якщо описати один і той самий баг п’ятьма різними способами.
- Робоча пам’ять: „Наразі усувається BUG-142; наступним кроком є тести інтеграції“. Вона забезпечує продовження поточної роботи.
- Епізодична пам’ять: „Під час першої сесії BUG-142 було усунуто шляхом зміни порядку залежностей, і тести пройшли“. Вона зберігає досвід.
- Семантична пам’ять: „Сервіс міграції потребує таблиці залежностей перед ініціалізацією“. Вона зберігає знання, які можна використовувати знову.
- Процедурна пам’ять: „Перед ініціалізацією міграцій перевірте таблицю та запустіть тести інтеграції“. Вона зберігає методи, які можна повторювати.
- Авторитетний стан: статус COMPLETED, коміт a7f43d2, тести PASSED. Він фіксує те, що додаток вважає істиною.
Вони пов’язані між собою, але не є взаємозамінними. Епізод не замінює запису завдання, а запис завдання не містить усього того, що було дізнано під час інциденту. Цей факт не визначає повної процедури дебаггінгу, а процедура не доводить, що певна помилка була виправлена. Від робочої пам’яті не можна очікувати, що вона залишиться активною після завершення сеансу.
Система не лише не змогла запам’ятати одну річ — вона також не змогла перетворити завершену роботу у відповідні стабільні форми.
Кожен тип виходить з ладу по-своєму
Якщо все зберігати в одному недиференційованому сховищі, діагностика ускладнюється. Краще запитати, яка саме інформація не була оброблена.
- Робоча пам’ять виходить з ладу, коли агент втрачає свій поточний план після скидання, зазвичай тому, що прогрес виконання завдання зберігався лише у вікні чи локальному процесі.
Кожна робота потребує власних правил щодо того, хто може писати, як отримуються дані, як довго вони зберігаються, як усуваються помилки та як оцінюється якість. Векторний індекс може допомогти отримати доступ до різних видів пам’яті, але індекс не визначає тип контенту. Корисне правило: класифікуйте інформацію перед тим, як обирати технологію зберігання.
Короткий чек-лист для класифікації
Коли агент зустрічає певну інформацію, поставте собі ці запитання у порядку.
- Чи потрібна вона лише для поточної роботи? Робоча пам’ять. Це може бути поточний план, результат останнього інструменту чи тимчасова гіпотеза.
- Чи це конкретна подія, яка вже відбулась? Епізодична пам’ять. Це може бути невдала спроба розгортання вчора, неефективна спроба ремонту чи дизайн, відхилений користувачем.
- Чи це знання, яке можна використовувати знову? Семантична пам’ять. Це архітектура, переваги, обмеження сфери діяльності, бізнес-визначення.
Одна ситуація часто потребує кількох форм представлення. Невдале розгортання може стати епізодом (воно зазнало невдачі о 14:20), фактом (сервіс X потребує версії схеми 17), процедурою (перевірити сумісність схем перед розгортанням) та зміною стану (розгортання скасовано). Це не марна дублювання, адже кожна форма відповідає на різне запитання.
Що мав зробити інструмент
Контекст ніколи не мав існувати вічно. Усе, що потрібно було зробити цьому інструменту, — це сприяти досягненню важливих результатів перед завершенням сеансу: записати епізод, вилучити факти, якщо вони були, додати або оновити процедуру та встановити статус замовлення разом із доказами виконання та тестування.
Завдяки цьому безпечно видаляти старі розмови. Чистий текст можна видалити, оскільки все, що варте збереження, вже було перетворено на форми, які мають залишитися. Контекст може зникнути, але важливі результати не повинні зникати разом із ним.
До чого це призводить
Класифікація — це початок, а складніші інженерні питання виникають після неї. Що заслуговує на зберігання? Де має знаходитися кожен тип інформації та хто може її записувати? Коли вона отримується та як потрапляє до системи? Коли вона оновлюється та коли закінчує свою дійсність? Що відбувається, коли два джерела інформації суперечать одне одному, та як визначити, чи покращила інформація роботу агента?
Ці питання становлять основу інженерії пам’яті, і жодне з них не можна належним чином відповісти до того, як інформація буде класифікована. Тож перед тим, як обрати базу даних типу vector database, фреймворк пам’яті чи стратегію пошуку, з’ясуйте, який тип інформації намагається зберегти агент.
Мета не в тому, щоб агент пам’ятав усе. Йдеться про те, щоб корисні дані збереглися у форматі, який відповідає способу їх використання. Далі йде життєвий цикл пам’яті: досвід, вилучення інформації, прийняття рішення про те, що зберегти, зберігання, отримання інформації, включення її у контекст, перевірка, дія та нарешті оновлення чи забування.