ИИ запоминает исправления уязвимостей: как работает Copilot Memory
GitHub добавила Copilot Memory в agentic autofix. Когда функция включена, агент читает сохранённые сведения о прежних исправлениях, а после нового исправления может записать шаблон решения на будущее. Идея проста: репозиторий имеет собственные соглашения по безопасности, которые общая модель не знает с первого взгляда.

Внедрим ИИ в работу вашей компании
Бесплатно разберём процессы и подготовим план запуска ИИ.

Что именно запоминается
Официальное обновление говорит о шаблонах исправлений и контексте, который помогает закрывать предупреждения безопасности. Память затем могут использовать и другие функции Copilot, например кодовое ревью и облачный агент. Это не база гарантированно верных ответов: прежнее решение могло подходить только для одной версии библиотеки или одного участка кода.
Представим сервис, где все запросы к внешнему API проходят через общий модуль проверки. Без контекста агент может предложить локальный фильтр прямо в обработчике. Память о принятом паттерне направит его к общему модулю и уменьшит шанс создать второй, несовместимый способ защиты. Но если архитектура изменилась, старый совет нужно пересмотреть.
Как проверить до включения
Выберите несколько исторических предупреждений с известными принятыми исправлениями. Сравните предложения agentic autofix с памятью и без неё. Оценивайте не совпадение строк кода, а закрытие причины уязвимости, совместимость со стилем проекта и результаты тестов. Добавьте один случай, где старый паттерн сознательно устарел: он покажет, умеет ли агент учитывать новые указания.
Настройте ревью того, что сохраняется в память. Секреты, временные обходы и детали единичного инцидента не должны превращаться в общую инструкцию. Желательно знать, кто может видеть и удалять записи, как ограничена область репозитория и сколько действует память. Без этих правил команда рискует закрепить ошибку и затем автоматически повторять её.
Предварительный статус и человеческое решение
GitHub помечает и agentic autofix, и Copilot Memory как публичное превью. Набор возможностей и поведения может измениться; перед рабочим включением проверьте актуальные условия в админке. Само исправление всё равно требует обычного ревью кода, тестов и оценки безопасности. Если после запуска новых предупреждений стало меньше, посмотрите, не выросло ли число повторных откатов.
Хороший результат памяти — не автономная печать патчей, а меньше времени на объяснение проверенных практик при сохранении ответственности инженера. Для этого у команды должна быть возможность поправить устаревший шаблон, прежде чем он повлияет на следующие исправления.
Память как кодовая политика
Команда может оформить принятые шаблоны исправлений в документации репозитория и сверять с тем, что запоминает агент. При расхождении приоритет должен быть у проверенного правила, а не у случая, который модель увидела последним. Владелец безопасности может просматривать спорные записи памяти после значимых обновлений зависимостей и архитектуры.
Измерять пользу стоит на новых предупреждениях, а не на тех, из которых память была создана. Иначе агенту легко повторить уже известный ответ, а команда получит ложное впечатление прогресса. Хороший эксперимент отделяет историю для обучения от свежих задач для проверки, как в обычном тестировании модели.
О материале и источниках
Редакционный материал ЛИИТ. Учебные примеры вымышлены, иллюстрации созданы с помощью ИИ.
- github.blog — первичный материал
Первоисточник опубликован 2026-09-25; факты отделены от редакционных рекомендаций.
Опубликовано