⚠️ Оговорка: текст статьи обрывается на описании скилов (раздел 3.2). Таблицы результатов и раздел про метаматериал не попали в материал. Выводы ниже опираются на абстракт и описание устройства агента. Конкретных цифр по каждому элементу у меня нет.
TL;DR
Агент = модель + «обвязка» (harness): конфигурационные файлы с инструкциями, каталог скилов (готовых скриптов, которые агент вызывает), файл со знаниями, роли субагентов. Авторы собрали агента на готовом фреймворке OpenClaw и по очереди меняли отдельные элементы обвязки и саму модель. Так они увидели, что даёт каждый элемент.
Главная находка: слабая модель задаёт потолок, который не пробить никакой настройкой. Можно часами переписывать инструкции, добавлять скилы и делить работу на субагентов. Если модель слабая, результат не вырастет. Настройки начинают давать эффект только когда модель достаточно сильна, чтобы ими пользоваться. Поэтому типичный сценарий «агент не справляется, давай усложним инструкцию» часто тратит время зря: сначала проверь модель.
Конструкция агента в статье такая: один оркестратор и несколько субагентов с ролями. Каждый субагент получает задачу, работает в своём контексте и возвращает только итоговое сообщение. Друг с другом субагенты не общаются. В конфигурации прописаны скилы, их назначение и то, какой скил какому субагенту доступен.
Схема метода
ШАГ 1: Оркестратор получает задачу → пишет задачу в контекст субагента
ШАГ 2: Субагент (своя роль + свой набор скилов) работает в цикле:
рассуждение → вызов скила → результат возвращается в контекст → снова рассуждение
ШАГ 3: Субагент возвращает ТОЛЬКО финальное сообщение → оркестратор собирает ответ
Внутри субагента скилы двух типов:
«Измерители» (примитивы): превращают данные в признаки
«Детекторы»: по признакам выносят решение (по одному на тип проблемы)
Что настраивается текстом: конфигурация (каталог скилов + как ими пользоваться),
файл знаний (агент читает его сам, если решит), роли и права субагентов.
Пример применения
Задача: Селлер на Wildberries каждое утро получает CSV-выгрузку продаж и остатков по 400 SKU. Перед отчётом нужно проверить данные: дубли строк, нули вместо реальных значений, резкие скачки цены, пропущенные дни. Раньше это делал стажёр глазами. Теперь это делает агент (Claude Code или Cursor) со скриптами-детекторами.
Важная деталь: в статье скил, лежащий в рабочей папке, не считается доступным. Его нужно описать в конфигурации и «объявить» агенту. Поэтому в файле инструкций каждый скрипт описан отдельно.
Промпт (файл AGENTS.md):
Ты — субагент контроля качества выгрузок Wildberries. Твоя задача — найти
дефекты в данных ДО построения отчёта. Ты ничего не исправляешь, только
сообщаешь.
Измерители (запускай первыми):
- scripts/profile_columns.py — статистика по колонкам: пропуски, мин/макс, число уникальных
- scripts/daily_series.py — ряд «значение по дням» для заданной колонки
Детекторы (запускай по результатам измерителей):
- scripts/detect_duplicates.py — дубли строк по ключу (SKU + дата)
- scripts/detect_zero_runs.py — подряд идущие нули в продажах/остатках
- scripts/detect_price_jumps.py — скачки цены больше 30% за день
- scripts/detect_gaps.py — пропущенные даты
1. Запусти оба измерителя на файле {путь_к_файлу}.
2. По признакам реши, какие детекторы нужны. Запусти только их.
3. Не угадывай по глазам: каждый вывод должен опираться на результат скрипта.
Справка по полям выгрузки: docs/wb_fields.md. Читай её, только если
не понимаешь смысл колонки.
Результат: Агент сначала запустит скрипты-измерители, потом выберет подходящие детекторы и выдаст список дефектов по структуре из блока . Если модель слабая, она, скорее всего, будет пропускать скилы или «угадывать» ответ без запуска. Это сигнал менять модель, а не переписывать AGENTS.md.
Почему это работает
Слабость LLM: модель читает инструкции и решает, что делать дальше. Если ей не хватает способности планировать и разбирать результаты инструментов, тонкая настройка ничего не исправляет. Каталог из 13 скилов она просто не использует как нужно.
Сильная сторона: модель хорошо вызывает готовые инструменты и разбирает их вывод. Скрипт-детектор считает точно, как калькулятор. Модели остаётся выбрать, что запустить, и объяснить результат.
Как метод это использует: точный счёт отдан скриптам, выбор и интерпретация — модели. Двухступенчатая схема «измерители → детекторы» не даёт модели «смотреть на данные глазами». Контекст разделён: субагент видит только свою задачу, а к оркестратору возвращается только итоговое сообщение.
Рычаги управления: - Модель — главный рычаг. Если результат плох, сначала подними модель или уровень reasoning (настройка «сколько думать»), потом правь инструкции. - Каталог скилов в конфигурации — самая «весомая» часть инструкций. Скил надо описать и объявить, одного наличия файла мало. - Файл знаний вместо подгрузки в контекст — агент читает его только если решит. Это экономит контекст. - Число субагентов — увеличивай только если задача этого требует. По обзору в статье, один агент, решающий задачу так же хорошо, лучше мультиагентной схемы: передача текстом даёт потери и ошибки, которые тянутся дальше. - Права субагентов — каждому свой набор скилов.
Шаблон промпта
Ты — {роль_субагента}. Твоя задача — {что_делать}. Чего не делаешь: {границы}.
Измерители (запускай первыми):
- {путь_к_скилу_1} — {что_делает}
- {путь_к_скилу_2} — {что_делает}
Детекторы / исполнители (запускай по результатам измерителей):
- {путь_к_скилу_3} — {что_делает, когда применять}
- {путь_к_скилу_4} — {что_делает, когда применять}
1. Запусти измерители на {входные_данные}.
2. По признакам реши, какие следующие скилы нужны. Запусти только их.
3. Каждый вывод опирай на результат скила, не угадывай.
Справочный файл: {путь_к_файлу_знаний}. Читай его, только если {условие}.
Если нужен оркестратор, добавь в его файл инструкций:
Ты — оркестратор. Задачу {общая_задача} раздели между субагентами:
- {субагент_1}: {задача}, доступные скилы: {список}
- {субагент_2}: {задача}, доступные скилы: {список}
Каждому субагенту пиши задачу целиком: он не видит твой контекст.
Субагенты не общаются друг с другом. Собери ответ из их финальных сообщений.
Подставь свои скрипты и пути к файлам, роли, формат ответа и условие чтения файла знаний.
🚀 Быстрый старт — вставь в чат:
Вот шаблон файла инструкций для агента со скилами. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у тебя есть скрипты или инструменты, что на входе и что должно быть на выходе. Ещё она спросит, нужны ли отдельные субагенты. Эти вопросы нужны, потому что в методе каждый скил должен быть описан и объявлен агенту, иначе он им не воспользуется.
Ограничения
⚠️ Материал неполный: доступный текст обрывается до результатов. Я не могу показать, какой именно элемент обвязки дал какой прирост. Об этом сказано только в абстракте.
⚠️ Одно семейство моделей: все эксперименты на моделях одного семейства (GPT 5.6). Что слабая модель задаёт потолок — общая закономерность. Где именно проходит граница «достаточно сильной», у других моделей может быть иначе.
⚠️ Синтетические данные и узкая область: тест на 50 искусственных записях с точно известными дефектами. На реальных, «грязных» данных результат может быть хуже.
⚠️ Скилы — это код: в статье это Python-функции. Читателю без программирования придётся просить LLM написать скрипты, либо использовать готовые инструменты.
⚠️ Часть советов взята из обзора литературы: например, «мультиагентность не улучшение сама по себе» авторы описывают по чужим работам, не проверяя сами.
Как исследовали
Авторы взяли два типичных акустических задания. Первое: найти и локализовать дефекты в записях шума салона электромобиля. Данные синтетические, поэтому правильный ответ известен точно. В набор вошли 50 записей, 25 чистых и 25 с одним из девяти типов дефектов (выбросы, обрезание сигнала, провалы и другие). Баланс 50/50 нужен, чтобы агент, говорящий «всё чисто», получал только половину очков.
Восемь промптов шли по нарастанию сложности: от «есть ли проблема?» до «какие типы и в каких интервалах?». Часть работала с одной записью, часть с пачкой из 50. В остальном исследователи меняли по одному элементу: конфигурацию, знания и модель. Так видно вклад каждого.
Второе задание: агент проектирует вентилируемую ячейку метаматериала с нужным ослаблением шума. Здесь менялось, какая часть работы дана агенту в виде готового скила, а остальное оставалось неизменным.
Главный вывод в абстракте: на первом задании агент находит дефекты почти безошибочно. Слабая модель ограничивает результат, и никакой дизайн обвязки этого не исправит. Настройки работают только на достаточно сильной модели. Отдельно авторы пишут, что подробно проверяли именно то, что доступно эксперту без инженерной работы над обвязкой: знания, конфигурацию и скилы.
Адаптации и экстраполяции
🔧 Техника: добавить лесенку сложности → найти, где агент ломается
Авторы проверяли агента восемью промптами с нарастающей детальностью. Сделай так же со своим агентом, прежде чем доверять ему рабочую задачу:
Тест 1: «Есть ли в этой выгрузке проблемы?» (да/нет)
Тест 2: «Какие типы проблем?»
Тест 3: «Какие типы и в каких датах?»
Тест 4: то же для пачки из 50 файлов
Там, где точность падает, смотри в первую очередь на модель, а не на инструкции.
Экстраполяция: «сначала модель, потом инструкции». Это моя вариация, а не метод статьи. Прогони эталонную задачу на самой сильной доступной модели с минимальным AGENTS.md. Если результат плохой, дело не в инструкциях. Если хороший, постепенно упрощай модель и смотри, где качество падает. Так ты отделяешь вклад модели от вклада настроек.
Ресурсы
- Работа: Practical Assessment of Agentic Systems in Acoustics (препринт)
- Авторы: Arne Hildenbrand, Philipp Diel, Zhuo Cao, Hanno Scharr, Stefan Pischinger, Steffen Marburg
- Организации: Technical University of Munich; RWTH Aachen University; Forschungszentrum Jülich
- Фреймворк: OpenClaw (open-source агентная инфраструктура)
- Упомянутые работы: ReAct (Yao et al., 2023); обзоры агентных систем Fang et al., Tran et al., Sapkota et al.