TL;DR
SHarP — способ найти в инструкциях и инструментах агента лишнее. Вы отключаете модули по одному (блок инструкций, инструмент, скил, механизм сжатия истории) и на тех же задачах смотрите две вещи: стало ли хуже и сколько токенов ушло. Модули, без которых качество падает, защищаете. Из остальных удаляете те, что дороже всего по токенам.
Главная находка: агенты, которые годами обрастают правилами, обычно сильно избыточны. Каждый сбой лечат новой строкой в промпте, новым инструментом или новым шагом. Харнес (обвязка вокруг модели: инструкции, инструменты, порядок шагов) только растёт. Часть правил давно ничего не даёт, но платит за них каждый запрос. В тестах после удаления большей части модулей качество оставалось прежним, а иногда росло. При этом удалять всё подряд нельзя: у одного агента качество при полной очистке упало вдвое.
Суть метода в четырёх шагах. Разбить агента на модули. Отключать каждый по очереди и мерить результат и стоимость. Составить «защитный список» из тех, без которых стало статистически хуже. Убирать остальные постепенно и проверять каждую усечённую версию на отдельных, не использованных ранее задачах.
Схема метода
ШАГ 1: Разбить агента на модули (инструмент, блок инструкций, скил, механизм)
→ список модулей; связанное (инструмент + его инструкция) — один модуль
ШАГ 2: Отключить каждый модуль по одному, прогнать dev-набор (~50 задач)
→ для каждого модуля: изменение качества и токенов
ШАГ 3: Сравнить с медианой по всем отключениям
→ «важен для качества» / «важен для экономии»
ШАГ 4: Защитить модули, без которых качество значимо падает
→ защитный список (в статье: p ≤ 0.05)
ШАГ 5: Остальные убирать по очереди — сначала самые «вредные» по токенам
→ лестница всё более урезанных версий
ШАГ 6: Прогнать каждую версию на отдельном validation-наборе (3 прогона на задачу)
→ выбрать лучшую по качеству и цене (+ контроль «всё выключено»)
Шаги 2–6 — отдельные прогоны. Всё в одном промпте не уместить.
Пример применения
Задача: Вы сделали агента поддержки для селлера на Wildberries. Он отвечает на вопросы покупателей, смотрит статус заказа, проверяет остатки, оформляет возврат. Системный промпт вырос до 14 блоков. Каждый раз, когда агент ошибался, вы добавляли строку: «никогда не обещай сроки», «всегда сверяйся с каталогом», «перед ответом перечитай историю». Счёт за токены растёт, и непонятно, что из этого нужно.
Промпт (в обычном чате, чтобы подготовить эксперимент):
Ниже системный промпт моего агента поддержки селлера Wildberries и список его инструментов.
[вставлен промпт и список инструментов]
Разбей это на модули для абляции: каждый инструмент, каждый блок инструкций, каждое правило-«заплатка».
Связанное (инструмент и его описание) держи вместе.
Для каждого модуля напиши, что значит «выключить» его: убрать блок или заменить нейтральной заглушкой.
Затем составь таблицу эксперимента: 40 прошлых диалогов с известным правильным исходом.
Один прогон — один выключенный модуль.
Что записывать: решена ли задача и сколько токенов потрачено.
Результат: Модель выдаст список модулей с определением «выключения» для каждого и таблицу для прогонов. Вы прогоняете 14+1 вариантов на 40 диалогах, собираете результаты, дальше действуете по правилам защиты и усечения из шаблона ниже. В итоге у вас остаётся укороченный промпт, для которого проверено, что он не хуже по качеству.
Почему это работает
Слабость. Растущий промпт никто не проверяет на нужность. Каждая новая строка добавлена по конкретному поводу, и кажется, что она «точно не помешает». Но лишние правила стоят токенов в каждом запросе. Иногда они ещё и мешают. Интуиция «чем подробнее, тем лучше» не подтверждается, и по одному взгляду на промпт не видно, какая часть нужна.
Сильная сторона. Отключить один модуль и сравнить результат на одних и тех же задачах дёшево: нужен всего один дополнительный прогон на модуль, а не перебор всех комбинаций. Сравнение с медианой по всем отключениям отсекает общий шум. Кроме того, измеряются сразу две вещи: качество и цена.
Как метод обходит слабость. Он заменяет спор «нужно ли это правило» измерением. Защитный список не даёт вырезать то, что держит качество. Лестница усечённых версий показывает, на каком шаге оно начинает падать. Проверка на отдельном наборе задач страхует от случайной подгонки.
Рычаги управления: - Размер dev-набора (в статье 50 задач) → меньше задач дешевле, но шумнее решение «важен / не важен». - Порог защиты (p ≤ 0.05) → строже порог защищает больше модулей, вы режете осторожнее. - Режим: efficiency-oriented (режем самое дорогое по токенам, защищая важное для качества) или performance-oriented (режем то, что меньше всего влияет на качество, защищая важное для экономии). Выбирайте по тому, что болит: счёт или результат. - Что считать модулем → мельче модули дают точнее картину, но больше прогонов. - Число прогонов на задачу (в статье 3) → больше прогонов надёжнее: LLM-агент нестабилен.
Шаблон промпта
Оригинал — автоматизированный процесс с прогонами на бенчмарках и t-тестами. Шаблон ниже превращает его в чат-инструкцию, которая готовит и ведёт ручной эксперимент: разбор модулей, план абляций, правила решения.
Ты — аналитик, который готовит обрезку агента методом SHarP:
по вкладу каждого модуля в качество и в стоимость в токенах.
Системный промпт и инструкции: {инструкции_агента}
Инструменты и скилы: {список_инструментов}
Задачи для проверки (с известным правильным исходом): {описание_набора_задач}
Метрика успеха: {что_считаем_успехом}
Разбей агента на модули: инструмент, блок инструкций, скил, отдельный механизм
(например, сжатие истории).
Связанное держи вместе (инструмент + его описание = один модуль).
Для каждого модуля опиши, что значит «выключить» его.
Если выключение оставляет часть функции — укажи это.
Определи также конфигурацию «всё выключено»:
только описание задачи и базовый минимум для запуска.
Составь план прогонов:
- A(все модули) — полный агент;
- A(без модуля i) — по одному прогону на каждый модуль.
Условия одинаковые: модель, лимиты, задачи.
Для каждого прогона записываем по каждой задаче: успех (0/1 или доля) и токены.
Когда я принесу результаты, для каждой задачи вычисли медиану
успеха и токенов по всем «без модуля i».
Для каждого модуля посчитай среднее отклонение от медианы:
- качество ниже медианы → модуль важен для качества;
- токены выше медианы без него → модуль важен для экономии.
Оцени, значимо ли отклонение или это шум.
Защитный список G: модули, без которых качество значимо хуже.
Их не удаляем.
Режим: {efficiency | performance}.
- efficiency: из незащищённых модулей удаляем сначала те, чьё отсутствие
меньше всего повышает токены, то есть самые дорогие для агента.
- performance: защищаем модули, важные для экономии,
удаляем сначала те, что меньше всего влияют на качество.
Построй лестницу конфигураций: убираем 3 модуля, потом ещё 3, и так до защитного списка.
Каждую конфигурацию проверить на ОТДЕЛЬНЫХ задачах (не из набора шагов 2–3), по 3 прогона на задачу.
Сравнить с полным агентом и с «всё выключено».
Выбрать конфигурацию, где качество не хуже полного, а токенов меньше.
Предупреждай: токены иногда ВЫРАСТАЮТ при удалении
(например, убрали механизм остановки — агент работает дольше).
Что подставлять. {инструкции_агента} — полный текст системного промпта или CLAUDE.md. {список_инструментов} — инструменты и их описания. {описание_набора_задач} — 30–50 реальных задач с известным результатом, часть оставьте на проверку. {что_считаем_успехом} — например, «клиент получил верный статус заказа без эскалации». Режим выбирайте по боли: счёт — efficiency, качество — performance.
🚀 Быстрый старт — вставь в чат:
Вот шаблон обрезки агента по методу SHarP. Адаптируй под мою задачу: [опиши своего агента и что он делает].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, из каких блоков состоит промпт, какие у агента инструменты, есть ли у вас задачи с известным верным результатом и как вы определяете успех. Это нужно для метода: без размеченных задач и чёткой метрики нельзя отличить «модуль лишний» от «модуль важен».
Ограничения
⚠️ Нужны задачи с проверяемым исходом: метод опирается на набор задач, где понятно, успех это или нет. Для «красиво написать» или «хорошо поддержать клиента» без чёткого критерия он не работает.
⚠️ Нужны сами прогоны: каждый модуль — отдельный прогон на десятках задач. В статье это делается кодом и статистикой. Вручную это долго, без скрипта или автоматизации обойтись трудно.
⚠️ Нельзя вырезать всё: на одном из агентов лучший результат дали 24 из 27 удалённых модулей. Но при удалении всех 27 успех упал более чем вдвое, хотя токенов ушло очень мало.
⚠️ Дешевле не значит эффективнее: у части конфигураций токены, наоборот, выросли. Например, у агента с поиском по статьям на промежуточном шаге, и у агента для покупок при полной очистке. Если убрать механизм, который помогает остановиться, агент «топчется» дольше.
⚠️ Избыточность зависит от агента: у агента по научным статьям лучшим остался полный вариант. Здесь обрезка стоила качества. Универсального «режь 90%» нет.
⚠️ Результат может не перенестись: вывод верен для тех задач и той модели, на которых мерили. Сменили модель или тип задач — прогон надо повторить.
Как исследовали
Идея взята из обрезки нейросетей: там отбрасывают веса с наименьшим «вкладом». Авторы перенесли её на обвязку агентов. Взяли четыре готовых харнеса: OpenHands (универсальный агент, задачи GAIA), PaperQA2 (вопросы по научным статьям), LIFE-harness (поддержка клиентов, авиалинии и ретейл) и агента для покупок. Всего получилось пять комбинаций «агент + задачи».
Для каждого вручную выделили модули: от 18 до 48 штук. Это зарегистрированные инструменты, блоки инструкций, скилы, механизмы вроде сжатия истории. Дальше на 50 задачах для настройки отключали по одному модулю и сравнивали с медианой по всем отключениям. Так получили две оценки: вклад в качество и вклад в экономию токенов. Всё прогоняли на одной модели, Qwen3.5-122B-A10B. Лестницу усечённых версий проверяли на отдельных задачах, по 3 прогона.
Результат оказался неожиданным. Все четыре агента сохранили сопоставимое качество при сокращении токенов хотя бы на 10%. Два даже улучшились. У OpenHands успех на GAIA вырос с 29,44% до 35,00% при 24 удалённых модулях из 27. LIFE-harness почти не терял качество даже при полном выключении кандидатов. На агенте для покупок режим «эффективность» дал сопоставимое качество (76,2% против 75,8%) при сокращении токенов на 39%. Режим «качество» на нём дал 82,5% при минус 5,9% токенов. На ретейле картина обратная: «эффективность» дала лучший успех (87,5%), а «качество» — самые дешёвые варианты (минус 21,2% токенов, но успех 70,0%).
Из этого следует практический вывод: выигрыш от обрезки не гарантирован и зависит от агента. Но в большинстве случаев лишнее есть, и его можно найти дёшево.
Адаптации и экстраполяции
🔧 Техника: проверять заплатки при добавлении → не копить мусор
Авторы показали, что харнес растёт монотонно, потому что каждый сбой лечат новым правилом. Можно сломать этот цикл: при добавлении правила в промпт сразу записывать, на каком сбое оно основано. При следующей ревизии так проще понять, какие блоки пора проверить абляцией. Это моя идея по мотивам статьи, самой статьёй она не проверялась.
В CLAUDE.md перед каждой добавленной строкой писать комментарий:
.
Экстраполяция: сначала обрезать, потом вернуть недостающее
Если полная ручная абляция не по силам, можно сократить объём работы. Прогнать «всё выключено» и полный вариант на одном наборе задач. Если разрыв маленький, модулей, скорее всего, лишних много, и обрезку стоит делать. Это эвристика: в статье она не проверялась, но она следует из результатов (у LIFE-harness «всё выключено» почти не уступало полному).
Ресурсы
- SHarP: Saliency-based Pruning of Agent Harnesses — Xinyi Gao, Qiucheng Wu, Kaizhi Qian, Handong Zhao, Shiyu Chang, Yang Zhang. UC Santa Barbara, MIT-IBM Watson AI Lab, Adobe Research.
- Код: https://github.com/UCSB-NLP-Chang/SHarP
- Использованные агенты и бенчмарки: OpenHands / GAIA, PaperQA2 / LitQA2, LIFE-harness / τ²-bench, JIT-Agent (agentfold) / DeepPlanning-Shopping.
- Смежные работы: Sengupta & Wang (2026), Agostino & D'Souza (2026), Lindenbauer et al. (2025).