Короткий ответ

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

Главное правило: куратор не должен автоматически удалять всё, чем давно не пользовались. Сначала нужно понять, почему skill не вызывался и что сломается без него.

Почему каталог начинает шуметь

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

  • почти одинаковыми инструкциями;
  • навыками под один конкретный сбой;
  • устаревшими ссылками и API;
  • правилами, которые противоречат друг другу;
  • копиями одного umbrella-skill;
  • модулями, которые никто не проверял после создания.

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

Что должен знать куратор

Минимальная telemetry-запись может содержать:

  • имя skill;
  • источник и владельца;
  • дату создания;
  • последний вызов;
  • последний просмотр;
  • количество patch;
  • состояние: active, stale или archived;
  • признак pin;
  • дату последней проверки.

Telemetry — не доказательство полезности. Частый вызов может означать, что skill хорош, а может — что он постоянно ломается. Это сигнал для ревью.

Четыре жизненных состояния

active → stale → archived
   ↑       │
   └───────┘ reactivated после проверки

Active

Skill используется или недавно проверялся.

Stale

Давно не было вызова. Ничего не удаляем: сначала выясняем, не нужен ли этот skill сезонно или для аварийного случая.

Archived

Skill убран из активной маршрутизации, но сохранён в backup/archive и может быть восстановлен.

Pinned

Skill защищён от автоматического перехода, потому что он критичен для базового контура, даже если используется редко.

Сроки вроде «30 дней до stale и 90 дней до archive» — это политики конкретной системы, а не природный закон. Для сезонных, юридических и аварийных навыков они должны отличаться.

Что такое consolidation

Consolidation — попытка объединить несколько пересекающихся skills в один umbrella.

Хороший кандидат:

guide-writing-short
guide-writing-long
guide-writing-faq
          ↓
guide-writing

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

Безопасный порядок работы куратора

  1. Собрать dry-run отчёт.
  2. Отделить bundled и Hub skills от агентских.
  3. Сверить candidates с usage и владельцем.
  4. Проверить pinned и load-bearing skills.
  5. Сделать backup.
  6. Предложить архивирование или merge.
  7. Применить только разрешённые переходы.
  8. Пересобрать индекс и проверить, что нужные навыки по-прежнему находятся.
  9. Оставить отчёт с конкретным diff.

Автоматический curator должен быть особенно консервативным с двумя группами:

  • системные bundled/Hub skills, которые поставляет сам runtime;
  • skills с действиями, влияющими на файлы, секреты, публикацию или внешние API.

Что нельзя делать автоматически

  • архивировать skill только из-за нулевой активности;
  • объединять skills без сохранения исходных версий;
  • менять bundled-инструкции, не проверив источник обновления;
  • принимать LLM-оценку «дубликат» как единственное доказательство;
  • удалять references и scripts, не проверив ссылки;
  • считать GitHub-копию автоматически разрешённой заменой live-профиля.

Куратор должен облегчать обслуживание, а не становиться вторым агентом без присмотра.

Практическая политика для маленького каталога

Пока skills меньше сотни:

каждое изменение → diff + test
каждое новое имя → объяснить триггер
каждый stale → сначала pin/review, потом archive
каждый merge → backup + список сохранённых правил
каждый archive → проверяемый restore

Не обязательно сразу строить сложную LLM-службу. Таблица usage, cron, dry-run и ручной review часто полезнее, чем автоматический «умный уборщик».

Как понять, что curator помог

Через один цикл обслуживания должны быть измеримы:

  • меньше дубликатов;
  • меньше ложных срабатываний маршрутизации;
  • сохранены все load-bearing skills;
  • archived можно восстановить;
  • индекс стал короче или точнее;
  • ни один production-инструмент не потерял права доступа;
  • человек может объяснить каждое изменение.

Если после curator никто не знает, что он сделал, это не обслуживание, а новая зона риска.

Что запомнить

Память агента должна не только накапливаться, но и проходить ревизию. Начните с telemetry, pin, dry-run и backup. Автоматическое объединение подключайте последним, когда уже умеете увидеть и откатить его последствия.

Следующий цикл можно продолжить отдельными материалами о sandbox, prompt injection и измерении стоимости длинных запусков.

Что читать дальше

Частые вопросы

Что главное в гайде «Куратор skills: как чистить и развивать память AI-агента»?

Каталог skills должен не только расти, но и обслуживаться. Разбираем безопасную работу куратора: usage, stale, archive, pin, backup и осторожное объединение.

Нужно ли внедрять всё сразу?

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

Что проверить перед запуском?

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

Источники

Редакторский статус: REVIEW. Нужна отдельная проверка терминов curator/pruning/consolidation и ToV-pass.