Паттерны Context Engineering

Короткая версия

Главные паттерны:

Практический смысл

Эти паттерны нужны, когда у вас есть:

• retrieval;
• multi-turn state;
• tool use;
• personalization;
• длинные instructions;
• cost и latency constraints.

Без них система быстро скатывается в две крайности: либо контекста слишком мало, либо его слишком много и он шумный.

1. Dynamic Assembly

Dynamic assembly означает, что контекст собирается по интенту и текущему состоянию задачи, а не по одному универсальному шаблону.

Примеры:

• support-запрос о заказе: instructions + order API + короткий policy block;
• research-запрос: instructions + retrieval + citations + structured output;
• coding-step: repo context + task state + tool results, но почти без user profile;
• короткий follow-up: только последние turns и актуальный state.

2. Budget Lanes

Большое context window не отменяет discipline. Даже если модель поддерживает 128K или 1M, без budget lanes контекст быстро раздувается и теряет сигнал.

Полезнее делить budget не “в целом”, а по слоям:

Точные цифры зависят от кейса, но сам принцип почти всегда одинаков: у каждого слоя должен быть собственный cap.

3. Priority Truncation

Когда контекст не помещается, healthy system не режет его случайно. Она делает priority truncation.

Типичный порядок:

1. system/policy почти не трогаются;
2. свежие tool results и последние critical turns защищаются;
3. retrieval режется по relevance;
4. memory режется мягко и редко;
5. старый transcript compact-ится или удаляется;
6. output reserve не жертвуется первым.

Контекст не влезает в окно. Что лучше убрать первым?
1. system policy
2. последний tool result
3. самые слабые retrieval chunks
4. output reserve

4. Compaction

Compaction нужен там, где диалог или workflow живут долго. Его задача — превратить длинную transcript-history в короткое рабочее состояние.

Типичные варианты:

• summary старых turns;
• state object с фактами и pending tasks;
• short-term window + long-term summary;
• latest tool snapshot вместо полного tool log.

Это особенно важно для:

• support conversations;
• agent loops;
• enterprise copilots;
• multi-step workflows.

5. Cacheable Prefixes

Cacheable prefix — это стабильная верхняя часть контекста, которую можно повторно использовать без полной повторной стоимости.

Лучшие кандидаты:

• system prompt;
• policy blocks;
• few-shot examples;
• schema instructions;
• длинные неизменные reference blocks.

Плохие кандидаты:

• свежая история;
• retrieved chunks под конкретный запрос;
• live tool results;
• user-specific ephemeral state.

Смысл паттерна простой: разделите stable prefix и dynamic tail, иначе hit rate будет слабым даже при поддержке provider-side caching.

6. Routing Before Retrieval

Один из самых недооценённых паттернов: сначала lightweight routing, потом retrieval и assembly.

На практике это снижает:

• лишний retrieval;
• шумные documents;
• лишний token spend;
• latency в простых сценариях.

Хороший routing часто бывает даже rule-based:

• support/order;
• support/billing;
• research;
• coding;
• general chat.

И уже только потом подтягиваются нужные collections, tools и contracts.

7. Observability

Без observability Context Engineering быстро превращается в guesswork.

Минимум, что полезно смотреть:

8. Как паттерны комбинируются

Обычно здоровая цепочка выглядит так:

1. routing;
2. dynamic assembly;
3. budget lane allocation;
4. compaction старого state;
5. priority truncation при необходимости;
6. stable prefix caching;
7. observability и iteration.

То есть паттерны работают не поодиночке, а как pipeline.

Пример pipeline с budgets и truncation

from dataclasses import dataclass


@dataclass
class Budget:
    instructions: int = 2_000
    retrieval: int = 10_000
    state: int = 4_000
    memory: int = 1_500
    tools: int = 3_000
    output_reserve: int = 4_000


def assemble_context(
    instructions: str,
    retrieval_chunks: list[str],
    recent_messages: list[dict],
    memory_facts: list[str],
    tool_results: list[dict],
    budget: Budget,
) -> dict:
    return {
        "instructions": instructions[: budget.instructions * 4],
        "retrieval": retrieval_chunks[:4],
        "recent_messages": recent_messages[-4:],
        "memory_facts": memory_facts[:10],
        "tool_results": tool_results[-2:],
        "output_reserve": budget.output_reserve,
    }

Для реальной production-системы этого мало, но даже такой примитивный pipeline уже вводит здоровые ограничения:

• каждый слой получает cap;
• свежие turns важнее старого transcript;
• tool results и retrieval ограничиваются отдельно;
• output reserve существует заранее, а не “если что останется”.