Наши публикации

Как дать агенту память и не превратить рабочую модель в журнал его мыслей

2026-08-11 14:43
Большая часть современных агентов живёт одну сессию. Пока открыт диалог, агент помнит поставленную задачу, найденные факты, проверенные гипотезы и причины принятых решений. В следующем диалоге всё это приходится объяснять заново — либо надеяться, что автоматическая история чата случайно вернёт в контекст именно то, что нужно.
Обычно эту проблему пытаются решить одним из двух способов. Агенту либо передают всё больше документов и переписок, либо разрешают записывать всё найденное прямо в рабочую систему: в карточки Jira, страницы базы знаний или объекты предметной модели. Первый способ быстро съедает контекст, второй превращает пространство, в котором работают люди, в журнал технической жизни агентов.
В Онто эти слои можно разделить. Видимая модель хранит состояние предметной области: задачи, требования, компоненты, оборудование, решения, людей и связи между ними. Агентская память находится рядом с этими объектами и привязана к ним, но не появляется автоматически на обычных диаграммах, в списках объектов и экспортах. При этом она не является тайной памятью конкретной модели: человек может её прочитать и проверить, а другой агент — восстановить по ней работу в новой сессии.

Где такое разделение полезно

1. Разработка: почему нельзя сложить всю память агента в Jira

В карточке Jira человеку нужны актуальная постановка, критерии приёмки, приоритет, ответственные и итог работы. Агенту для продолжения задачи требуется гораздо больше: какие файлы он уже изучил, какие гипотезы проверил, почему отказался от первого варианта, какие тесты упали и на каком месте остановилась предыдущая сессия. Если всё это записывать в карточку, через несколько итераций главное утонет в машинных логах и промежуточных рассуждениях. Если сохранять только итог, следующий агент повторит половину исследования и, возможно, снова придёт к уже отвергнутому решению.
В Онто задача остаётся обычным видимым объектом. К ней можно привязать журнал работы, стратегию тестирования, протокол ревью и handoff для следующего исполнителя. Люди продолжают видеть понятное состояние задачи, а агент по запросу получает подробный рабочий след именно по этому объекту.

2. Архитектура: сохранить не только решение, но и путь к нему

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

3. Исследование: продолжить работу другой моделью и в другой сессии

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

4. Эксплуатация конкретного объекта: память рядом с оборудованием

В карточке станка, сервера или бизнес-процесса должны быть видны его характеристики, текущее состояние, ответственные и действующие ограничения. Обслуживающему агенту дополнительно нужны результаты прошлых проверок, рабочие версии причин сбоя, последовательность уже выполненных действий и ближайшие точки контроля. Если перенести всё это в основные поля объекта, временные наблюдения начнут конкурировать с подтверждёнными данными, а устаревшая гипотеза легко будет прочитана как факт.
Агентская память позволяет держать эту историю рядом с конкретным экземпляром оборудования, не смешивая её с его паспортом. Подтверждённый результат диагностики можно перенести в видимую модель, а промежуточный разбор и журнал действий сохранить в системном слое. Так агент конкретного объекта восстанавливает его историю, но пользователи не получают перегруженную карточку.

Как провести границу между моделью и памятью

Удобно использовать простое правило. Видимая модель отвечает на вопрос «что мы знаем о системе и в каком состоянии она находится сейчас?». Агентская память отвечает на вопросы «как мы к этому пришли, что уже пробовали, на каких источниках основан вывод и с какого места продолжать работу?».
Это не деление на человеческие и машинные данные. Люди могут читать и принимать артефакты памяти, а агенты — работать с объектами видимой модели. Различается назначение слоёв: предметная модель поддерживает общую картину системы, память — непрерывность агентной работы. Если гипотеза подтверждена и стала значимым фактом предметной области, её следует перенести в видимую модель; если факт потерял актуальность, память всё равно может сохранить историю его происхождения и изменения.

Что мы получим в конце рецепта

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

Какие механизмы памяти есть в Онто

Через текущую MCP-поверхность AgentMemory доступна агентам только для поиска и чтения. Поэтому записывать долговременную память в этом рецепте мы будем с помощью MemoryArtifact.
Механизм
Для чего нужен
Работа через MCP
AgentMemory
Компактные типизированные записи: факт, наблюдение, решение, гипотеза или историческая информация
Поиск и чтение
MemoryArtifact
Полноценные документы агента: журнал работы, handoff, решение, стратегия, протокол ревью или dossier
Создание, изменение, проверка, принятие, поиск, чтение и версионирование
Управление населением агентов
Конституция пространства, реестр агентов и персональные хартии
Чтение агентов, предварительная проверка правил и приём нового агента

