Генеративні моделі вже давно вийшли за межі простих чат-ботів. Сьогодні бізнеси будують автономних агентів, які самі планують роботу, викликають інструменти, пишуть код, ходять у веб і можуть працювати годинами без участі людини. У своєму курсі «Context Engineering for AI Agents» старша applied scientist Twitch/Amazon Марина Вісс розбирає, чому в таких системах перестає працювати проста «магія промптів» і на перший план виходить контекст-інжиніринг — дисципліна, яка визначатиме, чи буде ваш агент надійним, чи зламається на 20‑му кроці.
Коли агент «ламається» не через модель, а через те, що вона бачить
Будівельники агентів добре знають типовий сценарій. На перших кроках усе виглядає блискуче: модель обирає правильні інструменти, логічно міркує, тримає в голові ціль. Але десь після 15–20 кроку поведінка починає «пливти». Агент забуває початкове завдання, викликає дивні інструменти, тоне в зайвих деталях або видає дедалі гірші відповіді.
Інтуїтивна реакція — звинуватити саму модель: «GPT/Claude/Kimi не тягне складні довгі задачі». Однак дедалі більше практичних кейсів показують інше: проблема часто не в можливостях LLM, а в тому, що саме вона бачить на кожному кроці. Інакше кажучи, у контексті.
Кожна дія агента — виклик API, читання файлу, завантаження веб-сторінки, проміжний висновок — додає нові токени до контекстного вікна. Це вікно обмежене, і коли воно заповнюється «шумом», модель починає втрачати важливі речі: початкові інструкції, план, ключові факти. Виникає те, що практики називають «context drop» — поступове розмивання якості міркування в міру зростання контексту.
Саме тут і з’являється контекст-інжиніринг як окрема інженерна дисципліна.
Що таке контекст-інжиніринг і чим він відрізняється від промпт-інжинірингу
Промпт-інжиніринг став першою масовою навичкою епохи LLM. Його суть — сформулювати хороші інструкції: чітко описати задачу, задати роль моделі, навести приклади, структурувати відповідь. Для діалогових сценаріїв на кшталт «чат з ChatGPT» цього часто достатньо.
Але як тільки ми переходимо від одноразових відповідей до агентів, які діють автономно десятки кроків, промпт-інжиніринг перестає бути достатнім. Агент не просто відповідає на одне питання — він:
- послідовно виконує дії;
- працює з інструментами;
- генерує і споживає великі обсяги проміжних даних;
- підтримує довгу історію взаємодії.
Кожен із цих елементів потрапляє в контекст, і саме сукупність усього, що модель бачить на кожному кроці, визначає результат.
У цьому сенсі контекст-інжиніринг — це проєктування всієї інформаційної системи навколо LLM. Не лише початкового системного промпту, а всього, що модель отримує як вхід на кожному кроці:
- системні інструкції;
- описи інструментів;
- результати попередніх викликів;
- історія діалогу;
- витягнуті документи;
- пам’ять;
- поточний стан агента.
Команда Anthropic формулює це ще точніше. У їхньому визначенні контекст — це набір токенів, які включені в момент семплінгу з LLM. А контекст-інжиніринг — це оптимізація корисності цих токенів для досягнення бажаного результату. Тобто завдання не просто «заповнити вікно», а зробити так, щоб кожен токен працював на ціль.
У цій рамці промпт-інжиніринг стає підмножиною контекст-інжинірингу. Усе, що ми звикли робити з промптами — чіткі інструкції, приклади, форматування — залишається важливим, але доповнюється вищим рівнем: керуванням інструментами, зовнішніми даними, історією повідомлень, пам’яттю та динамічним станом. Anthropic прямо описує контекст-інжиніринг як «природну еволюцію» промпт-інжинірингу.
Для розробників, які досі зосереджувалися лише на тексті промпту, це логічний наступний крок: від роботи з однією інструкцією — до управління всією інформаційною екосистемою навколо моделі.
Чому саме зараз контекст-інжиніринг стає критично важливим
Потреба в цій навичці зумовлена не лише технічними обмеженнями LLM, а й ринковою динамікою. Аналітики Gartner прогнозують, що до кінця 2026 року 40% корпоративних застосунків інтегруватимуть спеціалізованих AI‑агентів для виконання завдань. У 2025‑му цей показник становитиме менше 5%.
Такий стрибок означає, що за два роки агентні системи перестануть бути експериментами в R&D‑відділах і стануть звичною частиною бізнес‑інфраструктури: від внутрішніх інструментів для розробників до операційних систем підтримки клієнтів, аналітики, документообігу.
У цьому світі виграють не ті, хто просто «підключив GPT до продукту», а ті, хто навчився будувати агентів, здатних:
- працювати довго без деградації якості;
- коректно обирати інструменти на 50‑му кроці так само, як на першому;
- не губити початкові цілі й обмеження в морі проміжних даних.
Саме це й дає контекст-інжиніринг. Він перетворює LLM‑агента з «розумного, але забудькуватого стажера» на систему, яка може тримати курс протягом довгих, розгалужених сценаріїв.
З практичної точки зору це означає, що контекст-інжиніринг стає базовою компетенцією для AI‑інженерів, розробників продуктів, архітекторів систем і навіть технічних менеджерів. Без розуміння того, як працює контекст, важко оцінити ризики, спроєктувати архітектуру чи пояснити бізнесу, чому агент «ламається» через годину роботи.
LLM як CPU, контекст як RAM: чому «більше токенів» не рятує
Щоб зрозуміти, чому контекст потрібно інженерити, а не просто збільшувати, зручно скористатися аналогією, яку пропонує LangChain. Вона описує LLM як новий тип операційної системи:
- сама модель — це CPU, «процесор», який виконує обчислення, тобто міркує;
- контекстне вікно — це RAM, оперативна пам’ять, у якій зберігається все, що модель може одночасно «бачити» й опрацьовувати.
Як і в традиційних комп’ютерах, RAM обмежена. Коли вона заповнюється, система починає працювати повільніше й менш ефективно. У випадку LLM це проявляється не в затримках, а в погіршенні якості міркування: модель втрачає важливі зв’язки, перестає помічати релевантні факти, плутається в інструкціях.
Дослідження Chroma, у якому оцінили 18 передових моделей (GPT‑4.1, Claude 4, Gemini 2.5, Qwen 3 та інші), показало, що деградація продуктивності з ростом довжини вхідних даних — універсальне явище. Вона починається задовго до формальної межі контекстного вікна. Наприклад, модель із заявленим вікном у 200 тисяч токенів може демонструвати помітне падіння якості вже на рівні близько 50 тисяч токенів.
Важливо, що це не «обрив» на краю вікна, а плавний спад. Anthropic у своїх інженерних матеріалах також підкреслює, що деградація контексту — градієнтний процес. Чим більше ми наближаємося до межі, тим гірше модель справляється з повним набором зв’язків між токенами.
Технічно це пов’язано з тим, як працюють трансформери: кожен токен «уважно дивиться» на кожен інший, формуючи квадратичну кількість парних взаємодій. У міру зростання контексту модель змушена «розмазувати» увагу по дедалі більшій кількості елементів. У результаті деякі зв’язки просто випадають, як у людини, яка намагається одночасно тримати в голові занадто багато деталей.
Це означає, що стратегія «візьмемо модель з більшим контекстом і просто запхаємо туди все» не працює. Навіть якщо вікно формально велике, якість міркування в ньому не є рівномірною.
Ефект «lost in the middle»: коли інструкції зникають у центрі контексту
Окремий феномен, який робить контекст-інжиніринг ще важливішим, — це так званий ефект «lost in the middle». Дослідники виявили, що LLM демонструють U‑подібну криву уваги: вони краще запам’ятовують інформацію на початку й наприкінці контексту, а дані посередині обробляють гірше.
У вимірюваних експериментах переміщення релевантної інформації з початку контексту в його середину призводило до падіння точності більш ніж на 30 процентних пунктів. Для агентів це має прямі наслідки.
Уявімо, що початкові інструкції агента — його «характер», обмеження, стратегія — знаходяться на початку контексту. Далі протягом десятків кроків ми додаємо туди результати інструментів, фрагменти веб-сторінок, логи, проміжні міркування. Через деякий час оригінальний системний промпт опиняється десь посередині величезного контексту, оточений тисячами токенів.
З погляду моделі це означає, що інструкції фактично «зникають». Агент починає поводитися так, ніби забув, ким він має бути й за якими правилами працювати. Саме так народжуються дивні рішення на пізніх етапах довгих сесій.
Контекст-інжиніринг тут потрібен не лише для економії токенів, а й для того, щоб критично важлива інформація — цілі, обмеження, архітектурні правила — не опинялася в «мертвій зоні» середини контексту.
Сім типів інформації, які борються за місце в контексті агента
Щоб зрозуміти, чим саме доводиться керувати, варто розкласти контекст агента на основні категорії. У типовій агентній системі за місце у вікні змагаються щонайменше сім типів інформації.
По-перше, системний промпт. Це не просто «ви — корисний асистент», а повний опис ідентичності агента, його поведінкових правил, логіки керування, підходів до різних типів задач. У складних агентів системний промпт фактично задає архітектуру: як планувати роботу, коли викликати інструменти, як поводитися з помилками.
По-друге, описи інструментів. Кожен доступний агенту інструмент — від HTTP‑клієнта до спеціалізованого сервісу — потребує схеми в контексті: що він робить, які параметри приймає, коли його варто використовувати. Без цього модель не зможе коректно обрати й викликати потрібний інструмент.
По-третє, результати викликів інструментів. Кожен запит до API, кожне читання файлу, кожне завантаження веб-сторінки повертає дані, які додаються до контексту. Одна сторінка може займати 5–10 тисяч токенів, великий файл — стільки ж. Кілька таких кроків — і значна частина вікна вже заповнена сирими результатами.
По-четверте, витягнуті знання. Це документи з векторних баз, результати пошуку, відповіді зовнішніх API — усе, що система або сам агент підтягує для ухвалення рішень. У класичному RAG це часто основне джерело контексту, але в агентних сценаріях воно лише одна з багатьох складових.
По-п’яте, історія діалогу. Повний лог взаємодії: повідомлення користувача, відповіді агента, його попередні міркування й рішення. Усе це зростає лінійно з кожним кроком. Якщо не обмежувати історію, вона швидко починає витісняти інші важливі елементи.
По-шосте, пам’ять. І короткострокова в межах поточної сесії, і довгострокова між сесіями. Сюди входять уподобання користувача, результати попередніх задач, виявлені патерни. Це те, що робить агента «персоналізованим» і послідовним у часі.
По-сьоме, стан агента. Поточний план, список підзадач, маркери прогресу, робочі нотатки — усе те «мета-інформаційне» сміття, без якого багатокрокові задачі розвалюються. Це може бути як явний план, так і scratchpad із проміжними висновками.
Усі ці категорії одночасно претендують на місце в обмеженому вікні, яке до того ж деградує в міру заповнення. Контекст-інжиніринг — це мистецтво й ремесло балансувати між ними: що залишити, що викинути, що стиснути, що винести за межі контексту й зберегти в окремих структурах.
Як моделі й платформи підлаштовуються під агентні сценарії
Навіть ідеально спроєктований контекст не скасовує того факту, що різні моделі по‑різному поводяться в довгих, інструментально насичених сценаріях. Це стимулює появу спеціалізованих LLM, оптимізованих саме під агентну роботу.
Один із прикладів — Kimi K2.6, відкритий LLM, який досяг state-of-the-art результатів на бенчмарку SweBench Pro. Цей бенчмарк орієнтований на складні задачі програмування, де агент має працювати з реальними кодовими базами, виправляти баги, вносити зміни.
Команда Kimi демонструвала агент, побудований на K2.6, який автономно працював 13 годин, зробив понад тисячу викликів інструментів, змінив близько 4 тисяч рядків коду й майже утричі збільшив пропускну здатність уже оптимізованої кодової бази. Важливий момент у контексті нашої теми: нова версія моделі досягає тих самих результатів приблизно на 35 кроків менше, ніж попередня.
Менше зайвих викликів інструментів означає менше «сміття» в контексті. Кожен непотрібний крок — це додаткові токени історії, результатів, стану. Якщо модель краще планує й рідше робить зайві дії, контекст заповнюється повільніше, а агент довше зберігає чіткість міркування.
Ще одна цікава ідея — «рої» агентів. Kimi пропонує можливість запускати до 300 субагентів паралельно, кожен із власним чистим контекстним вікном. Кожен субагент виконує фокусовану частину задачі, а потім повертає результат. З погляду контекст-інжинірингу це спосіб рознести навантаження: замість одного агента з гігантським, зашумленим контекстом ми маємо багато невеликих, кожен із контрольованим, локальним контекстом.
Поверх моделі K2.6 компанія будує цілу екосистему: CLI‑агент Kimi Code у дусі Claude Code, конструктор сайтів, інструмент для генерації презентацій. Усі ці продукти по суті є різними інтерфейсами до агентних можливостей моделі, і в кожному з них контекст-інжиніринг — від того, як зберігаються інструкції до того, як організована пам’ять — визначає, наскільки інструмент буде корисним у реальних робочих процесах.
Те, що K2.6 є open source і може запускатися локально, робить його цікавим полігоном для команд, які хочуть експериментувати з власними підходами до контексту, не обмежуючись хмарними API.
Чотири стратегії LangChain: як мислити про контекст як про систему
Щоб не тонути в окремих трюках і «хаках», LangChain пропонує рамку з чотирьох базових стратегій контекст-інжинірингу: write, select, compress, isolate. Усі відомі техніки так чи інакше вкладаються в ці категорії.
Write — це про те, щоб навчити агента «записувати» важливу інформацію за межі контекстного вікна. Коли контекст переповнюється й система змушена його стискати або обрізати, усе, що не було збережено в зовнішніх структурах, безповоротно зникає. Запис дозволяє винести частину знань у стійкі сховища.
Один із форматів — scratchpad, тобто окремий робочий простір, куди агент може занотовувати проміжні висновки, важливі рішення, дані, які знадобляться пізніше. Anthropic, наприклад, створила для Claude інструмент think — спеціальний «чернетковий» простір для опрацювання складних задач. На одному з їхніх бенчмарків це дало приріст продуктивності на 54% для певних типів завдань.
Інший формат — файли правил, або стійка процедурна пам’ять. У Claude Code це реалізовано як файл claude.md, який завантажується на початку кожної сесії агента. У ньому описані структура проєкту, конвенції, способи запуску тестів, важливі застереження. Агент читає ці інструкції щоразу, коли стартує, і таким чином ніколи не «забуває» фундаментальні речі, навіть якщо робочий контекст сильно змінюється.
Третій формат — витяг пам’яті: збереження фактів, уподобань користувача, виявлених патернів у зовнішніх файлах або базах, до яких агент може звертатися між сесіями. Це дозволяє будувати довгострокову поведінку, не покладаючись на те, що все важливе завжди поміститься в поточне вікно.
Select — друга базова стратегія. Її суть: не давати агенту «все й одразу», а підбирати саме те, що потрібно для поточного кроку. У класичному RAG вибір релевантних документів робить система: користувач ставить запит, механізм пошуку повертає кілька фрагментів, їх «запихають» у промпт. Модель не контролює, що саме їй підсунули.
В агентних сценаріях, де є десятки інструментів, великі бази знань і довга історія, такий підхід перестає працювати. Потрібен більш тонкий механізм відбору, який враховує не лише поточний запит, а й план агента, його стан, попередні кроки. Це вже виходить за межі простого RAG і стає частиною загальної архітектури контексту.
Дві інші стратегії — compress і isolate — стосуються відповідно стискання інформації й розділення контекстів між підзадачами або субагентами. Вони детальніше розкриваються в інших частинах курсу, але важливо, що всі чотири разом задають спосіб мислення: контекст — це не «чорна скринька» моделі, а керований ресурс, який потрібно проєктувати так само уважно, як бази даних чи кеші.
Пам’ять агентів: епізодична, семантична, процедурна
Ще один важливий аспект контекст-інжинірингу — робота з пам’яттю. У розмові про агентів дедалі частіше використовують три типи пам’яті, запозичені з когнітивних наук і адаптовані до LLM‑систем.
Епізодична пам’ять — це конкретні приклади, few-shot демонстрації, фрагменти попередніх діалогів, які показують агенту, як поводитися в певних ситуаціях. Вони часто включаються безпосередньо в контекст як частина промпту.
Семантична пам’ять — це факти, знання про світ, доменну інформацію. Вона може зберігатися в зовнішніх базах і підвантажуватися за потреби через RAG або інші механізми вибірки.
Процедурна пам’ять — це стійкі поведінкові інструкції: «як ми тут робимо речі». Саме до неї належать файли на кшталт claude.md у Claude Code, які завантажуються на старті кожної сесії й задають правила гри для агента.
Контекст-інжиніринг у цьому вимірі — це про те, як рознести ці типи пам’яті між контекстом і зовнішніми сховищами, як їх оновлювати, коли й що підвантажувати назад. Без цього агент або тоне в надлишку «спогадів», або поводиться так, ніби нічого не пам’ятає.
Висновок: контекст як новий інтерфейс між людиною, моделлю й системою
Перехід від чат-ботів до агентів змінює саму природу роботи з LLM. Якщо раніше головним інтерфейсом був текстовий промпт, то тепер цим інтерфейсом стає контекст — динамічний, багатошаровий, наповнений інструментами, пам’яттю, станом.
Контекст-інжиніринг формалізує роботу з цим інтерфейсом. Він вимагає мислити про модель як про CPU, а про контекст — як про обмежену RAM, яку потрібно планувати, очищати, структурувати. Він змушує бачити за «магією» LLM конкретні інженерні рішення: що записати, що вибрати, що стиснути, що ізолювати.
На тлі прогнозів Gartner про вибухове зростання частки корпоративних застосунків з агентами до 40% уже в 2026 році стає очевидно: команди, які опанують контекст-інжиніринг, будуть будувати агентів, що працюють стабільно й передбачувано. Решта ризикують залишитися з системами, які вражають демо, але розвалюються в реальних, довгих сценаріях.
У цьому сенсі контекст-інжиніринг — не просто ще один модний термін, а новий базовий шар інженерії штучного інтелекту, без якого епоха AI‑агентів не відбудеться.
Джерело
Context Engineering for AI Agents: Complete Course — YouTube