Коротка відповідь: Context engineering для AI-агентів — це дисципліна вибору того, що агент бачить на кожному кроці: системні інструкції, інструменти, видобуті дані, памʼять і попередній діалог, — щоб модель отримувала мінімальний набір високосигнальних токенів, потрібних для правильної дії. Це наступник prompt engineering. Prompt engineering оптимізував одне повідомлення; context engineering оптимізує все інформаційне середовище, в якому працює агент, упродовж багатьох кроків. Причина, чому це важливо, контрінтуїтивна: додавання контексту зазвичай робить агентів гіршими, а не кращими. У моделей скінченний бюджет уваги, і якість падає в міру заповнення вікна — вимірюваний ефект, який дослідники тепер називають «context rot». Довести агента до продакшену — це здебільшого робота з управління цим вікном.

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

Від prompt engineering до context engineering

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

Context engineering ставить інше питання: з усього, що агент міг би бачити просто зараз, що йому справді потрібно — і що варто прибрати? Команда Applied AI в Anthropic, яка формалізувала термін у вересні 2025 року, сформулювала ціль точно: знайти «найменший можливий набір високосигнальних токенів, який максимізує ймовірність бажаного результату». Акцент на найменшому — і є весь зсув. Prompt engineering був про те, щоб додати правильні слова. Context engineering так само часто — про те, щоб прибрати неправильні.

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

Context rot: чому більше контексту робить агентів гіршими

Коли агент не справляється, інстинкт — дати йому більше: більше прикладів, більше документів, більше історії, більше інструментів. Цей інстинкт, як правило, хибний, і тепер це можна виміряти.

Дослідження Chroma 2025 року формалізувало явище під назвою context rot: у міру додавання токенів на вхід LLM якість виводу падає. У дослідженні протестували 18 фронтир-моделей на зростаючих довжинах контексту — деградувала кожна. Важливо, що деградація була не лише про досягнення межі довжини. Дослідження показало, що семантично схожий, але нерелевантний контент активно збивав моделі зі шляху — текст-дистрактор, що виглядав релевантним, відводив відповіді вбік сильніше, ніж пояснювалося самою лише довжиною.

Цифри гірші, ніж припускає більшість команд. За даними досліджень, моделі показували помітну деградацію точності задовго до заявлених меж — деякі вже близько 1000 токенів, а модель, розрахована на 200K токенів контексту, може почати деградувати ближче до 50K. Агентна продуктивність на моделях із заявленими вікнами в 1M+ токенів, за повідомленнями, різко падає вже близько 100K токенів. Заявлене контекстне вікно — це місткість, а не обіцянка якості на всій цій місткості.

І це не нішева інженерна турбота — це провідна причина провалів. За оцінками, що повідомляються, значна частка корпоративних провалів зі ШІ у 2025 році повʼязана з дрейфом контексту чи втратою памʼяті під час багатокрокового міркування. Це збігається з ширшим розривом між хайпом і продакшеном: Gartner прогнозує, що понад 40% агентних ШІ-проєктів будуть згорнуті до 2027 року, а більшість оцінок відносить частку агентних ініціатив, що так і не дійшли до продакшену, до понад 80%. Модель рідко є проблемою. Проблема зазвичай — контекст навколо неї.

Бюджет уваги: чому «менше — означає краще» тут буквально

Причина context rot механічна, а не загадкова. Трансформер розподіляє увагу по всіх токенах у своєму вікні. У міру зростання вікна увага розмазується тонше — кожному токену дістається менша частка фіксованого бюджету. Одне релевантне речення стає статистично важче знайти, коли воно оточене десятками тисяч низькосигнальних токенів. Модель не «забула» важливу деталь — вона її розбавила.

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

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

Чотири стратегії: write, select, compress, isolate

Спільнота практиків — спираючись на широко цитоване формулювання LangChain — зійшлася на чотирьох стратегіях управління контекстом агента. Це не конкурентні підходи; продакшен-агент зазвичай використовує всі чотири.

  1. Write (записувати) — зберігати контекст поза вікном. Замість того щоб нести все в промпті, агент записує стан, нотатки чи проміжні результати у зовнішнє сховище (чернетку, обʼєкт стану, постійне сховище) і підтягує їх назад лише за потреби. Вікно лишається компактним, і нічого не губиться.
  2. Select (вибирати) — підтягувати лише те, що потрібно поточному кроку. Це видобування, зроблене усвідомлено: дістати релевантні документи, релевантні спогади й навіть релевантні інструменти для цього кроку, а не завантажувати все за замовчуванням. Вибір трьох потрібних інструментів із сорока не дає означенням інструментів витіснити саме завдання.
  3. Compress (стискати) — лишати тільки токени, потрібні для дії. Довгі діалоги сумаризуються; багатослівні виводи інструментів дистилюються до суті перед повторним входом у вікно. Стиснення міняє невелику контрольовану втрату деталі на значний приріст щільності сигналу.
  4. Isolate (ізолювати) — розділяти контекст за межами. Коли завдання складається з кількох різних робіт — вивчити велику кодову базу, розібрати довгий документ, написати резюме — передача всіх їх одному агентові засмічує його вікно. Ізоляція дає кожній підзадачі свого агента з чистим контекстом, а потім обʼєднує результати. Кожен суб-агент працює в чистому повітрі.

