Опубликовано 2026-11-07

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

Статья охватывает пять направлений: окно контекста, встроенные файлы контекста, внешнюю память через Honcho, работу с знаниями на основе файлов через LLM-вики в Obsidian и методы сокращения напрасных потерь контекста.

Типы контекста вкратце

Контекстное окно

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

Hermes отображает использование контекста внизу интерфейса. В примере использовалось 27,9 тысячи из 500 000 токенов, или 6 процентов. Нажатие на индикатор использования открывает само контекстное окно. Индикатор контекста можно включить, щёлкнув правой кнопкой мыши по полосе использования.

Контекстное окно содержит пять категорий содержимого:

• Системный промпт
• Определения инструментов
• Определения субагентов
• Память
• Диалог

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

Ввод /compress сжимает контекст диалога. Это уменьшает количество токенов в окне, и агент создаёт сводку диалога.

Встроенный контекст

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

Системный промпт и идентичность: soul.md

Системный промпт включает в себя харнесс, то есть структуру агента. В данном примере харнессом является Hermes. Другие харнессы, упомянутые в источнике, включают Claude Code, Codex, Antigravity, Grokbot и OpenClaw. У каждого харнесса есть свой системный промпт.

Системный промпт также включает в себя идентичность агента, которая определяется в soul.md. Каждый профиль на шлюзе, который докладчик описывает как эквивалент бота в режиме бота, имеет собственный soul.md. Файл soul.md по умолчанию загружается в каждый новый чат. Каждый профиль может иметь разную «душу», которая определяет его личность и роль.

Докладчик настроил «душу» агента-исследователя. Файл включает протокол исследования, миссию и инструкции по работе с агентом-библиотекарем и агентом-оркестратором.

Инструкции проекта: agents.md

agents.md содержит инструкции для конкретного проекта или агента. Докладчик описывает его как бриф проекта или конституцию агента.

У каждого харнесса есть свой тип файла, например hermes.md или claude.md. agents.md — это открытый формат, который понимают все агенты в примере. Докладчик рекомендует его использовать, если только не существует особой причины применять файл, специфичный для харнесса. Его загрузка зависит от расположения. Файл, привязанный к конкретному проекту, может загружаться только тогда, когда пользователь работает в этом проекте.

Предпочтения и долговременная память: user.md и memory.md

В настройках, в разделе памяти и контекста, включена постоянная память. Hermes использует два файла для своей встроенной памяти:

• memory.md хранит долговременные воспоминания и состояние проектов. Докладчик описывает его как небольшой блокнот для агента.
• user.md ведёт профиль предпочтений пользователя.

Можно задать бюджет, ограничивающий объём контекста, который занимают эти файлы.

В примере user.md зафиксировано, что пользователь ценит приватность и прозрачность и что агент должен объяснять, когда содержимое локальных файлов, доступных инструментам, может покинуть систему. В примере memory.md записано, что профиль по умолчанию использует бэкенд Docker, и приведены инструкции по запуску агента в Docker. Docker изолирует агента и ограничивает его доступ. Докладчик рассматривает Docker в отдельном обучающем материале.

Файлы soul, agents.md, user.md и memory.md загружаются в каждый чат. Их краткость уменьшает окно контекста, доступное для каждого разговора.

Встроенный плагин памяти: Memory Wiki

Официальный плагин Memory Wiki от Nous Research устанавливается в разделе capabilities and plugins. Он добавляет вкладку Memory Wiki. Memory Wiki извлекает информацию из сессий пользователя. Он не предполагает вики, генерируемую LLM. Плагин предоставляет:

• Темы, извлечённые из сессий
• Ежедневные журналы активности в сессиях
• Сводку недавних сессий
• Просмотр memory.md и user.md
• Фрагменты сессий, привязанные к конкретным темам

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

Инструменты и навыки

Инструменты добавляют определения инструментов в контекст. Чем больше инструментов загружено, тем больше определений должен хранить контекст. В примере определения инструментов занимали 9 000 токенов. Инструменты, которые агенту не нужны, можно отключить. Инструмент Kanban был отключён для агента в примере.

Инструмент делегирования задач позволяет родительскому агенту передавать работу субагентам. Определения субагентов занимают 1 200 токенов. Отключение делегирования задач убирает эти токены из начального контекста.

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

Внешняя память: Honcho

Встроенная память находится внутри окна контекста. Провайдеры внешней памяти работают за его пределами, во время выполнения. Агент сохраняет данные сеанса во внешнем хранилище и извлекает их при необходимости. Hermes перечисляет провайдеров внешней памяти в разделе плагинов. Среди вариантов, названных в источнике, есть Hindsight, Nemesis и Hanzo. Ведущий ранее рассказывал о Nemesis и Hindsight в отдельном видео.

Ведущий сосредоточен на Honcho. По словам ведущего, Hindsight строит граф знаний и систему сущностей, которая связывает факты между проектами. Honcho строит stateful-модель того, как люди, агенты и группы меняются со временем.

Как работает Honcho

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

Система использует структуру из рабочих пространств, сеансов и участников (peers). Сообщения, отправленные агенту, поступают в Honcho. Honcho анализирует сообщения, решает, что сохранить, и формирует выводы (insights). Эти выводы возвращаются в последующих взаимодействиях.

Honcho добавляет к встроенной памяти Hermes три возможности:

1. Внедрение контекста на этапе запроса: контекст загружается только при необходимости.
2. Непрерывность между сеансами: предпочтения, история продуктов и рабочий контекст переносятся из сеанса в сеанс.
3. Долговременная запись обратно: новая информация, полученная в разговоре, записывается обратно в систему.

Ведущий приводит экономию токенов в размере от 60 до 90 процентов при использовании Honcho, поскольку внешний провайдер сокращает объём контекста, который необходимо загрузить.

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

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

