Самообучающиеся coding agents: как копятся навыки и начинается деградация

Коротко

Самообучающиеся coding agents полезно рассматривать не как прототип рекурсивного AGI, а как программную систему с дополнительным контуром эволюции. Обычный агент решает задачу и завершает сессию. Self-evolving-система использует результат, трассу действий, тесты и обратную связь, чтобы изменить то, как будут решаться следующие задачи.

Факт. Обзор Self-Evolving Coding Agents выделяет шесть объектов эволюции: framework, memory, skills, tools, models и collaboration structures. Следовательно, выражение «агент обучился» ещё не говорит, что именно было изменено.

Интерпретация. Практическая ценность self-evolving-подхода заключается в контролируемом накоплении повторно используемого опыта. Агент может быстрее распознавать знакомый класс задачи, выбирать подходящий инструмент или избегать уже обнаруженной ошибки без обязательного обновления базовой модели.

Ограничение. Исполняемые тесты дают coding-агентам сильный сигнал обратной связи, но он не равен истинной корректности. Неполный или ошибочный тест превращает эволюцию в оптимизацию ложной цели. Успех на тестах может закрепить неверный навык.

• Новый навык нельзя автоматически считать улучшением только потому, что он однажды помог.
• Память, skill bank, инструменты, политики и веса модели требуют разных процедур проверки.
• Главная угроза — не единичная ошибка, а её сохранение, повторное извлечение и тиражирование.
• Безопасный цикл требует eval gate, canary, версионирования, аудита происхождения и rollback.
• Метрики должны измерять не только pass rate, но и регрессии, safety drift, качество извлечения и покрытие provenance.

Что значит self-evolving без фантастики

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

Это изменение не обязательно затрагивает параметры модели. Система может сохранить краткое правило выбора инструмента, добавить рабочий пример в память, обновить стратегию поиска, создать новый исполняемый актив или изменить распределение ролей между несколькими агентами. Поэтому self-evolving — свойство всей системы, а не синоним дообучения модели.

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

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

Особенно важно разделять два времени: runtime, когда агент решает пользовательскую задачу, и evolution time, когда накопленный опыт анализируется и допускается к повторному использованию. Такое разделение упрощает аудит и не позволяет незавершённой гипотезе незаметно стать общей политикой.

Что именно может эволюционировать

Таксономия из шести объектов полезна не только для описания исследований. Она определяет радиус возможной ошибки и подходящий eval gate. Проверка записи памяти не должна быть идентична проверке нового исполняемого инструмента, а изменение командной структуры нельзя оценивать только тестами одного патча.

Объект эволюции	Что меняется	Основной риск	Что проверять перед promotion
Framework	Оркестрация, порядок шагов, правила вызова компонентов	Систематическая ошибка начинает затрагивать все задачи	Регрессии по классам задач, лимиты полномочий, наблюдаемость
Memory	Долговременные записи о прошлом опыте и контексте	Устаревшая или ложная запись извлекается как факт	Происхождение, область применимости, срок актуальности, конфликтующие записи
Skills	Повторно используемые стратегии решения и выбора действий	Узкий приём ошибочно обобщается на другие задачи	Контрольный набор, отрицательные примеры, польза относительно baseline
Tools	Исполняемые утилиты, адаптеры и способы применения инструментов	Новый актив расширяет полномочия или вносит скрытый побочный эффект	Изоляция, интерфейс, разрешения, детерминированность проверки, rollback
Models	Параметры или выбранная модель внутри системы	Широкая регрессия, которую трудно связать с одной записью опыта	Полный набор capability- и safety-eval, сравнение версий, canary
Collaboration structures	Роли, маршрутизация и взаимодействие нескольких агентов	Ошибки координации, потеря ответственности и взаимное подтверждение заблуждения	Качество итогового результата, стоимость координации, независимость проверки

Интерпретация. Чем шире область действия обновления, тем более строгим должен быть gate. Локальная запись памяти может быть отозвана точечно. Изменение framework или модели способно повлиять на весь поток задач, поэтому требует более широкого eval и осторожного развёртывания.

В реальной архитектуре объекты связаны. Новый навык может потребовать инструмента; инструмент — нового разрешения; память — метаданных для корректного извлечения; новая схема взаимодействия — другой политики verification. Именно поэтому нельзя оценивать «эволюцию агента» одним итоговым pass rate.

Откуда берётся обучающий сигнал

