Иерархия контекста: система уровней знаний для ИИ-агентов

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

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

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

Название иерархии

Единого общепринятого термина в отрасли не существует, поэтому определение здесь даётся явно. Иерархия знаний — это стратифицированное расположение того, что знает агент, где каждый слой различается по трём свойствам: как он входит в контекст модели, каков допустимый для него размер и как долго от него ожидается корректность. На уровне архитектуры знаний смежные парадигмы — PKM, RAG, вики и системы памяти — сравниваются в статье PKM против RAG против Вики против Систем Памяти, а рантайм-контракты, которые реализуют помощники на практике, описаны в Системы памяти в ИИ-помощниках. Обе входят в кластер Управление знаниями, который покрывает основы, методы и инструменты человеческих систем знаний. Эта статья добавляет классификацию на основе триггеров и границу профиля, которая делает размещение принудительным.

Две традиции объясняют форму иерархии.

Первая — иерархия памяти процессора (CPU). Процессор не хранит каждый байт, который может когда-либо понадобиться, в одном регистре. У него есть кэш L1 — маленький, постоянно резидентный, доступный без принятия решений —, кэш L2, основная память и диск, каждый слой больше, медленнее для доступа и задействуется только тогда, когда более верхние слои не содержат ответа. Правило проектирования гласит не «держи всё быстрым». Оно гласит: большинство данных редко имеют значение; платите за стоимость доступа только тогда, когда они нужны. Агент с одним плоским файлом памяти — это CPU, в который всё впихнуто в L1: файл регистров огромен, поэтому всё видно, включая те байты, которые текущая инструкция не запрашивала. MemGPT сделал то же самое для агентов, моделируя память как уровни с явным перемещением между быстрыми и медленными хранилищами.

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

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

• Всегда. Вводится в каждый ход, безусловно.
• Триггер задачи. Загружается, когда текущая активность совпадает с объявленным условием.
• Семантическое вспоминание. Появляется, когда текущее сообщение похоже на что-то сохранённое.
• Явная ссылка. Извлекается, потому что задача называет файл или запрос.

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

Пять слоёв

Читайте таблицу вдоль колонки триггеров, а не поперёк. Слой 0 и Слой 1 — это кэш L1: они платят за привилегию постоянного резидентства тем, что крошечны. Слой 2 — это кэш инструкций: вызывается по условию ветвления, когда задача совпадает с триггером навыка. Слой 3 — это диск: он может быть огромным, потому что ничего не входит в контекст, пока шаг задачи явно не прочитает именованный файл. Слой 4 — неловкий; это основная память, доступная по сходству, что является единственным триггером в списке, не связанным с решением, принятым вами или задачей. Сходство — вероятностный шлюз, и именно поэтому ему требуются самые строгие внешние контроли, которые предоставляет раздел о профилях. Изображение шкафа в начале этой статьи кодирует ту же идею: чем выше расположен уровень, тем свободнее его содержимое входит в беседу, а стеклянная перегородка отмечает, где заканчивается полка одной доменной области.

Слой 0: личность

SOUL.md, или как бы ваш агент назвал свой системный промпт. Его задача — определить кто, а не что: тон, ценности, границы отказа и политику памяти. Политика памяти находится здесь, потому что это единственная инструкция, которая должна действовать до любого обращения к памяти. Файл личности, начинающий перечислять имена серверов, имена клиентов или ставки, уже потерпел неудачу — он стал содержимым Слоя 1 в бейдже Слоя 0, и теперь въезжает в каждую беседу, включая те, где его не должно быть.

Слой 1: резидентная память

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

Первое: указатели, а не факты. Если факт служит только одной доменной области, он не принадлежит здесь. Верная запись — не сам факт, а указатель:

Инфраструктурные факты: wiki/infra/ + банк памяти 'homelab'.
Клиенты и контракты: wiki/business/clients/ + банк 'business'.

Указатель доменно-нейтрален, поэтому безопасно носить его везде. Факт, на который он указывает, загружается только той активностью, которая назвала назначение.

Второе: жёсткий бюджет, обеспеченный. Если у хранилища нет лимита символов, оно наполнится, и наполнится всегда тем, о чём говорилось в последнюю очередь — поэтому неделя по инфраструктуре тихо вытесняет или окружает общий контекст инфраструктурой. Бюджет, почти полностью занятый, заставляет осуществлять триаж, а триаж — единственный механизм, который сохраняет этот слой честным. Реализация Hermes — рабочий пример: MEMORY.md с лимитом в 2 200 символов и USER.md в 1 375, внедряемые как замороженный блок в начале сессии, описаны в Система памяти агента Hermes.

Слой 2: процедурные знания

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

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

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

Слой 3: справочные данные

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

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

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

Слой 4: извлекаемая память

Бэкенд памяти с автоматическим извлечением на каждый ход: эпизодическая и реляционная память агента. Решения и их даты, «клиент X подтвердил Y», «мы попробовали Z, и это не сработало». Здесь живёт динамическая, самоорганизующаяся часть системы — и здесь становится интересной история безопасности, потому что семантическое вспоминание — вероятностный шлюз, а вероятностные шлюзы пропускают.

