Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
ИИ-агент научился устойчивее отвечать на вопросы по документам, которые во много раз больше его окна контекста. Songtao Huang и коллеги в нерецензированном препринте, где все числа получены самими авторами, показали: LongHarness обошёл Codex на сложной версии OfficeQA Pro на 18,9 процентного пункта. Для продуктовых команд это переносит ключевую часть архитектуры из истории диалога в отдельное управляемое состояние.
Факты и выводы живут в разных состояниях
Обычная агентная обвязка складывает результаты поиска, заметки и рассуждения в растущую историю взаимодействия. Модель должна каждый раз восстановить из неё, какие сведения подтверждены, какие уже исправлены и чего ещё не хватает для ответа.
LongHarness поддерживает три части состояния. EvidenceBank хранит найденные утверждения со ссылками на конкретные фрагменты документов. Conclusion State содержит текущие выводы, рабочие гипотезы и явные пробелы в них. История сохраняет прежние действия и наблюдения, но перестаёт быть единственным местом, где лежит смысл работы агента.
Поиск направляют пробелы в выводах. Если агенту не хватает значения за определённый период или факта, который различает две гипотезы, он формулирует следующий запрос именно под эту потребность. После чтения документа агент добавляет свидетельство в банк, а затем отдельно пересматривает связанный вывод.
У свидетельств есть жизненный цикл. Новая запись сначала ссылается на прочитанный фрагмент, затем становится активной. Исправление создаёт новую активную запись, а прежнюю помечает как заменённую; опровергнутый факт можно отозвать. Так исправление не растворяется среди старых сообщений и остаётся доступным на последующих шагах.
Контроллер проверяет структуру действий, ссылки на уже прочитанные источники и ресурсные лимиты. При этом он не исправляет выводы автоматически: после замены свидетельства модель должна увидеть результат операции и обновить зависимые утверждения. Это оставляет рассуждение модели, но делает переходы состояния наблюдаемыми и проверяемыми.
Архитектуру проверяли на OfficeQA Pro с корпусом примерно в 100 миллионов токенов и его увеличенной версией, а также на AA-LCR и длинной части LongBench v2. В качестве основы использовали GLM-5.3-Flash и Qwen3.8-Flash, поэтому работа охватывает два класса входных данных: самостоятельный поиск по коллекции и рассуждение по уже выданному контексту.
Явное состояние дало основной прирост на составных вопросах
С GLM-5.3-Flash доля ответов, полностью совпавших с эталоном, выросла на OfficeQA Pro V1 с 15,8% до 60,2%. На V2, где нужно собирать значения из нескольких документов, результат поднялся с 4,4% до 61,1%.
Разбор траекторий связывает разницу не только с поиском. LongHarness чаще сохранял найденное свидетельство до финального решения и чаще превращал его в правильный ответ. Показателен случай с геометрическим средним расходов казначейства: Codex заметил исправление одного исходного значения, но не перенёс его в окончательный расчёт, тогда как LongHarness заменил запись в EvidenceBank и пересчитал ответ.
Проверка отдельных компонентов поддерживает именно архитектурное объяснение. Когда банк разрешал только добавлять факты, но не исправлять и отзывать их, точность на V2 снизилась на 10 процентных пунктов. Удаление поиска по пробелам и замена структурированных выводов обычными рабочими заметками тоже ухудшали результат.
Главное сравнение запускали один раз для каждой связки обвязки, модели и набора задач. Все системы получали одинаковые вопросы и полный корпус без эталонных документов, но результаты пока описывают заданные модели, лимиты и четыре тестовых набора, а не любой поиск по корпоративным данным.
В планах появляется отдельный слой состояния
Работа не требует обучать новую модель. LongHarness действует во время выполнения и может стоять поверх разных LLM, поэтому ближайший практический вывод касается не выбора основы, а устройства агентной платформы.
Команде, которая строит поиск по договорам, отчётам или базе знаний, имеет смысл отделить дословные свидетельства от интерпретаций. Для каждого факта нужно хранить источник, активный статус и историю замены; для каждого вывода — ссылки на подтверждения и перечень сведений, которые ещё способны изменить решение. Обычная память диалога эти гарантии не даёт.
Второе изменение касается инструментов. Агенту нужны отдельные операции для поиска, ограниченного чтения, добавления, исправления и отзыва фактов, вычисления и окончательной отправки ответа. Контроллер должен отклонять ссылки на непрочитанные фрагменты и не принимать финальный ответ, если его основания уже заменены.
Такой подход не означает бесплатный длинный контекст. В опытах LongHarness мог прочитать суммарно до миллиона токенов на задачу. При переходе к более сложному корпусу медиана длины траектории выросла у него на 8 шагов, а у Claude Code — на 95, но работа не переводит этот выигрыш в стоимость API или задержку.
Поэтому менять выбранную LLM только из-за этой статьи рано. Менять схему состояния уже разумно, если агент выполняет много поисковых шагов, объединяет противоречивые документы или должен пересматривать расчёт после исправления исходного факта. LongHarness показывает, что в таких задачах управляемые свидетельства могут влиять на результат сильнее, чем ещё один длинный журнал сообщений.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
