Контекст-инжиниринг для ИИ-агентов: память и инструменты

Viacheslav Dubrov

2025-10-05 · Обновлено 2026-08-16 · 13 мин · ИИ-агенты

Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Контекст-инжиниринг — это пайплайн, который перед каждым решением выбирает, что именно увидит модель: инструкции, примеры, знания, память, определения инструментов, наблюдения и гардрейлы. Агент действует не на основе всего, что известно системе. Он действует на основе рабочего набора, собранного для следующего вызова модели.

Именно на этапе выбора начинается множество сбоев. Устаревшее предпочтение выглядит актуальным. В retrieved-тексте содержится инструкция. Длинный результат инструмента скрывает невыполненное предусловие. Саммари сохраняет решение, но теряет информацию о том, какой файл был изменён.

Для инженеров, создающих или эксплуатирующих ИИ-агентов, retrieval-системы и приложения с tool use, практическая задача состоит в том, чтобы для каждого решения агента собрать минимальный достаточный рабочий набор, сохранив область действия, provenance и права доступа. В этой статье показано, как спроектировать контекстный пайплайн для каждого решения, найти его границы доверия, проверить, поддерживает ли рабочий набор выполнение задачи, и сделать сбои наблюдаемыми — вместо того чтобы обвинять модель, которая видит только собранный вход.

Коротко. Рассматривайте контекст как типизированный runtime-артефакт, несущий provenance. Выбирайте его для каждого шага, проверяйте область tenant и права доступа до retrieval и отделяйте доверенные инструкции от недоверенных данных. Распределяйте бюджет по полезности, валидируйте действия вне модели и оценивайте результат выполнения задачи, а не только длину контекста.

Контекст — это вход для принятия решения, а не память

Контекстное окно — это текущий вход модели плюс сгенерированные токены. В нём могут находиться ходы диалога, но само оно не является системой долговременной памяти. Долгосрочная память, индексы документов, базы данных и хранилища артефактов находятся за пределами окна. Контекстный пайплайн выбирает, что из них скопировать внутрь.

Размер окна — это ограничение ёмкости, а не гарантия качества. Исследования Lost in the Middle и RULER показывают, что retrieval и reasoning могут зависеть от позиции, задачи, модели и длины последовательности. Практический вывод не в том, что средние токены всегда игнорируются. Он в том, что добавление токенов, которые выглядят релевантными, всё равно может снизить качество выполнения задачи.

Диаграмма показывает качественный результат исследования, а не универсальную кривую аттеншна. Liu и соавторы тестировали multi-document question answering и retrieval по ключам и значениям. Они часто наблюдали более высокое качество, когда релевантный элемент находился ближе к началу или концу. Размер и форма эффекта менялись в зависимости от модели, задачи и длины контекста. Проверяйте позицию как отдельную переменную на собственном evaluation-наборе, а не исходите из фиксированного штрафа за середину.

Ниже приведена иллюстративная Pydantic-схема, а не протестированная реализация в репозитории. Она проверяет только типы полей и значения literal. Она не авторизует tenant, не поддерживает согласованность total_input_tokens с items, не сохраняет манифест и не принуждает модель к определённому поведению.

from datetime import datetime
from typing import Literal

from pydantic import BaseModel

class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int

class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

Манифест делает сбой воспроизводимым. Фраза «модель галлюцинировала» превращается в проверяемый вопрос: какие именно доказательства, версия, область прав и схема инструмента были ей переданы?

Жизненный цикл сборки контекста

Надёжный пайплайн выполняет эти операции по порядку:

1. Разрешите доверенный контекст запроса. Вне модели аутентифицируйте субъекта, tenant, локаль, время и текущее состояние задачи.
2. Выберите следующее решение. Для шага планирования, поиска доказательств, выбора инструмента и формирования финального ответа нужен разный контекст.
3. Выполните retrieval в заданной области. Применяйте фильтры авторизации и tenant до semantic ranking, а не после того, как документы попадут в набор кандидатов.
4. Ранжируйте и распределите бюджет. Выбирайте элементы по полезности, свежести, авторитетности и разнообразию в рамках бюджета входа.
5. Соберите контекст с границами доверия. Храните политику в каналах инструкций, а retrieved-контент передавайте как данные в цитатах. Retrieved-инструкции не становятся системной политикой.
6. Сгенерируйте типизированное предложение. Constrained output может задать поддерживаемый синтаксис и структуру. Он не делает значения корректными.
7. Провалидируйте и выполните. Код приложения проверяет авторизацию, бизнес-правила, аргументы инструментов и постусловия.
8. Запишите provenance и результат. Сохраните манифест, ID выбранных источников, ссылки на результаты инструментов, результат валидации и исход задачи.