Код удобен для замкнутого цикла тем, что часть результата можно исполнить и проверить. Компиляция, тесты и другие машинно проверяемые условия дают более предметный сигнал, чем субъективное впечатление от ответа. Но сила сигнала определяется качеством проверяющего контура.

Факт. В исследовательском пакете исполняемые тесты отмечены как сильный feedback signal для software agents. Одновременно зафиксировано ключевое ограничение: ошибочные и неполные тесты заставляют систему оптимизировать ложную цель.

Механизм деградации здесь прост. Агент получает высокий reward за изменение, которое удовлетворяет наблюдаемой проверке. Затем система извлекает из успешной трассы обобщённое правило. Если проверка не охватывала важное требование, правило сохраняет случайный или неверный способ достижения результата. При следующих задачах оно уже выступает не случайной ошибкой, а приоритетным опытом.

Факт с оговоркой. CODESKILL сообщает средний прирост pass rate на 9,69 пункта относительно no-skill baseline и на 4,01 пункта относительно сильнейшего prompt/memory baseline в собственных экспериментах. Это self-reported результат конкретной работы, а не универсальная гарантия для любого агента, репозитория или набора задач.

Факт с оговоркой. Socratic-SWE строит задачи из прошлых трасс и после трёх итераций сообщает результат 50,40% на SWE-bench Verified при собственных условиях. Число показывает заявленный результат замкнутого цикла, но само по себе не отделяет переносимый навык от адаптации к конкретной процедуре оценки.

Редакционная рекомендация. Учебный сигнал стоит собирать из нескольких независимых слоёв: проверки требований, исполняемых тестов, анализа регрессий, ограничений безопасности и оценки поведения на задачах, которые не использовались при создании навыка. Несогласие слоёв должно блокировать автоматический promotion, а не усредняться в удобный итоговый балл.

Skill bank и память

Долговременная память отвечает на вопрос «что происходило и что известно системе», а skill bank — «какую повторяемую стратегию стоит применить». На практике граница может размываться, но для контроля её полезно поддерживать явно. Фрагмент трассы ещё не является навыком; он становится кандидатом после обобщения, описания области применимости и проверки на новых задачах.

Без структуры skill bank быстро превращается в склад похожих советов. Retrieval начинает возвращать несколько конфликтующих правил, старый навык конкурирует с новым, а система не может объяснить, почему выбрала конкретный вариант. Увеличение памяти в таком случае снижает управляемость, даже если объём доступного опыта растёт.

Редакционная рекомендация. Карточка навыка должна содержать как минимум идентификатор и версию, источник трассы, условия применимости, ожидаемый эффект, известные противопоказания, использованные проверки, автора или процесс promotion, зависимости от инструментов и ссылку на предыдущую версию. Это не вывод о конкретной реализации из источников, а минимальная схема для аудируемой эксплуатации.

Жизненный цикл навыка полезно строить как конечный автомат: candidate, quarantine, canary, promoted, deprecated, revoked. Статус должен определять, может ли навык влиять на рабочее решение, а не служить декоративной меткой.

Факт. Источники рассматривают несколько отдельных аспектов памяти. MetaMem посвящена эволюции мета-памяти, PerMemSafe — безопасности долгоживущей персональной памяти, а Mem2ActBench — оценке использования долговременной памяти.

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

Инструменты и новые активы

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

Факт. Mem2Evolve исследует совместную эволюцию опыта и инструментов. Это подчёркивает связанность двух контуров: накопленный опыт может подсказывать, какого инструмента не хватает, а новый инструмент меняет доступные агенту стратегии.

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

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

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

Как появляется деградация

Деградация не всегда выглядит как немедленное падение среднего pass rate. Система может улучшиться на частом классе задач и одновременно стать менее надёжной на редких случаях. Она может решать больше задач, но чаще обходить verification. Или сохранять итоговое качество ценой растущего числа попыток, конфликтующих навыков и непрозрачных решений.

Вид деградации	Механизм	Наблюдаемый симптом	Как отличать от случайного шума
Деградация качества	Неудачное правило применяется за пределами исходной области	Рост регрессий в отдельных классах задач	Сегментировать eval и сравнить результаты с отключённым навыком
Retrieval-деградация	Хранилище возвращает нерелевантный или устаревший опыт	Правильный навык существует, но выбирается редко или не вовремя	Оценивать выбор записи отдельно от итогового действия
Safety drift	Накопленные обновления постепенно меняют допустимое поведение	Прохождение capability-тестов при ухудшении safety-проверок	Вести независимый safety-набор и историю версий
Операционная деградация	Рост числа навыков, вызовов и согласований	Больше шагов, конфликтов и откатов при сходном качестве	Сопоставлять результат с затратами и сложностью трассы
Деградация наблюдаемости	Потеря связи между действием и источником опыта	Нельзя объяснить выбор или отозвать конкретное влияние	Проверять полноту provenance и воспроизводимость решения

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