«Вопрос о биллинге для клиента X» и «какой хост запускает сервер биллинга» близки в пространстве эмбеддингов. Любой одиночный банк, содержащий и записи клиентов, и инвентаризацию инфраструктуры, с ненулевой вероятностью поднимет второе в контексте первого. Вы можете сузить это тегами и ограничениями извлечения, и вам стоит — но теговый фильтр на смешанном корпусе — это дисциплина, а не структура. Структурный ответ — прекратить смешивать: один банк на доменную область, так что радиус утечки извлечения, по построению, равен одной доменной области. Выбор самого бэкенда — политика захвата, зависимости, ограничения self-hosting — это отдельное сравнение, описанное в [Сравнение провайдеров памяти для агентов](https://www.glukhov.org/ru/ai-systems/memory/agent-memory-providers/ “Сравнение бэкендов памяти Hermes и OpenClaw по политике захвата, зависимостям и self-hosting.”}).

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

Профили: граница, делающая разделение структурным

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

Механизм для разделения доменных областей — профиль — полная, независимая инстанция агента: его собственный файл личности, собственная резидентная память, собственная директория навыков, собственные запланированные задачи и, что решающе, собственная проводка банков памяти. Профиль — не тег на беседу; это отдельная система, которая просто разделяет машину. Когда вы запускаете agent -p homelab, вы получаете процесс, чей весь путь от Слоя 0 до Слоя 4 ограничен доменной областью homelab, и чей пул извлечения не может содержать бизнес-банк, потому что бизнес-банка в его конфигурации вообще нет.

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

Практический пример, пять доменных областей:

Две ячейки в этой таблице делают основную работу.

Строка банка общего профиля — «нет, только чтение». Общая беседа — это там, где вы задаете сквозные вопросы, поэтому она должна видеть извлечённые факты каждой доменной области — но не писать ни в одну из них. Гляделки в общей сессии — это ровно тот материал, который вы не хотите, чтобы он был извлечён в долговременную память домена, и проводка «только чтение» полностью убирает выбор у модели. Если проводка бэкенда поддерживает списки банков только для извлечения (отдельные от банков записи), это одна строка конфигурации на каждый доменный банк; если нет, общий профиль извлекает из выделенного общего банка, и вы принимаете более слабый междоменный вид.

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

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

• Триггер становится интерфейсом. Если работа с homelab происходит в терминале, который вы запускаете с -p homelab, а работа с клиентами — на учётной записи мессенджера, маршрутизируемой в рабочий профиль, то какая «шляпа» на вас — свойство того, как вы запустили агента, а не флаг, который вы помните объявить. Ненаправление — случайный запуск клиентских задач в контексте homelab — становится таким же видимым, как запуск неверного шелла.
• Запланированные работы наследуют границу. Cron-задачи и делегированные подзадачи выполняются внутри того профиля, которому они принадлежат. Ночная инфраструктурная проверка, запланированная в homelab-профиле, не может сместить бизнес-контент в homelab-банк, потому что никогда не имеет его.
• Файловая система общая, и это честный лимит. Профили разделяют контекст, а не доступ. Терминал любого профиля может читать файлы любого профиля; граница защищает беседы, а не диски. Поэтому слои, содержащие действительно чувствительный материал, нуждаются в собственной дисциплине: учётные данные в файле окружения или хранилище секретов, а не в открытом тексте вики, вики вне любого публичного репозитория, и права на директории там, где ОС помогает. Рассматривайте границу профиля как файрвол для контекста — отличный в своей работе — и не позволяйте путать его с файрволом для данных.

Развёртывание из плоской горы

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

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

Второе, ограничьте Слой 1. Установите лимит символов на резидентные файлы, затем проведите аудит того, что уже в них, по лимиту. Доменно-специфичные факты становятся указателями на то, где они будут жить; остаётся то, что действительно применимо к каждой сессии.

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

Где иерархия гниёт

Архитектура настолько хороша, насколько хороше её обслуживание, и каждый слой гниёт характерным образом.

Слой 1 наполняется первым. Это слой с самым удобным путём записи («просто запомни это»), поэтому он первым начинает накапливать доменные факты в замаскированном виде. Бюджет делает это видимым: когда хранилище на 90% заполнено, проведите аудит записей, которые должны стать указателями. Исправление всегда одно и то же движение — понизить факты до Слоя 3, продвинуть указатель.

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

Слой 4 дрейфует молча. Извлекаемая память ориентирована на добавление и самоочевидна, поэтому устаревшие эпизоды никогда не корректируются, только переживаются. Преамбула извлечения («эти воспоминания — исторический контекст, а не проверенные факты») — стандартная митигация. Более чистая митигация — та же, что использует Слой 3: когда эпизод становится длительным фактом («клиент подписался в эту дату на этих условиях»), он записывается в систему записи, где он видим и редактируем, и банк хранит только повествование. Более острые варианты этого дрейфа — собственная инференция агента, написанная обратно как доказательство — разобраны в Самовоспроизводящиеся петли памяти в ИИ-агентах.

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

Итог: одно правило размещения

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

Плоская гора никогда не была провалом дисциплины. Это была архитектура, где каждый факт делит один триггер, и этот триггер — «всегда». Разбейте триггер, и утечки перестанут быть вопросом суждения модели. Они станут невозможными.

Ссылки

• PKM против RAG против Вики против Систем Памяти — фундаментальное сравнение личных хранилищ знаний, конвейеров извлечения и агентской памяти
• Системы памяти в ИИ-помощниках — стек рантайм-памяти, внутри которого сидит эта иерархия
• Извлечение против Представления в Системах Знаний — почему форма вашего хранилища определяет, что оно может ответить
• Центр памяти ИИ-систем