Контекст-інженерія стрімко переходить із теоретичних блогпостів у практику продакшн-систем. У новому навчальному курсі старша applied scientist Twitch та фахівчиня з генертивного AI Марина Вісс розбирає, як сучасні платформи на кшталт Claude Code та відкритого Kimi K2.6 реально управляють контекстом у довгоживучих агентів — і чому без цього будь-який «розумний» асистент починає деградувати вже на 15–20-му кроці.
Ця стаття зосереджується на інструментах і стратегіях, які вже працюють у бойових умовах: від чотирьох базових тактик LangChain до конкретних реалізацій в Anthropic і Kimi.
Чотири стратегії LangChain: як розкласти контекст-інженерію по поличках
У міру того як агенти переходять від разових відповідей до багатогодинних автономних сесій з сотнями викликів інструментів, стає очевидно: проблема не стільки в моделях, скільки в тому, що вони бачать на кожному кроці. Саме цю зону й описує контекст-інженерія — проєктування всієї інформаційної системи навколо LLM, а не лише стартового промпту.
LangChain пропонує просту, але досить всеосяжну рамку, яка структурує всі техніки роботи з контекстом у чотири стратегії: write, select, compress та isolate. Вони не конкурують між собою, а радше накладаються, формуючи повний цикл життя інформації в агенті.
Write — це про те, щоб вивести думки моделі за межі контекстного вікна: записати проміжні висновки, правила, факти в зовнішні сховища, які не зникають під час компактінгу. Select — про вибірковість: замість того, щоб заливати в промпт усе, що є, система має підбирати лише релевантні шматки знань, історії чи описів інструментів для конкретного кроку.
Compress — про стиснення: коли контекст наближається до межі, потрібно не просто відрізати «хвіст», а акуратно підсумовувати пройдений шлях, зберігаючи ключові рішення й артефакти. Нарешті, isolate — про ізоляцію: розділення роботи між окремими контекстами або агентами, щоб кожен із них оперував чистим, сфокусованим вікном, а не загальним «смітником» із усіх попередніх дій.
Ця чотиричленна схема виявляється корисною не лише як теоретична класифікація. Вона добре пояснює, чому деякі продакшн-продукти працюють стабільно на довгих траєкторіях, а інші «пливуть» уже через кілька десятків кроків.
«Write» у дії: scratchpad Anthropic і procedural memory Claude Code
Перша стратегія — write — вирішує базову, але критичну проблему: агенти забувають. Коли контекстне вікно заповнюється й система запускає компактинг, частина інформації неминуче зникає. Якщо до цього моменту агент не виніс важливі знання в зовнішнє сховище, вони втрачаються безповоротно.
Anthropic і Claude Code демонструють одразу кілька практичних форм цієї стратегії.
Один із найяскравіших прикладів — think tool від Anthropic. Це окремий робочий простір, по суті scratchpad, де модель може «думати вголос»: фіксувати проміжні висновки, розкладати задачу на кроки, записувати гіпотези й перевірки. У внутрішньому бенчмарку Anthropic такий явний простір для мислення дав до 54% приросту продуктивності на певних типах завдань. Фактично, це демонстрація того, що «записувати думки» — не просто зручна фіча, а реальний спосіб підвищити якість міркувань.
Інша форма write — стійка процедурна пам’ять. У Claude Code це реалізовано через файл правил claude.md. Це не просто README, а набір постійних інструкцій, які завжди підвантажуються на старті сесії. У ньому можуть бути описані структура проєкту, конвенції коду, порядок запуску тестів, обмеження безпеки, стиль коментарів — усе, що має визначати поведінку агента незалежно від конкретного завдання.
Такий файл працює як фундамент: замість того щоб щоразу «виховувати» агента новим системним промптом, розробник один раз формулює стійкі правила, які стають процедурною пам’яттю. Це зменшує варіативність поведінки між сесіями й робить результати більш передбачуваними.
Третій важливий аспект write — збереження семантичної пам’яті: фактів, уподобань користувача, виведених патернів. У розглянутій моделі це подається як файлова система, куди агент може записувати інформацію, що потенційно знадобиться в майбутніх сесіях, і потім діставати її через механізми вибіркового доступу. Ключовий момент: ці дані живуть поза контекстним вікном і не конкурують за місце з поточними інструкціями чи результатами інструментів.
У сукупності ці підходи показують, що write — це не одна техніка, а цілий клас механізмів, які переводять знання з крихкого, обмеженого RAM-контексту в більш стійкі форми зберігання.
Select і RAG MCP: як не топити модель у зайвих інструментах і документах
Записати інформацію — лише половина справи. Друга стратегія LangChain, select, відповідає на питання: що саме потрібно повернути в контекст саме зараз. У реальному агенті одночасно існують десятки інструментів, великі бази знань, історія діалогу, попередні кроки плану. Якщо все це бездумно підвантажувати в кожен промпт, контекстне вікно швидко заповнюється «шумом», а якість міркувань падає.
Показовий приклад селекції — робота, яку в курсі позначено як RAG MCP. У ній замість того, щоб інлайнити описи всіх доступних інструментів у кожен запит до моделі, використовується retrieval поверх описів інструментів. Тобто система спочатку шукає, які саме тулінги релевантні до поточного завдання, і лише їхні схеми потрапляють у контекст.
Результат виявився відчутним: точність вибору інструментів зросла з 14% до 43%, а обсяг токенів у промпті приблизно скоротився вдвічі. Це наочно демонструє, що «менше, але точніше» може бути вигіднішим, ніж «усе й одразу». Модель отримує менше тексту, але цей текст краще відповідає поточній потребі.
У ширшому сенсі select — це перехід від статичних пайплайнів до агентного RAG, де сама модель бере участь у вирішенні, які документи, інструменти чи фрагменти історії потрібні для наступного кроку. Система перестає бути просто конвеєром «запит — пошук — вставка в промпт» і перетворюється на динамічний механізм, який може уточнювати, що саме варто підвантажити.
Ця стратегія тісно пов’язана з різними типами пам’яті агента. Епізодична пам’ять — це few-shot приклади, які показують, як розв’язувати конкретний клас задач. Семантична — факти й знання, які можна діставати через RAG. Процедурна — стійкі інструкції на кшталт claude.md. Для кожного типу пам’яті потрібні свої селекційні механізми: приклади — лише для релевантного патерну задачі, факти — через пошук, правила — як базовий шар, який завжди присутній.
RAG MCP демонструє, що навіть на рівні інструментів простий перехід від «усі описи в промпт» до «спочатку шукаємо, потім підвантажуємо» може радикально змінити як ефективність, так і вартість роботи агента.
Compress і гібридні стратегії: як Claude Code стискає минуле, не ламаючи майбутнє
Третя стратегія — compress — стає критичною, коли агент працює довго: десятки або сотні кроків, великі обсяги логів, результати інструментів, проміжні плани. У якийсь момент контекстне вікно заповнюється, і система змушена або відкидати старі повідомлення, або стискати їх.
Claude Code пропонує показовий приклад автоматизованого стиснення. У ньому реалізовано механізм auto-compaction, який спрацьовує, коли використання контексту досягає приблизно 95%. Замість того щоб просто обрізати найстаріші повідомлення, агент формує узагальнення всієї траєкторії, зберігаючи ключові рішення й останні файли.
Це важливий нюанс: compress тут не означає «зменшити кількість токенів будь-якою ціною». Йдеться про те, щоб перетворити довгу історію в стиснений, але семантично насичений опис, який дозволяє моделі й надалі орієнтуватися в тому, що вже було зроблено, які обмеження діють, які гіпотези відкинуті. Останні файли при цьому залишаються в повному вигляді, оскільки саме з ними агент найчастіше працює безпосередньо.
На цьому тлі особливо помітною стає рекомендація щодо гібридної стратегії контексту. Ідея полягає в тому, щоб поєднати «фундаментальний» шар, який завжди присутній у контексті, з динамічним шаром, що підтягується за потреби.
До фундаментального шару належать такі речі, як claude.md — стійкі процедурні інструкції, які визначають базову поведінку агента. Вони завантажуються на старті кожної сесії й не залежать від конкретного завдання. Натомість детальна документація, попередні кроки плану, розлогі логи інструментів не повинні постійно висіти в контексті. Їх варто діставати «just in time» через механізми select і, за потреби, стискати через compress.
Такий гібрид дозволяє досягти компромісу між надійністю й ефективністю. З одного боку, агент завжди має під рукою свої «принципи роботи», не покладаючись на те, що вони випадково збережуться в довгій історії діалогу. З іншого — контекстне вікно не забивається деталями, які потрібні лише епізодично й можуть бути відновлені з зовнішніх сховищ.
Ізоляція на практиці: як Kimi K2.6 масштабує агентів через swarm
Четверта стратегія — isolate — стосується не стільки окремого промпту, скільки архітектури всієї системи. Ідея проста: замість того щоб змушувати один агент із єдиним контекстним вікном тримати в голові всю задачу, її можна розбити на підзадачі й роздати різним агентам, кожен із власним контекстом.
Kimi K2.6 показує, як це може працювати в реальних продуктах. Модель позиціонується як відкритий LLM, оптимізований саме під агентні сценарії. На бенчмарку SweBench Pro вона досягла state-of-the-art результатів, а в демонстраційному кейсі агент на базі K2.6 автономно працював 13 годин, зробив понад 1000 викликів інструментів, змінив 4000 рядків коду й майже утричі збільшив пропускну здатність уже оптимізованої кодової бази.
Один із ключових моментів — зменшення «зайвих» кроків. За наведеними даними, K2.6 досягає тих самих результатів приблизно на 35 кроків менше, ніж попередня версія моделі, завдяки скороченню непотрібних викликів інструментів. Це безпосередньо пов’язано з контекст-інженерією: менше марних дій означає менше «сміття» в контексті, отже, менше шансів, що важлива інформація буде витіснена чи загубиться в середині довгого логу.
Ще один показовий елемент — можливість запускати swarm із до 300 підагентів паралельно. Кожен із них отримує власне чисте контекстне вікно, виконує вузько сфокусовану частину задачі й повертає результат. Це практична реалізація стратегії isolate: замість одного «універсального» агента, який намагається одночасно тримати в голові все — від високорівневого плану до дрібних деталей реалізації, система розбиває роботу на незалежні контекстні простори.
У такій архітектурі контекст-інженерія виходить за межі одного промпту й стає питанням розподілу відповідальності між агентами. Одні можуть спеціалізуватися на плануванні, інші — на конкретних типах змін у коді, треті — на тестуванні. Кожен працює у власному, відносно невеликому контексті, де простіше підтримувати якість міркувань і уникати деградації від надмірної довжини вхідних даних.
Kimi Code, локальний запуск і роль відкритості в контекст-інженерії
Kimi K2.6 цікавий не лише як модель, а й як платформа, побудована навколо принципів контекст-інженерії. На його базі працює Kimi Code — CLI-агент для програмістів, концептуально схожий на Claude Code. До екосистеми також входять конструктор сайтів і інструмент для генерації презентаційних слайдів.
Спільним знаменником цих продуктів є опора на складні контекстні стратегії. Код-агенту потрібно тримати в полі зору структуру проєкту, історію змін, результати тестів, документацію. Конструктору сайтів — поєднувати вимоги користувача, дизайн-патерни, обмеження верстки. Генератору слайдів — працювати з великими текстами, виділяти ключові тези, структурувати їх у формат презентації. У всіх цих сценаріях без write, select, compress та isolate системи швидко впираються в межі контекстного вікна й починають поводитися нестабільно.
Важливий аспект — відкритість K2.6. Модель описується як open-source і придатна для локального запуску. Для контекст-інженерії це має кілька наслідків. По-перше, команди можуть експериментувати з власними механізмами пам’яті, стиснення й селекції, не обмежуючись тим, що надає хмарний провайдер. По-друге, з’являється можливість тонко налаштовувати поведінку агента під специфічні вимоги безпеки й приватності, зберігаючи чутливі дані в локальних сховищах, а не в зовнішніх векторах чи логах.
У поєднанні зі swarm-архітектурою це створює доволі гнучке поле для експериментів: від невеликих локальних агентів, які працюють із внутрішнім кодом компанії, до великих розподілених систем, де сотні підагентів паралельно обробляють різні частини задачі, кожен зі своїм контекстом і власними правилами стиснення та селекції.
Висновок: контекст-інженерія як новий базовий шар для AI-платформ
Поки LLM-агенти залишалися іграшковими демо, більшість розмов крутилася навколо розміру контекстного вікна й «чарівних» промптів. Але досвід Claude Code, Anthropic та Kimi K2.6 показує, що справжня надійність у довгих, складних сценаріях досягається не розширенням RAM, а грамотним управлінням тим, що в ній знаходиться.
Чотири стратегії LangChain — write, select, compress, isolate — дають корисну оптику для аналізу будь-якого агентного продукту. Scratchpad на кшталт think tool, процедурна пам’ять у вигляді claude.md, селективний доступ до описів інструментів у RAG MCP, авто-компакція траєкторій у Claude Code, swarm із сотень підагентів у Kimi — усе це різні прояви однієї й тієї самої ідеї: контекст — це ресурс, яким потрібно керувати так само уважно, як обчисленнями чи пам’яттю в класичній інженерії.
У міру того як агенти стають стандартною частиною корпоративних застосунків, контекст-інженерія перетворюється з нішевої теми блогів на обов’язкову компетенцію для команд, які хочуть будувати не просто «розумні» демо, а стабільні, довгоживучі системи. І саме на стику таких практичних платформ, як Claude Code та Kimi K2.6, сьогодні формується розуміння того, як це робити насправді.
Джерело
Context Engineering for AI Agents: Complete Course — YouTube