TL;DR
Исследователи разобрали по шагам логи агентов, которые сами ищут в интернете и собирают отчёты. Получился чеклист из 13 типов ошибок в двух слоях. Системный слой: сломанные вызовы инструментов, блокировки сайтов. Смысловой слой: что агент решил, как искал, когда остановился, как свёл источники. Чеклист можно использовать как рубрику для разбора логов (вручную или через LLM-судью) и как основу для правил в инструкции агенту.
Главная находка: ошибки синтаксиса у современных моделей почти исчезли. Агент редко ломает формат вызова. Он ломается на смысле. Он суёт URL в поисковую строку, ищет arXiv-ID через Wikipedia и останавливается раньше времени, смотрит только сниппеты и не открывает страницы. Он видит нужный факт в выдаче и не использует его. В длинных отчётах он теряет ваши ограничения и формат. Если данных не хватает, он выдумывает недостающее, чтобы закрыть структуру отчёта. Итоговая точность скрывает всё это: правильный ответ может прийти через кривой путь, а неправильный не скажет, где сломалось.
Метод идёт в два прохода. Сначала простой парсер вытаскивает из лога пары «что агент собирался сделать → какой вызов выполнил» и отсекает системные сбои. Затем LLM-судья по таксономии размечает смысловые ошибки. Так инфраструктурные проблемы не путаются с «агент плохо думает».
Схема метода
ШАГ 1: Парсинг лога → пары «мысль агента + вызов инструмента» на каждом шаге
(регулярки, без LLM)
ШАГ 2: LLM-судья: совпадает ли намерение с вызовом? → системные ошибки
(3 фазы: вызов инструмента / поиск / загрузка страницы)
ШАГ 3: LLM-судья по таксономии на полном логе → смысловые ошибки
Deep Search: 5 типов | Deep Research: 3 типа
ШАГ 4: Подсчёт: какие ошибки доминируют, где каскады
→ решение: чинить инструкцию, инструменты или менять модель
Шаги 2 и 3 — отдельные запросы к судье. Сначала системные ошибки, потом смысловые, чтобы не списывать на «плохое мышление» то, что сломалось в инфраструктуре.
Таксономия ошибок (сердце статьи)
Системный слой (общий для обоих типов агентов)
| Фаза | Тип ошибки | Что происходит |
|---|---|---|
| Вызов инструмента | Parsing Failure | Нет корректных тегов, действие не извлекается |
| Incorrect Tool Name | Агент выдумал несуществующий инструмент | |
| Поиск | Call Formatting | Нет обязательных аргументов, нарушена схема |
| Tool-Function Mismatch | Например, URL засунут в текстовый поиск вместо браузера | |
| Irrelevant Query | В запрос попали внутренние мысли или системные инструкции | |
| Domain Tool Misalignment | Не тот специализированный инструмент (arXiv-ID ищут через Wikipedia) | |
| Syntactical Query Failure | Запрос из мусора и спецсимволов, ноль результатов | |
| Загрузка страницы | Unsupported Modality | Видео, аудио, сложный мультимодальный контент |
| Non-Existent Page | Мёртвая ссылка | |
| Anti-Scraping | 403, капча, файрвол |
Смысловой слой — Deep Search (поиск конкретных фактов)
- Observation Neglect — нужное уже в выдаче, но в рассуждение не попало.
- Surface-Level Skimming — опора на сниппеты, страницы не открываются, запросы переформулируются по кругу.
- Premature Stopping — ответ выдан до сбора всех нужных данных. Типично для «найди все…» и многошагового счёта.
- Rabbit Hole Trap — несколько шагов подряд в малополезных разделах или в петле, без возврата.
- Ineffective Query — слишком общие запросы, повторы одного и того же при пустых результатах.
Смысловой слой — Deep Research (отчёты)
- Contradiction Neglect and Sourcing Bias — источники противоречат друг другу, агент не сверяет, а опирается на первые или заметные.
- Synthesis Hallucination — данных не хватает, пробелы закрыты знаниями «из головы» модели, а не найденным.
- Goal Drifting — контекст разросся, ограничения и формат из исходной просьбы теряются.
Пример применения
Задача: Вы попросили исследовательского агента (Deep Research в ChatGPT, Claude с поиском или агента в Cursor) собрать все российские банковские карты с кэшбэком от 5% на АЗС и вернуть таблицу: банк, карта, условия, лимит, ссылка. Вернулось четыре карты и два «условия по данным банка» без ссылок. Вы подозреваете, что агент остановился рано и кое-что додумал. У вас есть лог шагов агента.
Промпт:
Ты — аудитор логов исследовательского агента. Ниже цель задачи и полный лог его шагов (мысли, вызовы инструментов, результаты).
Цель задачи: найти ВСЕ российские банковские карты с кэшбэком от 5% на АЗС и вернуть таблицу: банк, карта, условия, лимит, ссылка на источник.
Лог:
[вставить лог агента: все шаги с поисковыми запросами, открытыми страницами и финальным ответом]
Проведи разбор в два прохода.
ПРОХОД 1. Системные ошибки. Для каждого шага сопоставь, что агент собирался сделать, с тем, какой вызов он выполнил. Найди:
- Tool-Function Mismatch (например, URL в поисковой строке)
- Irrelevant Query (в запросе мысли или инструкции)
- Domain Tool Misalignment (не тот инструмент для типа источника)
- Syntactical Query Failure (запрос из мусора)
- Anti-Scraping / Non-Existent Page (блокировки, 403, капча, мёртвые ссылки)
ПРОХОД 2. Смысловые ошибки. Проверь по каждому типу, есть ли он, приведи номер шага и цитату из лога:
- Observation Neglect: нужный факт был в результатах, но не вошёл в рассуждение
- Surface-Level Skimming: опора на сниппеты, страницы не открывались
- Premature Stopping: ответ выдан до сбора всех кандидатов
- Rabbit Hole Trap: серия шагов в малополезных разделах или в петле
- Ineffective Query: слишком общие запросы или повторы
- Contradiction Neglect and Sourcing Bias: противоречия между источниками не сверены
- Synthesis Hallucination: ячейки таблицы заполнены без опоры на найденное
- Goal Drifting: потеряны ограничения из цели (порог 5%, АЗС, требуемые колонки)
ВЫВОД:
1. Таблица: тип ошибки | есть/нет | шаги | цитата-доказательство
2. Какие системные сбои агент преодолел сам, какие нет
3. Главная причина неполного результата (одна)
4. Три правки в инструкции агенту, которые убрали бы эти ошибки
Если типа ошибки нет, пиши «нет» и не придумывай. Если лога недостаточно для вывода, скажи об этом.
Результат: Модель выдаст таблицу по всем типам ошибок с номерами шагов и цитатами. Затем разделит системные сбои (блокировки, неверные инструменты) и смысловые. Отдельно назовёт главную причину неполной выдачи, например преждевременную остановку или опору на сниппеты. В конце даст три конкретные правки для инструкции агенту. Если ошибки не нашлось, судья должен написать «нет».
Почему это работает
Слабость: по итоговому ответу не понять, что сломалось. Правильный ответ мог прийти случайно. Неправильный не показывает, виноваты блокировки сайтов, кривой запрос или то, что агент не открыл страницу. Если чинить «вслепую», правки уходят не туда: инструкцию переписывают, хотя сайт просто отдавал 403.
Сильная сторона LLM: модель хорошо сопоставляет два текста, например «что агент собирался сделать» и «что он реально вызвал». Она неплохо находит в длинном логе конкретные паттерны, если дать ей закрытый список категорий. Пересказывать и классифицировать при готовой рубрике она умеет лучше, чем придумывать рубрику с нуля.
Как метод это использует: жёсткую часть (вытащить шаги из лога) делает парсер, а LLM занята только оценкой соответствия и смысла. Два слоя разделены, поэтому инфраструктурные сбои не списываются на «агент глупый». Закрытый список категорий с определениями не даёт судье придумывать ошибки.
Рычаги управления: - Список категорий. Оставь только те, что актуальны для твоей задачи. Для «найди все…» важны Premature Stopping и Surface Skimming, для отчётов — Synthesis Hallucination и Goal Drifting. - Требование цитаты и номера шага убирает «галлюцинированные» ошибки судьи. - Фраза «если типа нет, пиши нет» защищает от придумывания проблем. - Блок «три правки в инструкции» превращает диагностику в действие. Его можно убрать, если нужна только диагностика. - Цель задачи в начале нужна, чтобы судья мог проверить Goal Drifting и полноту.
Шаблон промпта
Ты — аудитор логов исследовательского агента. Тебе даны цель задачи и полный лог шагов агента.
Цель задачи: {цель_и_ограничения_задачи}
{лог_агента}
Тип агента: {поиск_фактов_или_отчёт}
ПРОХОД 1. Системные ошибки.
Для каждого шага сопоставь намерение агента с вызовом. Найди:
- Tool-Function Mismatch
- Irrelevant Query
- Domain Tool Misalignment
- Syntactical Query Failure
- Anti-Scraping / Non-Existent Page / Unsupported Modality
- Incorrect Tool Name / Call Formatting / Parsing Failure
ПРОХОД 2. Смысловые ошибки.
Если тип агента = поиск фактов, проверь:
- Observation Neglect
- Surface-Level Skimming
- Premature Stopping
- Rabbit Hole Trap
- Ineffective Query
Если тип агента = отчёт, проверь:
- Contradiction Neglect and Sourcing Bias
- Synthesis Hallucination
- Goal Drifting
Для каждой найденной ошибки: номер шага + цитата из лога + почему это ошибка.
Если ошибки нет, пиши «нет». Не придумывай.
ВЫВОД:
1. Таблица: тип | есть/нет | шаги | цитата
2. Что агент преодолел сам, что нет
3. Главная причина плохого результата (одна)
4. {число_правок} правки в инструкции агенту
Что подставлять:
- {цель_и_ограничения_задачи} — исходная просьба дословно, вместе с форматом и порогами.
- {лог_агента} — шаги, поисковые запросы, открытые страницы, финальный ответ.
- {поиск_фактов_или_отчёт} — выбери один тип.
- {число_правок} — обычно 3.
🚀 Быстрый старт — вставь в чат:
Вот шаблон разбора лога исследовательского агента по таксономии ошибок. Адаптируй под мою задачу: [опиши, какого агента используешь и что он делал].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая у тебя цель, какие ограничения были в просьбе, какой тип агента (поиск фактов или отчёт) и как выглядит лог. Это нужно, чтобы выбрать нужные категории ошибок и проверять Goal Drifting и полноту против твоей исходной задачи, а не абстрактной.
Ограничения
⚠️ Нет проверенных «лекарств»: статья даёт диагностику, а не проверенный способ чинить. Правила для инструкции агенту ниже в «Адаптациях» достроены нами, авторы их не тестировали.
⚠️ Судья может ошибаться: разметку делает один LLM-судья (GPT-5) без отдельной проверки точности. Ваш судья тоже может «видеть» ошибки там, где их нет. Требование цитаты и номера шага снижает риск, но не убирает его.
⚠️ Нужен лог: метод работает, только если агент показывает свои шаги. В «чёрных ящиках» вроде чата, где виден только итог, разбор не сделать.
⚠️ Часть ошибок — инфраструктура: блокировки сайтов, капчи, мёртвые ссылки инструкцией не лечатся. Это среда, а не поведение модели.
⚠️ Частота ошибок зависит от фреймворка и модели: одни ломаются на ранней остановке, другие на плохих запросах, третьи на потере ограничений. Чужие цифры нельзя переносить на вашего агента, нужно мерить на своём.
⚠️ Много системных ошибок ≠ провал: агенты часто восстанавливаются сами. Не стоит чинить всё подряд, ориентируйтесь на ошибки, которые реально ломают итог.
⚠️ Часть текста статьи не получена: обсуждение практических выводов оборвано, промпты судьи вынесены в приложение и в тексте не приведены. Шаблон выше — реконструкция по описанию метода.
Как исследовали
Идея была в том, чтобы смотреть не на итоговый балл, а на траектории. Команда взяла готовые бенчмарки (BrowseComp, BrowseComp-zh, GAIA text-only, XBench-DS для поиска фактов и Deep Research Bench для отчётов) только как источник задач, чтобы агенты нагенерировали длинные логи. Для поиска использовали фреймворк Miroflow с двумя инструментами (search и fetch). Ограниченный набор нужен, чтобы ошибки не размывались сложной экосистемой. Моделей две: GPT-5-mini и открытая MiroThinker-30B. Для отчётов взяли open-deep-research (на GPT-5) и step-deep-research (на Step-3.5-Flash).
Разметка шла в два слоя. Системные ошибки находили парсером и LLM-судьёй, который сверяет намерение с вызовом. Смысловые категории сначала вывели вручную: люди просмотрели выборку траекторий и описали повторяющиеся паттерны. Потом GPT-5-судья разметил остальное в масштабе.
Результаты по MiroThinker-30B на поиске: - Доля шагов без системных ошибок: 75% на BrowseComp, 79% на BrowseComp-zh, 63% на XBench-DS, но всего 28% на GAIA. - На GAIA из 4362 шагов 3145 содержали ошибку. При этом точность 63%, тогда как на BrowseComp при чистых шагах всего 17%. Частые системные ошибки не мешают успеху, агент их обходит. - Чисто синтаксические сбои редки: десятки на тысячи шагов. Доминируют Tool-Function Mismatch, Domain Tool Misalignment и Anti-Scraping.
На смысловом уровне авторы описывают контраст моделей: - GPT-5-mini чаще останавливается рано и ограничивается сниппетами. Авторы называют это нежеланием вести многошаговый поиск. - MiroThinker-30B ищет упорно, но плохо формулирует запросы и пропускает сигналы в плотных выдачах. - Open Deep Research чаще всего страдает от Goal Drifting: контекст растёт, ограничения теряются. - Step Deep Research чаще фабрикует данные, чтобы закрыть структуру отчёта. Ошибки у него идут каскадом: игнор противоречий плюс выдумка.
Практический вывод: ошибки зависят от архитектуры агента, поэтому универсальной «починки» нет. Сначала нужно измерить, какая ошибка у вашего агента главная. Авторы также отмечают положительную связь между долей безошибочных шагов и итоговой точностью. Но в таблице по системным ошибкам этого не видно: на GAIA безошибочных шагов мало, а точность высокая. Зависимость, вероятно, относится к смысловым ошибкам.
Оригинал из исследования
Промпты судьи в статье вынесены в Appendix C и в тексте не приведены. Оригинальные названия категорий — для поиска и разметки:
System-Level:
Agent Tool Call: Tool Call Parsing Failure; Incorrect Tool Name
Web Search: Call Formatting Error; Tool-Function Mismatch; Irrelevant Query;
Domain Tool Misalignment; Syntactical Query Failure
Web Fetch: Unsupported Content Modality; Non-Existent Page; Anti-Scraping Blockers
Task-Level (Deep Search): Observation Neglect; Surface-Level Skimming;
Premature Stopping; Rabbit Hole Trap; Ineffective Query
Task-Level (Deep Research): Contradiction Neglect and Sourcing Bias;
Synthesis Hallucination; Goal Drifting
Контекст: это полный список категорий, по которым авторы размечали траектории.
Адаптации и экстраполяции
Это наши достройки. В статье они не проверялись.
💡 Адаптация для системного промпта / CLAUDE.md исследовательского агента: превращаем категории ошибок в правила.
Правила поиска:
- Не опирайся на сниппеты: если нужного факта нет в сниппете, открой страницу целиком.
- Перед ответом на вопросы «найди все…» перечисли, сколько кандидатов ты нашёл и что проверил. Если не уверен в полноте, продолжай поиск.
- После каждого результата выпиши, что нового ты узнал. Если нужный факт уже был в выдаче, используй его.
- Если два запроса подряд дали пустой результат, смени формулировку по существу, не повторяй похожий запрос.
- Не вставляй URL в поисковую строку: для адреса используй инструмент открытия страницы.
Правила отчёта:
- Если источники противоречат друг другу, покажи оба значения и источники. Не выбирай первое попавшееся.
- Если данных не нашёл, пиши «не найдено». Не заполняй пробелы знаниями из памяти.
- Перед финальным ответом перечитай исходную задачу и сверь формат и ограничения.
🔧 Техника: убрать «Проход 1» → быстрее и дешевле. Если сайт и инструменты у вас стабильные и важны только смысловые ошибки, оставь в промпте только Проход 2.
🔧 Техника: добавить колонку «серьёзность» (критично / терпимо). Тогда судья отделит ошибки, которые испортили итог, от тех, которые агент сам исправил. Это учитывает вывод статьи о том, что частые сбои не всегда критичны.
Экстраполяция: защита от Goal Drifting в длинных сессиях агента. Попроси агента каждые 10–15 шагов перечитывать исходные ограничения и сверять с ними текущий прогресс. Это достройка принципа: в статье показан сам эффект потери ограничений при росте контекста, но не проверка такого приёма.
Ресурсы
- Статья: Benchmarking and Error Analysis of Deep Search and Deep Research LLM Agents
- Авторы: Zixuan Yu (Sun Yat-sen University), Zhenheng Tang (HKUST), Xiaowen Chu (HKUST Guangzhou), Bo Han (Hong Kong Baptist University, TMLR Group)
- Площадка: ICML Workshop on Failure Modes in Agentic AI (FAGEN), Сеул, 2026
- Фреймворки в экспериментах: Miroflow, MiroThinker-30B, open-deep-research, step-deep-research
- Бенчмарки: BrowseComp, BrowseComp-zh, GAIA (text-only), XBench-DS, Deep Research Bench