TL;DR
LongHarness — это обвязка для агента, который отвечает на вопросы по огромной папке документов (десятки миллионов токенов). Вместо одной длинной истории переписки агент ведёт два отдельных списка. Первый — «банк доказательств»: короткие утверждения, у каждого есть ссылка на прочитанный источник и статус (действует / заменено / отозвано). Второй — «состояние выводов»: что агент сейчас считает верным и какие пробелы ещё мешают ответить. Следующий поиск идёт строго по пробелам, а новый факт сразу пересматривает вывод.
Обычный агент теряет нить. Он нашёл «поставщик А привезёт в понедельник», ушёл искать дальше, и это условие испарилось из головы. Либо он ищет бесконечно, пока не кончится бюджет, и в итоге отвечает наугад. Причина проста: выводы живут «где-то в истории чата» или в свободных заметках, и модель не видит, что уже решено, а что нет. Результат: прямое чтение даёт 15,8% точных ответов, а такой же агент с явными списками — 60,2%. Обвязки Claude Code и Codex на той же модели получили 48,1% и 46,6%.
Метод работает в цикле из трёх действий. Агент ищет и читает по текущему пробелу. Затем записывает найденное в банк доказательств с источником, а устаревшее помечает «заменено» или «отозвано». После этого пересматривает выводы и пробелы. Перед финальным ответом он проверяет, не изменят ли оставшиеся пробелы решение.
Схема метода
СОСТОЯНИЕ 1: Банк доказательств → [id | утверждение | источник | статус: действует/заменено/отозвано]
СОСТОЯНИЕ 2: Состояние выводов → [вывод | на каких id держится | открытые пробелы]
ЦИКЛ (много ходов, состояния живут между ходами):
ШАГ 1: Выбрать пробел → искать/читать только то, что его закрывает
ШАГ 2: Записать факт в банк (обязательно со ссылкой на прочитанный источник)
Исправление = новая запись, старая → «заменено»; ошибка → «отозвано»
ШАГ 3: Пересмотреть выводы по действующим доказательствам → обновить пробелы
ШАГ 4: Перед ответом: добавить недоучтённое, проверить — могут ли пробелы изменить решение
СТОП: бюджет исчерпан → ответ без гарантий
Это обвязка с кодом-контролёром: он проверяет формат, ссылки и бюджет. Идею можно повторить в агенте с файлами инструкций (см. шаблон), но тогда ссылки и бюджет придётся проверять самому.
Пример применения
Задача: Вы запускаете линейку термосов на Wildberries. Поставка должна быть на складе до пятницы. В папке 300 писем, накладных и счетов от двух фабрик. Первая оценка: фабрика А быстрее и дешевле. Агент должен выбрать поставщика и показать, на чём держится выбор.
Промпт: (для агента в Claude Code или Cursor с доступом к папке /supply)
Вопрос: какой поставщик (А или Б) успеет с отгрузкой на склад WB в Коледино до пятницы 18:00?
Работай по правилам из CLAUDE.md: веди файлы EVIDENCE.md и CONCLUSIONS.md.
Начальная версия вывода: «А быстрее и дешевле». Это гипотеза, не факт.
Для каждого вывода сразу выпиши пробелы: что нужно найти, чтобы его подтвердить или опровергнуть.
Ищи только то, что закрывает пробелы. Лимит: 40 поисков.
Результат: Агент заведёт два файла и будет обновлять их на каждом шаге. В EVIDENCE.md появятся записи вроде «А: отгрузка в понедельник» со ссылкой на письмо. В CONCLUSIONS.md будет стартовая гипотеза и пробел «когда приедет Б?». Найдя уведомление о поставке Б, агент добавит запись, пересмотрит вывод и закроет пробел. Старая запись при этом получит статус «заменено». В финале придёт ответ со ссылками на действующие доказательства. Если лимит поисков кончится раньше, ответ придёт с перечнем незакрытых пробелов, а не с молчаливым откатом к первой гипотезе.
Почему это работает
Слабость. Модель плохо удерживает «что уже выяснено, а что нет», когда история разрастается. Ранние находки тонут в поздних, поправки не доходят до итогового вывода, а поиск превращается в блуждание. Свободные заметки помогают слабо: в них вывод, факт и вопрос лежат вперемешку.
Сильная сторона. Модель хорошо делает локальные операции: прочитать кусок, выписать утверждение со ссылкой, сравнить его с выводом, сформулировать, чего не хватает. Всё это короткие и чётко очерченные задачи.
Как метод это использует. Факты и выводы разведены по двум спискам, а пробел становится «заданием на поиск». Так у поиска появляется цель, и он останавливается, когда пробелов нет. Статусы «заменено» и «отозвано» не дают устаревшему факту остаться в рассуждении. Аблации это подтверждают: структурированные выводы обошли свободные заметки на 6,8 и 7,8 пункта. А список «только дописывать» без замены потерял 3,8 и 10 пунктов.
Рычаги управления: - Лимиты поисков и чтения → уменьшай для простых вопросов, увеличивай для сложных составных. - Поле «пробелы» → без него агент вернётся к блужданию. Явное указание «ищи по пробелам» тоже дало прирост в аблации. - Обязательная ссылка на источник → убери, и записи станут «пересказом по памяти». - Проверка перед ответом («могут ли пробелы изменить решение?») → замени своим критерием остановки, например «все пробелы закрыты или помечены как недоступные».
Шаблон промпта
Для файла инструкций агента (CLAUDE.md / AGENTS.md) или системного промпта. Структура сохраняет логику метода: два состояния, статусы, цикл по пробелам.
Ты — исследовательский агент. Отвечаешь на вопрос по большой папке документов {папка}.
Читать всё нельзя, поэтому работаешь через два рабочих файла.
EVIDENCE.md — банк доказательств. Только факты из прочитанных источников.
Формат записи: [e{номер}] | {утверждение} | {файл / страница / абзац} | статус: действует | заменено на e{N} | отозвано
Правила:
- Запись без точной ссылки на источник, который ты реально прочитал, запрещена.
- Исправление факта = новая запись; старая получает статус «заменено на e{N}».
- Если факт оказался ошибочным и замены нет — статус «отозвано».
- Ничего не удаляй. Меняй только статусы.
CONCLUSIONS.md — состояние выводов. Только твои интерпретации.
Формат:
Вывод c{номер}: {текущее суждение} | опирается на: e{..}, e{..} | уверенность: подтверждён / гипотеза
Пробел g{номер}: {что нужно найти, чтобы подтвердить, уточнить или опровергнуть вывод c{..}}
Факты и выводы не смешивай: факты — только в EVIDENCE, суждения — только в CONCLUSIONS.
Перед началом: сформулируй первую гипотезу ответа и выпиши пробелы.
Пока есть открытые пробелы и не исчерпан лимит ({лимит_поисков} поисков, {лимит_чтения} чтения):
1. Выбери самый важный для решения пробел.
2. Найди и прочитай то, что может его закрыть. Не ищи «на всякий случай».
Если несколько гипотез — ищи то, что их различает.
3. Занеси найденное в EVIDENCE.md по правилам выше.
4. Покажи обновлённые записи, затем пересмотри CONCLUSIONS.md:
вывод по-прежнему подтверждён, требует уточнения или изменился?
Обнови ссылки на доказательства и список пробелов.
5. Если пробел не закрылся — переформулируй запрос или расширь область чтения.
Если доказательство заменено или отозвано, выводы сами не меняются: пересмотри их вручную.
Перед ответом:
- Учти все релевантные действующие записи, которых ещё нет в выводах.
- Проверь: могут ли оставшиеся пробелы изменить ответ на вопрос?
- В ответе укажи ссылки на действующие записи e{..} и источники.
- Если лимит исчерпан, а пробелы остались, прямо скажи, каких данных не хватило. Не откатывайся молча к первой гипотезе.
Подставляйте: {папка} — где лежат документы, {лимит_поисков} и {лимит_чтения} — бюджет под задачу.
🚀 Быстрый старт — вставь в чат:
Вот шаблон ведения доказательств и выводов для агента. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, где лежат документы, какой вопрос и какие бывают сроки и условия отказа. Ещё уточнит бюджет поисков и нужна ли строгая ссылка на источник. Это нужно, чтобы шаблон под твою задачу получил свои статусы, формат пробелов и точку остановки.
Ограничения
⚠️ Нужна обвязка, а не только промпт: В статье проверки ссылок, бюджета и формата делает программа-контролёр. В обычном агенте с файлами этого нет. Агент сам отвечает за то, что запись верно передаёт источник, и контролёра нет.
⚠️ Доказательств нет для простых задач: Метод проверяли на сложных вопросах по огромным корпусам, где нужно собрать значения из многих документов. Для вопроса «найди одну цифру в одном файле» два файла состояний — лишняя нагрузка.
⚠️ Выигрыш зависит от модели: С одной моделью преимущество над лучшей конкурирующей обвязкой — 12–19 пунктов, с другой на сложном наборе — около одного пункта. Не ждите одинакового прироста везде.
⚠️ Один прогон: Основные сравнения сделаны по одному запуску на конфигурацию. Трёхкратные прогоны есть в приложении, но только для одной модели.
⚠️ Пересчёта нет: Когда доказательство заменено или отозвано, выводы автоматически не обновляются. Агент должен сам их пересмотреть, и в инструкции это нужно прописать явно.
Как исследовали
Исследователи взяли четыре набора вопросов. Главный из них — OfficeQA Pro: вопросы по сотням документов Казначейства США. Для первой версии это около 100 миллионов токенов, во второй корпус вдвое больше, а вопросы составные: нужно собрать и свести значения из разных источников. Агентам не дают «правильных» документов, поиск входит в задачу. Для проверки на заданном контексте взяли ещё два набора: AA-LCR и длинную часть LongBench v2.
Сравнивали три вещи. Первая — «чистые» модели, которым подсовывают найденные поиском фрагменты в окно 256 тысяч токенов. Это работало плохо: максимум 23,2% на первой версии и 5,6% на второй. Вторая — готовые обвязки (Codex, Claude Code, RLM) на той же модели. Третья — LongHarness. Модели во всех сравнениях были одинаковые, чтобы разница шла только от обвязки.
Результат на GLM-5.3-Flash: 60,2% против 48,1% у Claude Code на первой версии и 61,1% против 42,2% у Codex на второй. Затем разобрали, на каком этапе агенты проигрывают: найти доказательство, удержать его до ответа или превратить в верный ответ. LongHarness выигрывал на всех трёх этапах, особенно на поиске и на финальной сборке ответа. Аблации выключали по одному компоненту. Сильнее всего просело, когда убрали структурированные выводы, а накопление «только дописывать» оказалось почти так же плохо. Любопытно, что на сложной второй версии потери от любой аблации больше. Чем больше значений надо свести, тем важнее держать порядок в доказательствах.
Адаптации и экстраполяции
🔧 Техника: добавить поле «что изменит ответ» к каждому пробелу → поиск станет ещё прицельнее
Пробел g3: когда приедет Б? | если дата после пятницы → выбор А; если до → выбор Б
Так агент заранее видит, зачем ему нужен факт, и не собирает лишнего.
🔧 Техника: убрать скрытность → видеть дрейф
Добавьте в правило: «после каждого шага покажи изменения в EVIDENCE и CONCLUSIONS списком „добавлено / заменено / отозвано"». Вы сразу заметите, где агент потерял условие.
Экстраполяция: тот же принцип в обычном чате без документов. Для долгого разбора решения («какой оффер брать», «куда вложить 3 млн ₽») можно просить модель в конце каждого ответа выдавать два блока: «Факты (что ты мне сообщил, с датой)» и «Текущий вывод + чего не хватает». Когда вы исправите факт, она пометит старый как заменённый и пересмотрит вывод. Это перенос идеи, в статье такой сценарий не проверяли.
Ресурсы
- LongHarness: Advancing Agentic Reasoning over 100M-Token Corpora via Stateful Evidence Management — основная статья.
- Бенчмарки: OfficeQA Pro V1/V2 (Opsahl-Ong et al., 2026), AA-LCR (Artificial Analysis), LongBench v2 (Bai et al., 2024).
- Сравнивались с Codex (OpenAI), Claude Code (Anthropic), RLM (Zhang et al., 2025).
- Имена авторов и университеты во входных данных не указаны.