Context Engineering: чому ваш agent тупішає на 40-му ході

Anthropic провела межу у вересні 2025 року, і ці два речення варто поставити поруч. Prompt engineering — це «методи написання та організації інструкцій для LLM для оптимальних результатів». Context engineering — це «набір стратегій для добору й підтримання оптимального набору tokens (інформації) під час LLM inference, включно з усією іншою інформацією, яка може потрапити туди поза prompts».¹

Практична різниця — коли і ким. prompt створюється один раз, людиною, і переглядається. Контекст збирається під час кожного виклику, кодом, на який ніхто не дивиться, з матеріалу, який ніхто не писав вручну: сорок ходів історії, шість результатів інструментів, чотири retrieved фрагменти, профіль користувача, дванадцять JSON-схем. Розділ 15 виміряв, що дають кращі інструкції. Цей розділ — про інші дев’яносто відсотків tokens, які приходять самі.

Той самий документ називає ресурс, який вони всі витрачають: моделі «мають attention budget, з якого вони черпають, коли розбирають великі обсяги контексту. Кожен новий token певною мірою виснажує цей бюджет». І він називає симптом: «коли кількість tokens у context window зростає, здатність моделі точно згадувати інформацію з цього контексту знижується» — context rot.¹

Останнє речення — твердження про поведінку, а отже його можна перевірити, і таблиця на початку цієї сторінки — це перевірка.

Сорок рядків проти локального endpoint з Розділу 22 — невеликий Python-сервер, що тримає Qwen2.5-0.5B-Instruct на CPU і говорить у формі chat-completions, щоб цикл лишався в TypeScript, а tensors — по той бік порту.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

Лічильник other перетворює невтішний результат на корисний: коли модель помиляється, вона загубилася чи вона впевнена?

Відповідь — впевнена. На восьми позиціях не на початку 136 із 205 неправильних відповідей були додатковим номером іншого звернення — реальне чотиризначне число, правильно відформатоване, зчитане з неправильного рядка. На позиції 1 лише один із п’яти промахів був таким; на позиції 7 — двадцять один із двадцяти шести.

Саме ця різниця має значення в production. Модель, яка каже я не можу це знайти, — це bug, який ви помітите; модель, яка повертає номер із сусіднього рядка, — це bug, який ви відвантажите, бо на екрані ці два випадки виглядають однаково. Це той збій, проти якого Розділ 19 будував перевірні цитати, тільки він приходить зсередини prompt, а не з index.

Позиція — одна вісь. Довжина — інша, і її простіше тестувати: тримайте відповідь посередині й нарощуйте список.

Один запис і 97 tokens: 90 %. Три записи й 159 tokens: 55 %. Вісім записів і 315 tokens: 15 %, а далі — рівно й низько аж до 140 записів і 4 477 tokens. Увесь обвал відбувається між першим і восьмим рядком списку.

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

Звідси випливають дві речі. Більший контекст купує право надіслати більше, а не гарантію, що це буде прочитано: ця модель має context window на 32 768 tokens і робочий діапазон, у цьому завданні, у кілька сотень tokens. І немає порога, немає урвища, немає стану «контекст повний» — деградація вже йде на третьому записі й завершується на восьмому, на одному відсотку вікна. Що б не було context limit, керує не він.

Зазвичай пропонують два механізми. Перший — арифметика з Розділу 9, яку Anthropic формулює тими самими словами, що й цей курс: моделі «базуються на transformer architecture, яка дає змогу кожному token attend to кожен інший token у всьому контексті. Це дає n² попарних зв’язків для n tokens».¹ Attention над довшою послідовністю — це не та сама операція, застосована до більшого матеріалу; це один фіксований бюджет імовірнісної маси, розподілений між більшою кількістю конкурентів. Другий — навчання: моделі бачать значно більше коротких послідовностей, ніж довгих, тому довгодистанційні positional patterns — найменш натренована частина мережі. Це аргумент, а не вимірювання, і цей розділ не може його закрити.