Шаг 1. Подключить Onto MCP

Для подключения потребуются API-ключ
В HTTP-режиме ключ может быть настроен на стороне MCP-сервера или передан в заголовке X-Onto-Api-Key. После подключения агент должен иметь доступ к пространству, в котором находится объект-якорь будущей памяти.

Шаг 2. Выбрать пространство и якорь

Память всегда принадлежит конкретному пространству Онто. Кроме пространства, каждый артефакт должен быть привязан хотя бы к одной существующей цели: пространству целиком, шаблону, объекту или диаграмме. Для обычного объекта используется target_kind="entity".
Связь с целью может играть одну из четырёх ролей:
  • primary — основной объект, о котором создана память;
  • related — связанный объект;
  • evidence — объект, который служит основанием или доказательством;
  • handoff_target — объект, по которому передаётся работа.
В нашем примере основным якорем будет объект «Интеграционный контракт». Сервис проверит, что указанный объект действительно существует в выбранном пространстве, поэтому привязать память к произвольному идентификатору не получится.

Шаг 3. Выбрать тип артефакта и режим записи

Артефакты делятся на журналы, которые дополняются новыми записями, и документы, у которых должна существовать одна текущая версия.
Для журнальных типов обязателен режим append, для версионируемых документов — replace. Это часть контракта, а не рекомендация по оформлению. В нашем примере сначала создадим worklog, который агент сможет продолжать в следующих сессиях.

Шаг 4. Создать черновик

Агент вызывает create_memory_artifact_draft и передаёт содержание, краткое резюме, происхождение записи и цели, с которыми она связана:
create_memory_artifact_draft(
realm_id="<UUID пространства>",
artifact_path="agents/integration-researcher/worklog",
artifact_kind="worklog",
write_mode="append",
body="Изучены структура контракта и обработка ошибок. Найдено расхождение версий...",
summary="Исследован контракт интеграции",
source_ref="codex-thread:<id сессии>",
source_context={
"agent": "codex",
"task": "integration-research"
},
targets=[
{
"target_kind": "entity",
"target_id": "<UUID объекта в Онто>",
"role": "primary"
}
]
)
Поля body, summary, source_ref, source_context и непустой список targets обязательны. artifact_path — не путь к локальному файлу, а устойчивый логический адрес памяти внутри пространства. Если агент продолжит ту же работу из другой среды, он сможет обратиться к этому адресу независимо от устройства и текущего диалога.
Происхождение памяти лучше заполнять содержательно. В source_ref можно указать идентификатор сессии, задачи или другого первичного источника, а в source_context — роль агента, название работы, этап процесса и другие данные, которые помогут проверить запись позднее. Передать произвольный agent_principal и таким образом выдать себя за другого агента нельзя: при явном указании он должен совпасть с аутентифицированным principal.

Шаг 5. Проверить и принять память

Созданный артефакт не становится общей памятью пространства автоматически. Нормальный жизненный цикл выглядит так:
create_memory_artifact_draft
→ get_memory_artifact
→ submit_memory_artifact
→ accept_memory_artifact
→ get_memory_artifact_by_path
Сначала агент перечитывает созданный черновик и убеждается, что память связана с правильным объектом и не содержит неподтверждённых выводов, выданных за факты. Затем артефакт отправляется на рассмотрение и принимается участником или владельцем пространства. После принятия он становится доступен другим агентам как общая память.
Основная последовательность статусов выглядит так:
draft → proposed → accepted → superseded
↘ ↘ ↘
revoked
Черновик изменяет только его владелец. Технически сервис не запрещает автору самостоятельно принять свой артефакт, если у него достаточно прав в пространстве. Если для конкретного процесса требуется разделение автора и проверяющего, это правило следует закрепить в governance пространства и в тракте работы агентов.

Шаг 6. Продолжать журнал

Когда агент возвращается к исследованию, ему не нужно создавать новый журнал после каждой сессии. В append-артефакт добавляется очередная запись:
append_memory_artifact(
realm_id="<UUID пространства>",
artifact_id="<UUID артефакта>",
body="Проверена обратная совместимость. Версия 2.1 нарушает обработку поля...",
source_ref="codex-thread:<id новой сессии>",
source_context={
"task": "integration-follow-up"
}
)
Пока артефакт находится в статусе draft или proposed, добавлять записи может его владелец. После принятия журнал становится общей памятью пространства, и продолжать его могут участники этого пространства. В состояниях superseded и revoked добавление новых записей запрещено: такие артефакты уже не считаются действующей веткой памяти.