Ограничение. Один агрегированный показатель скрывает такую динамику. Даже рост pass rate не доказывает здоровую эволюцию, пока неизвестно, какие сегменты улучшились, сколько регрессий появилось и не была ли проверка частью обучающего контура.

Self-poisoning и накопление ошибок

Факт. Работа EVOMAL: Self-Poisoning in Self-Evolving Coding Agents демонстрирует риск self-poisoning: агент может повторно тиражировать вредоносный или ошибочный шаблон из собственной памяти.

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

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

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

Карантин должен применяться не только к заведомо плохим записям, но и к неопределённым. Если кандидат показал пользу на одной задаче, но не прошёл проверку переноса, его нельзя смешивать с рабочим skill bank. Неопределённость — самостоятельное состояние, а не основание для автоматического допуска.

Benchmark overfitting

Benchmark overfitting возникает, когда эволюционный цикл всё лучше приспосабливается к наблюдаемой процедуре оценки, но не приобретает равноценной способности решать новые задачи. Для self-evolving-агента риск особенно высок: benchmark может использоваться не один раз для измерения, а многократно влиять на отбор навыков.

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

Ограничение. Заявленные CODESKILL приросты и результат Socratic-SWE нельзя автоматически переносить на другую модель, агентный framework, репозиторий или eval-процедуру. Исследовательский пакет не даёт основания объявлять эти числа универсальной оценкой self-evolving-подхода.

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

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

Контур promotion и rollback

Promotion — это решение изменить рабочее поведение будущих запусков. Его нельзя сводить к записи строки в базу. Gate должен подтверждать полезность, безопасность, воспроизводимость и управляемость кандидата. Rollback, в свою очередь, должен возвращать не только старый файл, но и прежнее состояние индекса, зависимостей, политик и маршрутизации.

Факт. Работа Towards Healthy Evolution показывает, что ограниченный надзор может снижать safety drift. В описанном подходе ANCHOR контроль verification phase оказался наиболее эффективной точкой вмешательства. Это результат конкретной работы и не доказательство того, что одной проверки достаточно для любой системы.

Интерпретация. Verification удобна как точка контроля, потому что здесь кандидат уже сформирован, но ещё не получил широкого влияния. Надзор не обязан повторять всю работу агента: он может проверять основания promotion, независимость eval и соответствие политики.

Практический чек-лист перед допуском навыка

1. Присвоить кандидату уникальный идентификатор и версию.
2. Сохранить исходную трассу и результат задачи, из которой он извлечён.
3. Указать модель, framework, инструменты и политики, участвовавшие в создании.
4. Сформулировать область применимости и условия, при которых навык нельзя использовать.
5. Проверить дубликаты, конфликты и зависимости от существующих навыков.
6. Исключить автоматическое доверие к тестам, созданным тем же контуром без независимой проверки.
7. Оценить кандидата на задачах, не использованных при его формировании.
8. Добавить отрицательные примеры и проверки известных регрессий.
9. Провести отдельный safety-eval, не заменяя его capability-метрикой.
10. Проверить влияние на выбор инструментов и фактические полномочия агента.
11. Запустить ограниченный canary с отдельной телеметрией.
12. Определить критерии остановки и владельца решения об откате.
13. Проверить, что rollback восстанавливает индекс, зависимости и прежнюю маршрутизацию.
14. Назначить срок повторной проверки или условие автоматической деактивации.
15. После promotion продолжить сравнение с контрольной версией, а не считать решение окончательным.

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

Минимальная архитектура безопасного цикла

Минимальный безопасный контур состоит не из одного общего хранилища, а из нескольких зон доверия. Рабочий агент читает только promoted-артефакты. Кандидаты попадают в отдельное хранилище. Сомнительные и отозванные версии остаются доступными для расследования, но не для runtime-retrieval.