Судження — в комбінації. Write і select тримають вікно релевантним; compress і isolate тримають його малим. Стійкий агент застосовує їх безперервно, а не один раз на етапі проєктування.

Що насправді живе в контекстному вікні агента

Щоб інженерити контекст, потрібно бачити його як багатошарову річ. На будь-якому кроці вікно агента зазвичай містить:


Більшість проблем із контекстом — це конкретний шар, що поводиться погано: забагато означень інструментів, надто широкі видобуті дані, ніколи не стискувана історія, ніколи не відбирана памʼять. Назвати шари — означає знайти витік.

Context engineering упродовж довгоживучого агента

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

На практиці це три повторювані рухи. Агент вивантажує стан у зовнішню памʼять по ходу роботи, щоб прогрес виживав поза вікном (стратегія write). Він ущільнює поточну історію з інтервалами — сумаризуючи те, що сталося, і відкидаючи сиру стенограму, — щоб вікно відображало ситуацію, не несучи кожен токен, який її породив. І він очищає відпрацьований контекст: щойно результат інструмента використано і його висновок зафіксовано, багатослівний оригінал може покинути вікно. Агент зберігає рішення, а не сміття.

Цей життєвий цикл — ще й місце, де context engineering зустрічається з рештою роботи з доведення агента до продакшену. Ті самі багатокрокові прогони, що гниють, потрібно трасувати й спостерігати, щоб побачити, де вікно пішло не так, і ті самі провали стають кейсами у вашому eval-харнесі, щоб довести, що зміна контексту справді допомогла. Context engineering — одна з граней тієї ж дисципліни, що й спостережуваність та evals: зробити поведінку агента читаною, вимірюваною та поліпшуваною, а не сподіватися, що вона втримається.

Часті помилки, які ми бачимо

Кілька помилок із контекстом трапляються знову і знову, і в них спільний корінь: ставлення до контексту як до того, у що додають, а не до того, що курують.

Перша — скидання. Команди видобувають усе, що може бути релевантним, і надають моделі розбиратися. Вона не може — нерелевантний матеріал не сидить тихо, він збиває зі шляху. Це провал «Dumb RAG»: видобування, що дістає правдоподібно-повʼязаний, але неправильний контекст і погіршує відповідь.

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

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

Четверта — плутати памʼять з історією. Зберігати повну стенограму — це не памʼять; це накопичення. Памʼять — це усвідомлений вибір того, що має зберегтися (кілька стійких фактів), а не відмова щось викидати.

Як до цього підходить Moai Team

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

Часті запитання

Що таке context engineering для AI-агентів?

Context engineering для AI-агентів — це дисципліна курування всього, що модель бачить на кожному кроці роботи агента: системних інструкцій, означень інструментів, видобутих даних, памʼяті та історії діалогу, — щоб вона отримувала мінімальний набір високосигнальних токенів, потрібних для правильної дії. Це ширше, ніж prompt engineering, який оптимізує лише одне повідомлення; context engineering управляє всім інформаційним середовищем упродовж багатьох кроків.

Чим context engineering відрізняється від prompt engineering?

Prompt engineering оптимізує те, як ви формулюєте один запит. Context engineering оптимізує все, що агент бачить упродовж усього багатокрокового прогону, — і часто означає прибирати токени, а не додавати. Промпт — лише один компонент контексту; інші (інструменти, видобуті дані, історія, памʼять) можуть зламати агента, навіть коли промпт бездоганний. У міру того як агент проходить багато кроків, context engineering значить набагато більше, ніж формулювання промпта.

Що таке context rot?

Context rot — це вимірюване явище, формалізоване дослідженням Chroma 2025 року: якість виводу LLM падає в міру додавання токенів на вхід. Тестування 18 фронтир-моделей показало, що деградувала кожна в міру зростання контексту, і що семантично схожий, але нерелевантний контент активно збивав їх зі шляху. Багато моделей деградують задовго до заявлених меж контексту — тому просте «дати агентові більше контексту» зазвичай робить його гіршим.

Якими є чотири стратегії context engineering?

Write (зберігати контекст у зовнішнє сховище, щоб вікно лишалося компактним), select (підтягувати лише документи, спогади та інструменти, потрібні поточному кроку), compress (сумаризувати історію та вивід інструментів, лишаючи тільки істотні токени) та isolate (розділяти завдання між окремими агентами, щоб кожен працював у чистому вікні). Продакшен-агенти зазвичай використовують усі чотири разом, а не обирають одну.

Moai Team будує AI-агентів із контекстом, спроєктованим з першого прототипу, — вузьке видобування, компактні набори інструментів і вбудоване ущільнення, — щоб вони лишалися надійними на тисячному реальному запиті, а не лише на демо. Запланувати дзвінок.