TL;DR
Исследование показывает, что агент, один раз прочитавший файл, продолжает считать его содержимое актуальным. Это происходит, даже если файл потом изменили: человек, другой агент или скрипт. Прочитанный текст остаётся в контексте как «факт», и никто не сообщает модели, что он устарел. Авторы предлагают Concord. Это прослойка между агентом и источниками данных: она запоминает, откуда взят каждый кусок контекста, замечает изменение источника и обновляет, помечает или убирает устаревший кусок до следующего вызова модели.
Боль знакома тем, кто работает с агентами. Агент отвечает уверенно, но по старой версии: «порог бесплатной доставки 100», хотя в конфиге уже 50. Модель не «забыла» и не «ошиблась в логике». У неё в контексте лежит старая версия файла, и нового сигнала нет. Даже когда рантайм проверял перед ответом и возвращал файл в исходное состояние, агент об этом не знал и повторял прежний ответ.
Сам Concord строится на коде, но из экспериментов вытекают правила, понятные без него. Простое уведомление «файл изменился» помогает только тогда, когда оно заставляет агента перечитать источник. Явный diff («было → стало») работает лучше, но стоит дорого по токенам. Лучше всего оказалась замена устаревшего блока или принудительное перечитывание.
Схема метода
ШАГ 1. РЕГИСТРАЦИЯ: результат инструмента → блок контекста с привязкой
к источнику (путь, версия, диапазон строк)
ШАГ 2. ИНВАЛИДАЦИЯ: источник изменился → найти блоки, которые зависят
от изменённого фрагмента (пересечение диапазонов строк)
ШАГ 3. СОГЛАСОВАНИЕ: выбрать политику для устаревшего блока:
• обновить (перечитать и подставить новое)
• пометить предупреждением «устарело»
• убрать из следующих промптов
• заставить агента перечитать источник до продолжения
Все три шага выполняет код в рантайме агента (адаптеры + менеджер контекста), а не промпт. Малое локальное изменение (≤ ~20% токенов или сходство ≥ 0,78) заменяется «на месте». Большое: блок убирается, агента заставляют перечитать источник.
Пример применения
В статье нет готовых промптов, она предлагает программный слой. Поэтому пример ниже — перенос принципов Concord в текстовые правила для агента, а не воспроизведение метода. Эффект такого переноса авторы не проверяли.
Задача: Вы ведёте интернет-магазин на Битриксе вместе с Claude Code. Агент в начале сессии прочитал config/delivery.php: бесплатная доставка СДЭК от 3000 ₽. Пока он работает, менеджер правит порог на 2000 ₽ к распродаже. Через час вы спрашиваете: «Заказ на 2500 ₽ едет бесплатно?» Агент должен перечитать конфиг, а не отвечать по памяти.
Промпт (фрагмент для CLAUDE.md или системной инструкции):
Всё, что ты прочитал из файлов, базы или сервисов раньше в этой сессии,
считай СНИМКОМ на момент чтения, а не текущим состоянием.
Перед ответом о текущем состоянии (значения конфигов, цены, пороги,
статусы, содержимое файлов) перечитай нужный источник заново.
Исключение: ты сам изменил его только что и видишь результат правки.
Если мне или другому агенту известно об изменении файла, считай
прежнее прочтение недействительным и перечитай.
В ответе укажи: источник, когда читал (до/после перечитывания).
Если значение изменилось с прошлого чтения, назови «было → стало».
Результат: Агент перед ответом снова откроет config/delivery.php и ответит по актуальному порогу. В ответе будет указано, откуда взято значение. Если порог изменился, агент отметит «было 3000 → стало 2000». Модель, не знавшая о правке, без инструкции ответила бы по старой цифре.
Почему это работает
Слабость LLM. Модель не видит внешний мир: она работает только с текстом в контексте. Результат чтения файла для неё такой же «факт», как строка из вашего запроса. Если источник изменился, но в контексте ничего не поменялось, у модели нет причин сомневаться. Эффект ещё сильнее, если она уже сделала на основании старых данных ответ. В экспериментах агент часто просто повторял прежний ответ.
Сильная сторона LLM. Модель хорошо реагирует на явный сигнал в тексте: «это устарело», «вот разница». А ещё она умеет вызвать инструмент и перечитать источник.
Как метод это использует. Concord делает так, чтобы в следующем вызове модели лежала либо свежая версия, либо чёткое требование перечитать. Данные из статьи: если после алерта агент делал новое чтение, он отвечал верно в 17 случаях из 18. Без перечитывания — только в 2 из 8. Значит, полезен не сам сигнал, а то, что он запускает повторное чтение.
Рычаги: - Политика устаревания → «пометить» дешевле, «перечитать принудительно» надёжнее. - Порог локальности изменения → мелкая правка заменяется на месте, крупная требует перечитывания. - Область отслеживания → любые изменения файловой системы дают больше охвата, только правки через инструмент агента дешевле. - Диапазон, а не весь файл → правка не в тех строках, что читал агент, не должна сбрасывать контекст.
Шаблон промпта
В статье шаблона нет. Ниже — перенос логики Concord (регистрация → инвалидация → согласование) в текстовые правила. Это адаптация, не авторский метод.
Веди таблицу прочитанных источников:
| источник | что именно прочитано (диапазон/поле) | когда | что извлёк |
Обновляй её после каждого чтения.
Считай запись устаревшей, если:
- источник менял я, другой агент или внешний процесс;
- прошло более {N} шагов/минут с чтения;
- ответ зависит от {тип_данных: цены / конфиги / статусы / код}.
Для устаревшей записи выбери политику:
- Мелкая правка в прочитанном диапазоне → перечитай и замени значение.
- Крупная правка или неясный диапазон → отбрось прежнее чтение,
перечитай источник целиком.
- Источник недоступен → скажи об этом, не отвечай по снимку как по факту.
Подставьте: {N} (порог устаревания), {тип_данных} (что у вас часто меняется).
🚀 Быстрый старт — вставь в чат:
Вот шаблон правил свежести контекста для агента. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие источники у вас меняются во время работы, кто их меняет (люди, другие агенты, скрипты) и что дороже: лишнее перечитывание или устаревший ответ. Это нужно, чтобы выбрать политику и пороги под вашу среду.
Ограничения
⚠️ Текстовые правила не проверены: авторы тестировали программный слой, а не инструкции в промпте. Сработает ли «перечитывай перед ответом» в Claude Code или Cursor, нужно проверять самому.
⚠️ Искусственный бенчмарк: 40 задач из HotpotQA, где файл подменяют и возвращают по расписанию. Реальные правки менее предсказуемы. Результат «40 из 40» сами авторы называют не гарантией надёжности.
⚠️ Только локальные файлы: базы, GitHub, Slack и другие MCP-ресурсы остались «на будущее». Параллельные агенты и повторные обновления не оценивались.
⚠️ Старые выводы не чинятся: если агент уже составил резюме или план по устаревшим данным, Concord их не пересматривает.
⚠️ Цена надёжности: принудительное перечитывание добавляет шаги и токены. Явный diff-протокол в тестах потребовал в разы больше токенов, чем идеальный прогон.
⚠️ Сам Concord требует кода: адаптеры, отслеживание изменений и версии источников нужно писать. Для читателя без разработки это не готовый инструмент.
Как исследовали
Идея простая: подменить факт в файле, дождаться, пока агент его прочитает, и сразу вернуть файл назад. Исследователи взяли 40 вопросов HotpotQA (ответы требуют нескольких фактов). Документы разложили как рабочую папку и в нужные предложения внесли правдоподобные ошибки: другую цифру, дату, имя. Агент читал «испорченный» файл, и сразу после этого файл восстанавливали. Ответ сверяли с исходным верным.
Сравнивали четыре варианта на трёх современных моделях: Naive (ничего не делать), Alert (дописать «файл изменён»), Diff (инструмент показывает «было → стало» и не даёт ответить без него), Concord. Для верхней планки взяли Oracle, прогон без подмены.
Результаты: Naive правильно отвечал в 37,5–60% случаев, Alert в 57,5–77,5%, Diff в 77,5–95%, Concord во всех 40. При этом Concord потратил на 46,4% меньше токенов, чем сильнейшая неидеальная альтернатива. Удивило то, что простой алерт слабо помогал: агент часто видел предупреждение и всё равно отвечал по памяти. Разбор следов показал: он работает только при последующем перечитывании. Значит, стоит строить схему вокруг действия «перечитать», а не вокруг уведомления.
Адаптации и экстраполяции
🔧 Техника: заменить «предупреждение» на «обязательное действие» → агент реже отвечает по снимку
Вместо «если файл изменился, учти это» пишите так:
Если ты не перечитал источник в этом ответе, не называй значение «текущим».
Либо перечитай, либо напиши «по состоянию на прошлое чтение, не проверено».
Это прямо следует из находки: сигнал без перечитывания почти не помогает.
Экстраполяция: журнал чтения в многоагентной схеме
Если несколько агентов работают в одном репозитории, дайте им общую заметку:
Перед правкой файла запиши в NOTES.md: «Агент {имя} изменил {файл}, строки {диапазон}, {время}».
Перед ответом по любому файлу проверь NOTES.md: если там есть запись
новее твоего чтения этого файла, перечитай его.
Это ручной аналог связи «источник → блок» из Concord. Эффективность не проверена, это идея по мотивам статьи.
Ресурсы
- When Agent Context Goes Stale: Incoherence in Volatile Agent Context — Yingying Liu, Junzhou Fang, Chenxiong Qian, The University of Hong Kong.
- Бенчмарк ConcordBench-Pioneer построен на HotpotQA.
- Агентные среды в статье: OpenHands, OpenCode, OpenClaw; протокол MCP.
- Смежные работы: STORM, CAID, CodeCRDT (согласованность рабочих пространств); MemGPT, Self-GC, STALE (память агентов).