Как сохранять знания для агента
Агент разобрался с ошибкой: после повторного запроса сервис создавал вторую заявку. В следующем проекте он встречает похожую проблему. Что стоит достать из памяти — историю расследования, короткий совет, последовательность проверок или готовый тест?
От формы сохранённого знания зависит, какую работу агенту придётся выполнить заново. Историю нужно понять и обобщить, правило — соотнести с ситуацией, процедуру — приспособить к задаче, программный навык — вызвать с подходящими входными данными и проверить результат.
Разберём один условный пример и несколько способов его сохранить. Четыре вопроса ниже — авторская рамка для объяснения; научные работы показывают отдельные механизмы, на которые она опирается. Сквозной пример придуман для статьи: это не отчёт об эксперименте.
Запись хранит связь с исходным тестом и условиями. В новой задаче агент проверяет эти условия: подходящую запись применяют, неподходящую пропускают. При изменении собственных оснований запись пересматривают.
Четыре вопроса о памяти
В обзоре агентной памяти разобраны задачи разработки, персональной AI-операционной системы и AI-операционной системы компании. Здесь сузим вопрос до одной записи: что именно мы сохраняем и как этим воспользоваться.
На узком экране таблицу можно прокрутить в сторону.
| Вопрос | Пример ответа |
|---|---|
| Что известно? | Что произошло, как удалось установить причину и при каких условиях этот способ проверки можно использовать снова? |
| Как знание представлено? | Текстовый разбор эпизода, условное правило, последовательность шагов, граф переходов или программа |
| Где оно хранится? | В файлах, таблицах базы данных или специализированном сервисе памяти |
| Как с ним работают? | Извлекают из опыта, проверяют, находят для новой задачи, применяют и пересматривают |
Эти решения связаны, но одно не определяет остальные. В текстовом файле можно записать и рассказ, и строгую таблицу переходов. Граф можно сохранить списками узлов и связей в обычной базе данных. Выбор хранилища сам по себе не определяет, какое знание записывать и когда его пересматривать.
Под знанием в этой статье понимается сохраняемое утверждение или способ действия с основаниями и областью применения. Такая запись может оказаться ошибочной или устареть; её наличие в памяти ещё не делает её достоверной.
Из какого опыта получается запись
Представим сервис регистрации заявок. Его программный интерфейс (API), через который другие программы обращаются к сервису, принимает запрос создания заявки и ключ операции. По контракту именно этого условного сервиса повтор с тем же ключом и содержимым в течение суток возвращает результат первой операции, а новый ключ означает новую операцию.
Клиент отправил запрос, не дождался ответа и повторил его с новым ключом. Первая заявка уже была создана, поэтому появилась вторая. Агент воспроизвёл ситуацию в изолированном тестовом окружении, нашёл смену ключа и исправил её. Проверки повторов с одним ключом дали одну заявку.
Теперь есть несколько разных оснований для памяти: контракт сервиса, журнал запросов, найденная причина, изменение кода и результат проверки. Журнал действий агента и ответов инструментов называют траекторией. Из неё можно извлекать опыт, но сама траектория содержит и полезные шаги, и случайные обходы, и неудачные догадки.
В нашем примере полезный вывод звучит так: при потерянном ответе стоит установить результат первой операции и проверить правила повтора. Совет «всегда повторяй с тем же ключом» был бы слишком широким: у другого сервиса могут отличаться поддержка ключа, срок его действия и поведение при изменении запроса.
Формы можно сочетать. Их полезность определяется тем, какую работу запись помогает выполнить в новой ситуации. Открыть схему в полном размере.
Запись об эпизоде: сохранить, что произошло
Самый прямой вариант — оставить связный разбор:
В тестовой версии сервиса повтор запроса с новым ключом создал вторую заявку. Первая операция успела завершиться до потери ответа. После сохранения ключа между попытками тесты дали одну заявку. Основания: контракт этой версии, журнал запросов и результаты проверок.
Такая запись сохраняет контекст расследования. Агент может проверить, действительно ли новая проблема похожа на старую, и вернуться к доказательствам. Чтобы выбрать следующее действие, ему ещё нужно выделить из рассказа полезный приём.
Рядом стоит сохранить ссылки на исходные материалы и версию системы. Это авторская рекомендация для нашего примера: она помогает отличать наблюдавшийся результат от позднейшего пересказа.
Условное правило: сохранить, когда полезен приём
Часть опыта можно выразить короче:
Условие: ответ на создание потерян, результат операции неизвестен. Действие: проверь, была ли создана заявка, затем сверь контракт повторов. Ловушка: новый ключ может обозначать новую операцию.
Правило помогает выбрать направление диагностики. Оно не задаёт весь путь: агенту предстоит найти нужный журнал, понять интерфейс поиска и определить, что считать достаточной проверкой.
Похожая форма используется в AutoGuide: из прежних попыток получают рекомендации, связанные с состояниями среды, а во время работы выбирают советы для текущей ситуации. В статье о сервисе мы используем собственное правило, иллюстрирующее эту форму памяти; оно не взято из экспериментов AutoGuide.
Процедура: сохранить связанную последовательность
Если полезным оказался целый способ расследования, можно сохранить процедуру, или workflow: последовательность действий для повторного выполнения работы.
Для нашего случая она могла бы выглядеть так:
- Восстановить последовательность исходного запроса и повторов.
- Установить результат первой операции по надёжному источнику состояния.
- Сопоставить ключи и содержимое запросов с контрактом сервиса.
- Выбрать исправление для найденной причины.
- Проверить потерянный ответ, последовательные и одновременные повторы в тестовом окружении.
Теперь агент получает порядок расследования. Ему всё ещё нужно приспособить конкретные команды и проверки к проекту.
В Agent Workflow Memory из прошлых решений выделяют повторно используемые workflows. В основном варианте они добавляются в инструкции агента и помогают построить дальнейшие действия. Авторы также исследуют вызываемые workflows; граница между описанной процедурой и программным инструментом зависит от реализации.
Граф: сохранить развилки и условия переходов
В расследовании есть развилки. Если первая заявка найдена, можно изучать причину повторного создания. Если результат первого запроса остаётся неизвестным, нужны дополнительные сведения. Линейную процедуру приходится дополнять такими условиями.
Граф представляет шаги узлами, а возможные переходы — направленными связями. Часть нашего условного графа можно прочитать как таблицу:
На узком экране таблицу можно прокрутить в сторону.
| Текущий шаг | Условие перехода | Следующий шаг |
|---|---|---|
| Проверить результат первого запроса | Есть подтверждение создания | Найти, почему повтор создал новую заявку |
| Проверить результат первого запроса | Результат пока неизвестен | Получить дополнительные сведения о состоянии операции |
| Найти причину повтора | Повтор получил новый ключ | Проверить, как клиент сохраняет ключ между попытками |
| Проверить работу с ключом | Причина подтверждена | Исправить и запустить проверки повторов |
В Procedural Graphs, §3 используется редактируемый граф процедур. Узлы могут обозначать инструменты, навыки, шаги рассуждения или состояния задачи. У переходов в описанной реализации есть условие, рекомендация и типичные ошибки.
Во время решения система сопоставляет последний шаг агента с узлом, получает соседние переходы и вместе с недавней траекторией превращает их в ситуативную подсказку. Если сопоставление не удалось, используется полный граф. Агент выбирает действие с учётом подсказки; граф направляет работу, сохраняя возможность рассуждать.
Граф остаётся фиксированным в пределах решения задачи. Между запусками отдельный процесс разбирает результаты, предлагает изменения и проверяет кандидатов на отдельном наборе задач. Сохраняются кандидаты, чей измеренный результат не хуже предыдущего; отклонения тоже учитываются при следующих предложениях. Эта проверка относится к конкретной выборке и не гарантирует улучшения на всех будущих задачах.
Так становится видно, что именно сохраняется в Procedural Graphs: связи между способами действия, условия их применения и накопленные рекомендации. Представление связано с механизмами извлечения и обновления памяти.
Исполняемый навык: сохранить проверяемое действие
Часть процедуры можно оформить программой. В нашем примере — функцией, которая в тестовом окружении воспроизводит потерю ответа, отправляет повторные запросы и возвращает число созданных заявок вместе с журналом проверки.
Агенту тогда нужно выбрать подходящий сценарий и параметры, запустить функцию и оценить результат. Требования к интерфейсу сервиса становятся зависимостями программы: при изменении контракта понадобится проверить и сам навык.
В SkillWeaver опыт взаимодействия с сайтами превращается в повторно используемые Python-функции поверх Playwright — средства управления браузером. Они проверяются в последующих попытках и становятся доступными агенту как инструменты. Наш тест дублирования — аналогия формы, а не результат веб-экспериментов авторов.
Слово «навык» здесь означает вызываемую программу. В агентных продуктах skill может также означать пакет инструкций, шаблонов и вспомогательных скриптов. При сравнении систем нужно смотреть, какой артефакт реально сохраняется и как он выполняется.
Что понадобится агенту в новой задаче
Пусть теперь агент работает с другим сервисом, где тоже возникают дубли. Найденная запись даёт направление работы, но условия ещё предстоит проверить: есть ли ключ операции, каков срок его действия, доступен ли надёжный поиск результата и совпадает ли причина сбоя.
На узком экране таблицу можно прокрутить в сторону.
| Форма записи | Что агент получает | Что ему нужно сделать в новой задаче |
|---|---|---|
| Текстовый разбор эпизода | Контекст расследования и основания вывода | Выделить подходящий опыт и сопоставить обстоятельства |
| Правило | Условие, совет и известную ловушку | Установить, выполняется ли условие |
| Процедура | Связанный порядок работы | Приспособить шаги к инструментам и среде |
| Граф | Варианты переходов с условиями | Определить текущий шаг и подходящую ветвь |
| Программный навык | Вызываемое действие с входами и результатом | Проверить совместимость, выполнить и оценить результат |
Это рабочее сравнение, а не лестница качества. Текстовый разбор может содержать условные правила, процедура — вызывать функцию, граф — связывать всё вместе. Дополнительная структура полезна, когда помогает выбрать и выполнить действие; её создание и обслуживание тоже требуют работы.
Если запись не подходит конкретной задаче, агент пропускает её и ищет другой способ. Пересмотр самой записи нужен, когда изменились её основания или обнаружена ошибка.
Например, для редкой ошибки может хватить проверяемого разбора. Для повторяющейся диагностики стоит рассмотреть сохранённую процедуру. Если выбор следующих действий регулярно зависит от нескольких условий, полезно проверить графовое представление. Это ориентиры для выбора, а эффект конкретного варианта измеряется на новых задачах — как описано в материале об оценке памяти.
Как сохранять связь с основаниями
Для нашего примера я бы сопровождал любую форму записи несколькими полями: источник опыта, версия сервиса, условия применения, проверенный результат и повод пересмотра. Статус «наблюдение», «гипотеза» или «проверено в таких-то условиях» помогает не превратить догадку в общее правило.
Если контракт повторов изменился, понадобится пересмотреть правило, связанные переходы и тестовую функцию. Связь с исходным контрактом позволяет найти эти производные записи. Саму историческую запись об эпизоде можно сохранить как свидетельство того, что происходило в прежней версии.
Запись попадает в контекст — информацию, которую модель получает при конкретном обращении, — только через определённый процесс: загрузку файла, поиск, выбор правила или навигацию по графу. Поэтому при проектировании памяти полезно сразу назвать и будущую операцию чтения: по какому запросу или состоянию агент должен найти это знание.
Первое решение при сохранении опыта — какую работу запись должна облегчить в следующей задаче. После этого можно выбрать её форму, способ извлечения и проверку применимости. Хранилище реализует эти решения и помогает поддерживать их во времени.
Термины
- Представление знания — структура, в которой зафиксированы утверждения, действия и отношения между ними.
- Траектория агента — последовательность его действий и полученных наблюдений при решении задачи.
- Условное правило — рекомендация вместе с условиями её применения.
- Процедура, workflow — связанная последовательность действий для выполнения работы.
- Процедурный граф — шаги или состояния и направленные переходы с условиями и рекомендациями.
- Исполняемый навык — повторно используемая программа с определёнными входами, действиями и результатом.
- API — программный интерфейс, через который другие программы обращаются к сервису.
- Контекст — сведения, доступные модели при конкретном обращении, включая загруженную память.
Источники
Механизмы сверены по первичным текстам 21 октября 2026 года. Статья сопоставляет формы памяти на авторском примере; эксперименты перечисленных работ здесь не воспроизводились, единый рейтинг эффективности не строился.
- Procedural Graphs, arXiv:2609.09153v1, §3 — граф переходов, ситуативная подсказка и отдельная проверка изменений.
- AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents, arXiv:2403.08978v2 — извлечение и выбор рекомендаций с учётом текущего состояния.
- Agent Workflow Memory, arXiv:2409.07429v1 — сохранение повторяемых процедур и варианты их использования агентом.
- SkillWeaver: Web Agents can Self-Improve by Discovering and Honing Skills, arXiv:2504.07079v1 — опыт в форме вызываемых функций и их проверка.
Время чтения: 10 минут.
Налаживаете работу с ИИ-агентами?
Помогаю командам выбрать рабочий процесс, подготовить знания и проверить результат внедрения. Практические заметки публикую в Telegram-канале.