Інженерія контексту для агентів з тривалим функціонуванням: векторна база даних, KV-кеш, Claude Code

Написано багато про те, що таке інжиніринг контексту. Набагато менше уваги приділено питанню, з яким стикається розробник на практиці: як слід спроєктувати конвеєр контексту для агента, який працює 200 кроків? Вікно у мільйон токенів здається щедрим, проте дослідження Chroma 2025 року з участю 18 передових моделей показало, що якість починає погіршуватися, коли вікно заповнюється на 50–70 відсотків. Далі наведено план дій щодо цього, спрямований на тих, хто створює продакшн-агентів. У ньому розглядається, чому довгі контексти деградують, модель пам’яті, запозичена з архітектури комп’ютерів, чотири підходи до керування контекстом, економіка KV-кешу, відмінності між трьома відомими продуктами та алгоритм прийняття рішень із показниками.

Агент без моделі пам’яті має амнезію

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

Дослідження, опубліковане Zylos AI у 2026 році, вказує на те саме: подвоєння тривалості завдання, за даними дослідження, подвоює ймовірність невдачі, а якість роботи агентів погіршується приблизно через 35 хвилин виконання завдання. У згаданому вище дослідженні Chroma було виявлено, що кожна з 18 моделей погіршувала свою продуктивність із збільшенням обсягу контексту. Бенчмарк NoLiMa (ICML 2025) показав ще гірші результати: вже при 32K токенах 11 з 13 моделей досягали рівня, нижчого за половину від своєї початкової продуктивності, хоча вони пропонували продуктивність 128K та більше; крім того, продуктивність GPT-4o знизилася з 99,3% до 69,7%.

Чому розпад є вбудованим

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

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

Розмір вікна, зазначений у описі, також є оманливим. Модель, яка приймає мільйон токенів, не забезпечує мільйон токенів корисної ємності.

Тривога через контекст

Користувачі помітили, а Anthropic підтвердив, ще одну особливість: Claude Sonnet 4.5 схильний завершувати завдання занадто рано, коли наближається ліміт контексту. Це явище називають тривогою через контекст. Модель поводиться так, ніби у неї закінчується оперативна пам’ять, і відмовляється від подальшої роботи ще до того, як її ресурси справді будуть використані.

Оскільки погіршення якості неможливо уникнути, архітектура агента мусить цим керувати. У інженерії систем існує давня аналогія, яка допомагає у цьому.

Модель — це процесор, контекст — оперативна пам’ять, база даних векторів — диск

У середині 2025 року Андрій Карпаті віддав перевагу „інженерії контексту“ перед „інженерією запитів“, описавши її як тонке мистецтво та науку заповнення вікна саме тією інформацією, яка потрібна для наступного кроку. Він не вигадував нового терміна — він вказував на зміну підходу: ШІ є процесором, вікно контексту — оперативною пам’яттю, а інженер, який створює агента, виконує роль операційної системи.

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

Ієрархія пам’яті для агентів

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

• Пам’ять роботи в контексті. Без додаткової затримки, від 200 тис. до 1 млн токенів. Відповідає регістрам та кешу L1: найшвидша, найдорожча та найбільш обмежена за ресурсами.
• Кеш KV. Затримка менше 10 мс. Порівнянний із кешем L2 або L3, зберігає матриці уваги, попередньо обчислені для попередніх токенів, та зберігає їх між запитами.
• Векторна база даних або семантичний пошук. Приблизно від 5 до 50 мс та мільйони записів, є аналогом оперативної пам’яті. Наведені цифри включають близько 0,34 мс на запит для FAISS, що працює локально, та 7 мс p99 для Pinecone.
• Файлова система або нотатки. Затримка понад 100 мс без реального обмеження за розміром, як у диска.
• Архівне зберігання. Час читання в секундах, порівнянний із мережевим або резервним зберіганням.

Кожне рішення щодо місця зберігання інформації — це компроміс між витратами, затримкою та пропускною здатністю. Якщо обрати неправильний рівень, наслідком може бути висока сума рахунку або агент, який забуває інформацію. Робота MemGPT 2023 року, яка часто цитується, сформалізувала цю ідею під назвою «віртуальне управління контекстом», заснована на принципах управління різними рівнями пам’яті в операційних системах. Сьогодні цей підхід продовжує існувати у вигляді фреймворку Letta.

Якщо контекст — це RAM агента, які шаблони використовуються для його управління в реальній системі та як вони взаємодіють?

Чотири шаблони: запис, вибір, стиснення, ізоляція

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

Запис: зберігання стану поза межами контексту

Написання тексту означає зовнішнє зберігання стану. Агент зберігає нотатки у файлі на кшталт todo.md, NOTES.md чи progress.md та читає їх знову на наступних етапах. Manus відомий за так званою „декламацією списку завдань“: агент постійно переписує свій список завдань у кінці контексту, щоб увага моделі була спрямована на загальний план. Це свідоме керування увагою, яке допомагає уникнути ефекту загублення інформації посеред процесу.

