Урок 5.3. Memory-as-an-OS: виртуализация контекста

Цель лекции

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

Ожидаемый результат

Читатель понимает OS-style подход к памяти: как context window становится аналогом RAM, external memory - аналогом disk, а memory layer отвечает за paging, read/write cycles, interrupts, eviction и discipline контекста.

Зачем это нужно

У LLM есть ограниченное context window. Даже если окно большое, оно не бесконечно и не бесплатно. В него нельзя постоянно складывать всю историю, все документы, все факты и все tool logs.

Значит, агент должен управлять контекстом.

Аналогия с операционной системой помогает:

RAM ограничена;
disk больше, но медленнее;
нужные страницы подкачиваются;
лишнее выгружается;
есть read/write operations;
есть cache;
есть policies eviction;
есть состояние процесса;
есть системные вызовы.

В агентской системе:

context window похож на RAM;
memory stores похожи на disk;
retrieval похож на paging;
context assembly похож на загрузку страниц в память;
summarization похожа на compaction;
forgetting похож на eviction или deletion;
tool calls к memory layer похожи на system calls.

Memory-as-an-OS делает управление контекстом явной архитектурной дисциплиной.

Основная идея

Модель работает с ограниченной "RAM", а memory layer подкачивает нужные данные из внешнего хранилища и выгружает лишние.

В простом RAG-паттерне агент ищет документы под вопрос. В OS-style паттерне агент живет дольше и активнее управляет своей памятью:

решает, что держать в active context;
запрашивает память через read operations;
записывает новые факты через write operations;
обновляет summaries;
переносит данные между hot/warm/cold слоями;
следит за context pressure;
использует deterministic memory tools;
может восстанавливать состояние после паузы.

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

Ключевые термины

Термин	Короткое определение
`Memory-as-an-OS`	Паттерн, где memory layer управляет контекстом как ОС управляет памятью процесса.
`Virtual context`	Логически большой контекст, физически представленный малым context window и внешней памятью.
`Context paging`	Подкачка релевантных memory blocks в prompt.
`Eviction`	Удаление или demotion блоков из active context.
`Memory interrupt`	Сигнал, что агенту нужно прочитать, записать или обновить память.
`Read cycle`	Управляемое обращение к memory layer за нужным контекстом.
`Write cycle`	Управляемая запись наблюдений, фактов или summaries.
`Working set`	Набор memory blocks, нужных для текущей задачи.
`Page fault`	Ситуация, когда нужного контекста нет в prompt и его нужно retrieve.
`Compaction`	Сжатие истории или состояния для экономии context window.

Аналогия: RAM и disk

Computer OS:
  RAM -> fast, small, active
  Disk -> slower, large, persistent
  Paging -> move pages between RAM and disk

Agent memory:
  Context window -> fast, small, active
  Memory stores -> slower, large, persistent
  Retrieval/context assembly -> move memory blocks into context

Аналогия полезна, но не буквальна.

ОС работает с deterministic bytes и pages. Агент работает с текстом, embeddings, summaries, facts, uncertain records и policies. Поэтому paging в agent memory не может быть полностью механическим: нужно учитывать meaning, source, confidence, permissions и current goal.

Схема Memory-as-an-OS

flowchart TD U[User task] --> A[Agent process] A --> C[Context window / RAM] A --> M[Memory manager] M --> R[Read memory] M --> W[Write memory] M --> E[Evict / summarize] R --> S[(External memory stores)] W --> S E --> S S --> V[Vector / search / graph / logs / files] R --> C C --> L[LLM reasoning] L --> A

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

Context paging

Context paging - подкачка нужных memory blocks в context window.

Пример:

Current task:
- Fix bug in discount calculation.

Current context lacks:
- Previous pricing incident.
- Pricing workflow rule.
- ADR about tax order.

Page in:
- Reflection about invoice totals failures.
- Procedure for pricing changes.
- Relevant ADR excerpt.

Paging может срабатывать:

перед planning;
перед tool call;
после error;
при смене subtask;
при упоминании entity;
когда модель обнаруживает missing context;
при high-risk decision.

Хороший paging не тащит весь архив. Он подкачивает working set для текущего шага.

Memory interrupts

Memory interrupt - момент, когда агент должен обратиться к памяти.

Сигналы:

пользователь говорит "как в прошлый раз";
задача относится к known project;
возникла ошибка, похожая на прошлую;
нужно проверить policy;
tool result противоречит памяти;
context window заполнено;
task переходит в новый phase;
агент готов завершить задачу и должен записать summary.

Пример interrupt:

Agent observes:
"invoice_totals.test.ts failed"

Memory interrupt:
Search prior episodes and reflections for invoice_totals.test.ts.

Interrupts делают memory access явным. Агент не должен случайно вспоминать всё в каждом шаге, но и не должен забывать обратиться к памяти в критичный момент.

Deterministic read/write cycles

OS-style подход часто требует явных cycles:

1. Read current task memory.
2. Plan.
3. Act.
4. Observe result.
5. Write important event.
6. Update summary.
7. Evict stale context.

Плюсы deterministic cycles:

легче тестировать;
меньше случайного retrieval;
понятнее audit trail;
можно задавать policies;
проще контролировать latency;
легче отлаживать memory failures.

Минусы:

может быть менее гибко;
больше orchestration;
требуется quality of memory tools;
bad policy может системно повторять ошибки.

В зрелых агентских системах memory read/write часто становится частью loop, а не произвольным поведением модели.

Working set

Working set - минимальный набор контекста, нужный для текущей фазы задачи.

Для writing task:

