Context Engineering: Защо вашият agent оглупява на ход 40

Anthropic начерта границата през септември 2025 г. и двете изречения трябва да стоят едно до друго. Prompt engineering е „методи за писане и организиране на LLM инструкции за оптимални резултати“. Context engineering е „наборът от стратегии за подбиране и поддържане на оптималния набор от token (информация) по време на LLM inference, включително цялата друга информация, която може да попадне там извън prompts“.¹

Оперативната разлика е кога и от кого. prompt се създава веднъж, от човек, и се преглежда. context се сглобява при всяко извикване, от код, който никой не гледа, от материал, който никой не е писал на ръка: четиридесет хода история, шест резултата от инструменти, четири извлечени пасажа, потребителски профил, дванадесет JSON схеми. Глава 15 измери какво купуват по-добрите инструкции. Тази глава е за останалите деветдесет процента от token, които пристигат сами.

Същият документ назовава ресурса, който всички те харчат: моделите „имат ‘attention budget’, от който черпят, когато анализират големи обеми context. Всеки нов въведен token изчерпва този бюджет с някакво количество“. И назовава симптома: „с увеличаването на броя token в context window способността на модела да си припомня точно информация от този context намалява“ — context rot.¹

Последното изречение е твърдение за поведение, което означава, че може да бъде проверено, а таблицата в началото на тази страница е проверката.

Четиридесет реда срещу локалния endpoint от Глава 22 — малък Python сървър, който държи Qwen2.5-0.5B-Instruct на CPU и говори във формата chat-completions, така че цикълът остава TypeScript, а тензорите остават от другата страна на порта.

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. Модел, който казва Не мога да го намеря, е бъг, който забелязвате; модел, който връща номера от съседен ред, е бъг, който пускате, защото на екрана двете изглеждат еднакво. Това е провалът, срещу който Глава 19 изгради проверими цитати, но идващ отвътре на prompt вместо от индекса.

Позицията е едната ос. Дължината е другата и се тества по-лесно: задръжте отговора в средата и увеличавайте списъка.

Един запис и 97 token: 90 %. Три записа и 159 token: 55 %. Осем записа и 315 token: 15 %, а оттам нататък ниско и плоско чак до 140 записа и 4 477 token. Целият срив се случва между първия и осмия ред на списък.

Последната колона е всичко, което не е нито правилният вътрешен номер, нито номер от друг запис — при един-единствен запис на страницата това е единственото място, където грешният отговор може да попадне. Двата пропуска при един запис заслужават да бъдат отчетени, вместо да бъдат закръглени, защото нито един не беше отказ: единият отговори 5806 на регистър, чийто единствен ред казва 5805. При 97 token и един-единствен кандидат този модел пак преписва грешно една цифра два пъти от двадесет, и това е подът, спрямо който се измерва всичко останало.

Следват две неща. По-голям context купува правото да изпращате повече, не сигурността, че ще бъде прочетено: този модел има context window от 32 768 token и работен диапазон, за тази задача, от няколкостотин token. И няма праг, няма пропаст, няма състояние „context е пълен“ — деградацията вече е в ход при третия запис и е завършена до осмия, при един процент от прозореца. Каквото и да е context limit, не той управлява това.

Обикновено се предлагат два механизма. Първият е аритметиката от Глава 9, която Anthropic формулира със същите думи като този курс: моделите „са базирани на transformer архитектурата, която позволява всеки token да attends to всеки друг token в целия context. Това води до n² двойкови отношения за n token“.¹ Attention върху по-дълга последователност не е същата операция, приложена към повече материал; това е един фиксиран бюджет от вероятностна маса, разпределен върху повече конкуренти. Вторият е обучението: моделите виждат много повече кратки последователности, отколкото дълги, така че дългобойните позиционни модели са най-малко упражняваната част от мрежата. Това е аргумент, не измерване, и тази глава не може да го реши.

