AT-AT: автоматическая доработка инструментов агента по логам его прошлых запусков

ШАГ 0: Собрать логи прошлых запусков агента + оценка каждого (успех/провал)
ШАГ 1: Положить в папку логи и исходники инструментов → «песочница» для кодинг-агента
ШАГ 2: Системный промпт: цель + «правь обобщённо, не под отдельные случаи»
        Первое сообщение: начало каждого провального прогона (первые ~4000 символов)
        + до 3 успешных прогонов для контраста
ШАГ 3: Кодинг-агент ищет повторяющиеся сбои, читает код инструментов,
        решает: чинить описание или реализацию → правит файлы
ШАГ 4: Проверка: код запускается, правки только в файлах инструментов
        Не прошла → агент правит ещё раз (до 5 попыток)
ШАГ 5: Прогнать агента на НОВЫХ задачах, сравнить с исходной версией

Шаги 1–4 идут одной сессией кодинг-агента. Шаг 5 отдельный: это независимая проверка.

Задача: Вы строите бота поддержки для сотового оператора в духе МТС или Билайна. У бота есть MCP-инструмент get_data_usage. Он возвращает {"used_gb": 8, "limit_gb": 10}. По логам видно: клиенты пишут «интернет не работает», а бот часами предлагает перезагрузить телефон. Он не замечает, что трафик закончился, потому что остаток надо вычислить и добавить ещё докупленные пакеты. Менять бота нельзя: он общий для нескольких команд. Инструмент менять можно.

Промпт (для Claude Code, в папке проекта лежат traces/ и tools/):

Ты оптимизатор инструментов для ИИ-агента поддержки сотового оператора.
Ты не меняешь агента. Ты меняешь только то, что видит агент: описания
инструментов и то, что инструменты возвращают.



Повысить долю решённых обращений. Критерий успеха — оценка в каждом файле traces/.



- traces/ — логи диалогов агента с оценкой (success/fail)
- tools/ — исходный код инструментов (tools/support_tools.py)



1. Найди сбои, которые повторяются в нескольких логах. Единичные случаи игнорируй.
2. Для каждого сбоя прочитай код инструмента и реши:
   нужно уточнить описание или изменить ответ инструмента.
3. Правки делай ОБОБЩЁННЫЕ: не подгоняй под конкретные номера и клиентов из логов.
4. Не меняй имена функций, параметры и формат ответа так, чтобы сломать вызывающий код.
5. Не создавай, не удаляй и не правь файлы вне tools/.
6. В конце проверь, что код запускается без ошибок.



Список правок: что изменено, какой повторяющийся сбой исправляет, в каких логах он виден.

Результат: Агент прочитает логи и найдёт повторяющиеся паттерны. Например, в провальных диалогах бот не понимает, что трафик исчерпан. Затем он откроет код инструмента и, скорее всего, добавит в ответ готовые поля вроде остатка трафика. Возможно, он также уточнит описание и сделает сообщения об ошибках более подсказывающими. В конце будет список правок с привязкой к логам. Вы смотрите diff, принимаете или отклоняете, а затем прогоняете бота на новых обращениях и сравниваете с прежней версией.

Слабость: агент видит инструмент только через его описание и ответы. Если ответ сырой («used 8, limit 10»), вывод приходится делать самой модели, и она иногда ошибается. Если описание расплывчатое, она неверно вызывает инструмент. Инструменты часто писали для разработчиков и обычного кода, а не для LLM. А промпт агента вы поправить не можете: он чужой или общий.

Сильная сторона: кодинг-агент умеет искать по длинным логам, читать код и решать, где причина сбоя: в описании или в реализации. Логи прошлых запусков — готовый и бесплатный источник знаний о том, где агенты спотыкаются. Правка инструмента сразу помогает всем агентам, которые им пользуются.