Шаг 7. Передать работу следующему агенту

Один журнал позволяет восстановить подробную историю, но для передачи работы лучше создать отдельный handoff. В нём следует оставить не пересказ всех действий, а рабочую границу: что уже сделано, что считается подтверждённым, какие вопросы открыты, где находятся доказательства и какое следующее действие ожидается.
Handoff связывается с тем же интеграционным контрактом с ролью handoff_target. После проверки и принятия следующий агент получает короткую точку входа, а при необходимости раскрывает связанный worklog, решение или стратегию тестирования. Так рабочая передача не зависит от того, сохранился ли первоначальный чат и умеет ли новая модель читать его формат.

Шаг 8. Восстановить контекст в новой сессии

Если логический путь известен, агент сразу читает текущую принятую версию:
get_memory_artifact_by_path(
realm_id="<UUID пространства>",
artifact_path="agents/integration-researcher/worklog"
)
В ответ он получает полное тело артефакта и все добавленные записи. Если путь неизвестен, память можно найти по объекту:
search_memory_artifacts(
realm_id="<UUID пространства>",
target_kind="entity",
target_id="<UUID интеграционного контракта>",
query="integration"
)
Поиск возвращает только принятые артефакты и не загружает их полное содержание. Агент сначала получает компактный список подходящих записей, выбирает нужную, а затем вызывает get_memory_artifact. Это позволяет не помещать в контекст все журналы и документы, когда для продолжения задачи нужен только один из них.
Собственный незавершённый черновик не появится в общем поиске. Его можно восстановить отдельно:
get_own_memory_artifact_draft_by_path(
realm_id="<UUID пространства>",
artifact_path="agents/integration-researcher/worklog",
agent_principal="<текущий аутентифицированный principal>"
)
Таким образом, общая рабочая память состоит только из принятых материалов, но агент не теряет собственную незавершённую работу между сессиями.

Шаг 9. Обновить решение без потери истории

Журнал можно продолжать, а решение нужно заменять новой версией. Для артефактов с write_mode="replace" безопасный путь выглядит так:
get_memory_artifact_by_path
→ create_memory_artifact_draft(supersedes_artifact_id=<id текущей версии>)
→ get_memory_artifact
→ submit_memory_artifact
→ accept_memory_artifact
→ get_memory_artifact_by_path
После принятия новый артефакт становится текущим, а предыдущий атомарно получает статус superseded. По одному artifact_path не может существовать две текущие принятые версии, поэтому следующий агент не столкнётся с двумя равноправными решениями и не будет самостоятельно угадывать, какое из них действует.
Существует и прямая операция supersede_memory_artifact, доступная владельцу пространства. Она сразу создаёт принятую следующую версию без стадии рассмотрения и поэтому относится к операциям повышенного риска. Для обычного агентного процесса разумнее использовать полный жизненный цикл с черновиком и проверкой.

Что происходит внутри Онто

Артефакты памяти хранятся в том же графе, что и предметная модель, и связаны с её объектами. Однако системные узлы помечены как слой agent_memory, поэтому обычные списки объектов, диаграммы, поиск связей и экспорт не должны показывать их как элементы пользовательской онтологии. Это и позволяет держать память рядом с объектом, не загрязняя рабочую модель.
У каждой записи есть автор, временные метки, ссылка на источник и произвольный контекст происхождения. Для MemoryArtifact также ведётся аудит событий: создание, изменение, добавление записи, отправка на проверку, принятие, отзыв и замещение новой версией. Принятая память доступна другим агентам и моделям с доступом к тому же пространству и поэтому не зависит от продолжительности конкретной сессии.
AgentMemory решает соседнюю задачу более компактных канонических записей. Такая запись может содержать тип памяти, заголовок, резюме, полное содержание, привязки, теги, срок актуальности и характеристику реальности: текущее состояние, целевое состояние, гипотезу, решение или исторический факт. Но поскольку текущая MCP-поверхность предоставляет для AgentMemory только поиск и чтение, полный рецепт записи и согласования памяти строится на MemoryArtifact.

Следующий уровень: память как основа населения агентов

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

Итог

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