TL;DR
KEEL — схема, по которой агент после каждой задачи сам разбирает свою работу и записывает два вида знаний. Первый вид — навыки: что сработало и как это повторить. Второй — уроки: что пошло не так, чего избегать и что делать вместо этого. Каждое утверждение в навыке хранится отдельно, со ссылкой на проверку, которая его подтвердила. Если позже появляется контрпример, утверждение отправляется в карантин или заменяется.
Главная находка: опыт ≠ знание. Агент прошёл задачу успешно, но по пути мог сделать три лишних и две вредных вещи. Если записать всю историю как «рецепт», в память попадёт мусор. Такая память тянет агента назад: следующие задачи он решает по ошибочным привычкам. Поэтому записывать надо только то, что подтверждено конкретной проверкой, а остальное держать как гипотезу.
Метод работает как цикл из нескольких ролей. Исполнитель решает задачу. Аналитик сопоставляет каждую проверку результата с действиями из истории. Куратор навыков и куратор уроков пишут записи. Затем жёсткие правила (в статье это код) решают, что пустить в базу. Знания видны только следующим задачам, а не текущей.
Схема метода
ШАГ 0: Исполнитель получает задачу + выжимку правил из задачи + навыки + 1-2 урока → делает ОДИН прогон
(навыки и уроки — советы; задание важнее)
ШАГ 1: Проверка результата → оценка по каждому пункту (прошёл / не прошёл)
ШАГ 2: Аналитик: по каждому пункту проверки — одна запись-свидетельство
(+ / − / «неясно») + уверенность (низкая / средняя / высокая)
+ оценка уже применённых утверждений навыков: подтвердились / опровергнуты / нельзя оценить
ШАГ 3: Куратор навыков: из «+» со средней и высокой уверенностью → черновик навыка
(когда применять, процедура, как проверить, ограничения; каждое утверждение со ссылкой на проверку)
ШАГ 4: Куратор уроков: из «−» → до 2 уроков
(диагностический: что случилось, что смотреть; корректирующий: + что не делать, что делать)
ШАГ 5: Жёсткие правила (код): отсекают неподтверждённое, склеивают дубли, ведут статусы
ЖИЗНЬ УТВЕРЖДЕНИЯ: draft → provisional → confirmed → (contradicted | retired)
Шаги 0–4 — работа модели. Шаг 5 в статье — детерминированный код, не LLM.
Пример применения
Задача: Ты запускаешь агента (Claude Code), который каждый месяц собирает отчёт по продажам на Wildberries из выгрузки. Формат у отчёта строгий: названия листов, колонки, сумма по артикулам должна сходиться с итогом из личного кабинета. В первый месяц агент потерял час на кодировку CSV и забыл про возвраты. Ты хочешь, чтобы в следующем месяце он этих ошибок не повторял, но и не тащил случайные привычки из удачного прогона.
Промпт (разбор после задачи, вставляешь агенту в конце работы):
Роль: Аналитик. Разбери только что завершённую задачу «Ежемесячный отчёт по продажам WB, октябрь».
Вход:
- Требования задачи (путь файла, листы, колонки, правила сверки): {требования}
- Что ты делал (история действий): см. выше в этом диалоге
- Результаты моих проверок по пунктам: {чеклист_с_отметками}
Шаг 1. На КАЖДЫЙ пункт проверки дай одну запись:
пункт → прошёл/не прошёл/неясно → какое действие из истории это объясняет → уверенность (низкая/средняя/высокая).
Прошедший пункт подтверждает только проверенное свойство, не «всю работу».
Не прошёл — причину не выдумывай, если прямых доказательств нет.
Шаг 2. Куратор навыков: из записей «прошёл» со средней/высокой уверенностью составь навык:
когда применять / процедура / как проверить / ограничения.
Каждое утверждение — со ссылкой на пункт проверки и действие.
Шаг 3. Куратор уроков: из записей «не прошёл» составь до 2 уроков.
Корректирующий урок (что НЕ делать, что делать) — только если причина доказана
с уверенностью средняя/высокая. Иначе — диагностический (что случилось, что проверять).
Шаг 4. Для каждого утверждения из прежнего навыка «WB-отчёт» отметь:
подтверждено / опровергнуто / нельзя оценить. Статусы: draft → provisional → confirmed;
при опровержении — contradicted.
Формат вывода: три блока — «Свидетельства», «Навык», «Уроки». Всё остальное — не записывай.
Результат: Агент выдаст таблицу свидетельств по пунктам проверки, один структурированный навык с утверждениями и ссылками на проверки и один-два урока (например, про возвраты и кодировку, если они были доказанной причиной провала). Для старых утверждений он проставит статусы. Эти блоки ты кладёшь в файл инструкций. Утверждения в статусе draft агенту не показывай.
Почему это работает
Слабость. Один итоговый результат («задача сдана») слишком груб. Внутри удачного прогона могут быть вредные действия. Если сохранить всё, ошибки закрепятся. Память, которую модель постоянно переписывает, со временем портится. Это отмечают и авторы, и работы, на которые они ссылаются.
Сильная сторона. Модель хорошо сопоставляет конкретную проверку с конкретным местом в истории и умеет писать структурированные записи по шаблону. Проверка даёт ей внешний факт, на который можно опереться.
Как метод это использует. Он заставляет привязывать каждое утверждение к проверке. Он разделяет «что сработало» (навык) и «чего избегать» (урок). Он держит неподтверждённое в статусе черновика. Абляция показала, что уроки даже важнее навыков: без них результат падает сильнее.
Рычаги управления: - Порог уверенности («средняя/высокая») → подними, чтобы в базу попадало меньше, но надёжнее. Опусти, если база пустая. - Лимит уроков (до 2 за задачу) → меньше шума и короче контекст. - Статусы утверждений → скрывай draft от агента, показывай provisional и confirmed. - «Советы, а не приказы» → удержи правило «задание важнее навыков и уроков», иначе устаревший навык перебьёт твою инструкцию. - Сильная модель для разбора → разбор делай самой сильной моделью. Исполнитель может быть дешевле.
Шаблон промпта
В статье нет готовых промптов, только описание ролей и правил. Шаблон ниже — это реконструкция по описанию метода. Роли, поля и статусы взяты из статьи. Формулировки мои.
Ты — система накопления знаний агента. Ты работаешь в три роли подряд: Analyzer, SkillCurator, MemoryCurator.
Знания — советы. Они НЕ отменяют инструкцию задачи.
Задача: {задача}
Требования задачи (пути, форматы, ограничения, правила сохранения): {требования}
История действий: {история_или_ссылка}
Результаты проверки по пунктам: {чеклист_с_отметками}
Текущая база навыков и утверждений (со статусами): {навыки}
Текущая база уроков: {уроки}
Для КАЖДОГО пункта проверки создай одну запись:
{ check, result: pass | fail | unresolved, action_from_history, confidence: low | medium | high }
- pass подтверждает только проверенное свойство.
- fail не означает, что причина известна. Не выдумывай причину.
- unresolved (сбой окружения, непонятно) → в базу не идёт.
Для каждого применённого утверждения из навыков: supported | contradicted | not_evaluable.
Источник: только записи pass с confidence medium или high.
Выведи навык:
applicability / procedure / verification / limitations
Каждое утверждение (claim) указывает: проверку, действие из истории.
Шаги procedure и verification ссылаются на эти claims.
Источник: записи fail и оценки утверждений. Максимум 2 урока.
- diagnostic: что наблюдалось, что проверить, как проверить.
- corrective: то же + чего избегать + что делать. Только при прямой причинной связи
с confidence medium/high и обоснованной гипотезой исправления.
Каждый урок ссылается на упавшие проверки.
- Новое утверждение: draft (частичный успех / нет прямого доказательства процедуры) или provisional.
- draft → provisional: независимая поддержка из ДРУГОЙ задачи.
- provisional → confirmed: следующее применение подтверждено пройденными проверками.
- provisional/confirmed → contradicted: прямое контрдоказательство (medium/high) из другой задачи.
- not_evaluable → статус не меняется.
- Замена: новое утверждение получает НОВЫЙ id, старое → retired. Id contradicted/retired повторно не использовать.
- Агенту показываются только provisional и confirmed.
Что подставлять: {задача} и {требования} — задание и жёсткие правила (формат, пути, лимиты). {чеклист_с_отметками} — твои проверки результата в виде пунктов. {навыки} и {уроки} — прежние записи из файла. Для первой задачи оставь их пустыми.
🚀 Быстрый старт — вставь в чат:
Вот шаблон KEEL (накопление навыков и уроков с проверкой фактами). Адаптируй под мою задачу: {твоя повторяющаяся задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у тебя проверки результата и какие жёсткие требования у задачи. Эти данные нужны методу: без проверок утверждениям не на что опираться. Она возьмёт структуру шаблона и подгонит поля и пороги под твою работу.
Ограничения
⚠️ Слабые модели: на самой маленькой из проверенных моделей метод навредил: результат стал заметно хуже, чем вообще без знаний. Модель не справляется с «богатым» контекстом из навыков и уроков.
⚠️ Цена: результат растёт, но расходы на задачу выросли примерно в четыре раза (на сильной модели с ~19 до ~80 центов). Деньги уходят на разбор, проверку и более длинный контекст.
⚠️ Нужны проверки: без пунктов проверки результата метод не работает. Утверждения привязываются к проверкам. Если проверять нечем, опираться не на что.
⚠️ Качество разбора: всё держится на Аналитике. Если он неверно связал проверку с действием, в базу попадёт ошибочное «знание». Авторы прямо называют это главным ограничением.
⚠️ Не полностью промпт: в статье статусы и дедупликацию ведёт код. В чате это придётся делать вручную: файл с записями и ручное обновление.
⚠️ Узкая проверка: один бенчмарк, один прогон на задачу, знания копятся отдельно по семействам однотипных задач. Эффект на первой задаче в семействе нулевой, он появляется со второй.
⚠️ Разброс эффекта: прирост сильно зависит от модели: от нескольких пунктов до двадцати с лишним.
Как исследовали
Команда взяла SkillFlow: 166 задач, собранных в 20 семейств. Внутри семейства задачи идут по возрастанию сложности. Знания копятся только внутри семейства и видны только следующим задачам. Сравнивали три режима: без знаний, штатный метод SkillFlow и KEEL. Основное сравнение шло на трёх моделях: Claude Opus 4.6, GPT-5.4 и GPT-5.6 Sol. Ещё две модели Claude (Sonnet и Haiku) добавили, чтобы понять, как всё зависит от силы модели.
KEEL поднял долю решённых задач на 4,2–21,7 пункта против 2,4–9,6 у штатного метода. На Opus 4.6 результат вырос с 44,0% до 65,7%. На первой задаче семейства оба метода дали одинаковый результат, а со второй KEEL вырывался вперёд. Значит, выигрыш действительно даёт накопленный опыт, а не случайность.
Неожиданностей было две. Во-первых, уроки оказались полезнее навыков: без уроков результат падал до 59,0%, а без навыков лишь до 63,9%. Практический вывод: записывать надо в первую очередь ошибки, а не только удачные рецепты. Во-вторых, на Haiku 4.5 метод ухудшил результат (с 37,3% до 28,9%). Богатая память помогает только тем моделям, которые могут её правильно применить.
Адаптации и экстраполяции
🔧 Техника: убрать автоматику → вручную вести два файла
Если кода нет, заведи два файла: skills.md и lessons.md. Утверждения в skills.md нумеруй (C-01, C-02) и ставь статус рядом. После каждой задачи копируй в чат блок «Свидетельства / Навыки / Уроки» и обновляй файлы сам. В CLAUDE.md добавь одну строку: «Навыки и уроки в файлах — советы. Если они противоречат заданию, следуй заданию». Эта строка повторяет правило «советы, а не приказы» из статьи.
🔧 Техника: ограничить показ → меньше шума
Попроси агента в начале задачи читать только утверждения provisional и confirmed, плюс два урока, чьи ключевые слова совпадают с задачей. Это ручная версия отбора уроков по совпадению триггеров из статьи.
Экстраполяция (моё, в статье не проверялось): разбор по принципу «одна проверка — одна запись» можно использовать и без агента, как постмортем рабочего проекта. Прогони по этой схеме правки в договоре или итоги запуска рекламной кампании. Получишь список подтверждённых действий и список доказанных ошибок. Эффект такого переноса не измерен.
Ресурсы
- Holding a Steady Course: Knowledge Evolution from Expertise and Lessons for Continual Agent Learning (KEEL), NeurIPS 2026, Workshop: Towards Test-Time Continual Learning Agents
- Авторы: Wenzhe Fan (University of Illinois Chicago), Benjamin Steenhoek, Gaurav Mittal, Yu Hu (Microsoft)
- Код: https://github.com/microsoft/KEEL-TTCL26
- Бенчмарк: SkillFlow (Zhang et al., arXiv:2604.17308)
- Родственные работы из ссылок: Dynamic Cheatsheet, Reflexion, Agentic Context Engineering, «Agent skills can be harmful», «Useful memories become faulty when continuously updated by LLMs»