Жизненный цикл выполняется для каждого решения. Повторное использование одного большого контекста на протяжении всего запуска агента создаёт устаревшие данные и даёт каждому шагу доступ к материалам, которые ему не нужны.

Назначьте каждому источнику контекста одну задачу

Инструкции задают устойчивое поведение

Инструкции описывают роль, политику, контракт вывода и поведение при эскалации. Стабильный контент держите стабильным, чтобы улучшить prefix caching, но не фиксируйте значения, которые меняются во время выполнения. Порог для возврата средств должен находиться в сервисе политик или версионируемой записи данных, а не бессрочно копироваться в промпт.

Иерархия инструкций — это граница управления, а не сэндбокс безопасности. Модель всё ещё может выполнить вредоносный текст из retrieved-документа. Разделяйте недоверенный контент, явно обозначайте его как данные, а не инструкции, независимо ограничивайте инструменты и тестируйте случаи prompt-инъекции.

Не переносите названия ролей одного провайдера в универсальную иерархию. OpenAI Model Spec определяет уровни авторитетности для инструкций платформы или системы, разработчика и пользователя. В Anthropic Messages API используются параметр верхнего уровня system и сообщения user и assistant. Эквивалентной роли developer в этом API нет. Другие рантаймы принимают иные решения. Сопоставьте свою политику с документированными каналами провайдера, а затем применяйте права доступа и побочные эффекты в коде приложения.

Состояние задачи фиксирует обязательства

Проза диалога — плохой источник истины для многошаговой работы. Храните явное состояние: цель, текущую фазу, выполненные действия, ожидающие согласования, ссылки на артефакты и статус тестов. Модель может суммировать это состояние для описания происходящего. Каноническую версию хранит код приложения.

Примеры показывают пограничные решения

Few-shot-примеры полезны, когда проясняют сложную границу, а не просто повторяют схему. Выбирайте примеры, соответствующие текущему решению, и включайте существенные пограничные случаи. Оценивайте retrieval примеров так же, как retrieval документов: внешне похожий, но несовместимый с политикой пример может быть хуже, чем отсутствие примера.

Знания поставляют доказательства

Retrieval подходит для актуальных, приватных или цитируемых фактов. Не существует универсально лучшего top_k, размера чанка, hybrid weight или cutoff реранкера. Настраивайте весь путь на вопросах с известными подтверждающими доказательствами.

Полезный элемент доказательств включает:

• источник и стабильный идентификатор документа
• версию или дату вступления в силу
• область прав доступа
• цитируемый фрагмент и его расположение
• retrieval- и reranking-оценки для отладки

Не просите модель цитировать URL, который ей не передавали. Не логируйте целиком приватные документы только ради отладки выбора.

Память обеспечивает continuity в заданной области

Память — это retrieved-данные с дополнительными рисками жизненного цикла. В качестве проектных метаданных отслеживайте субъект, provenance, назначение, применимое согласие или решение о правовом основании, время создания, политику истечения срока или пересмотра и путь удаления. Применимое законодательство о приватности и юристы продукта определяют правовое основание для продукта и его данных, а не этот чек-лист.

Фиксированные правила вроде «предпочтения хранятся 365 дней» нельзя переносить между продуктами как универсальную политику. Срок хранения определяется потребностями продукта, ожиданиями пользователя и законом. Перед загрузкой элемента памяти проверьте:

1. Относится ли он к этому аутентифицированному субъекту и tenant?
2. Имеет ли его назначение отношение к текущему решению?
3. Достаточно ли он актуален для использования?
4. Является ли его источник авторитетным или это всего лишь вывод модели?

Рассматривайте выведенные воспоминания как гипотезы. Не превращайте молча один ответ модели в постоянный факт о пользователе.

Контракты инструментов раскрывают возможности

Описания инструментов должны объяснять предусловия, эффекты, область авторизации, схему входа, схему вывода, идемпотентность и значимые ошибки. Вызов, корректный с точки зрения схемы, всё ещё может быть неавторизованным или небезопасным.

