2025-10-05 · Обновлено 2026-07-15

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

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

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

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

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

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

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

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

Размер окна представляет собой ограничение по объёму данных, а не гарантию качества. Исследования с длинным контекстом, такие как Заблокировано внутри структуры и Регулятор Это показывает, что эффективность retrieval и ризонинг может варьироваться в зависимости от позиции, типа задачи, модель и длины последовательности. Важный вывод заключается не в том, что средние токены всегда игнорируются, а в том, что добавление элементов токены, кажущихся релевантными, всё равно способно снизить производительность выполнения задачи.

Для каждого вызова модель следует использовать манифест контекста:

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

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

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

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

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

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

Придать каждому исходному контексту одну задачу

Инструкции определяют стабильное поведение системы

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

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

Записи состояния задачи фиксируют принятые обязательства

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

Примеры иллюстрируют принятие решений на грани случаев

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

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

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

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

• идентификатор исходного и стабильного документа
• версия или дата вступления в силу
• область разрешений
• цитируемые спан и местоположение
• оценки retrieval и реранкинг для отладки

Не просите модель указывать URL-адрес, который он никогда не получал. Также не записывайте полные версии частных документов исключительно с целью отладки процесса выбора.

Обеспечение преемственности памяти в определённых контекстах

Данные, извлекаемые из памяти, сопряжены с дополнительными рисками на протяжении всего их жизненного цикла. Каждая запись должна содержать информацию об объекте обработки, источнике происхождения, цели использования, наличии согласия пользователя или законных основаниях для обработки (при необходимости), времени создания, правилах истечения срока действия или периодической проверки, а также способ удаления.

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

1. Предназначено ли это для данного аутентифицированного субъекта и тенанта?
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 стандартизирует процесс, с помощью которого клиенты находят инструменты, ресурсы и промпты; при этом он не предоставляет разрешений на их использование и не гарантирует достоверность возвращаемого контента. Проверки гейтвейнов, учетных данных и политик следует выполнять вне описания модель и протокола.

Как ухудшается контекст

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

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

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

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

Бюджет по видам ресурсов, а не по квотам компонентов

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

Оценивайте кандидатов с использованием признаков, способных поставить под сомнение результаты ваших оценок:

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

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

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

Сжатие без потери состояния

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

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

• Беседа: кратко излагать принятые решения, нерешённые вопросы и взятые на себя обязательства.
• Заметки о инструментах: сохранять записанные результаты анализа и ссылки на созданные объекты; удалять шаблонный текст и дублирующиеся данные.
• Полученные доказательства: хранить идентификаторы исходных данных, вспомогательные спаны и даты вступления в силу, чтобы система могла повторно их загрузить.
• Статус задачи: сохранять информацию о статусе задачи отдельно от общего резюме.
• Хроника файлов и объектов: вести чёткий учёт операций чтения, записи, расчёта хэшей и результатов тестирования.

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

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

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

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

Оптимизация пути контекста

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

Компактная история выполнения операций

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

Маскировка подробных наблюдений

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

Сохранение префиксов, подлежащих кэшированию

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

Разделение по решению

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

Обеспечение безопасности цепочки поставок контекста

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

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

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

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

Пример реального случая: запрос поддержки по API-ключу

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

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

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

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

Антипаттерны, которые необходимо тестировать явно

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

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

Оценивайте сам ассемблер, а не только результат выполнения

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

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

Заключение

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

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

Список литературы

• Заблокировано внутри структуры — использование длинного контекста в зависимости от позиции Регулятор — многозадачная оценка эффективной длины контекста
• Модель Спецификация протокола контекста — концепции протокола и современные спецификации Оценка эффективности сжатия контекста для ИИ-агенты — токены-фрейминг по задачам и оценка с использованием пробных тестов Промпт-инъекция атаки и защиты в LLM-интегрированные приложения — таксономия угроз и средства защиты