Как метод это использует: он превращает повторяющиеся ошибки агентов в правки среды. В исследовании каждая часть оказалась нужной. Без логов, без доступа к коду реализации или без кодинг-агента (просто «перепиши файл одним запросом») прирост почти исчезал.

Рычаги управления: - Доступ к реализации (разрешить править код ответов): главный источник выигрыша. Если можно менять только описания, эффект слабее. - Число логов: возьмите несколько задач и повторные прогоны. Тогда правки обобщаются, а не подгоняются под один случай. - Провалы + успехи: провальные прогоны показывают проблему, успешные дают контраст. В исследовании: первые 4000 символов каждого провала и до трёх успешных. - Инструкция «правь обобщённо»: защита от переобучения под ваши логи. - Лимит попыток проверки: по умолчанию 5. Для простых инструментов хватит 2–3.

Точные промпты авторов лежат в Appendix G, в предоставленном тексте их нет. Шаблон ниже восстановлен по описанию метода: цель в системном промпте, инструкция про обобщённые правки, логи в файлах, ограничения проверки.

Ты оптимизатор инструментов для ИИ-агента ({тип_агента}).
Агента ты не меняешь. Ты меняешь только описания инструментов
и то, что инструменты возвращают агенту.



Повысить долю успешно решённых задач. Критерий успеха — оценка в каждом файле {папка_с_логами}.



- {папка_с_логами}/ — логи запусков агента с оценкой (успех/провал)
- {папка_с_инструментами}/ — исходный код и описания инструментов



1. Просмотри логи. Выпиши сбои, которые повторяются в нескольких запусках.
2. Для каждого сбоя прочитай код инструмента, который в нём участвовал.
3. Определи причину:
   - агент неверно вызвал инструмент → уточни описание / параметры;
   - агент получил неполный или неудобный ответ → измени реализацию,
     чтобы ответ содержал готовую нужную информацию или подсказку,
     как исправить ошибку;
   - причина не в инструментах → пропусти.
4. Внеси правки.
5. Проверь, что код запускается без ошибок.



- Правки обобщённые: не подгоняй под конкретные значения и случаи из логов.
- Не ломай интерфейс: имена функций, параметры и формат ответа сохраняй.
- Не создавай, не удаляй и не правь файлы вне {папка_с_инструментами}/.
- {разрешены_ли_правки_реализации: «Правь описания и код» или «Правь только описания»}



Список правок: что изменено, какой повторяющийся сбой исправляет, в каких логах он виден.

Что подставлять: - {тип_агента} — чем занимается ваш агент. - {папка_с_логами} — файлы диалогов с пометкой исхода. Лучше брать разные задачи и повторные запуски. - {папка_с_инструментами} — код или конфигурация инструментов. - {разрешены_ли_правки_реализации} — слабее всего работает вариант «только описания».

🚀 Быстрый старт — вставь в чат (или в Claude Code, если логи и код в папках):

Вот шаблон оптимизации инструментов агента по логам (метод AT-AT).
Адаптируй под мою задачу: {опиши своего агента и какие у него инструменты}.
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, что делает агент, какие у него инструменты, где лежат логи, как помечены успехи и провалы, можно ли править код ответов. Эти данные нужны, чтобы правила про «не ломай интерфейс» и «не трогай чужие файлы» были привязаны к вашим реальным файлам.

⚠️ Эффект не везде: значимый прирост получен только в одной области из трёх (Telecom, техподдержка с вычислениями). В Airline прирост такого же размера, но он не прошёл проверку на случайность. В Retail результат стал чуть хуже.

⚠️ Слепые правки вредят: метод DRAFT (правит только описания, без глубокого анализа) значимо ухудшил результат в Telecom. Принимайте правки только после проверки на новых задачах.

⚠️ Агент стал дороже: описания и ответы инструментов стали длиннее, и стоимость одного прогона агента почти везде значимо выросла. В Airline, например, с 0,0618 до 0,0675 доллара за симуляцию. Оптимизация обходится в 2–10 долларов разово, но платить за длинные ответы придётся постоянно.