После выполнения заменяйте подробный сырой вывод типизированным наблюдением, которое сохраняет значимый для решения результат и ссылку на полный артефакт:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

Спецификация MCP стандартизирует взаимодействие клиентов с инструментами, ресурсами и промптами. Она не авторизует их использование и не делает возвращаемый контент доверенным. Проверки gateway, учётных данных и политик должны находиться за пределами модели и описания протокола.

Загружайте детали только когда они нужны решению

Progressive disclosure — это паттерн сборки контекста: идентификаторы и доверенное состояние задачи остаются доступными, а детали загружаются для текущего решения. Это не обещание, что конкретный токен-бюджет подойдёт любой модели.

Роутер должен применять авторизацию и область tenant до retrieval. Он должен возвращать фрагменты доказательств, записи памяти и схемы инструментов, необходимые для текущего решения. Затем модель предлагает действие. Код приложения валидирует это предложение до выполнения. В руководстве Anthropic по контексту инструментов тот же принцип выборочной загрузки применяется к большим наборам инструментов. Tool search оставляет определения за пределами контекстного окна, пока модель не запросит их. В своей системе измеряйте, улучшает ли дополнительный шаг роутинга успешность задач, латентность и количество токенов на успешную задачу.

Как контекст деградирует

Плохой контекст приводит к сбоям не единственным способом. Следующая модель деградации из пяти паттернов — моя синтеза для отладки, основанная на приведённых выше оценках длинного контекста и исследованиях prompt-инъекций:

• Потеря из-за позиции: нужное доказательство присутствует, но модель использует его непоследовательно из-за позиции и окружающей последовательности. Оценки длинного контекста показывают, что эффект зависит от модели и задачи. Универсального «плохого диапазона в середине» не существует.
• Отравление: в рабочий набор попадают некорректная память, устаревший документ, вредоносная инструкция или ошибочное наблюдение инструмента и влияют на последующие решения.
• Отвлечение: релевантные доказательства конкурируют с материалами, которые свежи или семантически похожи, но не нужны на текущем шаге.
• Смешение: пересекающиеся инструкции, примеры или описания инструментов оставляют модели несколько правдоподобных трактовок задачи.
• Конфликт: два элемента, выглядящие авторитетными, расходятся в значении, политике или следующем действии, а сборщик не показывает их версии или приоритет.

Для этих сбоев нужны разные исправления. Улучшение ранжирования может помочь против отвлечения, но не исправит устаревший источник. Разделители могут помочь отделить данные от инструкций, но не авторизуют инструмент. Большое контекстное окно может сохранить больше противоречивых материалов, не разрешив конфликт.

При сбое запуска сначала изучите манифест и определите, какой паттерн проявился, а уже потом меняйте промпт или добавляйте ещё один этап retrieval.

Распределяйте бюджет по полезности, а не по квотам компонентов

Контекстный бюджет сначала резервирует место для вывода, а затем распределяет оставшийся объём входа под текущее решение. Отталкивайтесь от поддерживаемого моделью окна, вычитайте максимальный объём вывода и служебные накладные расходы, а затем упаковывайте кандидатов в остаток.

Оценивайте кандидатов по признакам, которые можно проверить на evaluation:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

Рассматривайте формулу как отправную точку для проектирования. В ответе по политике авторитетность может быть важнее семантического сходства. При отладке свежий лог с ошибкой может иметь больший приоритет, чем общая документация.

Порядок тоже важен. Стабильные доверенные инструкции размещайте в начале, если семантика кэша провайдера выигрывает от общего префикса. Текущую задачу и решение располагайте рядом с доказательствами, на которые они ссылаются. Не добавляйте timestamps или ID запросов в стабильные префиксы, если они там не нужны.

Сжимайте контекст, не теряя состояние

Сжатие необратимо теряет информацию, если оригинал нельзя адресно получить. Оценка Factory Research трёх подходов к сжатию в долгих сессиях ИИ-агентов рассматривает целевую метрику как количество токенов на задачу, а не на запрос. Я преобразую это в инженерную рекомендацию: оптимизируйте количество токенов на успешную задачу, а не количество токенов на запрос, при сопоставимых условиях выполнения задачи — но не воспринимайте это как универсальный закон. Оценка Factory Research