Те, що закрито, — це форма, і так було з 2023 року. Liu та ін. тестували multi-document question answering і key-value retrieval на різних сім’ях і розмірах моделей та знайшли, що «продуктивність часто найвища, коли релевантна інформація з’являється на початку або в кінці вхідного контексту, і суттєво погіршується, коли моделі мають дістатися релевантної інформації в середині довгих контекстів, навіть для явно long-context моделей».² Розділ 15 узяв із цієї роботи правило позиції; Розділ 19 узяв із неї причину, чому двадцять retrieved chunks можуть працювати гірше, ніж чотири. Практична форма цього факту — єдине речення тут, за яким варто діяти: це займає п’ять хвилин, щоб виміряти на вашій власній моделі з вашими власними даними, і жодна опублікована крива не замінить вашу.

Запитайте команду, що заповнює контекст їхнього agent, і отримаєте оцінку, бо жоден API не повертає відповідь: response дає вам prompt_tokens, одне число для всього.

Розклад можна відновити чотирма підрахунками й трьома відніманнями — весь rendered prompt, той самий без визначень інструментів, system message окремо з ними й без них, і все без результатів інструментів:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt застосовує власний chat template моделі перед tokenizing, і це важливіше, ніж здається: ваш текст — не те, що рахується. Маркери ролей, преамбула tool-calling і rendering схеми — усе це tokens, за які ви платите і яких ніколи не набирали. Розділ 7 побудував tokenizer, а Розділ 16 рахував через js-tiktoken; тут підрахунок походить від тієї самої моделі, яка читатиме prompt, і це єдиний підрахунок, що є точно правильним.

Тепер пропустіть через це справжній agent: сорок ходів розслідування інциденту, дванадцять інструментів, фейкове операційне середовище, що повертає реалістичні дампи логів і ряди метрик.

Прочитайте перший рядок проти останнього.

На ході 1 prompt має 2 547 tokens, і 71 % із них — визначення інструментів. system prompt — 3 %. Те, що набрав користувач, — 6 %. agent ще нічого не зробив, а вже несе 1 817 tokens JSON-схеми.

До ходу 40 prompt має 10 632 tokens, і частки перевернулися: визначення 17 %, розмова 29 %, результати інструментів 53 %. Вивід інструментів обігнав визначення на ході 5; розмова не обігнала їх аж до ходу 25, тож протягом перших шістдесяти відсотків сесії каталог інструментів був більший за все, що було сказано.

Потім загальна сума. За 57 model calls прогін нарахував 370 291 input tokens для фінального контексту 10 632 — останній prompt було оплачено приблизно тридцять п’ять разів, це квадратичність Розділу 16 з множником agent поверх. Із цих 370 291 103 569, або 28 % усього оплаченого, були дванадцятьма визначеннями інструментів, надісланими байт-у-байт однаково в кожному виклику.

Каталог інструментів — найбільша фіксована вартість в agent, і він невидимий, бо ви його ніколи не бачите: ви передаєте масив об’єктів, а provider рендерить його в prompt за вас. Виміряно на тих самих дванадцяти інструментах:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Маржинальна вартість на інструмент іде від 80 tokens для get_current_time, який приймає один рядок, до 263 для search_tickets, який приймає чотири параметри з enum і реченням guidance для кожного. Це обмінний курс за центральною порадою Розділу 18: опис — це API. Хороший опис коштує близько сотні tokens на кожному запиті до кінця життя agent. Три наслідки.

Інструмент, який ви не використовуєте, усе одно виставляє рахунок. agent викликав сім із дванадцяти. Інші п’ять коштували 697 tokens на кожному з 57 запитів — 39 729 загалом, більше десятої частини всього, що було нараховано за прогін, за можливості, яких він ніколи не торкнувся. Один із п’яти несе найгострішу деталь у трасі: модель тричі намагалася викликати read_log, якого не існує. Інструмент, який вона хотіла, був search_logs, друге найдорожче визначення в каталозі на 237 tokens. Вона заплатила за це визначення 57 разів, ніколи його не використала й ніколи не знайшла його назву.

Обрізання прози — найдешевша доступна оптимізація, і це trade-off. Скорочення описів до одного речення та видалення документації параметрів зекономило 526 tokens на виклик, 29 відсотків, не торкнувшись жодного рядка логіки, — і змусило модель гірше викликати інструменти, що й виміряв Розділ 18. Сенс у тому, що обидві сторони цього trade-off тепер в одній одиниці.

