Цель лекции
Показать, что working memory - это активная информация внутри текущего контекстного окна модели.
Зачем это нужно
В Module 01 мы ввели общую рамку: LLM не хранит долговременную память сама по себе, агентская память живет во внешней системе, а разные типы памяти выполняют разные роли. Module 02 начинает разбирать эти типы по отдельности. Первый и самый важный слой - working memory.
Рабочая память - это то, что агент использует прямо сейчас. Если долгосрочная память похожа на архив, профиль или журнал опыта, то working memory похожа на рабочий стол: на нем лежит только то, что нужно для текущего шага. Слишком пустой рабочий стол делает агента слепым. Слишком захламленный - медленным, дорогим и рассеянным.
Понимание working memory важно для всех следующих тем. Любая внешняя память становится полезной только тогда, когда ее релевантная часть попадает в текущий контекст модели. Поэтому качество агента часто определяется не тем, сколько он хранит, а тем, насколько точно он собирает рабочий контекст перед вызовом LLM.
Основная идея
Working memory - это активная информация, доступная агенту в текущем шаге рассуждения. В LLM-системах она обычно материализуется как содержимое context window: инструкции, запрос пользователя, последние сообщения, результаты инструментов, активная цель, промежуточный план и выбранные фрагменты внешней памяти.
Рабочая память ограничена, дорога и чувствительна к шуму. Ограничена - потому что context window имеет конечный размер. Дорога - потому что лишние токены увеличивают стоимость и latency. Чувствительна к шуму - потому что модель может начать учитывать нерелевантные детали, устаревшие инструкции или конфликтующие факты.
Хорошая working memory не равна "все, что удалось найти". Это тщательно собранный контекст, в котором каждый фрагмент помогает текущему шагу: понять задачу, соблюдать правила, выбрать действие, интерпретировать результат или сформулировать ответ.
Главный практический вопрос этой лекции: что должно попасть в рабочий контекст прямо сейчас, а что лучше оставить в хранилище, summary, логе или вообще не использовать?
Ключевые термины
| Термин | Короткое определение |
|---|---|
Working memory |
Активный контекст агента для текущего шага рассуждения или действия. |
Context window |
Максимальный объем токенов, который модель может учитывать в одном вызове. |
Context assembly |
Процесс сборки итогового входа для LLM из инструкций, запроса, состояния, истории, tool results и retrieved memory. |
Instruction hierarchy |
Приоритеты инструкций: system, developer, policy, user, tool output и другие источники. |
Tool result |
Наблюдение, полученное после вызова инструмента: вывод команды, ответ API, найденный документ, ошибка. |
Scratchpad |
Временное рабочее пространство для плана, промежуточных заметок или структурированного состояния. |
Context budget |
Ограниченный объем токенов, который можно потратить на разные части контекста. |
Retrieval noise |
Нерелевантные или слабополезные фрагменты, попавшие в контекст после поиска. |
Lost in the middle |
Риск, что важная информация в длинном контексте будет использована хуже, особенно если она окружена шумом. |
Что входит в working memory
Working memory собирается из нескольких источников. Они различаются по приоритету, времени жизни и роли в решении задачи.
| Источник | Что содержит | Зачем нужен | Риск |
|---|---|---|---|
| System и developer instructions | Глобальные правила поведения, безопасность, формат, ограничения среды. | Задают рамки, которые должны соблюдаться всегда. | Конфликт с пользовательским запросом или локальными правилами. |
| User request | Текущая задача, вопрос, цель, ограничения от пользователя. | Определяет, что агент должен сделать сейчас. | Неполнота, неоднозначность, скрытые предположения. |
| Последние сообщения | Недавний контекст диалога. | Помогают не терять нить разговора. | Быстро превращаются в шум при длинной беседе. |
| Session state | Активные настройки, выбранный workflow, текущий шаг. | Поддерживает непрерывность текущей работы. | Может ошибочно стать постоянным фактом. |
| Tool results | Файлы, команды, API, поиск, ошибки, диагностика. | Дают агенту наблюдения из среды. | Большие выводы команд могут переполнить контекст. |
| Retrieved memory | Факты, события, процедуры, документы из внешней памяти. | Подключают прошлый опыт и знания. | Нерелевантные retrieval-фрагменты сбивают фокус. |
| Scratchpad / plan | Краткий план, подзадачи, промежуточные переменные. | Помогает управлять многошаговой задачей. | Устаревший план может вести агента по неверному пути. |
Не все эти источники нужны в каждом вызове. Для простого вопроса достаточно user request и базовых инструкций. Для сложного агентского шага могут понадобиться project facts, результаты инструментов, активный план и несколько retrieved records.
Context window как физическое ограничение
Context window - это техническая граница: модель может учитывать только конечный объем входных и выходных токенов. Даже если окно большое, оно остается ограничением. Внутри него конкурируют инструкции, история, данные, документы, результаты инструментов и место для ответа.
У context window есть несколько практических последствий.
Во-первых, каждый фрагмент занимает бюджет. Если положить в prompt длинный лог, может не хватить места для более важных инструкций или свежих наблюдений.
Во-вторых, большой контекст стоит дороже. Агент, который делает много шагов, может многократно платить за одни и те же нерелевантные токены.
В-третьих, latency растет вместе с объемом входа. Это особенно заметно в интерактивных продуктах и tool-using agents, где один пользовательский запрос превращается в несколько LLM-вызовов.
В-четвертых, большой контекст не гарантирует хорошее внимание. Модель может хуже использовать факт, если он buried в середине длинного, слабоструктурированного prompt.
Поэтому working memory нужно проектировать как бюджет, а не как бездонную коробку.
Схема context assembly
Перед каждым LLM-вызовом агентский runtime собирает рабочий контекст. Упрощенно этот процесс выглядит так:
Эта схема показывает важную мысль: working memory не появляется сама. Ее нужно собрать. Для этого система фильтрует, сжимает, ранжирует и упорядочивает разные источники.
В хорошей сборке контекста есть порядок:
- Сначала фиксируются обязательные инструкции и политики.
- Затем добавляется текущая цель пользователя.
- Потом добавляется состояние текущей задачи.
- Затем выбираются релевантные наблюдения и результаты инструментов.
- После этого добавляется retrieved memory, если она нужна.
- В конце контекст упаковывается так, чтобы модель видела приоритеты и границы источников.
Приоритеты внутри рабочей памяти
Не все элементы контекста равны. Если в рабочую память попали конфликтующие фрагменты, агент должен понимать, какой источник важнее.
Типовая иерархия выглядит так:
| Приоритет | Источник | Пример |
|---|---|---|
| Высокий | System / safety / platform policies | Нельзя раскрывать приватные данные или выполнять опасные действия. |
| Высокий | Developer и project instructions | В этом репозитории не трогать intro/, писать Markdown на русском. |
| Средний | User request | "Напиши лекцию 2.1 по указанному файлу." |
| Средний | Active task state | Сейчас редактируется конкретный урок, TODO-файлы не обновляются без просьбы. |
| Средний | Tool results | Содержимое плана лекции, соседние файлы, git status. |
| Ниже | Retrieved examples и long-term memory | Предыдущие похожие решения, предпочтения, summaries. |
| Низкий | Старые сообщения и нерелевантная история | Давние детали, не влияющие на текущий шаг. |
Это не универсальный стандарт, а инженерная модель. В конкретной системе приоритеты должны быть явно описаны. Иначе LLM может одинаково серьезно отнестись к текущей политике безопасности и к случайной фразе из старого tool output.
Полезный и шумный контекст
Качество working memory определяется не объемом, а отношением сигнала к шуму.
Полезный контекст:
- напрямую связан с текущей целью;
- помогает выбрать следующее действие;
- содержит актуальные ограничения;
- имеет понятный источник;
- достаточно краток, чтобы не вытеснять более важные сведения;
- не конфликтует с более приоритетными инструкциями;
- представлен в форме, удобной для модели.
Шумный контекст:
- относится к другой задаче или другому scope;
- повторяет уже известную информацию без пользы;
- содержит устаревшие решения;
- слишком длинный и слабо структурированный;
- попал в prompt только потому, что был легко доступен;
- создает конфликт, который система не объяснила модели;
- похож на релевантный, но не помогает текущему шагу.
Пример:
| Ситуация | Полезно добавить | Лучше не добавлять |
|---|---|---|
| Агент пишет лекцию 2.1 | План урока, правила курса, переход из 1.3, требования к структуре. | Полные тексты всех 42 уроков. |
| Агент исправляет ошибку теста | Конкретный failing test, релевантный код, последние изменения. | Весь лог CI за неделю без фильтрации. |
| Агент отвечает пользователю о настройке продукта | Текущие настройки пользователя и актуальную документацию. | Старые обращения в support без связи с вопросом. |
| Агент вызывает API | Схему нужного endpoint, credentials policy, последний error response. | Полную OpenAPI-спецификацию, если нужен один метод. |
Результаты инструментов и наблюдения из среды
Tool-using agent постоянно получает новые наблюдения: вывод команд, содержимое файлов, ответы HTTP API, результаты поиска, ошибки, статусы задач. Эти наблюдения часто важнее старой памяти, потому что показывают текущее состояние среды.
Но tool results легко перегружают контекст. Один npm test может вернуть сотни строк. Один поиск по документации - десятки фрагментов. Один diff - тысячи строк. Если отправить все это в модель без отбора, working memory быстро станет шумной.
Практические приемы:
- добавлять только релевантный диапазон строк, а не весь файл;
- сжимать длинные логи до ошибки, stack trace и краткого summary;
- сохранять полный artifact вне контекста, а в prompt давать ссылку или выдержку;
- отделять наблюдения от интерпретации агента;
- явно помечать источник:
tool result,user message,retrieved memory,policy.
Для агента важно понимать разницу между "я видел это в tool output" и "я сделал из этого вывод". Первое является наблюдением, второе может быть гипотезой, которую нужно проверить.
Scratchpad, план и промежуточное состояние
В многошаговых задачах working memory часто включает рабочий план или промежуточное состояние. Это может быть список подзадач, текущий статус, открытые вопросы, выбранные файлы, результаты уже выполненных шагов.
Пример:
Goal: expand lesson_02_01_working_memory.md.
Known constraints:
- Russian Markdown lecture.
- Keep conceptual 101 level.
- Add context assembly schema.
- Do not update writing_todo unless asked.
Progress:
- Read skill instructions.
- Read lesson plan.
- Read transition from lesson 1.3.
Next:
- Replace plan with full lecture.
- Verify headings and git status.
Такой scratchpad полезен, пока задача активна. Но его нельзя слепо сохранять как долгосрочную память. После завершения работы большая часть промежуточных заметок устаревает.
Системы различаются в том, как используют scratchpad. Иногда это скрытое внутреннее состояние runtime. Иногда это явный plan в UI. Иногда это structured state, который не передается модели целиком, а используется orchestration layer.
Как собирать рабочую память
Хорошая сборка working memory обычно проходит несколько решений.
Сначала нужно определить текущую задачу. Что агент делает прямо сейчас: отвечает, планирует, вызывает инструмент, проверяет результат, пишет файл, принимает решение?
Затем нужно выбрать обязательные рамки: инструкции, политики, права доступа, требования проекта, ограничения пользователя.
После этого нужно добавить свежие наблюдения: последние сообщения, результаты инструментов, ошибки, изменения среды.
Затем можно подключить внешнюю память: факты, события, документы, процедуры или lessons learned, которые действительно помогают текущему шагу.
Наконец, контекст нужно упорядочить и сжать. Модель должна видеть не просто набор фрагментов, а структуру: что является задачей, что является правилом, что является фактом, что является результатом инструмента, а что является предположением.
Упрощенный шаблон:
1. Task
- What the user wants now.
2. Rules
- System/developer/project constraints.
3. Current state
- Active files, selected options, workflow progress.
4. Observations
- Relevant tool results and recent messages.
5. Retrieved memory
- Only records that affect this step.
6. Output expectation
- What the model should produce next.
Это не обязательный формат prompt. Это mental model для проектирования сборки контекста.
Лимиты и failure modes
Working memory ломается несколькими типичными способами.
| Failure mode | Что происходит | Как снижать риск |
|---|---|---|
| Переполнение контекста | В prompt не помещаются важные сведения или ответ. | Вводить context budget, фильтрацию и summaries. |
| Retrieval noise | В контекст попали похожие, но нерелевантные фрагменты. | Использовать reranking, scopes, freshness и явные критерии отбора. |
| Конфликт инструкций | Разные части prompt требуют разного поведения. | Явно задавать приоритеты и разделять источники. |
| Потеря фокуса | Модель начинает отвечать на побочную тему. | Держать текущую цель компактной и видимой. |
| Устаревший state | В рабочей памяти остался старый план или старое ограничение. | Обновлять state после каждого важного наблюдения. |
| Tool-output injection | В результате инструмента есть текст, похожий на инструкцию. | Помечать tool output как данные, а не команды к агенту. |
| Слишком сильное сжатие | Summary потеряло критичную деталь. | Сохранять ссылки на источники и проверять важные факты. |
Важно: многие проблемы working memory выглядят как "модель плохо рассуждает", хотя на самом деле модель получила плохой рабочий контекст.
Когда working memory достаточно
Не каждой системе нужна сложная долгосрочная память. Иногда достаточно аккуратной working memory.
Working memory может быть достаточной, если:
- задача короткая и завершается за один вызов;
- вся нужная информация уже есть в запросе пользователя;
- нет необходимости помнить пользователя между сессиями;
- нет долгого workflow с несколькими инструментами;
- нет персонализации, исторических решений или повторяемого опыта;
- риск ошибки от забывания низкий;
- данные чувствительные, и их лучше не сохранять.
Примеры:
- одноразовое объяснение термина;
- переписывание короткого абзаца;
- генерация черновика по полностью заданному brief;
- классификация одного сообщения;
- ответ на вопрос по документу, который пользователь приложил прямо сейчас.
В таких случаях добавление долгосрочной памяти может усложнить систему без пользы. Хорошая архитектура памяти начинается не с базы данных, а с честного вопроса: достаточно ли текущего контекста?
Когда working memory недостаточно
Working memory становится недостаточной, когда поведение агента должно зависеть от прошлого, которого нет в текущем prompt.
Признаки:
- пользователь ожидает, что агент помнит прошлые предпочтения;
- задача длится несколько сессий;
- нужно учитывать историю действий и ошибок;
- агент работает с инструментами и должен продолжать workflow;
- есть проектные или организационные правила, которые не помещаются целиком в prompt;
- нужно извлекать знания из большой базы документов;
- требуется audit trail или объяснение прошлых решений.
В этих случаях working memory остается центральной, но она становится только последним этапом: внешняя память хранит сведения, retrieval выбирает нужное, context assembly помещает это в текущее окно внимания.
Мини-кейс: working memory coding agent
Пользователь просит:
Исправь ошибку в тесте авторизации и проверь, что изменения не сломали login flow.
Плохая working memory:
- Полная история чата за месяц.
- Все файлы auth-модуля целиком.
- Полный лог CI.
- Несколько старых решений по unrelated OAuth-задачам.
- Текущий запрос пользователя где-то в середине prompt.
Такая сборка дорогая и шумная. Модель может потратить внимание на нерелевантные детали.
Более полезная working memory:
Task:
- Исправить failing auth test и проверить login flow.
Rules:
- Не добавлять зависимости без обсуждения.
- Сначала читать существующие паттерны проекта.
Current observations:
- Failing test: auth/session.test.ts, case "refreshes expired token".
- Error: expected 200, received 401.
- Recent diff touches token expiration parsing.
Relevant context:
- Auth service uses UTC timestamps.
- Previous similar bug was caused by local timezone conversion.
Next action:
- Inspect token expiration parsing and related test fixture.
Здесь рабочая память меньше, но полезнее. Она содержит цель, правила, свежие наблюдения, релевантный прошлый факт и следующий шаг.
Практические правила проектирования
Для working memory удобно держать несколько правил.
Первое: каждый фрагмент контекста должен иметь работу. Если он не помогает текущему шагу, его место не в prompt.
Второе: свежие наблюдения часто важнее старых summaries. Если tool result показывает текущее состояние файла, не надо полагаться только на прошлую память о нем.
Третье: внешняя память должна входить в контекст дозированно. Лучше несколько релевантных records с источниками, чем десятки похожих фрагментов.
Четвертое: структурируйте prompt. Разделы Task, Rules, Current state, Observations, Relevant memory, Expected output уменьшают риск смешивания ролей.
Пятое: не превращайте working memory в архив. Архивы, логи и базы знаний должны жить вне prompt, а в рабочий контекст попадать через selection и compression.
Типичные ошибки
Ошибка 1: считать context window долговременной памятью.
Context window существует для текущего вызова. Если важный факт должен пережить шаг или сессию, его нужно записывать во внешний слой памяти.
Ошибка 2: добавлять в prompt все retrieved chunks.
Retrieval - это не финальный ответ. Найденные фрагменты нужно фильтровать, ранжировать и проверять на соответствие текущей задаче.
Ошибка 3: держать в контексте старый план.
План полезен только пока отражает реальное состояние. После tool results его нужно обновлять, иначе агент будет действовать по устаревшей карте.
Ошибка 4: смешивать данные и инструкции.
Tool output, веб-страница или документ могут содержать текст в повелительном наклонении. Для агента это данные, а не правила поведения.
Ошибка 5: экономить на структуре.
Даже короткий контекст может быть плохим, если модель не понимает, где задача, где правила, где источник, а где пример.
Краткое резюме
Working memory - это текущее окно внимания агента. В LLM-системах она обычно выражается через содержимое context window, но проектируется на уровне agent runtime и context assembly.
Рабочая память должна быть компактной, релевантной и структурированной. В нее входят инструкции, текущий запрос, последние наблюдения, результаты инструментов, активный state, scratchpad и выбранные фрагменты внешней памяти.
Большой контекст не равен хорошей памяти. Чем больше prompt, тем выше стоимость, latency и риск шума. Хороший агент умеет не только вспоминать, но и не класть лишнее в текущее окно внимания.
Вопросы для самопроверки
- Почему working memory нельзя считать долговременным архивом агента?
- Какие источники обычно участвуют в
context assembly? - Чем полезный контекст отличается от шумного?
- Почему tool results нужно фильтровать или сжимать перед добавлением в prompt?
- В каких задачах working memory может быть достаточной без внешнего хранилища?
Что дальше
В следующей лекции мы разберем Conversation и Session Memory: как агент удерживает нить текущего диалога, чем sliding window отличается от rolling summary, зачем нужен session state и почему сессионные данные не должны автоматически превращаться в долгосрочный профиль пользователя.