Контекстная инженерия ИИ-агентов

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

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

Когда нужна отдельная работа с контекстом

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

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

Что собрать перед проверкой

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

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

Что означает контекстная инженерия

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

Промпт-инжиниринг помогает сформулировать инструкции. Контекстная инженерия, или context engineering, охватывает также отбор и обновление данных вокруг них. RAG — поиск внешних сведений для ответа — может быть частью этого отбора. MCP стандартизирует подключение инструментов и источников. Ни поиск, ни протокол подключения сами по себе не определяют, какие сведения попадут в очередной вызов модели.

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

Если нужно сначала разобраться, как модель, инструменты и среда выполнения образуют агента, это объясняет обзор agent loop и harness. Для продолжения задачи нужно определить, что передавать модели внутри этого цикла.

Четыре слоя данных

Под словом «память» часто объединяют разные данные. Из-за этого трудно понять причину сбоя: запись отсутствует, не найдена, не передана модели или неправильно использована. Для проектирования полезно разделить четыре слоя.

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

В примере с отчётом история содержит первоначальную просьбу разобрать API v1 и последующее исправление на v2. Состояние должно отражать действующую версию v2. В текущий контекст достаточно включить это условие и нужную часть спецификации. Сохранять оба сообщения в архиве полезно; предъявлять их модели как две равноправные инструкции — уже другое решение.

Порядок отбора для одного шага

1. Назовите ближайшее решение: найти источник, исправить раздел, проверить результат или выполнить действие.
2. Соберите действующие условия и отмените устаревшие версии инструкций в рабочем состоянии.
3. Выберите нужные фрагменты документов, памяти и результатов; сохраните адреса остальных источников.
4. Проверьте доступные инструменты, область задачи и основания для внешнего действия.
5. Посмотрите фактический вход модели и после шага сохраните подтверждённый результат и оставшуюся работу.

Как выбирать и обновлять данные

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

LangChain группирует подходы ↗ в четыре операции: записывать, отбирать, сжимать и разделять контекст. Это действия над информацией; их не следует путать с четырьмя слоями из таблицы. Записать рабочую заметку можно в состояние задачи, а отобрать для вызова — сведения сразу из нескольких слоёв.

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

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

Отбор можно сделать постепенным: сначала передать короткое описание источника и адрес, затем прочитать нужный раздел. Но описание должно помогать выбрать документ: название «полезные материалы» не объясняет, зачем к ним обращаться. Лучше указать предмет, границы и версию — например, «Спецификация создания объектов, API v2». Иначе сведения формально доступны, но у агента нет понятного повода их извлечь.

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

Состав инструментов также входит в контекст. Для чтения спецификации модели нужны понятные средства поиска и чтения; доступ к публикации не следует выдавать только потому, что такой инструмент вообще существует. Постоянные правила и подробные процедуры можно организовать отдельно — см. разбор AGENTS.md, SKILL.md и MCP.

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

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

Возьмём синтетический пример. Пользователь попросил отчёт по API v1, затем исправил версию на v2. Он также уточнил: персональные данные исключить, подготовить только черновик, ничего не публиковать. Агент прочитал спецификацию v2 и сохранил два раздела. Осталось описать, как обрабатывать неизвестный результат операции создания объекта.

Какие условия потеряла сводка

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

Какие сведения нужны для продолжения

Цель: подготовить технический отчёт по API v2.
Условия: без персональных данных; только черновик,
публикация не разрешена. Прежнее условие про v1 заменено.
Готово: спецификация v2 прочитана, два раздела сохранены.
Источник: sources/api-v2.txt, версия 2.
Черновик: drafts/api-report.txt.
Осталось: обработка неизвестного результата create.
Следующий шаг: перечитать раздел create в спецификации v2
и дополнить сохранённый черновик.

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

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

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

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

В разных системах сохранение и восстановление контекста устроены по-разному. Ниже — три отдельных механизма из версий, просмотренных 10 октября 2026 года. Фрагменты сокращены до обсуждаемого участка; это не готовые примеры для самостоятельного запуска.

OpenCode: предыдущая сводка и отбор истории

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

const prior = completedCompactions(history)
const hidden = new Set(prior.flatMap((item) =>
  [item.userIndex, item.assistantIndex]))
const previousSummary = prior.at(-1)?.summary
const selected = yield* select({
  messages: history.filter((_, index) => !hidden.has(index)),
  cfg,
  model,
})

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

Hermes: возвращение к сохранённым сообщениям

В Hermes инструмент поиска сессий позволяет открыть определённую сессию или окно сообщений вокруг выбранной записи. Ветка с указанием сессии выглядит так:

if isinstance(session_id, str) and session_id.strip():
    if around_message_id is not None:
        return _scroll(db, session_id.strip(),
                       around_message_id, window, current_session_id)
    return _read_scoped(db, session_id.strip(), profile)

Это отдельный путь к исходной истории, а не попытка вместить её целиком в сводку. Агенту всё равно нужно определить, какую запись искать и что из неё использовать. См. реализацию session_search ↗.

OpenClaw: структура передачи работы

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

`### In Progress\n${sections.inProgress}`,
`### Blocked\n${sections.blocked}`,
`## Key Decisions\n${sections.decisions}`,
`## Next Steps\n${sections.nextSteps}`,

Структура помогает явно отделить готовое от текущей работы. Однако заполненный раздел «Ограничения» может содержать устаревший текст или пропустить запрет. Шаблон OpenClaw ↗ задаёт форму; содержательную проверку нужно рассматривать отдельно.

Проверка входа модели и результата

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

В разработке RB Tech был проверен ограниченный сценарий: после потери прежней истории аргументы отклонённого действия передавались модели вместе с причиной отказа, с предварительным скрытием секретов. Отдельный сценарий проверял продолжение сохранённого черновика после перезапуска. Эти проверки использовали детерминированную модель; они подтверждают передачу данных и восстановление, но не измеряют качество понимания реальной LLM.

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

Для собственного процесса начните с небольшого набора сценариев:

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

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

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

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

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

Что дальше

Для организации файлов и результатов используйте разбор Agent Workspace. Постоянные инструкции описаны в руководстве по AGENTS.md и SKILL.md. Перед подключением внешних действий пройдите чек-лист доступа и подтверждений.