Контекст и память

Всё полезное становится контекстом​

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

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

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

Что входит в запрос​

Запрос к модели — не только твой последний промпт. В зависимости от обвязки он может включать:

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

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

Роль определяет значение​

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

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

Как выглядит контекстное окно​

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

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

Преимущество отсутствия состояния​

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

Память — это поиск, а не воспоминание​

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

Распространённые источники памяти:

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

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

Вопрос качества звучит не «помнит ли модель?», а «нашла ли программа нужные свидетельства и сжала ли их, не потеряв важное ограничение?».

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