Как опыт превращается в рабочие навыки ИИ-агента

Когда память важнее очередного промта

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

Работа WikiSkill от Google Research предлагает простую мысль: если агент чему-то научился на своих ошибках, это знание надо хранить отдельно и системно . Не только в виде текущего навыка, но и в виде постоянной базы знаний, куда складываются повторяющиеся паттерны, причины провалов и рабочие приёмы [источник: WikiSkill, разделы 1, 3] . Такой «вики-слой» живёт дольше, чем очередная правка навыка, и становится опорой для следующих обновлений навыков .

Если вы строите ИИ-агентов, вы быстро упираетесь в другой вопрос: умеет ли система улучшать саму себя предсказуемо . WikiSkill как раз про это: как превратить разрозненный опыт запуска агента в воспроизводимую процедуру улучшения .

Что такое WikiSkill

В основе WikiSkill лежит разделение рабочего пространства агента на три слоя [источник: раздел 3.1] .

Схема WikiSkill: сырые логи, постоянная база знаний и активные навыки работают как отдельные слои одного пайплайна.

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

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

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

Ключевая идея тут в том, что навык и знание разведены . Навык можно откатить, если он ухудшил качество . А вот вики сохраняется и продолжает накапливать опыт . Значит, даже неудачная попытка не пропадает зря .

Коротко механика выглядит так :

🟠 Агент решает тренировочные задачи с текущими навыками и оставляет логи .

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

🟠 Предлагатель навыков читает вики, смотрит свежие логи и вносит одну атомарную правку: создать новый навык или поправить существующий .

🟠 Проверка на валидации решает, оставить правку или откатить её .

Во время тренировочных прогонов сам агент не читает вики . Авторы отдельно показали, что если дать агенту доступ к вики слишком рано, он начнёт опираться на неё при решении задач, а не превращать это знание в устойчивый навык . В итоге следы выполнения становятся менее полезны для дальнейшего улучшения [источник: раздел 5.1] .

Почему обычной эволюции навыков уже мало

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

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

Это особенно полезно для длинных и инструментальных задач, где провал редко объясняется одной строкой . Например :

🟣 агент зацикливается в текстовой среде и повторяет одно и то же действие ;

🟣 агент в задаче по таблицам пишет короткие обходные команды вместо надёжного скрипта ;

🟣 агент в длинных документах начинает читать всё подряд вместо точечного поиска ;

🟣 агент повторно предлагает идею, которую уже пробовали и отклонили .

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

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

Авторы прогнали WikiSkill на пяти бенчмарках и пяти моделях [источник: раздел 4.1] .

По задачам набор получился разношёрстный :

🟠 математика — LiveMath ;

🟠 поиск в сети — SealQA ;

🟠 работа с таблицами — SpreadsheetBench ;

🟠 вопросы по длинным документам — OfficeQA ;

🟠 интерактивная среда — ALFWorld .

По моделям тоже без перекоса в одну сторону: Qwen-3.5 4B, Qwen-3.5 9B, Qwen-3.6 27B, Gemma-4 31B и Gemini-3.5-Flash .

Сравнивали с тремя системами эволюции навыков: EvoSkill, Trace2Skill и SkillOpt, плюс с базовым вариантом без навыков вообще [источник: раздел 4.1] .

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

Что получилось

WikiSkill стабильно выигрывает и у режима без навыков, и у других методов эволюции навыков [источник: таблица 1, раздел 4.2] .

WikiSkill обходит базовый режим без навыков и другие методы эволюции навыков; отрыв растёт на более сильных моделях.

Средняя точность по пяти задачам выросла так :

🟣 Qwen-3.5-4B: с 26.2 до 38.5

🟣 Qwen-3.5-9B: с 29.9 до 47.4

🟣 Qwen-3.6-27B: с 39.4 до 63.3

🟣 Gemma-4-31B: с 41.3 до 54.9

🟣 Gemini-3.5-Flash: с 49.5 до 68.1

Коротко по цифрам :

🟠 чем сильнее модель, тем больше она выигрывает от эволюции навыков ;

🟠 внутри семейства Qwen прирост составил 12.3, 17.5 и 23.9 процентного пункта для моделей 4B, 9B и 27B соответственно [источник: раздел 4.2.1] ;

🟠 масштаб модели и эволюция навыков складываются, а не заменяют друг друга .

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

Ещё несколько наблюдений :

