Архитектура общей памяти агентов для программирования

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

Когда агенту полезно «вспоминать» чужой опыт

Авторы работы Memory Transfer Learning: How Memories are Transferred Across Domains in Coding Agents предлагают выйти из этого локального мышления. Их идея проста и амбициозна: если разные задачи программирования всё равно делят общую инфраструктуру — языки, shell, тестирование, API-контракты, структуру репозиториев, — почему бы агенту не переносить опыт между доменами? Например, использовать урок, полученный на соревновательной задаче, чтобы лучше починить баг в реальном репозитории.

И, что важно, статья показывает: это не красивая метафора, а вполне рабочий механизм. В среднем перенос памяти между разными типами задач по программированию даёт +3,7% к качеству. По меркам зрелых бенчмарков это уже заметный прирост — особенно если речь идёт не о дообучении модели, а о том, как она использует уже полученный опыт.

В чём здесь новизна

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

Авторы называют свой подход Memory Transfer Learning (MTL). В отличие от обычных memory-based агентов, которые копят воспоминания внутри одного домена, MTL строит единую память из гетерогенных задач — от генерации кода функций до репозиторных исправлений и задач на воспроизведение ML-экспериментов.

Это важно по двум причинам. Во-первых, индустрия идёт к универсальным агентам, которые должны уметь и править баги, и запускать пайплайны, и ориентироваться в чужом репозитории, и не ломаться об инфраструктуру. Во-вторых, масштабировать модели всё дороже, а значит, любые прибавки за счёт лучшего использования inference-time опыта становятся особенно ценными.

Как устроена память в этой работе

Авторы не ограничились одним форматом «воспоминаний», а протестировали сразу четыре — от максимально сырого до максимально абстрактного.

Вот эти четыре формата:

Trajectory — почти сырая трасса действий агента: команды, код, выводы среды.

Workflow — выжимка из траектории: цель и последовательность значимых шагов.

Summary — краткий пересказ задачи, действий и причин успеха или провала.

Insight — максимально обобщённый инсайт: принцип, который может пригодиться в будущих задачах без привязки к конкретным файлам и деталям.

Это очень удачный дизайн эксперимента, потому что он позволяет проверить не просто «работает ли память», а какая именно память переносится лучше. И ответ, пожалуй, главный в статье: чем более память абстрактна, тем полезнее она для междоменного переноса.

Как они это проверяли

Экспериментальная часть у работы добротная. Авторы гоняли агента по шести бенчмаркам, которые покрывают разные классы задач по программированию:

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

Технически retrieval сделан довольно просто: задачи и элементы памяти встраиваются в embedding-пространство, затем по косинусовой близости выбираются три самых релевантных воспоминания. Это не выглядит как особенно хитрая retrieval-система — и именно поэтому результаты интересны. Эффект достигается не за счёт сложной инженерии, а за счёт самого принципа.

Что получилось в цифрах

Главный результат: в среднем MTL действительно улучшает качество по шести бенчмаркам. Лучший формат — Insight. Для основного сетапа на GPT-5-mini средний Pass@3 вырос с 0.523 до 0.560, то есть как раз на 3,7%.

Особенно заметные приросты были на задачах, где важны не только алгоритмы, но и дисциплина работы с окружением: ReplicationBench и MLGym-Bench получили весьма чувствительные бонусы. На SWE-Bench Verified тоже есть прибавка, что особенно показательно: это уже не игрушечная генерация функций, а реальные багфиксы в репозиториях.

Авторы также проверили перенос на других моделях — DeepSeek V3.2 и Qwen3-Coder. Эффект сохраняется, пусть и слабее: +2.6% и +1.8% в среднем. Это важный момент: похоже, речь идёт не о частном трюке под одну модель, а о более общем свойстве агентной памяти.

Почему память помогает: не код, а мета-знание

Пожалуй, самая сильная мысль статьи — переносится в основном не содержательный кодовый паттерн, а способ поведения.

Авторы проанализировали случаи, когда zero-shot агент проваливался, а с MTL — проходил, и классифицировали вклад памяти. Оказалось, что основной выигрыш даёт не «вспомнил правильный алгоритм», а более прозаичные, но критически важные вещи:

Это очень похоже на то, как работает хороший инженерный опыт у человека. Старший разработчик часто выигрывает не потому, что знает больше алгоритмов, а потому, что лучше чувствует процесс: где проверить контракт, где не делать опасный рефакторинг, где сначала воспроизвести баг, а потом чинить.

И в этом смысле статья делает важный шаг к более реалистичному пониманию агентов для программирования: их бутылочное горлышко — не всегда «недостаток интеллекта», часто это недостаток процедурной дисциплины.

Почему абстракция решает всё

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

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

Авторы визуализируют это через t-SNE и дополнительно меряют количественно: по мере роста абстракции воспоминания становятся менее привязанными к конкретному бенчмарку и сильнее перемешиваются между доменами. Это и есть признак обобщаемости.

Иными словами, если кратко: плохая память для переноса — это лог действий; хорошая память — это правило поведения.

Где система всё ещё ошибается

Разумеется, междоменная память не всегда помогает. Иногда она даёт negative transfer — когда чужой опыт неуместно якорит решение.

Авторы разбирают три основных режима провала:

Один из показательных кейсов: память из R-задачи подталкивает агента к неуместному перезаписыванию файлов в C++-проекте. В другом случае полезный совет «сначала быстро проверь, что всё запускается» искажается в оправдание поверхностного smoke-test вместо полноценной работы над качеством.

Это важное напоминание: память — не магия. Если retrieval слабый, а адаптация к новой задаче поверхностна, агент будет не учиться, а галлюцинировать по аналогии.

Чем больше память, тем лучше — но не бесконечно просто

Ещё один практический вывод: MTL масштабируется. Чем больше память и чем больше разных доменов в ней собрано, тем выше шанс вытащить полезное мета-знание.

Это особенно интересно на фоне популярного скепсиса к memory-системам: мол, всё упрётся в шум. Здесь авторы показывают, что по крайней мере в их сетапе рост разнообразия скорее помогает, чем мешает. Видимо, для кодовых агентов широкая база процедурных паттернов действительно ценна.

При этом любопытно, что более сложные retrieval-стратегии не обошли простой embedding-based поиск. Ни LLM-reranking, ни переписывание памяти под задачу не дали лучшего результата. Вероятное объяснение — в агентных сценариях заранее трудно понять, какой именно кусок опыта окажется полезен на следующем шаге. Статический reranking тут уступает грубой, но устойчивой семантической близости.

Почему это важно для индустрии

У статьи есть вполне прикладной смысл. Сегодня мы много говорим о software engineering agents как о будущих универсальных помощниках разработчика. Но пока многие из них остаются «сильными стажёрами»: что-то умеют, но легко теряются вне привычного формата.

Эта работа подсказывает более реалистичный путь развития. Вместо бесконечной гонки за ещё большей моделью можно учить агента систематически накапливать и переиспользовать опыт — причём не в узкой специализации, а поперёк разных задач. По сути, речь идёт о building blocks для инженерной интуиции.

Особенно важен акцент на мета-знании. Если будущие агенты действительно будут работать в production-средах, то решать задачу мало — нужно ещё уметь не портить репозиторий, не нарушать контракты, корректно валидировать изменения и адекватно общаться с инструментами. Именно такой опыт и переносится лучше всего.

Вывод

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

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

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

И это, возможно, куда более важный шаг к надёжным агентам, чем ещё один скачок в размере модели.