ANTMAN: координация агентов по списку неразрешённых вопросов, а не по размеру данных

ПОДГОТОВКА: пространство поиска делится на «территории» + карточка на каждую (что внутри)
ШАГ 0: Вопрос → реестр потребностей (Need Graph): статус, доказательства, попытки, прогресс
ЦИКЛ (пока есть открытые потребности):
  ШАГ 1: Select — выбрать открытую потребность
  ШАГ 2: Route — выбрать территорию по реестру и карточкам
  ШАГ 3: Exec — исполнитель ищет ТОЛЬКО в своей территории → отчёт (доказательства, прогресс, что осталось неясно)
  ШАГ 4: Update — закрыть / оставить / переформулировать / добавить новую потребность
  ЗАСТОЙ: N неудач подряд → переформулировать | перенаправить | запасной путь
ФИНАЛ: ответ собирается из доказательств закрытых потребностей

В статье это оркестрация на коде. Промпты авторов вынесены в Приложение E, а в тексте их нет. Ниже я переношу механику в текстовую инструкцию.

Задача: Вы ведёте интернет-магазин на Python. Клиенты жалуются, что иногда заказ после оплаты через ЮKassa создаётся дважды. Репозиторий большой: десятки модулей, платежи, корзина, очереди. Вы просите Claude Code найти причину и не хотите, чтобы он запускал десять параллельных поисков «по всему».

Промпт:

Ты — координатор расследования. Сам код не читай «вообще».
Ты ведёшь реестр неразрешённых вопросов и решаешь, куда смотреть дальше.



Почему при оплате через ЮKassa иногда создаётся дубль заказа?



T1: apps/orders — модели и создание заказа
T2: apps/payments — интеграция с ЮKassa, вебхуки
T3: apps/cart — корзина и оформление
T4: workers/ — фоновые задачи Celery и ретраи



Для каждой потребности веди: id, формулировка, status (open/resolved/stalled),
evidence (файл:строка + факт), attempts (где искали и что вышло),
progress, depends_on.



Init: разложи вопрос на 3–5 потребностей.
While есть open или stalled и шагов < 12:
  n = Select(G)
  t = Route(n, G, Territories)
  r = Exec(t, n)   // смотри только в t; отчёт: evidence, progress, remaining_uncertainty
  G = Update(G, r) // resolve | keep | reframe(n→n') | add_need
  If 2 попытки по n без прогресса: Recover(n) = reframe | reroute | fallback
  Покажи текущий реестр после каждого шага.
Final: Synthesize только из evidence закрытых потребностей.

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

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

Сильная сторона. Модель хорошо ведёт структурированный список и отлично обновляет его по новому факту. Дать ей чёткую запись «что открыто, что закрыто, что пробовали» — значит снять с неё нагрузку держать всё в голове.

Как метод это использует. Размер пространства определяет только то, где можно искать, а не сколько агентов работает. Число активных исполнителей ограничено двумя величинами: количеством территорий и числом потребностей, умноженным на лимит попыток. Явный реестр важен сам по себе. Когда его заменили обычным «перепланированием» без графа, качество упало примерно на четверть на длинном контексте на 512K и на шестую часть на GAIA.

Рычаги управления: - Лимит попыток на потребность (в примере 2) → меньше число — быстрее и дешевле, но больше риск бросить решаемое. - Лимит шагов (12) → защита от бесконечного цикла и расходов. - Поля реестра → убери depends_on для простых задач, добавь confidence для задач, где важна уверенность. - Показ реестра после каждого шага → убери, если нужен только итог. Оставь, если хочешь контролировать ход. - Три вида восстановления (переформулировать / перенаправить / запасной путь) → оставь только те, что подходят задаче.

Ты — координатор поиска. Сам не ищешь и не отвечаешь по памяти.
Ты ведёшь реестр неразрешённых информационных потребностей
и решаешь, куда направить поиск дальше.


{вопрос}


T1: {область_1} — {что внутри}
T2: {область_2} — {что внутри}
T3: {область_3} — {что внутри}



Для каждой потребности веди:
- id и формулировка
- status: open | resolved | stalled
- evidence: найденные факты со ссылкой на источник
- attempts: где уже искали и что получилось
- progress: что осталось выяснить
- depends_on: от каких потребностей зависит



Init: разложи {вопрос} на {число_потребностей} потребностей.
While есть open или stalled и шагов < {макс_шагов}:
  n = Select(G)                  // выбери открытую потребность
  t = Route(n, G, Territories)   // выбери территорию по реестру и описаниям
  r = Exec(t, n)                 // ищи ТОЛЬКО в t; верни evidence, progress, remaining_uncertainty
  G = Update(G, r)               // resolve | keep | reframe(n→n') | add_need
  If {лимит_попыток} попыток по n без прогресса:
     Recover(n) = reframe | reroute | fallback
  Покажи реестр после шага.
Final: ответ только из evidence закрытых потребностей. Если что-то не закрыто — скажи прямо.

Что подставлять: {вопрос} — задача, {область} — папки, базы, разделы документов или источники. Описания областей важны: по ним идёт маршрутизация. {число_потребностей} — обычно 3–5. {макс_шагов} — потолок 8–15. {лимит_попыток} — 2–3.

🚀 Быстрый старт — вставь в чат или в агента:

Вот шаблон ANTMAN (координация поиска по реестру неразрешённых потребностей).
Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

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