Используйте разные механизмы для разных типов материалов:

• Диалог: суммируйте решения, нерешённые вопросы и обязательства.
• Наблюдения инструментов: сохраняйте типизированные результаты и ссылки на артефакты. Удаляйте шаблонный и повторяющийся payload.
• Retrieved-доказательства: сохраняйте ID источников, подтверждающие фрагменты и даты вступления в силу, чтобы система могла выполнить повторный retrieval.
• Состояние задачи: храните канонически за пределами саммари.
• Трасса файлов и артефактов: ведите явный индекс чтений, записей, хешей и результатов тестов.

Запускайте компактификацию при измеренной деградации или при достижении порога бюджета, выбранного для конкретной модели и задачи. Не публикуйте общее правило «сжимать на 70%», будто все модели начинают сбоить в одной и той же точке.

Оценивайте сжатие пробами, требующими продолжения работы, а не лексического сходства:

• Какова текущая цель и следующее действие?
• Какие файлы или записи изменились?
• Какое решение было отклонено и почему?
• Какой источник подтверждает текущее утверждение?
• Какое согласование всё ещё ожидается?

Выполняйте одну и ту же задачу со сжатием и без него. Сравнивайте успешность, некорректные действия, повторные retrieval, латентность и общее количество токенов.

Оптимизируйте путь контекста

Оптимизация должна сохранять контракт решения. После измерения боттлнека полезны четыре техники:

Эти техники решают разные задачи. Компактификация и редактирование контекста могут уменьшить объём данных, отправляемых модели. Селективная загрузка инструментов позволяет не передавать неиспользуемые схемы. Prompt caching может снизить стоимость повторяющихся префиксов, но не уменьшает число токенов в контекстном окне. Партиционирование меняет набор возможностей и доказательств, доступных каждому решению. Руководство Anthropic по контексту инструментов явно проводит эти различия, а его документация по редактированию контекста предоставляет настраиваемые триггеры, а не универсальный порог.

Компактифицируйте завершённую историю

Заменяйте старые ходы диалога структурированным handoff, в котором зафиксированы решения, нерешённые вопросы, изменённые артефакты и состояние тестов. Оставляйте исходный транскрипт или артефакты адресуемыми, если они нужны для ревью или восстановления.

Маскируйте подробные наблюдения

Инструмент может вернуть страницы логов, хотя следующему шагу нужны только статус, код ошибки и ссылка на артефакт. После валидации преобразуйте сырой результат в типизированное наблюдение, а полный payload храните за пределами промпта. Не позволяйте модели суммировать единственное свидетельство сбоя.

Сохраняйте кэшируемые префиксы

Провайдеры и рантаймы могут повторно использовать вычисления, если начало запроса остаётся стабильным. Храните долгосрочные инструкции и схемы инструментов в согласованном порядке, а timestamps, ID запросов, retrieved-доказательства и текущее состояние переносите в динамический суффикс. Перед проектированием с расчётом на это проверьте семантику кэша провайдера.

Разделяйте контекст по решениям

Планировщику, retriever, вызывающему инструменты и шагу формирования финального ответа нужны разные материалы. Передавайте каждому шагу только необходимые доверенные инструкции, состояние, доказательства и инструменты. Партиционирование одновременно уменьшает расход токенов и область доступных возможностей, но только оценки на уровне задачи покажут, не удалило ли оно необходимую информацию.

Защитите цепочку поставки контекста

Исследования prompt-инъекций рассматривают недоверенный внешний контент как поверхность атаки (статья). В операционной модели этой статьи отравление контекста может происходить через документы, память, результаты инструментов, skills или предыдущие сообщения ассистента. Пометка текста как «недоверенного» помогает модели, но enforcement должен быть архитектурным.

Следующий чек-лист цепочки поставки — моя инженерная рекомендация. Он превращает границы протокола и threat model в элементы управления приложения. Ни спецификация MCP, ни статья о prompt-инъекциях не обеспечивают весь этот чек-лист.

Используйте следующие границы:

