TL;DR
TRACE–FIX — это связка из двух шагов для разбора сбоя долгого агента, который меняет файлы, базы и другое постоянное состояние. Сначала TRACE превращает лог в структурированный реестр. В нём записано, какие требования задачи сейчас не выполнены и какие прошлые события с ними связаны. Затем FIX выбирает, что делать дальше: проверить гипотезу, чинить или продолжать. Он учитывает общий бюджет действий и заранее оставляет часть на ремонт.
Главная находка: шаг, который сломал, симптом и то, что надо чинить сейчас, — это три разные вещи. Агент молча удалил журнал SQLite на 2-м шаге, а упал на 97-м. Если показать модели лог и спросить «где ошибка?», она укажет на последнюю подозрительную команду или на самое громкое сообщение об ошибке. Бывает и наоборот. В истории есть сбой, но текущее состояние уже здоровое, и чинить нечего. Когда проверки и ремонты делят общий бюджет, агент часто тратит всё на диагностику и не успевает проверить свой ремонт.
Суть метода в трёх ходах. Первый: смотреть на невыполненные требования задачи, а не на историю ошибок. Второй: ранжировать гипотезы о причине и проверять их отдельно, до ремонта. Третий: заранее резервировать бюджет на починку и после каждого действия пересобирать картину. Исследователи показали, что именно резерв, а не хитрое планирование само по себе, дал основной прирост.
Схема метода
ШАГ 1 (TRACE): лог + требования задачи → реестр: что не выполнено,
какие события с этим связаны, какие данные устарели
ШАГ 2 (TRACE): LLM ранжирует топ-N событий-кандидатов в причины
→ пакет гипотез (гипотеза ≠ факт)
ШАГ 3 (FIX): список допустимых действий с ценой
(проверка / ремонт / продолжить / сдать) → прогноз исходов
ШАГ 4 (FIX): выбор действия с учётом резерва на ремонт
ШАГ 5: выполнили → квитанция → устаревшее помечено →
реестр пересобран → снова ШАГ 3
В оригинале шаги 1, 3–5 выполняет код (рантайм), а LLM ранжирует события и даёт прогнозы. В обычном чате вручную можно воспроизвести шаги 1–2 и логику решений шагов 3–4.
Пример применения
Задача: Вы ведёте интернет-магазин и поручили Claude Code перенести каталог из старой базы в новую (PostgreSQL). На 60-м шаге падает финальный тест: «в каталоге 11 840 позиций вместо 12 000». Агент уже перебрал три версии скрипта, все с ошибками. Скрипт чистки дублей на 14-м шаге молча удалил 160 товаров без артикула. Ошибок он не выдал, а тест упал только в конце.
Промпт:
Ты разбираешь сбой агента. Не ищи, какая команда выглядела подозрительно.
Сначала собери реестр.
<Задача>
Перенести каталог из старой базы в PostgreSQL. Итог: 12 000 позиций,
у каждой есть артикул, цена, категория.
<Требования>
R1: в новой базе 12 000 позиций
R2: у всех позиций заполнена цена
R3: у всех позиций заполнена категория
R4: скрипт миграции запускается повторно без ошибок
<Лог>
{вставь лог команд и их результатов, с номерами шагов}
<Симптом>
Шаг 60: тест R1 не прошёл, 11 840 вместо 12 000.
Шаг 1. Для каждого требования напиши статус: выполнено / не выполнено /
заблокировано / неизвестно. Укажи, на чём основан статус
(какой шаг лога). Если после этого шага состояние менялось,
пометь доказательство как устаревшее.
Шаг 2. Только для невыполненных требований выбери до 3 событий из лога,
которые могли создать проблему. Отдельно отметь: это команда,
которая ИЗМЕНИЛА данные, или более поздняя проверка/отчёт о проблеме.
Если явной вредной записи нет, рассмотри пропущенные
или переставленные шаги.
Шаг 3. Для каждой гипотезы предложи дешёвую проверку, которая её
подтвердит или опровергнет. Ничего не чини, пока гипотеза не проверена.
Шаг 4. Если требование уже выполнено в текущем состоянии,
не предлагай его чинить, даже если в истории была ошибка.
Выдай: таблицу требований, топ-3 гипотезы с проверками, рекомендацию
первого действия.
Результат: Модель выдаст таблицу статусов по R1–R4 с привязкой к шагам лога. Затем три гипотезы по требованию R1, причём события-изменения будут отделены от более поздних проверок. К каждой гипотезе будет приложена дешёвая проверка, например подсчёт позиций без артикула до и после шага 14. В конце будет рекомендация сделать сначала проверку, а не ремонт. Требования, которые уже в порядке, модель пометит как «не чинить».
Почему это работает
Слабость. Если дать модели сырой лог и вопрос «где ошибка?», она цепляется за заметное: последнюю команду, текст ошибки, самый подозрительный шаг. Но причина и симптом в долгих задачах расходятся. Удаление произошло тихо, с кодом возврата 0, и никакой ошибки не показало. Кроме того, часть «вины» из истории уже неактуальна: агент сам всё починил или состояние позже изменилось.
Сильная сторона. Если дать модели структуру вместо плоского потока, она хорошо ранжирует кандидатов по связи с конкретным невыполненным требованием. В опыте авторов тот же объём информации, поданный плоским текстом (Residual Context), прироста не дал. Подача в виде реестра с зависимостями дала.
Как метод это использует. Он сужает вопрос с «что пошло не так?» до «какое требование не выполнено, какое событие его затрагивает и что можно позволить себе сделать сейчас?». Гипотеза остаётся гипотезой, пока её не подтвердила проверка. А резерв бюджета защищает от главной ловушки: тратить всё на диагностику и оставить ремонт без проверки.
Рычаги управления: - Число гипотез (топ-3) → меньше для простых задач, больше, если причина «размазана». - Бюджет и резерв на ремонт → увеличь резерв, если ремонт дорогой или рискованный. - Требование «не чинить» → убери, если нужна полная ревизия, а не точечный ремонт. - Пометка устаревших доказательств → особенно важна, если агент много перезаписывает файлы. - Запасной вариант → если прогноз не получился, просто продолжай как раньше, а не выдумывай переход.
Шаблон промпта
Оригинальный текст промпта ранжировщика в статье не приведён, есть только его описание. Шаблон ниже — реконструкция по описанию: она сохраняет структуру из трёх видов данных (задача, лог, приёмка), правила ранжирования и разделение «гипотеза / проверка / ремонт».
Ты разбираешь сбой агента, который менял постоянное состояние
(файлы, базы, настройки). Твоя задача — найти, что ещё не выполнено
и какое прошлое событие этому мешает. Не угадывай виноватого.
Цель: {цель_задачи}
Требования:
{список_требований_R1_R2_...}
Зависимости между требованиями: {что_от_чего_зависит}
{пронумерованный_лог: шаг, команда, результат, какие ресурсы затронуты}
Результаты проверок: {какие_проверки_что_показали}
Наблюдаемый симптом: {что_упало_и_когда}
1. Для каждого требования: выполнено / не выполнено / заблокировано /
неизвестно. Укажи шаг лога, на котором основан статус.
2. Если после этого шага менялся ресурс, от которого зависит доказательство,
пометь доказательство УСТАРЕВШИМ и не опирайся на него.
3. Остаточное обязательство = требование, которое не выполнено,
заблокировано невыполненной предпосылкой или потеряло подтверждение.
4. Историческая ошибка не является целью ремонта, если текущее
состояние уже удовлетворяет требованию.
Выбери до {N} событий, которые вероятнее всего создали невыполненное
требование, от более к менее вероятному.
- Отличай команды, ИЗМЕНИВШИЕ состояние, от более поздних наблюдений,
тестов и отчётов о проблеме.
- Если явной вредной записи нет, рассмотри пропущенные или
переставленные действия.
- Зависимость и «последняя запись» — это подсказка, не доказательство.
Для каждой гипотезы: ID события, ссылки на доказательства,
какие требования затронуты, дешёвая проверка, которая её подтвердит
или опровергнет. Гипотеза остаётся гипотезой до проверки.
Бюджет: {всего_единиц}. Резерв на ремонт и повторную проверку: {резерв}.
Допустимые действия и цена: {проверка=..., ремонт=..., продолжить=..., сдать=...}
Для каждого действия оцени возможные исходы и что останется возможным после.
Правила:
- Не трать резерв на диагностику.
- Не чини то, что уже выполнено.
- После любого действия пересобери реестр с шага 1.
- Если оценить нельзя, продолжай как раньше.
Выдай: таблицу требований, пакет гипотез, следующее действие с обоснованием
и остаток бюджета.
Подставь: {цель_задачи} — одно предложение; {список_требований} — что должно быть истинно в конце; {пронумерованный_лог} — команды и результаты; {N} — 3; {всего_единиц} и {резерв} — условные единицы, например 12 и 4.
🚀 Быстрый старт — вставь в чат:
Вот шаблон TRACE–FIX для разбора сбоя агента. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: какие требования должны быть выполнены в итоге, какие действия доступны агенту (проверить, откатить, переписать) и какой у них «вес», сколько попыток можно потратить. Это нужно, потому что метод держится на конкретных требованиях и бюджете, без них реестр получится пустым. Остальное она возьмёт из шаблона.
Ограничения
⚠️ Нужен код для полной версии: в оригинале реестр собирается автоматически, а действия выбирает код по динамическому программированию. Модель только ранжирует события и даёт прогнозы. В чате воспроизводится «облегчённая» версия: разбор по реестру и правила решений. Полный цикл с пересборкой после каждого действия вручную тяжёл.
⚠️ Свой бенчмарк, часть результатов пока не измерена: корпус из 1 500 сбоев пока запланирован, оценки идут на 200, 120 и 60 случаях. Часть абляций (Figure 4) — «планируемые цели» без измеренных значений. Это слабая опора для кратных обещаний.
⚠️ Прогнозы модели не откалиброваны: авторы прямо пишут, что это оценки для планирования, а не вероятности. Решения «что делать» нельзя считать надёжными без проверки реальным исполнением.
⚠️ Нужны явные требования и проверки: метод работает, когда у задачи есть проверяемый критерий готовности. Для творческих задач без критерия приёмки реестр построить нечем.
⚠️ Гипотеза ≠ факт: даже верхняя в рейтинге причина остаётся догадкой. Если пропустить проверку и сразу чинить, метод теряет смысл.
Как исследовали
Исследователи собрали бенчмарк LongH-Debug из естественных сбоев агентов в семи средах: оболочка и файлы (Terminal-Bench), диалоги с инструментами (τ²-bench), симуляции (ALFWorld, ScienceWorld, TextWorld), длинный поиск (BrowseComp-Plus, xbench). Идея в том, чтобы разделить три разных вопроса: нашли ли причину (TRACE на 200 сбоях), починили ли при известной причине (FIX на 120 случаях), работает ли связка целиком (60 задач). Так нельзя незаслуженно хвалить ремонтника за скрытую повторную диагностику.
Для поиска причин TRACE дал Hit@1 68% против 42% у обычного «ранжируй по логу». Доля гипотез, которые удалось независимо подтвердить в бюджете, выросла с 31% до 60,5%. Стоило это на 29% дороже по токенам. Метод Who&When показал всего 8%, а TraceElephant — 44% при пятикратной цене. Удивительный результат: те же сведения плоским текстом (Residual Context) прироста не дали, 43% против 42%. Значит, дело в структуре, а не в объёме.
Для ремонта при известной причине полный FIX поднял успех с 35% (агент просто продолжает) до 67,5% и снизил вредные вмешательства до 2,5%. Важная деталь: информационный выбор с резервом на ремонт дал 61,7% против 50% без резерва. Авторы сами сказали, что прирост даёт именно резерв, а не рекурсия Беллмана. Поэтому они сравнивали с сильным базовым методом, а не с заведомо слабым.
Практический вывод: что считать целью ремонта и сколько беречь на сам ремонт важнее красоты алгоритма.
Адаптации и экстраполяции
🔧 Техника: добавить правило остановки в инструкцию агента → защита от «диагностики до нуля»
Для CLAUDE.md или AGENTS.md (это экстраполяция принципа резерва, в статье такой текст не приведён):
Когда тесты падают: сначала выпиши, какие требования задачи не выполнены сейчас. Историческую ошибку не чини, если текущее состояние уже проходит проверку. Не более 3 диагностических действий подряд. Остальной запас оставь на ремонт и повторную проверку. После каждого ремонта пересобери список невыполненного.
Комбинация с самопроверкой: после шага 3 шаблона добавь «Если проверка опровергла гипотезу, вычеркни её и перейди к следующей, не пытаясь чинить опровергнутую». Это дисциплина «гипотеза → проверка → ремонт» из статьи.
Ресурсы
- From Trace to Fix: Residual Task State in Long-Horizon Agents (Under review)
- Авторы: Zile Huang, Ser-nam Lim, University of Central Florida
- Код: https://github.com/toffeecat/tracedp
- Используемые среды: Terminal-Bench, τ²-bench, ALFWorld, ScienceWorld, TextWorld, BrowseComp-Plus, xbench; сравнение с Who&When, TraceElephant