Чому пам’ять агента для кодування має містити лише дельту та як її зберігати.
Пам’ять агента кодування повинна зберігати лише те, що модель не могла вгадати. Чотири тести для кожної запису, три вимоги до зберігання та чому markdown у git добре підходить.
Джерела: Why Your Agent Needs Memory, and How to Organize It
Уявіть собі сховище особистих спогадів, створене для агента-програміста на одній машині. У ньому зберігається 181 файл з тематичним контентом під індексом з 134 рядків, причому майже ніщо з цього не є знанням у звичайному розумінні. Агент вже розуміє механізми Express middleware, структуру тестів Playwright та функції Dockerfile, прочитавши про кожен з цих елементів набагато більше, ніж зможе прочитати будь-яка людина. Кожен рядок у цьому сховищі існує з протилежної причини: він позначає місце, де певний варіант відрізняється від середнього рівня у своїй галузі.
Два приклади ілюструють цю ідею. Механізм перевірки розгортання блокує випуск, якщо перевірка не може бути виконана, і це робиться навмисно. Механізм самостійної схвалення процесу розгортання читає значення поля .status, а не .conclusion — деталь, яка коштувала півдня роботи, перш ніж стала одним рядком у файлі.
Ось якою має бути структура хорошої пам’яті агента. Це не копія того, що знає агент. Це дельта — та частина, що залишається. Усі погоджуються, що агенту потрібна пам’ять, але ніхто не визначив її конкретної форми, тому у цьому розділі розглядаються два аспекти: чому агенту взагалі потрібна пам’ять, та як її організувати. Друга частина поділяється на чотири частини: необхідність простоти, вимоги до кожної одиниці пам’яті та до сховища, сховища, які відповідають цим вимогам, та процедури роботи з нею.
Пам’ять агента — це не людська пам’ять
Природним інстинктом є міркування за аналогією. Люди пам’ятають речі, тож агенти також повинні це робити. Однак аналогія провалюється вже на першому кроці. Людина починає з нуля, тому людська пам’ять мусить зберігати як середні значення, так і винятки. Модель ж починає роботу з вже завантаженими середніми значеннями, у масштабах, які перевищують можливості будь-якої окремої людини. Інформація про те, що таке проміжне програмне забезпечення, не додає жодних даних — вона лише додає токени.
Токени коштують грошей, і саме тут багато хто робить помилки. Контекст, який не є необхідним, не є нейтральним — це чиста втрата. У одному дослідженні фахівці підрахували, наскільки часто модель правильно здійснювала виклики API. Коли модель отримувала документацію до API, які вона вже добре знала, а отримана інформація була неповною, частка правильних викликів знизилась на 39 відсоткових пунктів. Натомість отримання такої документації для рідкісних API, яких модель раніше не бачила, допомогло, підвищивши точність на дев’ять пунктів. Той самий контент та та сама процедура обробки, проте ефект змінив свій знак.
Якщо дивитися з цієї точки зору, файл пам’яті — це відмінності, додані до існуючих припущень моделі. Кожен рядок, який повторює відому конвенцію, конкурує за увагу з тим єдиним рядком, який справді має значення, а уваги завжди бракує.
Записуйте лише те, що модель не могла б вгадати.
Якщо пропустити справжні файли контексту через цей фільтр, більша частина їхнього вмісту зникає. Правила найменування, принцип „композиція замість успадкування“ та структура папок зі зразками — це загальновідомі речі, які обробляє інструмент лінтингу та вже містяться в моделі. Те, що залишається, зазвичай є незручним: тимчасові рішення, покинуті шляхи або щось, що справедливе лише в цьому кодовому базі, а не в інших.
У зразковому магазині, довжиною близько 3 700 рядків (3 831, якщо врахувати індекс), жоден рядок не пояснює, що таке мідлверк чи як структурувати тест. Рядки, які пояснювали відомий інструмент, видаляються, оскільки модель вже знала про нього, і це марно витрачало токени при кожному запиті.
Найдешевша пам’ять — це та, якої вам не потрібно
Якщо пам’ять мене не підводить щодо цього фактора, то його розмір залежить від того, наскільки проект відхиляється від загальноприйнятої схеми. Якщо дотримуватися стандартної архітектури, агенту майже нічого не потрібно, адже він добре знає цю сферу. Якщо ж створювати власну систему модулів, кожне з її правил стає рядком коду, який потрібно записувати, дотримуватися та оплачувати за кожен запит.
Для відчуття ефекту не потрібні жодні тестові даних. У стандартних технологічних стеках агент просто виконує свою роботу. У нішевих мовах чи власних внутрішніх фреймворках він зупиняється, робить припущення чи ставить запитання. Щоб скоротити цю відстань, потрібно самостійно керувати контекстом: записувати його, версіонувати та постійно підтримувати у актуальному стані.
Не існує чистого тесту типу A/B для підтвердження цього твердження, і було б нечесно вдавати протилежне. Наведені тут дослідження підтримують механізм, тоді як файли однієї людини підтверджують лише практику, що не є доказом механізму. Проте досвід є послідовним: нова робота в звичайних стеках виконується швидко, а робота у великих старих системах, де більша частина контексту ніколи не записувалася, виконується повільніше, іноді навіть повільніше, ніж вручну.
Отже, вибір архітектури став вибором між різними способами зберігання даних у пам’яті. Виберіть нудний, широко використовуваний патерн — і не доведеться постійно щось додатково підтримувати. Кожне відхилення від загальноприйнятого патерну означає, що хтось мусить все записувати та підтримувати у точності, а індивідуальний підхід коштує дорожче при кожному наступному запиті, а не лише під час його створення.
Найскладніше — залишатися маленьким
Ось чому. Спосіб починається з неприємної реальності: те, що руйнує системи пам’яті в практичному використанні, — це не забування, а накопичення.
Корисність відстає від об’єму. Подвоєна пам’ять не означає подвоєної цінності, адже безлад накопичується швидше, ніж корисні дані, і після певної межі більший об’єм пам’яті дає гірші результати, ніж менший, навіть для запитань, для яких він і був створений.
Конфлікти ростуть швидше, ніж об’єм. Будь-який новий факт може суперечити будь-якому існуючому, тому кількість можливих суперечок зростає набагато швидше, ніж кількість файлів. Суперечка також коштує набагато дорожче, ніж прогалина в даних. Коли бракує факту, агент не впевнений, і така невпевненість є прийнятною: він запитує або зазнає невдачі там, де це можуть побачити люди. Коли два факти суперечать один одному, агент впевнений, але помиляється, і оскільки ніщо в системі не виглядає несправним, ніхто цього не помічає.
Ще гірше те, що більшість продуктів для зберігання пам’яті не можуть помітити проблему. Метод векторної схожості реєструє два речення на одну тему, але не бачить, що одне з них стверджує «так», а інше — «ні». Тож значення стають однорідними, конфлікти продовжують зростати, і після певного розміру система зберігання пам’яті погіршує роботу агента.
Пам’ять рідко дає явні ознаки збою. Вона «перестає працювати», стаючи впевнено неправильною, при цьому кожен запит все ще виконується успішно.
Отже, складність полягає не у накопиченні інформації, адже кожен продукт із задоволенням це робитиме. Справа у тому, щоб залишатися компактним, водночас забезпечуючи достатню кількість інформації. Для цього потрібно видаляти даних, а видалення означає оцінювати власні попередні записи.
Люди схильні спочатку шукати структуру. Стикаючись із хаотичною купою даних, вони запроваджують таксономію ієрархій, категорій, діаграм чи формальних схем знань. Це надійно призводить до негативних наслідків. У одній оцінці 2026 року було протестовано додавання глибини до індексу контексту за запитом за допомогою того самого моделювання, і точність знизилась з 0,91 до 0,64. Проста структура виявилася кращою за ієрархічну у всіх випробуваннях. Складна структура не усуває складності — це ще одна складність, додана до першої, і тепер обидві потребують підтримки.
Тож організація пам’яті — це не стільки створення кращої діаграми, скільки встановлення стандарту, який має бути досягнутий кожною лінією, а також наявність механізму, який полегшує його досягнення.
Чотири тести для кожної одиниці пам’яті
Цей стандарт стосується окремої одиниці, а не всієї системи. У команді це також те, що перевіряє рецензент.
- Просто та насичено. Лише інформація про насіння. Жодне речення не існує лише для того, щоб здаватися повним. Рядок, який не змінює того, що буде робити агент, є декорацією, а декорації мають свою ціну.
- Без суперечностей. Немає двох фактів, які не могли б бути одночасно істинними. Цьому потрібні активні зусилля, адже суперечності накопичуються повільно та ніколи навмисно.
- Вимірювано корисно. Пам’ять не робить агента розумнішим. Вона робить його швидшим та дешевшим при тій самій якості, надаючи ті самі відповіді без необхідності повторного пошуку. Файл, який не дозволяє помітно скоротити час чи кількість ресурсів під час виконання реального завдання, не виправдовує свого утримання.
reference_, правила — у 50 файлах типу feedback_, а тимчасові стани — у 14 файлах типу project_. Читач знає, що містить файл, ще до його відкриття.Один опублікований результат, здається, підриває третій тест, а насправді його підтримує. Дослідники з ETH Zurich провели порівняння файлів контексту репозиторію з ситуацією, коли файлів взагалі немає. Вони не виявили загального покращення у успішності виконання завдань, а навпаки — додалося понад двадцять відсотків до витрат на інтерпретацію; крім того, файли, створені машиною, показали результати трохи гірші, ніж у випадку відсутності файлів. Якщо уважно прочитати правило дельти, це не є протилежним результатом. Файл, наповнений середніми знаннями, саме те, що, за прогнозом правила, коштуватиме чогось, але не принесе жодної користі. Це висновок не стверджує, що файли контексту завжди невдали, а лише те, що файли, які повторюють середні дані, є невдалими, що стосується більшості з них.
Тому дисципліна означає менше написання та більше оптимізації: кожен рядок має залишатися насиченим, і жодна пара рядків не може суперечити одна одній.
У серпні Адді Османі також розглядав цю проблему з точки зору підтримки, стверджуючи, що файли агентів стають застарілими з покращенням моделей (його пост має назву «Аудит файлів агентів»), тому їх потрібно періодично очищувати та перестраювати, а не дозволяти їм безкінечно зростати. Пам’ять, яка лише розширюється, фактично йде на спад.
Потім розділіть те, що залишилося, за завданнями, як це робить ваш власний механізм згадування. Те, що завантажується для написання тексту, відрізняється від того, що завантажується для виправлення помилок під час компіляції.
Нікому не потрібна одна пам’ять. Потрібна найменша правильна частина пам’яті для конкретного завдання.
Три вимоги до сховища
Ці чотири тести нічого не говорять про те, де знаходяться файли, що є іншою половиною процесу організації.
Підказка походить від того, що вже існує у наявних інструментах. AGENTS.md — це звичайний файл Markdown за прогнозованим шляхом, який читають понад двадцять інструментів, хоча їхні розробники конкурують майже у всьому іншому. Конкуруючі виробники ніколи не впроваджували однаковий API пам’яті.
Опитування щодо інструментів для кодування (опубліковане на Substack) показало, що сім з них дійшли до однакової конструкції без координації: невеликий файл Markdown завжди знаходиться в контексті, а також більший архів на диску, який відкривається, коли це необхідно для виконання завдання. Жоден з них не використовував векторний пошук. Хоча у них немає спільного критерію оцінки, усі сім відповідають однаковим трьом вимогам.
Можливість пошуку без жодних встановлень. Під «пошуком» зазвичай розуміють семантичний пошук, хоча це навіть не є типовим варіантом. Власний інструмент пам’яті Anthropic дозволяє переглядати, створювати, замінювати, вставляти, видаляти та перейменовувати дані, але зовсім не має функції запитів. Агент перелічує каталог та читає те, що там є. Пам’ять, яка працює лише тоді, коли створений індекс, ембеддинги є актуальними та працює постачальник послуг, створює слабке зв’язку в контексті. Вона мусить продовжувати працювати, навіть коли все це не працює.
Зміни відбуваються під час спостереження за людиною. Самообновлювана пам’ять — саме там виникають проблеми. Згідно з аудитом 10 134 записів, автоматично отриманих у умовах роботи, 97,8% з них виявилися непотрібними. Інше дослідження передбачало зберігання моделями результатів своїх успішних виконань у пам’яті, проте результати виявилися гіршими, ніж без пам’яті, у всіх чотирьох тестованих агентах. Самозаписувана пам’ять змінюється раптово, а не поступово, тому будь-які зміни мають бути видимими у вигляді відмінностей, щоб їх можна було відхилити та скасувати.
Можливість технічного обслуговування за допомогою вже існуючих інструментів. Пошкодження рідко призводять до зупинки роботи системи пам’яті. Проте занедбаність так — файл записується один раз, ніхто до нього не повертається, і він поступово стає некоректним. Згідно зі звітом про дослідження 2026 року, половина файлів контексту так і не зазнавала змін після першого коміту, а 6% файлів, які продовжували коригуватися, належали людям, які повідомляли про реальну користь від цього інструменту. Технічне обслуговування має відбуватися в редакторі, системі пошуку та контролю версій, які люди вже використовують щодня.
Це повна специфікація. Залишається лише визначити, який формат зберігання її відповідає.
Чому файли Markdown підходять у git
Ідея використання файлів не є новою. Автори на Medium принаймні шість разів цього року стверджували, що «markdown кращий за векторні бази даних для пам’яті агентів», а теми на Hacker News продовжують містити жарти, які зводяться до використання звичайного тексту. Рідко наводиться обґрунтування цього підходу.
Три постачальники баз даних пам’яті опублікували свої аргументи проти використання файлів протягом трьох місяців, тоді як два постачальники провідних агентів вже обрали файли. У цьому аргументі немає нічого, що можна було б продати, лише папка.
Що зберігає ця галузь
Те, що зберігає система, визначає все, що відбувається далі.
- Mem0 зберігає речення, витягнуте з LLM, разом із його ембеддингом — один рядок у векторному індексі. У результаті отримується не оригінальний документ, а перефразування з боку засобу витягування інформації, і його неможливо відкрити.
- Zep зберігає набраний графічний ребро для кожного факту та відстежує дві часові шкали для кожного факту, тож кожен з них має вікно дійсності. Виправлення вносяться шляхом заміни: старе ребро позначається як недійсне замість того, щоб його редагувати.
- Стартап, що працює з векторними даними протягом багатьох років використовував векторні архіви. На початку 2026 року він змінив стандартне сховище для своїх кодувальних агентів на дерево файлів у форматі markdown у git-репозиторії, здійснюючи коміт після кожної зміни.
- Anthropic пропонує інструмент для керування пам’яттю, який здійснює лише операції з файлами у каталозі
/memoriesта виконується власним клієнтом користувача. Його хостований, все ще у бета-версії API для керування пам’яттю називає елементи за шляхом у файловій системі та вирішує проблему одночасних записів за допомогою хешу вмісту, що є аналогом моделі даних git з HTTP-інтерфейсом. - Асистенти споживачів містять короткий огляд, який користувачі можуть бачити лише у відображеному вигляді. Станом на вересень 2026 року для жодного з них не існує документованого формату експорту, придатного для читання машиною.
Справжньою різницею є можливість читання пам’яті, а підхід, що базується на файлах проти баз даних, її ігнорує. Усі варіанти, що не є файлами, мають одну спільну рису: пам’ять неможливо порівняти у два різні моменти часу. Корекції вносяться за допомогою перемикача, а не коміту.
Кожна зі сторін має свої переваги, і кожна частково має рацію
У березні 2026 року MatrixOrigin стверджувала, що статичний Markdown з часом втрачає ефективність та нічого не гарантує. Через п’ять тижнів Mem0 опублікувала пост під назвою „Пам’ять вашого AI-агента — це просто файл? Ось у чому проблема“, у якому зазначала, що плоскі файли повторюють помилки до появи баз даних 1970-х років: відсутність семантичного пошуку, відсутність темпорального міркування, відсутність безпечних одночасних записів та неможливість „забувати“ інформацію. У червні Zep додала, що „Markdown — це не пам’ять агента“, підкресливши ключову ідею: файл Markdown показує лише те, що було написано, але ніколи не те, що це замінило чи чому.
Тим часом власний агент для програмування від Anthropic зберігає свою пам’ять у вигляді звичайного Markdown на диску, а документація Windsurf тихо радить переміщувати все, що варто зберегти, з їхнього сховища пам’яті до формату Markdown під контролем версій. Варто звернути увагу на те, хто що пропонує.
У постачальників баз даних є два обґрунтовані аргументи. Векторні методи є ефективними, коли запит та запис не мають спільної лексики, наприклад, коли йдеться про запит на „те, що означає відчуття виснаження“, а запис ніколи не містить слова „виснаження“. Лише метод вбудовування може подолати цю проблему з стабільною швидкістю при обробці мільйонів рядків. Grep не може знайти те, що неможливо назвати.
Графові системи мають перевагу у часі. Щоб відповісти на запитання про те, у що хтось вірив минулого вівторка та що замінило це, потрібні факти з позначенням дат початку та кінця, а оцінка схожості не може визначити, який із двох суперечливих фактів є актуальним. За повідомленнями, повторна обробка часових запитань у одному тесті на довготривалу пам’ять показала 63,8% для графової системи проти 49,0% для векторної. У обох випадках файли поступаються.
Докази та їхні обмеження
Результати пошуку у 2026 році здивували всю галузь. Агенти, які використовували прості інструменти на кшталт grep, find та прямого читання файлів, показали кращі показники, ніж будь-які методи на основі ключових слів, ембеддингів чи переранжування. Один з тестів ефективності агентського пошуку показав, що відмова від використання ембеддингів та можливість прямого читання файлів підвищила точність з 69% до 80%, при цьому витрати зменшилися майже на третину. Інше дослідження щодо запитань довгострокової пам’яті показало, що звичайний пошук за ключовими словами перевершує семантичний пошук у кожній конфігурації використання інструментів. Однак, коли результати поверталися у вигляді файлів, порядок змінювався у половині випадків, оскільки запитання оцінювалися за точністю знаходження конкретних елементів — таких як дата, кількість, ідентифікатор чи рядок з помилкою.
У статті про агентський пошук також є важлива зауваження, яка має бути очевидною: якщо збільшити кількість документів з 100 000 до 400 000, точність того самого методу знижується з 80% до менше 40%, при цьому кількість викликів інструменту зростає у три рази. Grep працює в певних межах обсягу даних і не є законом природи; у цих межах він перевершує інші засоби за якістю та витратами, а поза ними його ефективність різко падає.
Тож справжнє питання полягає у тому, на якій стороні цих меж знаходиться система, а не у тому, який підхід є загалом кращим. Збірка з 181 файлом у сотні разів менша за обсяги даних, де, за повідомленнями, виникають проблеми. Система оперативної пам’яті у великій компанії на кшталт LinkedIn не є настільки малою, і ніхто не стверджує, що вона повинна використовувати markdown.
Оцінка: файли проти альтернатив
Щодо цих трьох вимог, файли Markdown відповідають кожній з них майже без жодних витрат. Grep виступає як альтернатива — будь-які зміни фіксуються у вигляді diff (оборотного коміту в репозиторії), а інструменти для технічного обслуговування вже є на робочому столі.
Ще дві переваги надаються безкоштовно. Виникають суперечності, оскільки два суперечливі факти представлені у вигляді двох рядків тексту замість двох масивів, а формат зберігання водночас є форматом експорту.
Цей компроміс варто назвати, а не приховувати. Файли поступаються ембеддингам, коли потрібна нечітка поверненість інформації з великої кількості документів. Рішенням є створення індексу над файлами, який можна будувати заново в будь-який момент, замість того щоб ставити його на їхнє місце. Системи на основі баз даних SQLite використовують базову пам’ять для створення цього шару, memsearch — Milvus, а ідея Karpathy щодо композитних вікі обходиться лише індексною сторінкою, без жодних ембеддингів. Коли індекс є основою зберігання, знижується можливість перегляду, порівняння, визначення власника та портативності, заради повернення інформації, яка й так була доступна.
Якщо ви не можете виконати операції grep, порівняння та видалення рядка, це не ваша пам’ять. Це чиясь кеш-система щодо вас.
Як виглядає працююча система
Принципи є недорогими, тож ось одна функціональна конфігурація.
- Шари посилань без жодного маніфесту. Перший файл, який відкриває агент, має 21 рядок. Він функціонує як карта з трьома верхніми рівнями, кожен з яких складається з одного рядка та вказує на більш глибокі файли. На наступному рівні файл проекту містить справді особисту інформацію: активний репозиторій порівняно з тим, що було видалено під час перейменування, версії, до яких прив’язано все, та правила комунікації, яких потрібно дотримуватися. У дереві проектів є 28 таких файлів; усі вони написані вручну, і кожен завантажується лише тоді, коли робота спрямовується до нього.
- Сховище, яке заповнює агент, підтверджує людина. Поруч з цим знаходиться автоматична пам’ять, яка складається з 181 файлу тем під індексом з 134 рядками. Індекс завантажується лише під час початку сеансу, а файл теми відкривається в момент, коли для цього є потреба.
Шари для завантаження, а не для міркувань
Підрахуйте кількість рівнів вище — їх чотири, що є саме тією глибиною, проти якої попереджає попередній результат у діапазоні 0,91–0,64. Однак у тому дослідженні змінною була глибина, тоді як індекс залишався незмінним у кожній конфігурації. Найкращою була конфігурація з плоским індексом на кожне завдання: агент читає його один раз перед тим, як вирішити, що відкрити, що майже вдвічі підвищує точність порівняно з простим навігуванням при приблизно половинній витраті ресурсів. Результати погіршувалися лише тоді, коли індекс мав гілки, по яких моделі доводилося спускатися, вгадуючи лише за мітками, яка з них містить відповідь.
Індекс цієї конфігурації є простим порядком: один рівень, який читається повністю під час початку сеансу. Він містить 134 рядки, приблизно по одному на тему; кожен з них вказує назви файлів, до яких він посилається, разом із коротким описом. Немає жодних розгалужень, тому не потрібно нічого здогадувати. Це невелика таблиця маршрутизації, яку ведуть вручну, а не таксономія, за допомогою якої модель могла б міркувати; крім того, вона може бути недосконалою: одинадцять із 181 файлу в ній відсутні. Файли, що стосуються тем, є невеликими, простими та читаються повністю; рівень відкривається тоді, коли робота потрапляє у його сферу, а не тому, що якась запитувальна система починає пошук. Це і є принцип поступового розкриття інформації.
Тест простий. Якщо моделі доводиться здогадуватися, у якій гілці знаходиться відповідь, спираючись лише на мітки, це означає, що було створено дерево, і результат становить 0,64. Якщо ж вона читає весь індекс та відкриває файл за назвою, це є порядком завантаження.
Структура існує для того, щоб вирішувати, що завантажувати. Вона не призначена для того, щоб модель через неї міркувала.
Захист від відхилень
Агент пропонує зміни, вони відображаються у вигляді різниці, а людина може їх прийняти або ні. Файли, які знаходяться у репозиторіях, мають власну історію, що дозволяє відповісти на запитання про те, чому агент щось вважає, шляхом читання цієї історії, чого не можуть зробити жодні сховища векторів чи сторінки пам’яті виробника. Пам’ять, яку ніхто не перевірив, — це чутка з ім’ям файлу.
Іноді відбувається повільна процедура очищення: видаляються рядки, які були правдивими у червні, файли, які модель згодом поглинула, та правила, які були замінені кращими. Об’єм сховищ зменшується частіше, ніж очікують люди.
Усе зберігається у вигляді звичайного Markdown на локальному диску та працює без асистента, який допомагав у його створенні. Коли наступного року з’явиться потужніший інструмент, спрямуйте його на ту саму папку та продовжуйте роботу.
Перевірка, яку можна пройти сьогодні
Усю структуру можна розмістити на одній картці: чотири тести для кожної збереженої рядка, три вимоги щодо місця їх зберігання та людина, яка виступає посередником між агентом та файлом.
Щоб визначити своє місце, відкрийте файл контексту проекту — чи то CLAUDE.md, AGENTS.md, чи щось інше, що читає інструмент — та видаліть усі рядки, які модель могла б вгадати самостійно. Реалістичний результат — скорочення кількості рядків наполовину. Потім доручте наступне справжнє завдання скороченому файлу та перевірте, чи щось погіршиться. Після цього, щоразу коли агент припуститься помилки у чомусь, про що він не міг знати, додайте один рядок та перевірте його, як код. Ось така дисципліна, і вона не розширюється шляхом додавання нових елементів.
Агент вже знає середнє значення. Єдина задача — це визначення дельти.
Пов’язані матеріали
- Чому тестування пам’яті агентів вводить в оману та як оцінювати їх на власних даних — У публічних топ-листах щодо пам’яті є помилкові ключі відповідей та системи оцінювання. Необхідно розділити процес пошуку інформації та формування відповідей, додати перевірки на послідовність, свіжість, утримання від відповідей та забування, а також відстежувати витрати.
- Вставка запитів та смертельна тріада: як забезпечити безпеку AI-агентів — Чому агенти не можуть розрізнити ваші інструкції від інструкцій зловмисника, як працювали атаки EchoLeak та GitHub MCP, та які заходи захисту є ефективними.