Working set:
- target lesson plan
- adjacent lesson style
- course conventions
- user final-answer preference

Для debugging task:

Working set:
- failing test
- changed files
- relevant procedures
- recent related failures
- source of truth docs

Working set меняется. То, что нужно для planning, может быть лишним для final response. OS-style memory должна уметь пересобирать working set между фазами.

Eviction и compaction

Context window нужно очищать.

Eviction может убрать:

старые tool outputs;
уже использованные chunks;
дублирующие facts;
низко-confidence hypotheses;
завершенные subtask notes;
details, replaced by summary;
irrelevant branch context.

Compaction заменяет длинные данные коротким summary.

Пример:

Before:
- 40 messages of debugging attempts.

After compaction:
- Tried A and B; both failed.
- Current hypothesis: issue in rounding after discount.
- Next step: inspect invoice_totals expected values.

Eviction не должен удалять важные records из long-term memory. Он убирает их из active context или demotes в более холодный слой.

MemGPT и Letta как семейство идей

В research и open-source ecosystem идеи вроде MemGPT/Letta популяризировали OS-style подход: агент управляет ограниченным context window, вызывает memory operations, переносит данные между active context и external memory, поддерживает long-running state.

Для этого курса важна не конкретная реализация, а mental model:

context window ограничен;
память должна быть виртуализирована;
агенту нужны explicit read/write tools;
memory manager должен решать, что держать active;
summaries и external stores расширяют effective context;
retrieval failures становятся похожи на page faults.

Этот подход не нужен каждому чат-боту, но полезен для долгоживущих agents.

Плюсы OS-style подхода

Плюсы:

управляемость context window;
масштабирование за пределы prompt;
clear memory operations;
better auditability;
возможность long-running tasks;
явная политика read/write;
удобство checkpointing;
better separation of active vs stored memory.

Особенно полезно, когда агент:

работает долго;
выполняет много tool calls;
возвращается к старым задачам;
должен сохранять state;
должен объяснять, почему вспомнил запись;
ограничен context budget;
работает с большим corpus.

Минусы и риски

Минусы:

архитектурная сложность;
дополнительная latency;
ошибки retrieval становятся критичными;
bad eviction может убрать нужный контекст;
bad promotion может перегрузить prompt;
нужны robust memory tools;
труднее тестировать end-to-end;
могут появиться loops чтения/записи памяти.

OS-style memory может выглядеть elegant, но она увеличивает количество moving parts. Для простых задач это overkill.

Мини-кейс: long coding task

Задача:

Refactor pricing module and keep invoice totals stable.

OS-style loop:

Read:
- project pricing conventions
- previous invoice failures
- relevant ADR
- test workflow

Act:
- inspect files
- make patch
- run tests

Observe:
- invoice_totals.test.ts failed

Memory interrupt:
- retrieve prior reflections about invoice totals

Write:
- event: test failed after patch
- update task summary

Evict:
- old raw test output replaced by short failure summary

Так агент не держит весь репозиторий и всю историю в prompt. Он подкачивает нужный контекст на каждом этапе.

Мини-кейс: research agent

Research task:

Find current API behavior and summarize changes since last version.

Working set phases:

Planning:
- research question
- source policy
- freshness requirements

Source search:
- official docs
- changelog
- migration guide

Comparison:
- previous version summary
- current version snippets

Final answer:
- verified changes
- citations
- caveats

OS-style memory помогает не держать все sources в context одновременно. Агент подкачивает snippets, compact findings и сохраняет citations.

Когда использовать

Memory-as-an-OS подходит, если:

agent long-running;
context pressure постоянный;
задачи многошаговые;
memory read/write должны быть audit-friendly;
есть разные storage tiers;
нужен explicit state management;
retrieval и compaction можно тестировать;
стоимость context window значима.

Не стоит использовать, если:

задачи короткие;
no long-term continuity;
один prompt полностью покрывает контекст;
команда еще не понимает basic write/retrieval policy;
latency критична;
system complexity важнее autonomy.

Типичные ошибки

Ошибка 1: воспринимать OS analogy буквально.

Agent memory работает с meaning и uncertainty, а не с байтами.

Ошибка 2: делать paging слишком частым.

Каждый read увеличивает latency и может добавить шум.

Ошибка 3: не тестировать eviction.

Если evict убрать важный constraint, агент сломает задачу.

Ошибка 4: не различать active context и persistent memory.

Удаление из prompt не равно forgetting.

Ошибка 5: использовать OS-style подход без good retrieval.

Если paging достает плохие blocks, вся архитектура становится хрупкой.

Ошибка 6: забывать про permissions.

Memory manager должен соблюдать scope при read/write.

Ошибка 7: применять паттерн слишком рано.

Для простого assistant OS-style orchestration может быть лишней сложностью.

Краткое резюме

Memory-as-an-OS - паттерн, где memory layer управляет ограниченным context window как операционная система управляет RAM и disk: подкачивает нужные memory blocks, выгружает лишние, сжимает историю, поддерживает read/write cycles и реагирует на memory interrupts.

Этот подход помогает долгоживущим агентам работать с контекстом больше prompt. Но он требует качественного retrieval, eviction policy, scopes, auditability и контроля latency.

Вопросы для самопроверки

В чем полезна аналогия context window с RAM?
Что такое context paging?
Какие события могут быть memory interrupts?
Чем eviction из context отличается от forgetting?
Почему OS-style подход может быть overkill для простых задач?

Что дальше

В следующей лекции мы перейдем к Hybrid Vector-Graph Memory: как объединять semantic similarity, exact search и строгие связи между сущностями.