У експерименті з грою Pokémon Claude Opus 4, за повідомленнями, зберігав точні нотатки протягом тисяч кроків гри, включаючи рівні персонажів, карти та стратегії, без жодних прямих вказівок щодо структурування своєї пам’яті.

Вибір: отримувати інформацію саме в потрібний момент

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

За повідомленнями, Claude Code пробував векторні бази даних, але відмовився від них через те, що код виходить з синхронізації, а права доступу ускладнюються. Cursor обрав протилежний підхід, поставивши на динамічне відкриття інформації через семантичне індексування. За даними тесту типу A/B, коли агент завантажував інструменти MCP за потребою, кількість токенів зменшилась на 46,9%.

Стиснення: зменшення об’єму

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

За повідомленнями, Claude Code попереджає про досягнення приблизно 80% завантаження та автоматично компактує дані близько 95%, зберігаючи архітектурні рішення. Надмірно агресивна компактація видаляє тонкі, але важливі контекстуальні елементи, і агент починає знову досліджувати вже оброблені ділянки. На практиці оптимальним рівнем стиснення для продуктивної роботи вважається 3–6 разів. Академічні тестування показують значно вищі показники (LLMLingua наводить показник 20 разів із втратою точності лише на 1,5 бали для формату GSM8K), але для продакшн-використання потрібна вища точність.

Ізоляція: розділення за допомогою підагентів

Ізоляція означає розділення контекстів. Спеціалізований дитячий агент працює у власному вікні контексту та передає скорочений результат своєму батьківському агенту. Він може обробити 10 тис. токенів або більше, але повернути лише узагальнення обсягом 1–2 тис., що значно менше, ніж накопичується у спільному контексті. Manus застосовує принцип, запозичений з Go: не комунікуйте шляхом спільного використання пам’яті, а спільно використовуйте пам’ять шляхом комунікації.

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

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

Швидкість доступу до кешу KV — ключове показник

KV-кеш зберігає матриці уваги, які вже були обчислені для попередніх токенів, тож моделі не потрібно їх переобчислювати для кожного нового токена. Уявіть собі базу даних, яка заздалегідь обчислює результати об’єднання даних для часто використовуваних префіксів запитів. У одному з вимірювань GPT-2 генерація 200 токенів займала 11,9 секунди з використанням кешу та 56,2 секунди без нього, що дає прискорення приблизно в 4,7 рази.

Чому це змінює економіку агентів

Типовий продуктивний агент має співвідношення вхідних та вихідних даних близько 100 до 1, на відміну від приблизно 1 до 1 у чат-ботів. Переобчислення всіх вхідних даних становить основну частину кожного запиту. Кешування запитів — це механізм з боку постачальника, який зберігає обчислені токени для ідентичних префіксів між запитами, що робить операції зчитування приблизно в десять разів дешевшими. Для Claude Sonnet ціни становлять 0,30 долара за мільйон кешованих токенів проти 3,00 долара за токени без кешування.

Отже, переформування дизайну контексту навколо кешу KV може ефективно зменшити місячний рахунок за API з $8 000 до $800, що узгоджується з десятикратною знижкою від Anthropic за використання кешу. Ічао „Пік“ Цзі, співзасновник Manus, зазначав, що для агента у промисловому використанні ніщо не має більшого значення, ніж частота звернень до кешу KV.

Три правила для підтримки активного кешу

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

Чіткі точки розриву кешу. Відзначте у контексті точки, які підкажуть постачальнику, де зберігати префікс.

Існує ще одна проблема, іноді називана „податком MCP“. Припустимо, 10–15 інструментів кожен містить від 10 тис. до 15 тис. токенів визначень. Це означає від 100 тис. до 225 тис. токенів додаткових витрат ще до того, як користувач щось введе. Для 1 000 розробників із п’ятьма сеансами на день приблизна оцінка показує витрати близько 1,2 мільйона доларів на рік лише на визначення інструментів. Рішенням є поступове розкриття інформації: завантажувати інструменти саме тоді, коли вони потрібні, а не всі одночасно.

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

Claude Code та ще два продукти, три філософії

Claude Code, Cursor та Manus пропонують три послідовні та різні рішення для однієї й тієї самої проблеми. Кожне з них ґрунтується на власному контексті завдання, а не на незнанні альтернатив.

Claude Code: статичне завантаження заздалегідь плюс читання в момент потреби

Claude Code від Anthropic завантажує CLAUDE.md на початку сеансу як документ для ознайомлення, а потім переглядає кодову базу за допомогою інструментів glob та grep, без використання баз даних типу vector. Він автоматично стискає дані майже на 95% та зберігає архітектурні рішення. За повідомленнями, поєднання інструменту для керування пам’яттю з редагуванням контексту дало покращення на 39% порівняно з базовим варіантом.

Через проблеми з контекстом у версії Sonnet 4.5 моделі потрібні були зовнішні скидання контексту. За даними Anthropic, цю проблему було вирішено у новіших версіях моделі без змін у архітектурі інструменту.