На певному масштабі надсилати визначення взагалі перестає мати сенс. Anthropic дала число в листопаді 2025 року: великий набір підключених серверів означає обробку «сотень тисяч tokens» визначень ще до того, як запит буде прочитано, а заміна цього на виконання коду — agent відкриває й завантажує лише ті визначення, які йому потрібні, — «зменшує використання tokens зі 150 000 tokens до 2 000 tokens, економія часу й вартості 98,7%».³ Та сама ідея, що й у решті цього розділу, застосована до schemas замість історії: тримайте index, resolve entry on demand.

У той сорокахідний transcript було підкладено дві речі. На ході 2, ще до будь-якої реальної роботи, користувач формулює постійне правило: будь-яке звернення, яке ти відкриваєш, має бути подане під моїм номером працівника, 4417. На ході 19, посеред інциденту, факт: уражений shard — pay-shard-7, це підтвердила команда payments. На ході 40 користувач просить agent відкрити інцидентне звернення, для чого потрібні обидва. Кожен probe ставиться у шести різних формулюваннях і оцінюється з шести — greedy decoding детермінований, тож один виклик дає неповторюване так або ні, а шість дають rate.

Потім transcript відтворюється під сімома context policies. Саме відтворюється, а не запускається заново, навмисно: повідомлення, tool calls і результати інструментів байт-ідентичні в усіх семи, тож єдина змінна — що кожна policy вирішила залишити. Розділ 16 показав, чому sliding window — поганий економічний крок, бо він руйнує cacheable prefix. Ось що він робить із поведінкою:

Рядки compaction включають вартість ущільнення: 18 581 input tokens за сім summary і ще 3 392 за note-taker. Контрольний рядок потрібен, щоб нуль читався як нуль — із двома повідомленнями окремо в prompt на 1 981 token ця модель відповідає на обидва probes ідеально, тож жоден рядок не означає, що завдання надто складне.

Повна історія пам’ятає і є найдорожчою річчю в таблиці: 370 291 input tokens для сесії, чий durable content — два речення.

Це відповідає на питання, яке початок лишив відкритим. Чому transcript на 10 632 tokens утримує факт, який реєстр на 853 tokens губить? Бо довжина — неправильна змінна. Реєстр містить двадцять п’ять чотиризначних додаткових номерів у двадцяти п’яти однакових реченнях — двадцять чотири майже ідеальні приманки для того, що вам потрібне. transcript містить рівно один номер працівника й одну назву shard. Context rot — це interference до того, як це volume, саме тому 136 із 205 неправильних відповідей угорі були значенням сусіда. Корисне питання про window — не наскільки він довгий; а скільки речей у ньому схожі на відповідь.

Sliding window на 57 % дешевший і вже втратив інцидент. Номер працівника виживає лише тому, що agent повторив його в нещодавніх ходах. shard, сказаний один раз на ході 19, не входить до останніх дванадцяти повідомлень — і модель цього не каже. Коли її запитали шість разів, вона відповіла «уражений payment shard — shard 4417», тягнучись до номера працівника, єдиного іншого identifier, що лишився у її window, і двічі «pool», підняте з рядка pool_exhausted у log line.

Compaction дешевий і втратив той самий факт. Сім summaries, написаних моделлю під явною інструкцією зберігати identifiers, numbers, standing instructions and open questions, і pay-shard-7 немає в жодному з тих, що мали значення; шість здогадок були shard 1, pay_shard_1 і pool. Compaction не падає голосно. Він створює плавну, правдоподібну, набагато коротшу сесію, яка тихо викинула один рядок.

Три рядки отримали 0/6 на факті з ходу 19 — sliding window, compaction і compaction з нотатками. Вісімнадцять неправильних відповідей між ними, і жодна з них не була «я не знаю».

Потім рядок, за який мало би бути соромно. Збереження власних сорока повідомлень користувача дослівно, плюс останні чотири ходи повністю і більше нічого, коштує 168 550 tokens — на 54 % менше за повну історію — і відповідає на обидва probes не гірше за повну історію або краще. Жодного summariser, жодного note-taker, жодної другої моделі: фільтр на role === "user". Слова користувача — найдешевші high-value tokens у window agent, і більшість дизайнів викидають їх разом з усім іншим.

