Что такое Context Engineering

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

Context Engineering отвечает на пять практических вопросов:

1. Какие блоки контекста нужны для этой задачи?
2. Что должно быть статическим, а что динамическим?
3. Какой у каждого блока приоритет в бюджете окна?
4. Что кэшировать, суммаризировать или отбрасывать?
5. Как измерить, что контекст реально улучшает качество?

Из чего обычно состоит контекст

Пользователь спрашивает: «Почему заказ задерживается?»

В контекст попадают:
1. system instructions
2. профиль пользователя и язык
3. последние 2 сообщения
4. tool result из order API
5. короткая статья о сроках доставки
6. schema ответа для support UI

Чем это отличается от prompt engineering

Prompt Engineering концентрируется на том, как сформулировать запрос. Context Engineering концентрируется на том, как собрать весь model input.

Подходит почти для любого LLM-приложения, где есть retrieval, state, personalization, tool use или длинные multi-turn сценарии.

1. Context Engineering начинается там, где одного prompt уже мало

Для single-shot задачи часто хватает хороших инструкций. Но как только приложение становится stateful или tool-driven, одного prompt уже недостаточно.

Типовые признаки, что вам нужен именно Context Engineering:

• ответ зависит от профиля пользователя;
• модель должна опираться на ваши документы, а не на pretraining;
• диалог продолжается много ходов;
• ответ строится после вызовов tools или API;
• нужен стабильный output contract для UI или automation;
• важны cost, latency и cache hit rate.

Именно поэтому современная практика строится не вокруг “идеального супер-промпта”, а вокруг context assembly pipeline.

2. Основные компоненты контекста

Instructions

Это system prompt, policy blocks, guardrails и output instructions. Они задают рамку:

• кто модель;
• как она отвечает;
• что ей запрещено делать;
• как выглядят refusal, uncertainty и final output.

Этот слой обычно самый стабильный и часто лучше всего подходит под caching.

Retrieval

Retrieval добавляет релевантные внешние знания: FAQ, docs, policy pages, code snippets, tickets, contracts. Его задача не “положить в контекст побольше текста”, а положить только те куски, без которых модель не сможет корректно ответить.

Главный вопрос retrieval-слоя: не сколько документов вы нашли, а сколько реально стоило включать в context.

Conversation State

Это не вся история чата навсегда, а рабочий слой текущего диалога:

• последние сообщения;
• текущая цель;
• открытые вопросы;
• pending actions;
• последний tool result.

Если вы передаёте всю transcript-history целиком, это почти всегда знак плохого Context Engineering.

Durable Memory

Память нужна для фактов, которые переживают одну сессию:

• предпочтительный язык;
• тариф и account flags;
• имя или роль пользователя;
• устойчивые рабочие предпочтения;
• важные long-term facts.

Память нельзя путать с chat history. История объясняет, что происходило сейчас. Memory хранит, что стоит помнить долго.

Tool Results

Когда модель вызывает tool, основой ответа становится уже не prompt и не retrieval, а свежий structured result из системы. Для многих агентных и support-сценариев именно этот слой наиболее “grounded”.

Типичные примеры:

• статус заказа из backend;
• баланс из billing API;
• SQL aggregation;
• web search result;
• классификация или extraction из отдельного сервиса.

Output Constraints

Structured outputs, JSON schema, strict tool arguments и UI contracts тоже часть Context Engineering. Они определяют не только смысл ответа, но и его форму.

Это особенно важно, когда LLM не просто “пишет текст”, а отдаёт результат дальше в интерфейс, workflow или automation.

3. Большое окно не отменяет budget discipline

Одна из самых вредных идей 2025-2026: “если модель держит 128K или 1M, можно просто отправлять всё”. На практике это почти всегда ухудшает economics и нередко качество.

Правильнее думать не про размер окна вообще, а про budget lanes:

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

4. Хороший Context Engineering почти всегда динамический

Один и тот же user input не должен собирать один и тот же контекст для всех сценариев.

Примеры:

• support-вопрос о заказе: больше tool results, меньше retrieval;
• research-задача: больше retrieval и citations;
• coding-agent step: больше repo context и текущего task state;
• короткий follow-up: достаточно свежей истории без повторного retrieval.

Это и есть dynamic context assembly: система решает, какие слои нужны именно сейчас.

5. Truncation, compaction и caching — это не опции, а базовые механизмы

Когда контекст растёт, у вас всегда есть только три здоровых действия:

1. Truncate низкоприоритетные блоки.
2. Compact старую историю в summary/state object.
3. Cache стабильный префикс.

Обычно healthy priority такой:

• system / policy защищены почти всегда;
• свежие tool results и последние turns имеют высокий priority;
• retrieval режется по relevance;
• старая история сначала compact summary, а не полный transcript;
• output reserve не жертвуется первым.

Prompt caching особенно хорошо работает для:

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

6. Где Context Engineering даёт наибольший выигрыш

Сильнее всего он влияет на четыре класса систем:

• RAG и enterprise search: качество зависит от retrieval contribution, а не от “магии промпта”.
• Support/copilot systems: нужны user state, policy docs и tool results.
• Agents и workflows: контекст меняется по шагам, а budget нужно контролировать на каждом tool loop.
• Long-running chats: без compaction и memory hygiene модель быстро тонет в своей же истории.

7. Что нужно мониторить

В production Context Engineering почти всегда измеряют через:

8. Минимальная mental model

Если упростить до одной формулы, то Context Engineering выглядит так:

response_quality
= right_instructions
+ right_external_knowledge
+ right_state
+ right_tool_results
+ right_output_constraints
- noise
- stale_context
- broken_budgeting

Это не про “добавить больше текста”. Это про добавить правильный контекст, в правильном порядке, в правильном объёме.

Пример простого context assembler

from dataclasses import dataclass, field


@dataclass
class ContextPlan:
    instructions: str
    retrieval_chunks: list[str] = field(default_factory=list)
    recent_messages: list[dict] = field(default_factory=list)
    durable_facts: list[str] = field(default_factory=list)
    tool_results: list[dict] = field(default_factory=list)
    output_contract: str | None = None


class ContextAssembler:
    def __init__(self, max_input_tokens: int = 32_000):
        self.max_input_tokens = max_input_tokens

    def assemble(self, plan: ContextPlan) -> list[dict]:
        messages: list[dict] = []

        system_parts = [plan.instructions]

        if plan.durable_facts:
            system_parts.append(
                "Known user facts:\n- " + "\n- ".join(plan.durable_facts)
            )

        if plan.output_contract:
            system_parts.append(
                f"Output contract:\n{plan.output_contract}"
            )

        messages.append(
            {"role": "system", "content": "\n\n".join(system_parts)}
        )

        if plan.retrieval_chunks:
            messages.append(
                {
                    "role": "system",
                    "content": "Retrieved context:\n\n"
                    + "\n\n---\n\n".join(plan.retrieval_chunks[:4]),
                }
            )

        messages.extend(plan.recent_messages[-4:])

        for result in plan.tool_results[-2:]:
            messages.append(
                {"role": "tool", "content": str(result)}
            )

        return messages

Главная мысль в этом примере не в коде, а в дисциплине:

• instructions, retrieval, state и tools живут как отдельные слои;
• у каждого слоя есть собственный budget и priority;
• memory и recent history не смешиваются;
• retrieved context и tool output ограничиваются до полезного минимума.