Модель спросит, из каких областей состоит ваше пространство поиска и что в каждой лежит. Это нужно, чтобы маршрутизация шла по описаниям, а не наугад. Ещё она уточнит, что для вас считается закрытой потребностью и сколько попыток разрешено. Паттерн реестра и цикла она возьмёт из шаблона.

⚠️ Нужен код в оригинале: авторы строили систему на оркестраторе с отдельными вызовами исполнителей. Шаблон выше — текстовый перенос механики в одну инструкцию агенту. Эффект в таком виде в статье не проверялся. Сами промпты авторов в тексте не приведены.

⚠️ Малые выборки: на вопросах из сборников — по 30 на набор, на проверке длинного контекста — 10 вопросов. Работа — препринт на рецензии. Результаты стоит считать сильным сигналом, но не окончательным доказательством.

⚠️ Одно семейство моделей: главная модель — GPT-4.1, малые исполнители — Qwen3-8B. Как поведёт себя схема на других моделях, не проверяли.

⚠️ Малые исполнители проседают на трудном: с моделью на 8B метод держится заметно хуже на самых сложных вопросах (Level 3 в GAIA, MuSiQue). Дешёвых исполнителей стоит ставить на простые территории.

⚠️ Не лучше везде: на классических вопросах по нескольким документам специализированный поиск S2G-RAG остаётся сильным. Особенно ему подходит Wiki-набор, где он выигрывает.

⚠️ Вызовов станет больше, если вопрос сложнее: при фиксированном объёме и росте требуемых фактов с 1 до 16 вызовов на запрос выросло с 35 до 86. Экономия идёт от размера пространства, не от сложности запроса.

⚠️ Для коротких задач избыточно: если ответ лежит в одном документе, реестр и цикл — лишние шаги.

Идея была простой: разделить две вещи, которые обычно смешивают. Одна — размер пространства поиска, вторая — сколько нужно знать для ответа. Для первой взяли тест «иголки в стоге» из LongAgent: 10 вопросов, доказательство лежит в начале, середине или конце, вокруг наращивали шум с 32K до 512K. Нужная информация оставалась той же, менялся только объём лишнего. Для второй сделали обратный опыт: пространство зафиксировали на 512K и увеличили число нужных фактов с 1 до 16. Все факты ANTMAN нашёл и ответил верно на все вопросы.

Потом проверили, переносится ли идея на реальные среды: два набора вопросов по репозиториям (108 и 80 вопросов) и 103 текстовые задачи GAIA с инструментами. Сравнивали с поиском по BM25, DPR, ReAct, OWL, S2G-RAG и специализированными агентами для кода. На стандартных вопросах по нескольким документам из трёх наборов было 30 вопросов на набор и девять методов — 810 ответов.

Самое показательное — абляция (отключение одной части): заменили явный реестр обычным «перепланированием» без графа. Качество упало примерно на четверть на 512K и на шестую часть на GAIA. Отсюда вывод для практики: пользу даёт именно явно записанное состояние «что осталось выяснить», а не просто «умная перестройка плана». Ещё одна находка: при положении доказательства в середине контекста разрыв у ANTMAN почти нулевой, а при подаче всего контекста целиком — заметно отрицательный. Малые исполнители сохранили от 89 до 98 процентов качества. Дешёвые модели можно ставить на «чёрную работу» при сильном координаторе.

🔧 Техника: убрать зависимость от исполнителей → реестр в одном чате

Если у вас нет агентов-исполнителей, оставьте только реестр. Замените цикл на:

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

Так реестр работает как память расследования в длинной переписке. Проверено ли это в одном чате — в статье нет.

🔧 Техника: добавить критерий остановки → защита от бесконечного поиска

Добавьте в : «Если последние три шага не закрыли ни одной потребности — остановись и сообщи, что именно не удалось найти». Это переводит условие выхода из «шагов хватит» в «прогресса нет».

Экстраполяция: реестр потребностей в CLAUDE.md

## Правила расследования
- Перед поиском по репозиторию выпиши открытые вопросы списком.
- Для каждого веди: статус, найденные факты (файл:строка), что уже пробовал.
- Не запускай субагентов на каждую папку. Подключай субагента только под конкретный открытый вопрос.
- Вопрос без прогресса после двух попыток — переформулируй или смени папку.
- В финале ссылайся только на факты из закрытых вопросов.

Это мой перенос принципа «координация идёт от вопросов, а не от размера репозитория», в статье такая инструкция не проверялась.

• ANTMAN: Adaptive Need Tracking for Multi-Agent Navigation in Large Information Spaces — Jerry Wang, Haibo Jin, Xiaopeng Yuan, Peng Kuang, Haohan Wang, University of Illinois Urbana-Champaign. Препринт, на рецензии.
• Сравнивали с: LongAgent (Zhao et al., 2024), Chain of Agents (Zhang et al., 2024), S2G-RAG (Li et al., 2026), ReAct (Yao et al., 2023), OWL (Hu et al., 2025), RepoGraph, RepoDistill.
• Наборы данных: HotpotQA, 2WikiMultiHopQA, MuSiQue, GAIA, RepoProbe-Python, SWE-QA-Pro, Needle-in-a-Haystack PLUS.
• Идейная основа: модель информационного поиска Bates, 1989 (запрос меняется по ходу поиска).