1. Авторизуйте действия до retrieval и выполнения инструментов.
2. Разделяйте каналы данных и инструкций и выделяйте внешний текст разделителями.
3. Разрешайте инструменты по allowlist для каждого шага и субъекта. По умолчанию запрещайте возможности с побочными эффектами.
4. Валидируйте идентификаторы ресурсов, а не позволяйте модели выдумывать ключи tenant или пути к файлам.
5. Требуйте подтверждение для операций с высоким воздействием на основе политики, а не уверенности модели.
6. Сканируйте и проверяйте исполняемые skills или коннекторы до установки.
7. Не допускайте попадания секретов и сырого чувствительного контекста в логи и долгосрочную память.

Автоматический «ремонт» допустим только для изменений, сохраняющих смысл, например для парсинга даты в известном формате. Подстановка «разумных значений по умолчанию» в пропущенные аргументы инструмента может изменить операцию. Если смысл неясен, запросите уточнение или отклоните действие.

Практический пример: запрос в поддержку по API-ключу

Для вопроса «Почему мой API-ключ не работает?» следующим решением должен быть сбор диагностических доказательств, а не формирование финального ответа. Сборщик может включить:

• доверенную политику поддержки и контракт ответа
• ID аутентифицированного аккаунта и тариф из состояния приложения
• текущую цель тикета и уже выполненные действия
• два актуальных фрагмента runbook, выбранных в рамках области продукта и версии
• scoped-воспоминание о том, что ключ был создан три дня назад, с provenance
• check_api_key_status и search_incidents, но не инструменты удаления или ротации ключа

Модель предлагает проверку статуса только для чтения. Код приложения авторизует аккаунт, вызывает инструмент и записывает типизированное наблюдение. Второй вызов модели получает релевантные фрагменты runbook и это наблюдение. Финальный ответ ссылается на версию runbook, не выводит ключ и предлагает ротацию только как отдельное авторизованное действие.

Обратите внимание, что остаётся за пределами контекста: нерелевантная история тикета, все примеры поддержки, сырые дампы аккаунта, инструменты мутации и память других tenant.

Антипаттерны, которые нужно тестировать явно

• Заполнять окно: загружать все retrieved-документы, историю, память и инструменты только потому, что остаётся свободная ёмкость.
• RAG повсюду: использовать semantic retrieval для значений, которые должны находиться в базе данных, сервисе политик или аутентифицированном состоянии приложения.
• Неограниченная память: хранить выведенные факты без области действия, срока годности, механизма исправления или удаления.
• Один вызов на все этапы: просить один промпт выполнять retrieval, reasoning, авторизацию, мутацию и объяснение без наблюдаемых границ.
• Схема равна корректности: считать валидный JSON доказательством корректности значений, прав доступа или бизнес-решений.
• Нет оценок компонентов: оценивать только финальную прозу и не замечать сбоев retrieval, выбора контекста или инструментов.

Превратите каждый антипаттерн в контрпример evaluation-набора. Рекомендацию, которую не проверяет ни одна задача или трейс, легко нарушить незаметно.

Оценивайте сборщик, а не только ответ

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

Используйте абляции для поиска причинного вклада: поочерёдно удаляйте память, реранкинг, примеры или сжатие. Компонент, который добавляет токены, но не улучшает релевантный срез, не должен загружаться по умолчанию.

Заключение

Хороший контекст-инжиниринг избирателен и подотчётен. Он не заполняет большое окно только потому, что ёмкость доступна. Он формирует рабочий набор для конкретного шага из доверенных инструкций, канонического состояния задачи, scoped-доказательств, проверенной памяти и разрешённых инструментов.

Цикл короткий: собрать, записать манифест, предложить, провалидировать, выполнить и оценить. Если решение оказалось неверным, этот цикл показывает, чего не хватило: доказательств, свежести, авторитетности, состояния или политики. Он также даёт тест для следующего изменения.

Источники

• Lost in the Middle — зависимость использования длинного контекста от позиции
• RULER — multitask-оценка эффективной длины контекста
• OpenAI Model Spec — специфичные для провайдера уровни авторитетности инструкций
• Anthropic Messages API — системный параметр и структура ролей сообщений
• Manage tool context — селективная загрузка инструментов, кэширование и редактирование контекста
• Anthropic context editing — настраиваемая очистка результатов инструментов и компактификация
• Model Context Protocol specification — концепции протокола и актуальная спецификация
• Evaluating Context Compression for AI Agents — метрика токенов на задачу и probe-based evaluation
• Formalizing and Benchmarking Prompt Injection Attacks and Defenses — таксономия угроз и защиты