Agent Workflow Memory: как сохранить повторяемый способ работы
Агент научился находить карточку одного станка. Завтра нужно найти другой, а послезавтра — открыть историю его обслуживания. Полная запись первого разговора содержит много случайных подробностей. Для следующей задачи полезно выделить повторяемую часть: как перейти от инвентарного номера к проверенной карточке.
Стрелки показывают, откуда берётся следующий шаг. Условия и ограничения разобраны в статье.
Такую единицу опыта рассматривает Agent Workflow Memory (AWM) — работа Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried и Graham Neubig. Разбираем arXiv:2409.07429v1 от 11 сентября 2024 года. История с оборудованием и все предлагаемые ниже проверки придуманы для этого текста.
Что сохраняет AWM
Траектория — запись наблюдений и действий агента при выполнении задачи. Метод извлекает из таких записей повторяемые рабочие процедуры — workflows: описание цели и последовательность шагов. Конкретные значения заменяются переменными. Шаг содержит описание состояния, объяснение выбора и действие. Процедуры добавляются в текстовую память агента, которая помогает выбирать действия. Это основной вариант метода; исполняемые составные действия исследуются отдельно. Основной механизм, §2.1–2.3, составные действия, §5.
В offline-режиме процедуры заранее извлекаются из подготовленных примеров. В online-режиме агент последовательно решает задачи; модель-оценщик определяет успех попытки, и из признанной успешной траектории извлекается пополнение памяти. Оно доступно следующим задачам. В экспериментах память организована по сайтам. §2.3 и §3.
Для проектирования собственной системы это ставит два вопроса: какую часть опыта стоит обобщать и как проверить, что сохранённый способ подходит следующей ситуации?
Из одного поиска — в повторяемую процедуру
Представим внутренний каталог оборудования. Пользователь просит агента узнать дату последнего осмотра станка с номером М-042. Агент открывает каталог, вводит номер, получает несколько результатов, выбирает нужную карточку, переходит в обслуживание и читает запись.
В этой истории есть по меньшей мере две потенциально полезные процедуры: «найти карточку по инвентарному номеру» и «найти последний завершённый осмотр в карточке». Первая пригодится для проверки владельца оборудования, вторая — для подготовки сводки по обслуживанию. Их полезность не зависит от того, назывался ли исходный станок М-042.
Я бы описал первую процедуру следующим образом. Это наш учебный вариант, а не формат, скопированный из работы.
| Наблюдаемая ситуация | Действие | Что должно стать доступно |
|---|---|---|
| Открыт поиск оборудования | Ввести переданный инвентарный номер | Результаты поиска по этому номеру |
| Видны результаты | Сопоставить полный номер, тип и подразделение | Основание выбрать конкретную карточку |
| Подходящая карточка найдена | Открыть её | Карточка с подтверждённой идентичностью оборудования |
Вместо М-042 теперь используется параметр «инвентарный номер». Но обобщение не должно стереть существенные признаки. Если одинаковые номера встречаются в разных подразделениях, процедура обязана сохранить проверку подразделения или возможность уточнения.
Удалять случайные значения и удалять условия корректности — разные действия. Чем короче получится процедура, тем легче её прочитать; это ещё не означает, что её безопасно применять к большему числу задач.
Почему готовые шаги не заменяют наблюдение
Предположим, в новом интерфейсе после поиска появились две вкладки: действующее и списанное оборудование. Прежняя процедура ожидала единую выдачу. Агенту нужно заметить изменение и выяснить, где искать требуемый объект.
Если он исполняет сохранённые клики вслепую, знакомая последовательность может привести в неправильную карточку. Если использует процедуру как ориентир, он сопоставляет ожидаемое состояние с фактическим экраном перед следующим действием.
В нашей реализации я бы проверял каждый переход вопросом: «Мы получили то состояние, из которого следующий шаг имеет смысл?» После ввода номера мог появиться не список, а сообщение об отсутствии доступа. Тогда шаг «выбрать карточку» ещё не наступил.
При этом не требуется заново объяснять агенту всю задачу после каждого действия. У сохранённой процедуры остаётся польза: она подсказывает последовательность ожидаемых промежуточных результатов. Проверка наблюдений удерживает эту последовательность связанной с реальным интерфейсом.
Для этой задачи я бы сначала оставил процедуру текстовой подсказкой. Превращение её в вызываемую функцию потребует отдельной проверки параметров, промежуточных состояний и отказов. Такое решение зависит от стабильности конкретного интерфейса, а не от одного факта, что маршрут однажды сработал.
Успешная попытка ещё требует правильной оценки
Агент сообщил дату осмотра и закончил задачу. Можно ли сохранять его способ как удачный?
В нашем примере ответ зависит от того, что видел проверяющий. Красиво сформулированный итог не устанавливает, что открыли правильный станок. Найденная дата может относиться к плановому осмотру, который ещё не состоялся. Даже совпадение даты со случайным ожиданием не подтверждает правильность маршрута.
Для учебного каталога можно заранее задать правильную карточку и идентификатор нужной записи обслуживания. Тогда проверка смотрит на результат действия, а не только на убедительность текста. В реальной системе доступность такого основания придётся выяснять отдельно.
Я бы сохранял рядом с процедурой ссылку на исходную попытку и основание признания успеха. Эти сведения нужны при разборе ошибок. Если позже выяснится, что оценщик принимал запланированный осмотр за завершённый, станет понятно, какие процедуры нужно пересмотреть.
Это предложение для нашей системы. Наличие этапа оценки само по себе не даёт независимой гарантии: важно, насколько проверка различает правильную и внешне похожую неправильную работу.
Как выбрать размер сохраняемого опыта
Слишком маленькая единица — «нажать поле поиска» — почти не помогает спланировать работу. Слишком большая — «подготовить месячный отчёт о ремонтах всех станков» — связывает множество условий и исключений в один маршрут.
Для нашего каталога я бы выбирал единицу по повторяемому промежуточному результату. «Получить проверенную карточку» имеет ясный вход и выход. «Получить последний завершённый осмотр» начинается с этой карточки и добавляет свою проверку. Из таких частей можно строить более длинную работу, сохраняя точки, в которых видно отклонение.
Перед добавлением новой процедуры полезно спросить, отличается ли она от существующей. Поиск станка М-042 и поиск насоса Н-117 могут быть одним способом с разными параметрами. Поиск списанного оборудования может требовать другой ветви. Для нашего проекта это вопрос структуры памяти, который нельзя решить простым подсчётом накопленных записей.
Проверка переноса и накопления
Следующие сценарии показывают, какую именно способность мы хотим получить. Это план проверки, а не отчёт о запуске AWM.
| Сценарий | Наблюдаемый результат |
|---|---|
| Новый номер оборудования, прежний интерфейс | Используется новый параметр; старый номер не переносится из примера |
| Два объекта с одинаковым номером | Агент проверяет дополнительный признак или запрашивает уточнение |
| После поиска появляется новая вкладка | Агент замечает, что ожидаемое состояние не получено |
| Открыта карточка, но нет доступа к обслуживанию | Процедура не выдумывает отсутствующий результат |
| В память предложен маршрут с ошибочной датой | Проверка выявляет ошибку до превращения примера в рабочую рекомендацию |
| Задача требует только владельца оборудования | Агент останавливается после нужного результата и не проходит лишние шаги обслуживания |
Отдельно я бы проверил порядок задач. Если память пополняется после каждого выполнения, поздние задания получают больше опыта, чем ранние. Стоит повторить коллекцию в нескольких порядках, а затем проверить зафиксированную память на новой группе заданий.
Полезно сравнить отсутствие памяти, исходные записи попыток и обобщённые процедуры при одинаковых моделях и бюджетах. Считать нужно правильность всей задачи, лишние действия и цену подготовки памяти. Увеличение числа удачных промежуточных кликов ещё не означает, что пользователь чаще получает правильный итог.
Как читать результаты исследования
Работа оценивает AWM на WebArena и Mind2Web. Во втором случае отдельно измеряются успешность шагов и целых задач. Авторы отмечают ошибки процедур из неверно оценённых попыток и трудности отклонения от подходящего лишь частично маршрута. Сочетание offline- и online-памяти не дало простого сложения преимуществ. Результаты и ошибки, §3.2, сочетание режимов, приложение C.
Мы не воспроизводили эти результаты и не измеряли их перенос на каталог оборудования. Практический следующий шаг — выделить одну повторяемую процедуру, подготовить обычный случай и два исключения, затем проверить наблюдаемый результат. Так можно узнать, сохраняет ли память полезный способ работы вместе с условиями его применения.
Термины
- Рабочая процедура (workflow) — повторяемая последовательность действий для промежуточной цели.
- Траектория — наблюдения и действия в конкретной попытке решить задачу.
- Обобщение — выделение повторяемого способа с заменой частных значений параметрами.
- Offline-режим — подготовка памяти до выполнения проверяемых задач.
- Online-режим — пополнение памяти по мере последовательного выполнения задач.
- Оценщик — компонент, определяющий, выполнена ли задача; качество его решения нужно проверять отдельно.
Источник
Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried, Graham Neubig. Agent Workflow Memory. Проверенная редакция: arXiv:2409.07429v1, 11 сентября 2024 года. Карточка публикации, полный текст. Основной механизм разобран в §2, эксперименты — в §3–5, дополнительные проверки — в приложениях A–C.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.