🟠 маленькая модель с навыками может обогнать большую без навыков: Qwen-3.5-9B с WikiSkill набрала 47.4, а Qwen-3.6-27B без навыков — 39.4 ;

🟠 на задачах с таблицами прирост особенно заметен: у Qwen-3.6-27B результат вырос с 40.8 до 81.7 ;

🟠 на математике улучшение устойчиво у всех моделей: например, Gemini-3.5-Flash выросла с 33.0 до 72.6 ;

🟠 не все задачи одинаково поддаются улучшению: на OfficeQA приросты меньше, а у маленькой Qwen-3.5-4B даже есть небольшое ухудшение .

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

Навыки можно переносить между моделями

Один из самых интересных результатов — навыки переносятся между моделями , иногда лучше, чем работают у автора этих же навыков [источник: таблица 2, раздел 4.2.2] .

Например, навык, который выработала Qwen-3.6-27B, поднял Qwen-3.5-9B на SpreadsheetBench до 50.5 . Для сравнения: без навыков у той было 24.3, а со своими собственными навыками — 33.6 .

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

Но перенос не всегда безопасен . Авторы показывают и отрицательный перенос . К примеру, навыки от Qwen-3.5-4B на задачах по таблицам ухудшили Gemini-3.5-Flash с 50.5 до 18.1 [источник: таблица 2, раздел 4.2.2] .

Почему так бывает :

🟣 маленькая модель записывает слишком низкоуровневые обходные приёмы ;

🟣 сильная модель из-за этого теряет свободу выбрать более общий и надёжный путь ;

🟣 фрагментированные инструкции приводят к лишним вызовам инструментов ;

🟣 у модели заканчивается бюджет шагов до завершения задачи .

Коротко :

🟠 навык — переносимый артефакт, но не универсальный ;

🟠 перенос между моделями надо проверять отдельно по типам задач ;

🟠 качество навыка зависит не только от того, кто его исполняет, но и от того, кто его нашёл .

Зачем здесь нужен именно вики-слой

Авторы отдельно проверили, что именно даёт постоянная база знаний, а не просто ещё один этап анализа [источник: раздел 5.1] .

Когда у модуля, который предлагает новые навыки, нет доступа к вики, средний результат на Gemini-3.5-Flash составляет 48.7 . Когда доступ есть, метрика поднимается до 63.7 . Разница — 15 процентных пунктов .

То есть дело в том, что система помнит контекст прошлых попыток .

Пример из ALFWorld: отклонённая правка не исчезает, а остаётся в вики и помогает сформулировать следующую, уже успешную версию навыка.

Особенно нагляден пример из ALFWorld . Сначала система замечает цикл действий, предлагает одно исправление, оно не проходит валидацию и откатывается . Но запись о неудачной правке остаётся в вики . На следующей итерации модуль видит: этот путь уже пробовали, он не помог . И формулирует другой, более конкретный навык — уже с успешным правилом поведения [источник: раздел 5.3] .

Журнал здесь становится рабочим знанием для следующего шага .

Что это меняет на практике

WikiSkill сдвигает разговор об ИИ-агентах в полезную сторону: как организовать накопление процедурного знания вне весов модели .

Для практики это даёт несколько выводов :

🟠 не всё надо дообучать — часть улучшений удобнее хранить как внешние навыки и базу знаний ;

🟠 память об ошибках должна жить дольше одной итерации ;

🟠 сильные модели особенно выигрывают от хорошей обвязки ;

🟠 перенос навыков между моделями реален, но его нужно проверять по типам задач ;

🟠 разделение “сырые логи → знание → навык” полезнее, чем сваливать всё в один промт или один файл инструкции .

Есть и ограничения . В работе навыки просто целиком подмешиваются в системный промт, так что вопрос выбора нужного навыка из большой библиотеки пока остаётся открытым . Валидация жёсткая: принимаются только те правки, которые сразу улучшают результат . А сама вики со временем может разрастись и потребовать чистки [источник: раздел Limitations] .

Вывод

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

Из результатов видно три главные мысли [источник: таблицы 1–3, разделы 4–5] :

🟣 эволюция навыков работает лучше, когда знание отделено от самих навыков ;

🟣 более сильные модели получают от таких навыков ещё больше пользы ;

🟣 навыки можно переносить между моделями, но перенос зависит от того, насколько общими оказались процедуры .

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