TL;DR
Evidence Ledger — способ организовать работу агента с инструментами. Агент не копит в диалоге сырые результаты поиска, а ведёт компактный журнал: что ещё нужно выяснить, какие факты подтверждены (с источником) и какие источники противоречат друг другу. Каждый результат инструмента сначала разбирает отдельный «критик». В журнал попадает только проверенная выжимка. Планировщик видит журнал и последний результат, но не всю историю.
Главная находка: агенты ошибаются не потому, что плохо «видят» или «читают», а потому, что теряют нить плана. Модель забывает, чего ещё не хватает, принимает шумную страницу за найденный ответ и останавливается раньше времени. Поэтому обвязка решает больше, чем модель. С одной и той же парой моделей точность менялась от 5,6% до 81% в зависимости от устройства агента. Замена «мозга» (планировщика) била по результату в полтора раза сильнее, чем замена «глаз и ушей» (модели, которая смотрит видео и слушает аудио).
Метод в три шага: составь чек-лист того, что нужно выяснить, проверяй каждую находку отдельным шагом-критиком до записи и отвечай только когда все обязательные пункты закрыты, а противоречий нет.
Схема метода
ШАГ 0: Разбор вопроса → чек-лист открытых потребностей (обязательные / дополнительные),
слоты для фактов и вычислений
ЦИКЛ:
ШАГ 1: ПЛАНИРОВЩИК читает журнал + последнее наблюдение → выбирает действие
(поиск, браузер, расчёт, проверка, finish)
ШАГ 2: Инструмент возвращает сырой результат
ШАГ 3: КРИТИК сверяет результат с открытыми потребностями
→ вердикт: подтверждает / противоречит / не содержит нужного
ШАГ 4: РЕДЬЮСЕР (единственный, кто пишет в журнал) → обновляет:
U (открытые) → F (факты, расчёты) → E (доказательства + источник) → C (конфликты)
ШАГ 5: Проверка готовности:
нет открытых обязательных потребностей И все слоты заполнены И нет конфликтов
→ да: черновик ответа + сверка с журналом
→ нет: дальше по циклу, либо «недостаточно данных», если действий не осталось
В оригинале это отдельные вызовы модели плюс код-редьюсер. В обычном чате роли разыгрываются по очереди в одном диалоге (см. шаблон).
Пример применения
Задача: вы готовите справку для выпуска подкаста про российский e-commerce. Вопрос: «Сколько месяцев прошло между IPO Ozon на Nasdaq и первым отчётным кварталом, когда компания показала положительный скорректированный EBITDA?» Нужно найти две даты в разных источниках, отсеять нерелевантные страницы и посчитать разницу. Это многошаговая задача со слотами «факт» и «вычисление». Именно здесь журнал выигрывает у обычного поиска «в лоб».
Промпт:
Ты — исследовательский агент с доступом к веб-поиску. Ты не отвечаешь по памяти
и не копишь сырые тексты в рассуждениях. Ты ведёшь ЖУРНАЛ ДОКАЗАТЕЛЬСТВ.
Вопрос: Сколько месяцев прошло между IPO Ozon на Nasdaq и первым отчётным
кварталом, когда компания показала положительный скорректированный EBITDA?
Формат ответа: целое число месяцев + одна строка с датами и источниками.
U (открытые потребности):
[обязательная] N1: дата IPO Ozon на Nasdaq
[обязательная] N2: первый квартал с положительным скорректированным EBITDA
[обязательная] N3: дата окончания/публикации этого квартала (уточнить, что берём за точку отсчёта)
[обязательная] N4: разница в месяцах
[дополнительная] N5: перепроверка по второму источнику
F (слоты фактов и расчётов): пусто
E (подтверждённые доказательства: факт + источник + дата источника): пусто
C (противоречия между источниками): пусто
Повторяй:
1. ПЛАНИРОВЩИК: прочитай журнал, выбери ОДНО действие, которое закрывает
открытую потребность. Напиши: действие + какую потребность закрывает.
2. Выполни действие (поиск / открытие страницы / расчёт).
3. КРИТИК: отдельным блоком оцени сырой результат относительно потребностей:
- ПОДТВЕРЖДАЕТ (что именно и где)
- ПРОТИВОРЕЧИТ (что с чем)
- НЕ СОДЕРЖИТ нужного
Не принимай страницу за ответ, если нужного факта на ней нет.
4. РЕДЬЮСЕР: обнови журнал по правилам:
- подтверждённый факт → в F, доказательство с источником → в E, потребность убери из U
- противоречие → в C, оба источника сохрани
- сырой текст в журнал НЕ копируй, только выжимку
5. Выведи обновлённый журнал целиком (коротко).
Отвечай, только если: нет открытых обязательных потребностей И все слоты фактов
и расчётов заполнены И журнал конфликтов пуст.
Дополнительная потребность может остаться открытой, если ответ от неё не зависит.
Потребность, которую не удалось закрыть после повторных попыток, пометь
«не удаётся закрыть» и убери из U.
Если действий, которые продвинут журнал, не осталось — ответь «недостаточно данных»
и перечисли, чего не хватает.
Перед финальным ответом составь черновик и сверь его с E: каждое число
в ответе должно иметь запись в журнале.
Результат: модель сначала раскладывает вопрос на 4–5 пунктов чек-листа. Дальше она идёт циклами, где видны выбранное действие, вердикт критика и обновлённый журнал, причём журнал остаётся коротким, а сырые страницы в него не попадают. Если два источника расходятся по дате, конфликт появится в блоке C, и модель не ответит, пока не найдёт третий. В финале придут число месяцев и строка с датами и источниками, а каждая цифра будет привязана к записи в журнале.
Почему это работает
Слабость. Когда в историю диалога падают целые страницы и длинные описания, планировщик тонет в шуме. Он забывает, какие пункты уже закрыты, принимает случайный текст за нужный факт и «сходится» раньше времени. Сжатие в свободный пересказ помогает слабо: пересказ не удерживает различие «закрыто / открыто» на длинных задачах. К тому же модель плохо исправляет собственные ошибки без внешней проверки. Если она сама ошибочно записала «страница = ответ», ошибка тянется через весь диалог.
Сильная сторона. Модель хорошо работает с компактным структурированным текстом: прочитать чек-лист, выбрать следующее действие, сравнить один результат с одним требованием. Когда каждый шаг — маленькая отдельная задача, она с ней справляется.
Как метод это использует. Журнал берёт на себя «память» о том, чего не хватает и что противоречит друг другу. Критик отделён от планировщика, поэтому проверка не смешивается с принятием решения. Готовность определяется формальным правилом, а не ощущением модели «вроде хватит».
Рычаги управления: - Разделение на обязательные и дополнительные потребности → убери дополнительные для простых задач, агент закончит быстрее. - Правило «конфликт блокирует ответ» → ужесточи («нужны два независимых источника») для фактчекинга и ослабь для черновой разведки. - Отдельный критик → выноси в отдельный чат или субагента, если нужна строже проверка. - Лимит повторных попыток → ограничивает расход токенов и страхует от зацикливания. - Правило «сырой текст в журнал не копируем» → ради него всё затевалось, не убирай.
Шаблон промпта
Ты — исследовательский агент. Ты не отвечаешь по памяти и не копишь сырые
тексты. Ты ведёшь ЖУРНАЛ ДОКАЗАТЕЛЬСТВ и обновляешь его после каждого действия.
Вопрос: {вопрос}
Доступные инструменты: {инструменты}
Формат ответа: {формат_ответа}
Лимит шагов: {число_шагов}
U (открытые потребности): разбери вопрос на пункты, пометь каждый
[обязательная] или [дополнительная]
F (слоты фактов и расчётов): что именно должно получить значение
E (подтверждённые доказательства: факт + источник + дата источника): пусто
C (противоречия между источниками): пусто
Повторяй до готовности или до лимита шагов:
1. ПЛАНИРОВЩИК: прочитай журнал, выбери ОДНО действие, назови, какую
потребность оно закрывает. Можно выбрать finish, если журнал готов.
2. Выполни действие.
3. КРИТИК (отдельный блок): оцени сырой результат относительно открытых
потребностей → ПОДТВЕРЖДАЕТ / ПРОТИВОРЕЧИТ / НЕ СОДЕРЖИТ нужного.
Не засчитывай «похожее» как «нужное».
4. РЕДЬЮСЕР: обнови журнал строго по правилам:
- подтверждено → факт в F, доказательство с источником в E, потребность
убрать из U
- противоречие → записать в C, сохранить оба источника
- сырой текст в журнал не копировать
5. Покажи обновлённый журнал.
Ответ разрешён, если: в U нет открытых обязательных потребностей И все слоты
в F заполнены И C пуст.
Дополнительная потребность может остаться открытой.
Потребность, не закрытую после {число_попыток} попыток, пометь
«не удаётся закрыть» и убери из U.
Если подходящих действий не осталось — ответь «недостаточно данных»
и перечисли пробелы.
Перед финальным ответом составь черновик и сверь его с E: каждое утверждение
должно иметь запись в журнале. Если сверка не прошла — вернись в цикл
и запиши, чего не хватило.
Что подставлять: {вопрос} — задача, где нужно собрать несколько фактов из разных источников и, возможно, что-то посчитать. {инструменты} — поиск, браузер, анализ файла, калькулятор. {формат_ответа} — как вам удобно получить итог. {число_шагов} — 10–20 для типовых задач. {число_попыток} — обычно 2–3.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Evidence Ledger. Адаптируй под мою задачу: {опиши задачу}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой именно вопрос нужно закрыть, какие инструменты есть, какой формат ответа нужен и какие пункты обязательные. Это нужно, чтобы правильно разложить задачу на чек-лист и задать правило готовности. Структуру журнала, критика и условие остановки она возьмёт из шаблона.
Ограничения
⚠️ Нужен код для оригинальной версии: в статье журнал обновляет программа-редьюсер по жёстким правилам, а планировщик, критик и финализатор — отдельные вызовы модели. В чате или файле инструкций вы получаете имитацию: модель сама следит за дисциплиной записи. Это в статье не проверялось.
⚠️ Роли в одном чате не равны независимому критику: авторы объясняют выигрыш тем, что проверка отделена от планирования. Если одна и та же модель в одном окне проверяет сама себя, часть эффекта теряется.
⚠️ Результат проверен на узком классе задач: многошаговый поиск доказательств по видео, аудио, картинкам и вебу. Основная часть результатов получена на одном сильном планировщике. Перенос на тексты, код и креатив авторы не проверяли.
⚠️ Остаются ошибки восприятия и поиска: даже с журналом большинство оставшихся провалов — ошибки добычи фактов (модель не так прочитала видео, поиск не нашёл). Журнал не лечит плохие источники.
⚠️ Для простых задач избыточно: если ответ в одном запросе, журнал только съест токены.
⚠️ Обучение планировщика — не для читателя: вторая часть статьи (дообучение на следах журнала) даёт прирост в несколько процентов и требует инфраструктуры. Для практики это не нужно.
Как исследовали
Авторы взяли бенчмарк OmniGAIA (360 вопросов, где нужно найти факт в видео или аудио, дополнить его из интернета и посчитать) и проверку на длинных видео WorldSense. Планировщиком, критиком и финализатором выступал GPT-5.2, «глазами и ушами» — Gemini-3.1-Pro.
Сначала они меняли по одному компоненту. Замена планировщика на слабые модели обрушивала точность с 81% до 47% и до 15%. Замена модели восприятия оставляла результат на уровне 59–66%. Вывод: главное узкое место — планирование, и когда планировщик слаб, качество восприятия уже не важно.
Затем сравнили три способа хранить состояние на одних и тех же моделях. Журнал дал 81,4%. Rolling-пересказ («память») дал 68,3%. Обычный ReAct с накоплением истории дал 60,3%. Разрыв с ReAct рос с длиной задачи: около 16 пунктов на лёгких вопросах и около 24 на средних и сложных. Журнал держит различие «закрыто / открыто» там, где история и пересказ его теряют.
Ещё одно сравнение показало, что при одной паре моделей «минимальный агент» без структуры набирал 5,6%, а полный Omni-Decision — 81%. По стоимости журнал вышел дешевле прямого ответа Gemini-3.1-Pro: около $1,2 против $2,8 за вопрос.
Аудит 360 вопросов показал, что из 67 неудач ошибки восприятия (40%) и поиска (33%) составляют три четверти. Преждевременная остановка — всего 4%. То есть журнал почти убрал ошибки решений, и осталась проблема добычи фактов.
Адаптации и экстраполяции
Это мои переносы идеи, в статье они не проверялись.
🔧 Техника: журнал как файл в рабочей папке агента → меньше потерь при длинных сессиях
Для Claude Code или Cursor добавь в CLAUDE.md / AGENTS.md:
Для задач с несколькими шагами веди файл LEDGER.md с секциями: ОТКРЫТО (обязательное / дополнительное), ПОДТВЕРЖДЕНО (факт + источник), КОНФЛИКТЫ. После каждого вывода команды или чтения файла обнови LEDGER.md выжимкой, а не копией вывода. Перед завершением задачи перечитай LEDGER.md и убедись: ОТКРЫТО (обязательное) пусто, КОНФЛИКТЫ пусто.
🔧 Техника: критик в отдельном чате → независимая проверка
Если задача важная, отправляй каждую находку в новый чат с инструкцией: «Вот требование и вот сырой источник. Подтверждает ли он требование? Ответь: подтверждает / противоречит / не содержит. Процитируй место». Результат вставляй в журнал в основном чате.
Ресурсы
- Omni-Decision: A Progressive Evidence-State Agent System for Omni-Modal QA (Evidence-Ledger Planning for Omni-Modal Agents). Авторы-корреспонденты: Yi Zhu, Yiran Zhong. Университеты в предоставленном тексте не указаны.
- Бенчмарки: OmniGAIA (Li et al., 2026), WorldSense (Hong et al., 2026).
- Связанные работы из статьи: Huang et al., 2024 (модели не исправляют собственные ошибки без внешней обратной связи); Lindenbauer et al., 2025 (The Complexity Trap: замена старых наблюдений заглушками работает не хуже пересказа); Zhang et al., 2026b (разница между обвязками агента для одной модели может превышать разницу между моделями).