ACE: как обновлять память агента, сохраняя полезные детали
Представим помощника, который каждую неделю собирает отчёт о работе библиотеки. Постепенно он узнаёт, где лежат архивные события, как устроены ответы сервисов и по какому часовому поясу считаются дни. Эти подробности занимают место, но без них красивый отчёт может оказаться неверным.
Стрелки показывают, откуда берётся следующий шаг. Условия и ограничения разобраны в статье.
Если после каждой задачи поручать модели заново пересказать всё накопленное, частное условие легко превратится в общую фразу. Вместо «архивный сервис возвращает идентификаторы, а карточки нужно запросить отдельно» останется «внимательно проверяй данные». Проверить такую инструкцию трудно; выполнить конкретный запрос по ней ещё труднее.
Работа Цичжэна Чжана, Чанжань Ху и соавторов Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models предлагает способ постепенного обновления контекста. Разберём ACE по версии v3 от 29 марта 2026 года. Первая версия опубликована 6 октября 2025 года. Библиотека и все её задачи ниже — мой условный пример. Карточка исследования.
Три роли вокруг рабочего справочника
В ACE контекст — информация, доступная модели — содержит развиваемый справочник, или playbook. Генератор выполняет задачу, рефлектор анализирует попытку и обратную связь, куратор готовит небольшие дополнения. Программная логика объединяет их с существующими записями. У записей есть идентификаторы и отметки полезности или вреда; отдельная обработка сокращает дублирование. Так обновление затрагивает нужные фрагменты, сохраняя остальное. §3–3.2.
Для меня основная инженерная идея здесь — сделать изменение памяти обозримым. Когда добавляется один пункт, можно обсуждать его содержание и основания. При полном переписывании длинного документа приходится одновременно искать полезные изменения и незаметные потери.
Где исчезает важное условие
Продолжим наш пример. Помощник обращается к сервисам библиотеки через интерфейсы программирования приложений (API). В его справочнике уже есть два правила: для недельного отчёта использовать местные календарные границы и отдельно учитывать отменённые мероприятия.
Поступает новая задача: добавить статистику прошлогодних событий. Архивный сервис возвращает список строковых идентификаторов. Агент предполагает, что получил готовые карточки, и пытается прочитать у строки поле с числом посетителей. Выполнение останавливается с ошибкой. Затем агент изучает описание сервиса, запрашивает карточки по идентификаторам и завершает расчёт.
В этой траектории — последовательности действий и результатов — есть конкретная поправка к пониманию интерфейса. Если целиком пересказать справочник после успешного расчёта, можно сохранить новый урок и случайно выбросить правило об отменённых событиях. Следующий отчёт тогда станет хуже по другой причине, хотя последняя ошибка была исправлена.
В подходе с небольшими дополнениями исходный справочник остаётся основой следующей версии. Изменение можно выразить одним пунктом: «При чтении архива сначала получи идентификаторы событий, затем загрузи их карточки». Существующие правила о периоде и отменах не требуют новой формулировки.
Как опыт проходит через роли
В нашем сценарии генератор оставляет результат попытки: вызовы сервисов, ошибку типа данных, уточнённый запрос и полученный отчёт. Рефлектору этого материала достаточно для вопроса: какое предположение оказалось неверным и чем это видно? Ответ «агент был невнимателен» почти ничего не меняет. Ответ о формате архивного сервиса указывает конкретное действие для следующей задачи.
Куратор рассматривает этот урок рядом с текущим справочником. Если соответствующего пункта нет, появляется дополнение с самостоятельным идентификатором. Если та же информация уже выражена достаточно ясно, новое изложение лишь усложнит чтение. В объясняемом примере полезен один пункт, по которому можно вернуться к исходной ошибке.
После применения дополнения агент берётся за другую выборку: мероприятия по конкретному филиалу. Старые сведения помогают задать период и исключить отмены, новое — правильно прочитать архив. Именно совместное применение показывает ценность накопления деталей.
Я бы добавил к каждой записи ссылку на описание интерфейса и дату наблюдения. Это моя рекомендация к внедрению. Она позволяет через месяц выяснить, относится ли правило к действующей версии сервиса. Сам по себе понятный текст не сообщает, когда и почему он перестал подходить.
Аккуратное добавление не доказывает правильность
В ACE объединение дополнений не является независимым испытанием каждой новой рекомендации. Авторы отмечают зависимость от качества обратной связи; без надёжных сигналов адаптация может ухудшить результат. §4.4, §5 и приложение A.3.
Пусть архивный сервис действительно вернул строки, но только потому, что агент случайно включил сокращённый режим ответа. Обобщение «архив всегда возвращает идентификаторы» окажется слишком широким. Оно пройдёт через все роли, если никто не проверит параметры вызова. У каждого участника процесса будет аккуратный выходной документ, а исходная причина останется неверно понятой.
Нужно различать и силу наблюдений. Завершение программы без исключения подтверждает совместимость типов на пройденном пути. Оно не подтверждает полноту отчёта, правильность периода или отсутствие двойного счёта. Для этих вопросов нужны другие наблюдения: например, заранее подготовленная выборка с известным составом событий.
Счётчик полезности я воспринимал бы как повод проверить запись. Если агент постоянно использует правило и система считает его полезным, счётчик может расти вместе с повторением одного и того же заблуждения. Полезность для выполнения конкретной попытки и истинность обобщения нужно оценивать раздельно.
Когда сокращение памяти снова становится опасным
Допустим, в справочнике появились два похожих пункта: один про архивные события, другой про текущие. Они отличаются условием получения карточек. Автоматическое устранение повторов может принять их за дубликаты и оставить более общее правило, потеряв исключение.
Я бы проверял результат такой обработки на парных задачах: одна обращается к архиву, другая — к действующему расписанию. Если после объединения одна из них ломается, сходство текстов оказалось плохим основанием для слияния. Важно сохранить различие, которое влияет на действие.
Авторы ACE исследуют воздействие шумных рекомендаций в отдельном опыте. Его результат не гарантирует устойчивость к любой последовательности ошибок. Приложение A.4. В нашей библиотеке я отдельно проверил бы изменение версии сервиса: старое правило может устареть сразу для всех последующих задач, и накопленная полезность не спасёт его от этого.
Как проверить справочник на длинной серии задач
ACE испытывают, в частности, на агентных задачах AppWorld и специализированных финансовых наборах. В последовательной оценке ответ сначала получают с текущим контекстом, затем обновляют его по завершённому примеру. §4.1.
Для собственной проверки я бы зафиксировал подобный порядок и сохранил каждую версию справочника. Измерять нужно качество следующего отчёта: улучшенная инструкция, написанная после ошибки, не исправляет уже выданный ответ задним числом.
Сравнение я построил бы между неизменным справочником, полным пересказом после каждой задачи и небольшими дополнениями. Во всех режимах нужны одинаковые модель, доступные сервисы, исходные сведения и бюджет попыток. Иначе преимущество более богатой обратной связи можно ошибочно приписать способу хранения.
В набор включил бы забываемые исключения: отменённое событие, пустой архив, другое отделение, смену формата ответа. После обновлений проверял бы, сохранились ли прежние удачные действия. Одновременно считал бы размер контекста, стоимость его обработки и число шагов до результата.
Дополнительно я хотел бы видеть небольшой журнал изменений: что добавили, по какой попытке, какие проверки это поддерживают и как вернуть прежнюю версию. Такой журнал — предлагаемая мной инженерная мера. Он делает ошибку памяти локальной и позволяет исправлять её предметно.
Первое решение для внедрения получилось бы скромным: выбрать один повторяемый поток задач и выяснить, какие детали действительно нужны следующим попыткам. Если сохранение этих деталей улучшает новые результаты при приемлемой цене, есть основание расширять справочник и область его применения.
Термины
- ACE — Agentic Context Engineering, метод постепенного изменения контекста модели на основе опыта выполнения задач.
- API — интерфейс, который задаёт доступные программные запросы к сервису и формат их результатов.
- Playbook, рабочий справочник — набор отдельных рекомендаций, уточнений и условий для следующих задач.
- Рефлектор — роль, которая анализирует выполненную попытку и доступную обратную связь.
- Куратор — роль, которая готовит дополнения к справочнику из полученных уроков.
- Дельта — небольшое изменение существующего состояния; здесь — набор дополнений к памяти.
- Устранение дубликатов — обработка похожих записей для сокращения повторов; сходство само по себе не доказывает равнозначность.
Источники
- Qizheng Zhang, Changran Hu, Shubhangi Upasani и соавторы. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. Первая публикация: 6 октября 2025 года; разобрана версия v3 от 29 марта 2026 года. Механизм: §3; оценка: §4; ограничения: §5; дополнительные опыты и инструкции: приложения A и F.
- Официальная страница ACE и репозиторий авторов. Библиотечный пример, предлагаемый журнал изменений и план самостоятельной проверки выше — мой анализ, а не результаты внедрения у авторов.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.