Това, което е решено, е формата, и то още от 2023 г. Liu et al. тестват multi-document question answering и key-value retrieval в различни семейства и размери модели и откриват, че „производителността често е най-висока, когато релевантната информация се намира в началото или края на входния context, и значително се влошава, когато моделите трябва да достъпят релевантна информация в средата на дълги contexts, дори при модели, изрично създадени за long-context“.² Глава 15 взе своето правило за позиция от тази статия; Глава 19 взе от нея причината двадесет извлечени chunks да могат да се представят по-зле от четири. Практическата форма на факта е единственото изречение тук, по което трябва да действате: това се измерва за пет минути на вашия собствен модел с вашите собствени данни, и никоя публикувана крива не замества вашата.

Попитайте екип какво пълни context на техния agent и получавате оценка, защото никое API не връща отговора: отговорът ви дава prompt_tokens, едно число за всичко.

Можете да възстановите разбивката с четири броя и три изваждания — целия рендериран 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 и рендерирането на схемата са все token, за които плащате и които никога не сте въвеждали. Глава 7 изгради tokenizer, а Глава 16 брои с js-tiktoken; тук броят идва от същия модел, който ще прочете prompt, което е единственият точно правилен брой.

Сега прекарайте истински agent през него: четиридесет хода разследване на инцидент, дванадесет инструмента, фалшива операционна среда, която връща реалистични log dumps и metric series.

Прочетете първия ред срещу последния.

На ход 1 prompt е 2 547 token и 71 % от него са дефиниции на инструменти. System prompt е 3 %. Това, което потребителят е въвел, е 6 %. agent още не е направил нищо и вече носи 1 817 token JSON schema.

До ход 40 prompt е 10 632 token и дяловете са се обърнали: дефиниции 17 %, разговор 29 %, резултати от инструменти 53 %. Output от инструменти изпревари дефинициите на ход 5; разговорът не ги изпревари до ход 25, така че през първите шестдесет процента от сесията каталогът с инструменти беше по-голям от всичко, което беше казано.

После общата сума. В 57 model calls изпълнението беше таксувано за 370 291 input token за финален context от 10 632 — последният prompt беше платен около тридесет и пет пъти, което е квадратичното от Глава 16 с множителя на agent отгоре. От тези 370 291, 103 569, или 28 % от всичко таксувано, бяха дванадесетте дефиниции на инструменти, препращани byte-identical при всяко извикване.

Каталогът с инструменти е най-големият фиксиран разход в 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 token за get_current_time, който приема един string, до 263 за search_tickets, който приема четири параметъра с enum и по едно изречение насоки за всеки. Това е обменният курс зад централния съвет на Глава 18, че описанието е API-то: добро описание струва около сто token при всяка заявка до края на живота на agent. Три последствия.

Инструмент, който не използвате, пак се таксува. agent извика седем от дванадесетте. Другите пет струваха 697 token при всяка от 57-те заявки — общо 39 729, повече от една десета от всичко, за което изпълнението беше таксувано, за възможности, които никога не докосна. Един от петте носи най-острия детайл в trace: моделът опита три пъти да извика read_log, който не съществува. Инструментът, който искаше, беше search_logs, втората най-скъпа дефиниция в каталога с 237 token. Той плати за тази дефиниция 57 пъти, никога не я използва и никога не намери името ѝ.

Рязането на проза е най-евтината налична оптимизация и е размяна. Съкращаването на описанията до едно изречение и махането на документацията на параметрите спести 526 token на извикване, 29 процента, без да се пипа ред логика — и накара модела да извиква инструментите по-зле, което е измереното в Глава 18. Идеята е, че двете страни на тази размяна вече са в една и съща единица.