1. Сбор. Агент сохраняет трассу, вызовы инструментов, результаты проверок и версию окружения.
2. Извлечение. Отдельный процесс формирует кандидата в память, навык, инструмент или политику.
3. Нормализация. Кандидат получает схему, provenance, область действия и список зависимостей.
4. Карантин. Артефакт изолируется от рабочего retrieval до завершения eval.
5. Capability-eval. Измеряется вклад в решение задач относительно зафиксированного baseline.
6. Safety-eval. Проверяются ограничения, побочные эффекты и изменение полномочий.
7. Verification gate. Независимый контролёр проверяет основания для promotion.
8. Canary. Кандидат получает ограниченную область применения и отдельный мониторинг.
9. Promotion. Подписанная версия становится доступна рабочему агенту.
10. Наблюдение и rollback. Метрики сравниваются с контрольной версией; при нарушении условий выполняется отзыв.

Архитектура должна хранить связь между четырьмя сущностями: задачей, трассой, созданным артефактом и последующими решениями, где он применялся. Без этой цепочки невозможно определить радиус деградации.

Интерпретация. Отдельный verification gate важнее большого числа формальных стадий. Если один и тот же процесс создаёт навык, пишет для него тест, оценивает результат и разрешает promotion, все стадии могут повторять одну ошибку. Независимость сигнала важнее количества отметок в pipeline.

Редакционная рекомендация. На первом этапе не стоит разрешать агенту одновременно менять framework, skill bank и инструменты в одной эволюционной транзакции. Разделение обновлений облегчает причинный анализ: становится понятнее, какой объект дал улучшение или регрессию.

Метрики здоровья

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

Метрика	Что измеряет	Как интерпретировать	Главное ограничение
Delta pass rate	Разницу между агентом с обновлением и зафиксированным baseline	Положительная разница указывает на пользу в данном eval	Не доказывает переносимость и зависит от качества тестов
Skill utility	Долю случаев, где извлечённый навык улучшил результат относительно контроля	Показывает практическую ценность конкретного навыка	Требует контрфактического запуска или надёжного контроля
Retrieval precision	Насколько часто выбранная запись действительно релевантна задаче	Отделяет качество хранилища от качества поиска	Нужна разметка релевантности или проверяемый proxy
Regression rate	Частоту ухудшений после promotion по сегментам	Помогает обнаружить локальный ущерб за средним ростом	Зависит от полноты регрессионного набора
Safety drift	Изменение результатов независимого safety-eval между версиями	Показывает направление накопительного сдвига	Не охватывает риски, отсутствующие в eval
Poisoning recurrence	Повторное появление отозванного шаблона или его производных	Проверяет эффективность очистки зависимой ветви	Сложно обнаруживать семантически изменённые варианты
Canary divergence	Разницу поведения canary и контрольной версии	Даёт ранний сигнал перед широким promotion	Canary может не представлять будущую нагрузку
Rollback readiness	Возможность определить затронутые версии и восстановить прежнее состояние	Измеряет управляемость деградации	Формальная кнопка отката не гарантирует полноту восстановления
Provenance coverage	Долю активных артефактов с полной цепочкой происхождения	Показывает, насколько система пригодна для аудита	Полнота метаданных не подтверждает их истинность

Метрики нужно связывать с версиями. Сравнение текущего агента с неопределённым «прошлым состоянием» бесполезно, если одновременно менялись модель, skill bank, инструменты и набор тестов. Для причинного анализа необходимо фиксировать конфигурацию целиком.

Редакционная рекомендация. Отчёт об эволюции должен показывать не только лучшие результаты, но и число кандидатов, долю отклонённых обновлений, сегменты с регрессиями, причины rollback и объём навыков без полной provenance. Это снижает стимул превращать promotion rate в самоцель.

Что нас ждёт

Интерпретация. Ближайшее развитие self-evolving coding agents, вероятно, будет происходить не вокруг одной техники, а вокруг совместного изменения нескольких слоёв. Таксономия уже охватывает framework, memory, skills, tools, models и collaboration structures, а Mem2Evolve отдельно ставит вопрос совместной эволюции опыта и инструментов.

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

Третья линия — отдельные eval для памяти и её использования. Наличие Mem2ActBench в исследовательском пакете указывает на потребность оценивать переход от сохранённой информации к действию, а не только качество самой записи.

Четвёртая — более строгая работа с персональной и долгоживущей памятью. PerMemSafe показывает, что безопасность такой памяти является самостоятельным исследовательским направлением. Для продуктовых систем это означает необходимость контроля срока жизни, области доступа и происхождения записей.