Порядок настройки

Следующие шаги настраивают Honcho в Hermes и основаны на демонстрации ведущего:

1. Откройте capabilities, затем plugins, и выберите Honcho. Нажмите install. Плагин устанавливается только для текущего бота или профиля.
2. Откройте settings, затем memory and context. В разделе memory provider выберите Honcho.
3. Выберите облачный вариант развёртывания.
4. Войдите в Honcho. В разделе explore создайте рабочее пространство. Пример рабочего пространства называется wanderlust-tutorials.
5. Откройте API keys и создайте новый ключ. Ограничьте его область действия рабочим пространством. Скопируйте ключ.
6. В Hermes вставьте API-ключ. Оставьте base URL пустым и сохраните облачную настройку.
7. Введите имя пользователя-участника, в примере это Callum. Введите имя ИИ-участника, в примере это Waterloo Tutorials. Оставьте стратегию сеанса по умолчанию или измените её при необходимости.
8. Для одного пользователя, который не делит профиль, закрепите пользовательского участника (pin). Закрепление сохраняет имя пользователя стабильным при смене профилей.
9. Перезапустите gateway. Ведущему пришлось перезапустить gateway, чтобы плагин Honcho настроился корректно.

Запуск нового сеанса подтверждает подключение. Агент ответил после подключения к Honcho.

Проверка памяти между агентами

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

Чтобы проверить, передаётся ли память между агентами, ведущий выполнил следующие шаги:

1. Создал новый профиль без конфигурации. Профиль был пустым.
2. Спросил нового агента: «Кто я?» Агент ответил, что не знает имени и личности пользователя. В ответе отмечалось, что аккаунт, видимый в сеансе, называется «wanderlust», но агент не может подтвердить, что именно так пользователь себя называл.
3. Создал новый API-ключ с датой истечения срока действия и скопировал его.
4. Установил Honcho для нового профиля, перезапустил десктоп и выбрал Honcho в качестве провайдера памяти в настройках.
5. Применил новый API-ключ, задал то же рабочее пространство и имена участников, закрепил пользовательского участника, сохранил изменения и перезапустил gateway.
6. Установил стратегию сеанса «per directory», которая сопоставляет разговоры с папкой. Ведущий указал папку wanderlust-tutorials. Другие варианты: per repository, per session или global.
7. Снова спросил: «Кто я?»

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

Знания о файловой системе: LLM Wiki в Obsidian

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

Загрузка всего хранилища в каждый диалог увеличила бы контекст. Вместо этого агент ищет в хранилище заметки, относящиеся к конкретной задаче.

Многоагентный процесс

Пример процесса использует отдельных агентов с определёнными ролями:

• Агент исследователь создаёт предлагаемые файлы.
• Агент библиотекарь получает предложение в виде передачи контекста. Библиотекарь решает, войдёт ли материал в общую wiki.
• Агент оркестратор координирует профили.

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

Со временем утверждённые заметки образуют LLM Wiki, то есть постоянный, структурированный и взаимосвязанный слой знаний, которым могут пользоваться совместно инструменты ИИ. Докладчик поддерживает wiki с помощью агентного библиотекаря. Процесс включает следующие этапы:

1. Собираются исходные материалы, например статьи.
2. Исходные материалы проверяются и превращаются в предложения.
3. Утверждённые предложения попадают в хранилище как структурированные знания, связанные с остальной системой знаний.

Пример поиска

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

Агент загрузил навык обоснования и цитирования, навык проверки LLM Wiki и навык wiki. Затем он прочитал соответствующие заметки. Согласно его ответу, существующая wiki охватывает базовую безопасность, уровни доверия, контролируемую запись и недоверенный поиск. В ответе основной возможностью названо исследование того, как эти механизмы защиты работают в системе обучения «человек — ИИ». Ключевые вопросы касались того, могут ли люди создавать и пересматривать знания вместе с агентом, не принимая загрязнённые знания и не будучи перегруженными решениями по безопасности.

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

Ответ включал предлагаемый порядок заполнения пробелов в wiki. Докладчик заявил, что цель состоит в повышении качества и надёжности знаний, создаваемых совместно с ИИ.

Оптимизация контекста

Оптимизация устраняет потери на каждом уровне контекста. Были описаны четыре метода.

1. Контролируйте, что попадает в контекст

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

• Отключайте инструменты, которые задача не требует.
• Уменьшайте размер soul.md, если он слишком большой.
• Держите memory.md и user.md короткими, когда память обрабатывается внешней системой памяти.
• Переносите содержимое этих файлов в заметки Obsidian. Затем soul может ссылаться на хранилище и направлять агента к нему за внешней информацией.

2. Управляйте временем сжатия

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

3. Передавайте контекст между моделями и чатами

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

Более эффективный метод — попросить агента создать два результата:

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

Следующий чат читает только те части документа, которые ему нужны. Этот метод сокращает объём контекста, необходимый для того, чтобы ввести нового агента в курс дела. Метод становится более ценным по мере роста диалогов. Докладчик предлагает, чтобы агент итеративно обновлял документ передачи контекста на протяжении длительного проекта, например, после 50 или 100 чатов.

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

4. Настройте вспомогательные модели и движки сжатия

Для сжатия используется модель. В настройках, в разделе вспомогательных моделей, модель сжатия можно изменить по умолчанию, которое установлено как main. Другая модель может снизить стоимость сжатия.

В разделе памяти и контекста секция сжатия контекста перечисляет альтернативные движки контекста. Некоторые пользователи создали собственные компрессоры. Докладчик их не тестировал. Докладчик также рассказал об автоматическом переключении моделей в отдельном видео о маршрутизации моделей.