При определен мащаб изобщо престава да има смисъл да се изпращат дефиниции. Anthropic сложи число през ноември 2025 г.: голям набор свързани сървъри означава обработване на „стотици хиляди token“ дефиниции преди заявката да бъде прочетена, а замяната на това с code execution — agent да открива и зарежда само дефинициите, от които има нужда — „намалява употребата на token от 150 000 token до 2 000 token, спестяване на време и разходи от 98,7%“.³ Същата идея като останалата част от тази глава, приложена към схеми вместо към история: запазете индекса, разрешавайте записа при нужда.

В този четиридесетходов transcript бяха посадени две неща. На ход 2, преди реалната работа, потребителят задава постоянно правило: всеки тикет, който отвориш, трябва да бъде заведен под моя служителски номер, 4417. На ход 19, в средата на инцидента, факт: засегнатият shard е pay-shard-7, потвърден от екипа по плащанията. На ход 40 потребителят моли agent да отвори тикета за инцидента, което изисква и двете. Всяка проверка се задава в шест различни формулировки и се оценява от шест — greedy decoding е детерминиран, така че едно извикване дава неповторимо да или не, а шест дават процент.

След това transcript се преиграва при седем context политики. Преиграва, а не се изпълнява отново, умишлено: съобщенията, tool calls и резултатите от инструменти са byte-identical във всичките седем, така че единствената променлива е какво е избрала да задържи всяка политика. Глава 16 показа защо sliding window е лош икономически ход, защото унищожава cacheable prefix. Ето какво прави с поведението:

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

Пълната история помни и е най-скъпото нещо в таблицата: 370 291 input token за сесия, чието трайно съдържание е две изречения.

Това отговаря на въпроса, който началото остави отворен. Защо transcript от 10 632 token държи факт, който регистър от 853 token губи? Защото дължината е грешната променлива. Регистърът държи двадесет и пет четирицифрени вътрешни номера в двадесет и пет идентични изречения — двадесет и четири почти съвършени примамки за този, който искате. transcript държи точно един служителски номер и едно име на shard. Context rot е интерференция, преди да е обем, затова 136 от 205-те грешни отговора горе бяха стойност на съсед.

Sliding window е с 57 % по-евтин и е загубил инцидента. Служителският номер оцелява само защото agent го беше повторил в последните ходове. shard, заявен веднъж на ход 19, не е в последните дванадесет съобщения — и моделът не го казва. Попитан шест пъти, той отговори „засегнатият payment shard е shard 4417“, посягайки към служителския номер, единствения друг идентификатор, останал в прозореца му, и два пъти „pool“, извадено от string pool_exhausted в log line.

Compaction е евтин и загуби същия факт. Седем обобщения, писани от модела под изрична инструкция да запазва идентификатори, числа, постоянни инструкции и отворени въпроси, и pay-shard-7 не е в нито едно от важните; шестте предположения бяха shard 1, pay_shard_1 и pool. Compaction не се проваля шумно. Той създава гладка, правдоподобна, много по-кратка сесия, която тихо е изпуснала един ред.

Три реда дадоха 0/6 за факта от ход 19 — sliding window, compaction и compaction с бележки. Осемнадесет грешни отговора между тях и нито един не беше „Не знам.“

После идва редът, който би трябвало да е неудобен. Запазването на собствените четиридесет съобщения на потребителя verbatim, плюс последните четири хода изцяло и нищо друго, струва 168 550 token — 54 % по-малко от пълната история — и отговаря на двете проверки толкова добре, колкото пълната история, или по-добре. Без summariser, без note-taker, без втори модел: филтър върху role === "user". Думите на потребителя са най-евтините високостойностни token в прозореца на agent, а повечето дизайни ги изхвърлят заедно с всичко останало.

Последните два реда са началната таблица отново, вътре в agent. Същият закрепен блок, преместен от system message към края на prompt: 5/6 става 6/6. При шест опита това не е значима разлика и не се предлага като такава — предлага се като напомняне, че къде е параметър, който задавате, независимо дали го знаете.