Cursor: два рівні та динамічне пошукове функціонування

Cursor (створений компанією Anysphere) розділяє „контекст наміру“, тобто те, про що просить користувач, від „контексту стану“, тобто актуальний стан файлів, змін та помилок. За замовчуванням він читає лише перші 250 рядків будь-якого файлу — це свідомий вибір, який дозволяє заощадити токени та гроші.

Значна зміна відбулася у січні 2026 року. Cursor зазначив, що оскільки моделі ставали кращими у форматі агентів, краще було надавати менше деталей спочатку та дозволяти агенту самостійно знаходити відповідний контекст. Раніше згаданий тест A/B показав зниження кількості токенів на 46,9% порівняно з завантаженням за запитом.

Manus: градієнтний спуск шляхом проб і помилок

Manus описує свій підхід як „стохастичне зниження градієнта“, причому файлова система виступає у ролі кінцевого контексту. За повідомленнями, з березня 2025 року команда п’ять разів перебудовувала свою платформу. Підсумок Джі: інженерія контексту виявилася зовсім не простою справою та є експериментальною наукою.

Команді приписують шість принципів:

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

Що дає це порівняння

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

Легко припустити, що збільшення обсягу даних вирішить проблему, адже мільйон токенів має бути достатньо. Однак дані NoLiMa та Chroma швидко спростовують це припущення. Claude 4 Sonnet демонструє значно кращу стійкість до зіпсованого контексту, ніж старіші моделі, але це виняток, який підтверджує правило, а не доказ того, що проблема зникла.

Ці системи та шаблони охоплюють те, що є ефективним. Решта полягає у тому, щоб перетворити їх на конкретні варіанти проектування для певного агента та з’ясувати, чи справді проектування контексту виконує свою функцію.

План дій: що використовувати та що вимірювати

Стаття від березня 2026 року про архітектуру багатоагентних систем у корпораціях (arXiv:2603.09619, про перехід від запитів до інженерії контексту) пропонує п’ять критеріїв якості контексту та розглядає контекст як операційну систему агента:

• Релевантність. Чи є інформація актуальною для поточного кроку прийняття рішення? Нерелевантний контекст безпосередньо завдає шкоди.
• Достатність. Чи має агент усе необхідне, без необхідності здогадувань?
• Ізоляція. Чи належним чином розділені контексти агентів, щоб дані одного користувача ніколи не потрапляли до іншого?
• Економія ресурсів. Чи є контекст найменшою можливою кількістю токенів із високою інформативністю? Кожен зайвий токен витрачає бюджет уваги.
• Походження. Чи можна відстежити, звідки походить кожен елемент контексту? Це важливо для виправлення помилок.

Шлях прийняття рішень

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

Для тривалого завдання, де рішення на 5-му кроці впливає на 50-й крок, використовуйте компактування, яке зберігає архітектурні рішення. Попереджайте при приблизно 80% заповнення та автоматично компактуйте при приблизно 95%.

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

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

Що потрібно відстежувати

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

• Швидкість зростання кількості токенів. Постійне монотонне зростання означає відсутність стратегії компактування. Характер зростання, зупинки та знову зростання свідчить про ефективну роботу механізму компактування.
• Коефіцієнт успішних запитів до кешу KV. Рівень нижче 50% вказує на те, що щось у префіксі системного запиту постійно змінюється. Спочатку перевірте часові позначки та інші динамічні елементи.
• 35-хвилинна гіпертеза. Здається, що ефективність агентів знижується приблизно через 35 хвилин виконання завдань, тому плануйте контрольні точки, враховуючи цей факт.
• Амнезія після компактування. Якщо агент знову досліджує вже пройдену територію, це означає, що процес компактування, ймовірно, є занадто інтенсивним.

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

SWE-ContextBench (arXiv:2602.08316) підтверджує це, виявивши, що нефільтрований або неправильно обраний досвід приносить обмежену чи навіть негативну користь. Більше контексту не завжди краще, а поганий контекст активно шкодить.

Правила проєктування контексту для довготривалих агентів

Розробка конвеєра контексту — це інше питання, ніж запитання про те, що таке інженерія контексту, і з цього випливає кілька висновків.

• Зіпсування контексту — це фізична властивість трансформерів. Краща модель це не виправляє; цим займається архітектура пам’яті.
• Модель — це CPU, контекст — це RAM, а інженерія контексту — це операційна система агента, що переносить дискусію з лінгвістики до інженерії систем.
• Запис, вибір, стиснення та ізоляція — це взаємодоповнюючі етапи, а не альтернативи, і кожен продакшн-агент використовує усі чотири.
• Критерієм оцінки є рівень використання кешу KV, а одна помилкова дата у системному запиті може додати десятки тисяч доларів до щомісячного рахунку.
• Не існує єдиної правильної філософії, як показують Claude Code, Cursor та Manus.
• Хороше проектування контексту означає наявність п’яти критеріїв якості та вимірюваних показників, а не інтуїції.

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