⚠️ Нужны размеченные логи и доступ к коду: без оценок успеха и провала метод не работает. Если вы не владеете кодом инструментов (чужой API), остаются только описания, а они дают меньше.

⚠️ Перенос между агентами не доказан: при смене модели агента улучшение в двух областях из трёх не вышло за пределы случайного разброса. Гипотеза «правки полезны всем агентам» подтверждена не надёжно.

⚠️ Один проход: авторы проверили единичное обновление, а не непрерывный цикл улучшений. Агент в основных тестах — не самая современная модель (GPT-4.1).

Авторы из Netflix взяли бенчмарк τ²-bench-verified: симуляция службы поддержки в трёх областях (авиалинии, ритейл, телеком). Сначала они прогнали агента по 5 раз на каждую задачу и получили базовые логи. Часть задач отдали оптимизатору (кодинг-агент Pi на Claude Opus 4.7), а остальные оставили для проверки. Каждую задачу гоняли по 30 раз и сравнивали исходные и улучшенные инструменты парным перестановочным тестом. Это нужно, потому что агент от запуска к запуску даёт разные результаты, и обычная разница средних ничего не доказывает.

В Telecom доля успешных задач выросла с 29,5% до 36,75% (p=0,0033), в Airline с 52,17% до 59,17% (не значимо). Конкурентов (DRAFT, ToolObserver, GEPA) обошли или сравнялись при меньших затратах на оптимизацию: у ToolObserver она стоила 16–49 долларов, у AT-AT 2–11. Самое поучительное — абляции: в Telecom «только описания» дали 31,2%, «без логов» — 30,4%, «без кодинг-агента» — 30,5%. Все три почти на уровне базы 29,5%, то есть нужны были все части. На TerminalBench-2 и TBLite авторы улучшили инструменты внутри кодинг-агента OpenCode и сообщают о росте на отложенных задачах (таблица в предоставленном фрагменте обрезана). На трёх боевых MCP-серверах Netflix правки описаний по логам снизили стоимость или число ошибок инструментов на всех, а число успешных задач выросло на одном.

🔧 Техника: разрешить правки реализации → выигрыш выше. Если ваш инструмент — функция, которой вы владеете, не ограничивайте оптимизатор описаниями:

- Правь описания И код ответов инструмента.
- Если агент делает вывод из сырых данных (считает остаток, сравнивает даты),
  перенеси этот вывод в ответ инструмента.

Без доступа к коду метод ближе к «улучшению описаний», а это в исследовании дало мало.

Экстраполяция: принцип feedback shaping без автоматизации. Идея из статьи работает и без логов. Вручную пройдитесь по ответам своих инструментов. Для каждой ошибки спросите, подсказывает ли сообщение, что делать дальше:

Вот сообщения об ошибках и ответы моих инструментов агента: {список}.
Перепиши их так, чтобы агент из самого ответа понимал: что пошло не так,
что уже известно и какой следующий шаг разумен. Не меняй формат и ключи ответа.

Это моя экстраполяция идеи авторов: их эксперимент ставился на логах, а не на ручном переписывании.

• Работа: AT-AT: Automatic Tool Optimization from Agent Traces. Maya Ravichandran, Pragya Tripathi, Dharamendra Kumar, Adith Swaminathan, Nathan Kallus (Netflix). NeurIPS 2026, Workshop on Continual Learning in the Era of Foundation Models and Embodied Agents.
• Код: https://github.com/Netflix-Skunkworks/agent-tool-opt-core
• Бенчмарки: τ²-bench-verified, TerminalBench-2, TBLite.
• Связанное: Anthropic о проектировании инструментов для агентов (цитируют снижение времени выполнения на 40% после доработки инструментов); DRAFT, ToolObserver, GEPA, Meta-Harness.