Четирите стратегии по-долу са на Anthropic, в неговия ред, макар само последните три да са неговият long-horizon списък.¹ И четирите са вариации на една инструкция: не носете това, което можете да извлечете, и не носете сурово това, което можете да носите компресирано.

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 не е в таблицата по-горе, защото не работи четиридесет хода: работи веднъж, в прозорец, който някой е ограничил за него. С дадения system prompt, ходове 17 до 19 и нищо друго — 2 737 token — той отговори на shard проверката 6/6, по-добре от всяка политика в таблицата, и на employee проверката 0/6, защото този номер не е в трите хода, които са му подадени.

Това са sub-agents в две числа: чистият прозорец не е интелигентност, а обхват, и определянето на обхвата се прави предварително от код, който така или иначе трябва да знае кои ходове са важни. Още едно нещо в тези отговори си струва да се запази. Това беше единствената политика, която отговори „Няма налично“, вместо да измисли нещо. Модел с малък, кохерентен context знае какво му липсва; модел с голям, шумен context — не.

Почти всеки объркан разговор за памет на agent е три механизма, носещи една дума. Те имат различен живот, собственици и режими на провал, и система, която ги държи на едно и също място, има проблем, който още не е забелязала.

Академичната рамка е CoALA, която организира language agents около „модулни компоненти на паметта“ и отделя working memory от episodic, semantic и procedural хранилища.⁴ MemGPT приема същата идея буквално, заемайки virtual memory от operating systems: бърз слой вътре в прозореца, бавен слой извън него, и самият модел премества данни между тях с function calls.⁵ И двете налагат въпроса, на който продуктът така или иначе трябва да отговори — не колко мога да запазя, а в кое хранилище принадлежи това и кога изтича.

Практическият тест е един въпрос за всеки факт: какво трябва да остане вярно утре? Резултат от инструмент от ход 12 — нищо. Обобщение на сесията — докато сесията приключи. Че служителският номер на потребителя е 4417 — докато смени работа. Три отговора, три хранилища.

Вече можете да измервате какво има в прозорец, да решавате какво остава в него и да различавате agent, който е забравил нещо, от такъв, който го е носил и не е погледнал.

Последната от четирите стратегии е тази, която не се побира тук. Sub-agent не е context политика, а втори agent, и в момента, в който има два, трябва да решите какво минава между тях и кой командва. Глава 25 е това: петте orchestration patterns и откъде всъщност идва всяко от имената им, двете топологии, които се бъркат — да попиташ sub-agent и да получиш отговор обратно, срещу това да му предадеш разговора и да не го получиш обратно — и измереното откритие, че за задачата, която остойностява, по-простата подредба печели — последвано от теста кога спира да печели.

Тя наследява и точно това, което тази глава току-що измери. Sub-agent връща обобщение. Обобщението е compaction, който не сте писали, произведен от модел, чийто прозорец не можете да видите, а родителят няма начин да различи добро обобщение от уверено грешно — същото разграничение, което раздели 84 % от 19 % в началото на тази страница и превърна осемнадесет липсващи факта в осемнадесет измислени. Така че: когато sub-agent греши, какво точно може да погледне родителят?

Всяко число тук е произведено на тази машина и нито едно не е оценка. Моделът е Qwen2.5-0.5B-Instruct във float32 на CPU с greedy decoding, served over loopback от малък Python endpoint, който говори във формата chat-completions и излага route за token count — отново seam от Глава 14, тензорите от Python страната и цикълът от TypeScript страната — така че всеки брой е собственият tokenizer на този модел, приложен към собствения му chat template. Таблицата за позиция е 288 извиквания, девет позиции по тридесет и два опита с различен тикет във всеки опит; таблицата за дължина е 140 извиквания; agent run е 57 model calls за 43 минути wall clock; таблицата с политики е този един transcript, преигран при седем политики. Интервалите са на Wilson, от Глава 4. Не беше извикано платено API, което е и причината в главата да няма нито една цена: token counts са точни, а тарифите, по които бихте ги умножили, са в Глава 16.