Harness-Search: три роли вместо одного агента для долгого поиска — одна роль ищет, вторая ведёт записи, третья не даёт остановиться раньше времени

ЦИКЛ (до лимита ходов):

РОЛЬ 1 — Поисковик (Retrieval Policy): предлагает ОДНО действие
   search | read | redirect | curate | end

РОЛЬ 2 — Хранитель памяти (Memory Operator): проверяет и записывает
   • search/read  → убирает дубли, оценивает релевантность каждого документа
   • redirect     → формулирует новое направление, старое пишет в журнал
   • curate       → отклоняет неверные ID, дубли, превышение лимита
   (сам ничего не ищет и не решает, когда закончить)

РОЛЬ 3 — Аудитор (Summary Auditor): вызывается ТОЛЬКО когда поисковик сказал end
   → пробует собрать ответ из отобранных доказательств
   → проверяет: полнота / обоснованность / связность
   → answer_ready → конец
   → search_more  → называет пробел, поисковику разрешён только redirect

ЖЁСТКИЕ ПРАВИЛА ХОДА:
   • после 5 поисков подряд → только curate
   • после curate → только redirect или end
   • после search_more → только redirect

Рабочая память общая: все найденные документы, отобранные доказательства (лимит по числу), текущее направление поиска и журнал (что исследовано, что не сработало, что не закрыто).

Задача: Вы готовите разбор для подкаста: как Александр Говор выкупил российский бизнес McDonald's и превратил его во «Вкусно — и точка». Нужна цепочка проверенных фактов: кто и когда объявил уход, на каких условиях прошла сделка, что досталось покупателю, кто сейчас владеет брендом. Задача многошаговая: каждый следующий вопрос зависит от найденного. Обычный агент быстро набирает пересказы новостей и закругляется, не закрыв юридическую сторону сделки.

Промпт:

Ты ведёшь долгий поиск в режиме трёх ролей. Тема: «Как Александр Говор выкупил российский бизнес McDonald's: условия сделки, что перешло покупателю, кто владеет брендом сейчас».

Роли (в каждом ходе пиши, какая роль говорит):

[ПОИСКОВИК] Предлагает ровно одно действие: search, read, redirect, curate или end.
[ХРАНИТЕЛЬ] Единственный, кто меняет память. Проверяет предложение поисковика и записывает результат. Сам ничего не ищет и не решает, когда закончить.
[АУДИТОР] Вызывается только после end. Пробует написать ответ строго по отобранным доказательствам и проверяет полноту, обоснованность, связность.

Память (показывай её в конце каждого хода):
- Найдено: список источников с короткой пометкой, о чём каждый
- Отобрано: до 15 источников, на которых будет держаться ответ
- Направление: что ищем прямо сейчас и зачем
- Журнал: что уже исследовано, что не дало результата, что осталось неясным

Правила хода:
- После 5 поисков подряд следующее действие только curate.
- После curate допустимы только redirect или end.
- end — это предложение, а не остановка. Решает аудитор.
- Если аудитор говорит search_more, он называет пробел, и следующее действие поисковика только redirect на этот пробел.

Начинай.

Результат: Модель будет вести поиск по ходам с пометками ролей. Видны серии поисков, затем отбор источников и смена направления (например, с общих новостей к условиям сделки). После предложения закончить аудитор пробует собрать ответ. Если звена не хватает (скажем, нет подтверждения условий передачи бренда), он вернёт search_more с названием пробела, и поиск продолжится. Финал: ответ только по отобранным источникам плюс журнал того, что искали и что осталось неподтверждённым.

Слабость. Когда одна модель ведёт поиск, все решения лежат в одной истории. Ей легко увязнуть в знакомом направлении и потерять уже найденное. Остановиться она тоже может слишком рано: «в целом всё понятно». Оценивать собственные находки сложно: модель судит о достаточности тем же умом, который эти находки собирал.

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

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

Рычаги управления: - Число поисков до обязательного отбора (в исследовании 5) → меньше для запутанных тем, больше для простых. - Лимит отобранных источников (60 в исследовании) → ограничьте под размер итогового ответа, иначе в «доказательства» попадёт всё подряд. - Лимит ходов (40) → защита от бесконечного поиска и от расхода токенов. - Критерии аудита (полнота, обоснованность, связность) → добавьте свой: «каждая цифра с датой», «два независимых источника на ключевой факт». - Журнал → проверяйте его, чтобы увидеть, где агент ходил по кругу.

Ты ведёшь долгий поиск информации по теме: {тема}.
Работаешь в трёх ролях. Перед каждой репликой пиши название роли в квадратных скобках.



[ПОИСКОВИК]
  Предлагает ровно одно действие за ход:
  search(запрос) | read(источник) | redirect | curate(добавить/убрать источники) | end
  Сам память не меняет — только предлагает.

[ХРАНИТЕЛЬ]
  Единственный, кто меняет рабочую память.
  - после search/read: убирает дубли, к каждому новому источнику пишет, чем он полезен для вопроса «{вопрос}»
  - после redirect: формулирует новое направление поиска, старое и причину смены записывает в Журнал
  - после curate: отклоняет несуществующие источники, дубли и всё, что выходит за лимит {лимит_источников}
  Сам ничего не ищет и не решает, когда закончить.