Останні два рядки — це початкова таблиця знову, всередині agent. Той самий pinned block, перенесений із system message у кінець prompt: 5/6 стає 6/6. На шести спробах це не значуща різниця, і вона не подається як така — це нагадування, що де є параметром, який ви задаєте, знаєте ви це чи ні.

Чотири стратегії нижче — від Anthropic, у її порядку, хоча лише останні три входять до її long-horizon списку.¹ Усі чотири — варіації однієї інструкції: не носіть те, що можете fetch, і не носіть raw те, що можете носити compressed.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Sub-agent не в таблиці вище, бо він не працює сорок ходів: він працює один раз, у window, який хтось для нього окреслив. Отримавши system prompt, ходи 17–19 і нічого більше — 2 737 tokens — він відповів на shard probe 6/6, краще за кожну policy в таблиці, і на employee probe 0/6, бо цього числа немає в трьох ходах, які йому дали.

Ось sub-agents у двох числах: чистий window — це не intelligence, це scope, і scoping заздалегідь робить код, який уже має знати, які ходи важливі. У цих відповідях є ще одна річ, яку варто зберегти. Це була єдина policy, яка відповіла «Немає доступних» замість того, щоб щось вигадати. Модель із малим, цілісним контекстом знає, чого їй бракує; модель із великим, шумним — ні.

Майже кожна заплутана розмова про пам’ять agent — це три механізми під одним словом. У них різні строки життя, власники й режими відмови, і система, яка тримає їх в одному місці, має проблему, якої ще не помітила.

Академічна рамка — CoALA, яка організує language agents навколо «modular memory components» і відокремлює working memory від episodic, semantic і procedural stores.⁴ MemGPT бере ту саму ідею буквально, позичаючи virtual memory з операційних систем: швидкий tier усередині window, повільний tier поза ним, і сама модель переносить дані між ними через function calls.⁵ Обидва змушують поставити питання, на яке продукт усе одно має відповісти, — не скільки я можу зберегти, а до якого store це належить і коли воно expire.

Практичний тест — одне питання на факт: що має лишатися правдою завтра? Результат інструмента з ходу 12 — нічого. Summary сесії — доки сесія не завершиться. Те, що номер працівника користувача — 4417, — доки він не змінить роботу. Три відповіді, три stores.

Тепер ви можете виміряти, що є у window, вирішити, що в ньому лишається, і відрізнити agent, який щось забув, від agent, який це носив і не подивився.

Остання з чотирьох стратегій — та, що сюди не вміщується. Sub-agent — це не context policy, це другий agent, і щойно їх стає двоє, вам треба вирішити, що між ними передається і хто головний. Розділ 25 саме про це: п’ять orchestration patterns і звідки насправді походить кожна з їхніх назв, дві topology, які плутають, — запитати sub-agent і отримати відповідь назад проти передати йому розмову й не отримати її назад, — і виміряний висновок, що в завданні, яке він оцінює, простіший arrangement виграє, — а потім тест, коли він перестає вигравати.

Він також успадковує рівно те, що щойно виміряв цей розділ. Sub-agent повертає summary. Summary — це compaction, який ви не писали, створений моделлю, window якої ви не бачите, і parent не має способу відрізнити хороший summary від упевнено неправильного — та сама різниця, що відділила 84 % від 19 % на початку цієї сторінки і перетворила вісімнадцять зниклих фактів на вісімнадцять вигаданих. Отже: коли sub-agent помиляється, на що саме parent може подивитися?

Кожне число тут було отримане на цій машині, і жодне не було оцінене приблизно. Модель — Qwen2.5-0.5B-Instruct у float32 на CPU з greedy decoding, подана через loopback невеликим Python endpoint, що говорить у формі chat-completions і exposes token-count route — знову seam із Розділу 14, tensors на Python-боці, а цикл на TypeScript-боці, — тож кожен count є власним tokenizer цієї моделі, застосованим до її власного chat template. Таблиця позицій — 288 calls, дев’ять positions по тридцять дві trials з іншим зверненням у кожній trial; таблиця довжини — 140 calls; agent run — 57 model calls за 43 minutes wall clock; policy table — той один transcript, replayed під сімома policies. Інтервали — Wilson, з Розділу 4. Жоден paid API не викликався, саме тому в розділі немає жодної ціни: token counts точні, а rates, на які ви їх множили б, — у Розділі 16.