Пятая — усиление verification как точки ограниченного, но целевого надзора. Результат ANCHOR не отменяет другие меры, однако делает проверку перед promotion естественным местом для человеческого или независимого машинного контроля.

Редакционная рекомендация. Успех будущих систем следует оценивать не по числу автоматически созданных навыков, а по доказанной полезности после независимого eval, низкой частоте регрессий и способности точно отозвать неудачное обновление. «Больше памяти» и «больше эволюционных итераций» сами по себе не являются признаками прогресса.

Ограничения

Материал основан только на исследовательском пакете и фиксирует состояние на 27 августа 2026 года. Он не добавляет внешние сведения о реализациях, датасетах, стоимости запусков или независимых репликациях.

Числа CODESKILL и Socratic-SWE являются результатами, заявленными авторами соответствующих работ при собственных экспериментальных условиях. Они не представлены здесь как независимая проверка и не сравниваются напрямую между собой.

Таксономия из шести объектов описывает поле, но не задаёт единственную обязательную архитектуру. Предложенные в статье стадии promotion, схема карточки навыка, метрики и чек-лист являются редакционной инженерной рекомендацией, а не заявленным стандартом источников.

Работа ANCHOR показывает возможность снижения safety drift при ограниченном надзоре и выделяет verification phase как эффективную точку вмешательства в своих условиях. Из этого нельзя заключить, что verification устраняет все ошибки или заменяет изоляцию, canary и мониторинг.

EVOMAL демонстрирует риск self-poisoning, но исследовательский пакет не даёт оснований количественно оценить частоту этого явления во всех self-evolving-системах. Аналогично, наличие работ о мета-памяти, персональной памяти и memory-to-action evaluation подтверждает направления исследования, но не универсальную зрелость решений.

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

FAQ

Самообучающийся coding agent обязательно меняет веса модели?

Нет. Эволюционировать могут framework, память, навыки, инструменты, модели и структуры взаимодействия. Во многих системах накопление опыта возможно без обновления весов базовой модели.

Чем навык отличается от записи в памяти?

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

Почему успешного прохождения тестов недостаточно?

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

Что такое self-poisoning?

Это накопительный риск, при котором ошибочный или вредоносный шаблон сохраняется во внутренней памяти, повторно извлекается и тиражируется в следующих решениях.

Где лучше ставить контроль эволюционного цикла?

Работа ANCHOR указывает на verification phase как наиболее эффективную точку ограниченного вмешательства в её условиях. На практике этот контроль следует дополнять независимым eval, canary, мониторингом и rollback.

Как доказать, что новый навык действительно полезен?

Нужно сравнить агента с кандидатом и зафиксированный baseline на задачах, не участвовавших в создании навыка, проверить отрицательные примеры и отдельно измерить регрессии и safety drift.

Можно ли напрямую сравнивать результаты CODESKILL и Socratic-SWE?

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

Что должно откатываться вместе с навыком?

Не только содержимое записи, но и индекс retrieval, зависимости, связанные инструменты, политики и маршрутизация. Иначе прежнее влияние может сохраниться после формального удаления.

Какая метрика важнее всего?

Одной достаточной метрики нет. Pass rate нужно рассматривать вместе с регрессиями, качеством retrieval, safety drift, provenance, поведением canary и готовностью к rollback.

Источники

1. Self-Evolving Coding Agents — подтверждает таксономию поля и выделение шести объектов эволюции: framework, memory, skills, tools, models и collaboration structures.
2. CODESKILL: Learning Self-Evolving Skills for Coding Agents — источник по управлению skill-bank и заявленным приростам pass rate относительно no-skill и prompt/memory baseline.
3. Socratic-SWE — подтверждает подход с задачами из прошлых трасс и заявленный результат 50,40% на SWE-bench Verified после трёх итераций при условиях работы.
4. Towards Healthy Evolution — источник тезиса о снижении safety drift при ограниченном надзоре и эффективности контроля verification phase в подходе ANCHOR.
5. Mem2Evolve — подтверждает исследовательское направление совместной эволюции опыта и инструментов.
6. EVOMAL: Self-Poisoning in Self-Evolving Coding Agents — источник тезиса о self-poisoning и повторном тиражировании вредоносных или ошибочных шаблонов из памяти агента.
7. MetaMem — подтверждает выделение эволюции мета-памяти в самостоятельное направление.
8. PerMemSafe — источник по безопасности долгоживущей персональной памяти.
9. Mem2ActBench — подтверждает необходимость отдельной оценки использования долговременной памяти при переходе от записи к действию.