[АУДИТОР]
  Вызывается только после действия end.
  1. Пробует написать ответ на вопрос строго по списку «Отобрано».
  2. Проверяет: полнота (есть ли всё нужное для ответа?), обоснованность (каждое утверждение опирается на источник?), связность (факты складываются в одну цепочку?).
  3. Возвращает одно из двух:
     answer_ready — остановку принимаю
     search_more — остановку отклоняю; называет, какого факта или какой связи не хватает



Показывай в конце каждого хода:
- Найдено: все встреченные источники с пометкой, о чём они
- Отобрано: до {лимит_источников} источников, на которых держится ответ
- Направление: что ищем сейчас и зачем
- Журнал: что исследовано, что не сработало, что остаётся неясным



- Максимум {лимит_ходов} ходов.
- После {N} поисков подряд (search/read) следующее действие — только curate.
- После curate допустимы только redirect или end.
- end — это предложение остановиться, а не остановка. Решает [АУДИТОР].
- После search_more следующее действие [ПОИСКОВИКА] — только redirect на названный пробел.



Финал: ответ на вопрос только по списку «Отобрано», с указанием источника у каждого утверждения; отдельно — что не удалось подтвердить.


Начинай.

Что подставлять: {тема} — широкое описание задачи; {вопрос} — конкретный вопрос, на который нужно ответить; {лимит_источников} — например, 15; {N} — 5 для сложных тем, 8–10 для простых; {лимит_ходов} — например, 30–40.

🚀 Быстрый старт — вставь в чат (с включённым веб-поиском):

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

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

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

⚠️ Одиночный агент с описанием ролей почти не хуже: авторы сравнили полную систему с одним агентом, у которого три роли описаны в промпте. Разрыв небольшой, хотя и заметный. Шаблон выше — именно такая «облегчённая» версия, а не полная система из отдельных вызовов с жёсткими правами записи.

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

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

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

⚠️ Проверено на поиске по корпусам документов: эксперименты шли на базах документов и бенчмарках. Как поведёт себя схема на открытом вебе с шумными источниками, в статье не проверялось.

⚠️ Аудитор той же модели: аудит делает та же модель, что ищет. Она может принять слабые доказательства за достаточные. Критерии достаточности нужно задавать явно.

Команда Xiaohongshu и Шаньдунского университета взяла семь бенчмарков на долгий поиск. Четыре из них требуют вернуть набор документов с доказательствами, три — дать ответ на многошаговый вопрос. Все конкурирующие агентные системы запускали на одной и той же небольшой модели GPT-OSS-20B. Так сравнивали устройство системы, а не силу модели. В ключевых метриках система выиграла у сильнейшей конкурирующей схемы на каждом бенчмарке. Те же роли потом поставили на Qwen, Gemini и GPT, и результаты выросли дальше.

Самое поучительное — абляции (убирают по одному куску и смотрят, что сломается). Без хранителя памяти качество падает сильнее всего, на 13 пунктов. Без аудитора остановки просадка около 6 пунктов, без оценщика релевантности и планировщика направления примерно по 5. Значит, самое ценное здесь — дисциплина записи доказательств, а не «умный поиск». Отдельно проверили, нельзя ли получить то же в одном агенте: структурированные инструменты и промпт с тремя ролями дали прирост меньше, чем полная система, но не нулевой. Идею можно взять и в промпт, но потеряется часть эффекта. Анализ по ходам показал, что у обычных агентов покрытие доказательств упирается в потолок после первых шагов. Harness-Search продолжает находить новое до конца и меньше повторяет одни и те же запросы. Цена этого — больше токенов. Дополнительное дообучение на траекториях улучшило результаты, но это уже не про промптинг.

💡 Адаптация для агента с инструкциями (CLAUDE.md / системный промпт): переносить всю схему не обязательно. Достаточно правила «остановка = проверка».

Copy

Перед тем как завершить задачу и написать итог:
1. Составь черновик итогового ответа ТОЛЬКО из того, что ты подтвердил (файлы, логи, найденные источники).
2. Проверь три вещи: полнота (всё, что просили, закрыто?), обоснованность (у каждого утверждения есть источник?), связность (части не противоречат друг другу?).
3. Если не хватает факта или связи — назови, чего именно, вернись и закрой это одним целевым шагом. Только потом заканчивай.

Это моя адаптация принципа аудита, не точный промпт авторов.

🔧 Техника: аудитор в отдельном чате или субагенте → свежий взгляд. Когда поисковик говорит «готово», отдайте аудитору (новый чат, субагент в Claude Code) только отобранные источники и вопрос. Аудитор не видит всей истории поиска, поэтому не поддаётся «я же уже всё нашёл». Авторы использовали одну модель во всех ролях, так что отдельный контекст — моё предложение, его надо проверять.

• Harness-Search: Guiding Long-Horizon Search through Multi-Agent Coordination — Shanyong Wang, Zhenwen Ji, Lei Jin, Yining Zhao, Yicheng Qian, Chengqiang Lu, Yi Wu, Yao Hu, Lizhen Cui, Yanyu Xu. Xiaohongshu Inc.; Joint SDU-NTU Centre for Artificial Intelligence Research (Shandong University); University of Illinois at Urbana-Champaign.
• Код: https://github.com/SwimmingWang/Harness-Search
• Промпты и алгоритм — в приложениях A и E исследования (в доступной мне версии текста их нет, шаблон выше собран по описанию метода).
• Связанные работы: ReAct (Yao et al., 2022), Harness-1 (Jiang et al., 2026), MemHarness (Wu et al., 2026).