⚠️ Текст исследования обрезан на описании STEWARD. Результаты самого STEWARD по таблицам и рисункам не видны, только по аннотации и введению. Всё про диагностику (модели, подбор инструментов, скилы) разобрано по полному тексту разделов 3–4.
TL;DR
Агент с большим каталогом инструментов находит почти все нужные, но вместе с ними тянет кучу лишних. Он вспоминает почти всё нужное и при этом путается в похожих и устаревших вариантах. Второй вывод: скилы, накопленные агентом на старых версиях инструментов, со временем перестают помогать, а местами вредят. Метод STEWARD (менеджер экосистемы) предлагает держать инструменты и скилы как связанную пару и обновлять скил, когда меняется инструмент.
Боль знакомая. Инструмент в MCP обновили: старый остался, рядом появился новый, который делает то же за три вызова вместо одиннадцати. Агент по привычке идёт старым путём. Задача выполнена, всё зелёное, но вы платите за лишние шаги. Хуже того, скил, написанный под старый инструмент, продолжает «подсказывать» устаревший путь. Причина: успех задачи скрывает упущенные возможности. Агент не сравнивает свой путь с лучшим, он просто доводит дело до результата привычной дорогой. Когда исследователи убрали лишние и устаревшие инструменты, результат заметно вырос. Когда дополнительно подсунули готовый план действий, прироста не было. Узкое место в выборе инструментов, а не в планировании.
STEWARD работает в три хода. Он отслеживает связь «скил ↔ инструмент». Когда инструмент меняется, он точечно обновляет затронутые скилы, а не перегенерирует всё с нуля. Во время задачи он выдаёт агенту только нужные в этот момент инструменты и инструкции к ним. Сам STEWARD — код, но его логику можно перенести в ручной процесс: аудит скилов при каждом изменении набора инструментов и сужение набора под задачу.
Схема метода (STEWARD, по аннотации и введению)
ШАГ 1: Хранить скилы вместе со связями «этот скил использует эти инструменты»
и статусом доступности → библиотека скилов с зависимостями
ШАГ 2: Инструмент изменился/исчез/появился аналог → обновить ТОЛЬКО затронутые скилы
(инкрементально, не пересобирать всё) → актуальная библиотека
ШАГ 3: Во время задачи: показать агенту узкий набор инструментов + релевантные скилы,
менять набор по ходу, если видно, что чего-то не хватает → компактный «вид» ресурсов
Это код (отдельный менеджер над агентом). Шаги выполняются в процессе работы агента, не в одном промпте.
Пример применения
Задача: Вы руководите маркетингом интернет-магазина. В Claude Code подключены MCP-инструменты к amoCRM, «Яндекс Метрике» и Google Таблицам. Есть скил weekly-leads-report, который агент написал себе полгода назад. Разработчики CRM-коннектора выкатили обновление. Старые get_leads и get_lead_details остались, но появился get_leads_with_details, который делает то же за один вызов. Скил по-прежнему работает и отчёт собирается. Но вы подозреваете, что агент гоняет десятки лишних вызовов и тратит токены.
Промпт:
Проведи аудит скила weekly-leads-report после обновления инструментов.
Вот текущий скил:
[вставить содержимое SKILL.md]
Вот актуальный список инструментов amoCRM-коннектора с описаниями:
[вставить список]
Что изменилось в коннекторе:
- добавлен get_leads_with_details (объединяет get_leads + get_lead_details)
- параметр date_from в get_leads теперь называется created_from
Сделай по порядку:
1. Составь карту зависимостей: какие шаги скила какие инструменты вызывают.
2. Для каждого шага отметь статус: «работает как есть» / «параметр устарел» /
«есть более короткий путь» / «инструмента больше нет».
3. Для шагов со статусом «более короткий путь» посчитай, сколько вызовов
было и сколько станет.
4. Перепиши ТОЛЬКО затронутые шаги. Остальные не трогай.
5. В конце выдай список шагов, которые ты не смог проверить без запуска.
Результат: Модель выдаст таблицу «шаг скила → инструмент → статус». Далее будет оценка экономии вызовов по затронутым шагам и переписанные только затронутые фрагменты скила. В конце придёт список того, что надо проверить запуском. Заменить скил целиком она не предложит, потому что это прямо запрещено в пункте 4.
Почему это работает
Слабость. Агент выбирает инструмент по описаниям. Когда в каталоге похожие и устаревшие варианты, а описания неточные, он берёт нужное вместе с лишним. Скилы, написанные под старую версию, «вшивают» устаревший путь в привычку агента. Рабочий старый путь никто не проверяет, поэтому улучшения остаются незамеченными.
Сильная сторона. Если дать модели ровно те инструменты, которые сейчас актуальны, она их использует хорошо. Готовый план сверху ничего не добавил. Модель умеет планировать, ей нужна чистая карта доступного. Ещё она хорошо сравнивает текст скила с текстом описания инструмента и находит расхождения.
Как метод это использует. Он не пересобирает знания, а связывает скилы с инструментами и обновляет точечно. Ваши рычаги: - Сужение набора (инструменты только под задачу) → меньше путаницы между похожими вариантами. - Запрет «переписать всё» → сохраняете рабочий опыт, а не теряете его при перегенерации. - Явный статус шага («работает / устарел / есть короче») → видно, где есть упущенная выгода, а не только где сломалось. - Частота аудита → проводите после каждого обновления коннекторов, а не по расписанию.
Шаблон промпта
В исследовании нет готового промпта: STEWARD реализован кодом. Шаблон ниже — ручной перенос логики «связать скил с инструментами и обновить точечно». Это адаптация принципа, а не промпт из статьи.
Проведи аудит скила {название_скила} после изменений в инструментах.
Скил:
{текст_скила}
Актуальные инструменты (названия, параметры, описания):
{список_инструментов}
Что изменилось:
{список_изменений}
По порядку:
1. Карта зависимостей: какой шаг скила какие инструменты вызывает.
2. Статус каждого шага: «работает как есть» / «параметр устарел» /
«есть более короткий путь» / «инструмента больше нет».
3. Для «более короткого пути» посчитай вызовы: было → станет.
4. Перепиши только затронутые шаги, остальное не трогай.
5. Список того, что нельзя проверить без запуска.
Подставьте: {название_скила} — имя скила, {текст_скила} — содержимое файла, {список_инструментов} — описания из вашего MCP или коннектора, {список_изменений} — заметки об обновлении или то, что вы сами заметили.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита скила после изменений в инструментах. Адаптируй под мою ситуацию: [опиши, какие скилы и инструменты у тебя есть].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие инструменты подключены, что в них поменялось и где лежат скилы. Это нужно, чтобы построить карту «скил ↔ инструмент», на которой держится метод. Она возьмёт паттерн из шаблона и адаптирует под вашу связку.
Ограничения
⚠️ Главный метод — код: STEWARD — отдельный менеджер над агентом. Без программирования можно воспроизвести только идею: ручной аудит и сужение набора. Исследователи этот ручной вариант не проверяли.
⚠️ Идеальных данных у вас нет: в диагностике «Oracle Tools» означает, что модели заранее дали только верные актуальные инструменты. В реальной работе такого списка нет, его надо собирать самому.
⚠️ Синтетическая среда: сервисы и задачи сгенерированы, пользователь — тоже модель. Мелкие ручные изменения в вашей компании могут вести себя иначе.
⚠️ Диагностика на одной модели: контролируемые эксперименты и сравнение скил-методов шли на одной базовой модели. Общую картину поддерживает сравнение девяти моделей, но детали могут отличаться.
⚠️ Текст обрезан: результаты STEWARD и подробности его устройства в доступном фрагменте не видны. Не делайте выводов о его точном приросте.
Как исследовали
Исследователи собрали 42 области с «живыми» сервисами (с базой данных и MCP-интерфейсами) и 1588 многошаговых задач. Затем они шесть раз меняли набор инструментов, не отнимая возможностей: переименовывали и добавляли параметры, разбивали один инструмент на несколько, сливали несколько в один. Старое могло остаться рядом с новым, и тогда агенту надо выбирать, или исчезнуть, тогда надо искать замену. Часть описаний нарочно делали неполными и устаревшими. Для каждой версии динамическим программированием считали кратчайший путь к цели и сравнивали с ним путь агента.
Девять сильных моделей и агентных оболочек показали успех не выше 42%. Лучшая вспоминала около 90% нужных инструментов, но точность отбора была около 20%: нужное находят, лишнее не отсекают. Дальше шла диагностика по ступеням помощи: узкий домен, инструменты задачи, только актуальные инструменты, готовый путь. Успех рос до ступени «только актуальные инструменты». Готовый путь ничего не добавил. Значит, проблема не в планировании, а в выборе между похожими и устаревшими вариантами.
Затем сравнили четыре готовых метода накопления скилов с агентом без скилов. На первой версии все четыре помогли. По мере смены версий преимущество растаяло. В одной из версий два метода обнулились по умению адаптироваться к ухудшению пути, а агент без скилов сохранял около 10%. Самый сильный метод оказался в 2–3 раза дороже других по расходу на обслуживание скилов. Практический вывод: скилы без привязки к инструментам стареют, а чем больше вы вкладываетесь в их улучшение, тем дороже обновлять.
Адаптации и экстраполяции
💡 Адаптация для файла инструкций агента: добавьте в CLAUDE.md или AGENTS.md правило, которое возвращает агенту привычку сверяться с актуальным каталогом. Это моя экстраполяция, в статье такого правила нет.
Перед тем как применять любой скил, сверь инструменты, которые он вызывает,
с текущим списком доступных инструментов.
Если инструмент из скила отсутствует, переименован или есть более короткая
замена, не следуй скилу слепо: выполни задачу актуальным путём и в конце
сообщи, какой шаг скила устарел.
🔧 Техника: сузить набор → меньше путаницы. Если можете управлять подключёнными инструментами, оставляйте под конкретную задачу или сессию только нужные. В исследовании сужение инструментов до домена и до задачи стабильно повышало успех и эффективность. В чате или кастомном GPT то же делается прямым перечислением: «Для этой задачи используй только: A, B, C. Остальные не вызывай».
Ресурсы
- Δτ-Bench: Pushing Agents Toward a Moving Capability Frontier (Preprint)
- Код: github.com/zjunlp/delta-tau-bench
- Датасет: huggingface.co/datasets/zjunlp/delta-tau-bench
- Авторы: Shuofei Qiao, Xuanguang Pan, Yijun Chen, Wendi Feng, Bin Wu, Runnan Fang, Yuqi Zhu, Shumin Deng, Emine Yilmaz
- Университеты: Zhejiang University, University College London
- Сравнивались методы накопления скилов: EvoSkill, AutoSkill, Trace2Skill, SkillOpt