🧠 Свежие данные не спасают агентов от устаревших планов Распределённая команда LLM-агентов может прочитать новейший общий факт r4 и всё равно отправить действие, выведенное из старого требования r3. Планировщик строит план на r3, другой агент записывает r4, а исполнитель получает r4, но не пересобирает план — эту ситуацию авторы называют выполнением устаревшего плана. Протокол PlanFence, описанный в статье на arXiv, вводит проверку в пределах зависимостей: план ссылается на конкретные публичные записи, а исполнитель проверяет только те записи, которые влияют на внешнее действие, и блокируется или один раз перепланирует действие при неполной проверке. В 30 контролируемых рабочих процессах с изменением данных после составления плана исполнитель, учитывающий только свежесть данных, действовал по устаревшему плану в каждой задаче, а PlanFence завершил все задачи без единого недопустимого действия. Для русскоязычных команд, собирающих агентные конвейеры на GigaChat или открытых моделях, механика та же: общее хранилище фактов не отменяет версии планов. → 30 рабочих процессов: исполнитель, учитывающий только свежесть данных, — 100% действий по устаревшему плану → PlanFence: 0 недопустимых действий во всех задачах → Упреждающая синхронизация выигрывает по задержке при низкой частоте изменений; PlanFence — при росте частоты изменений и размера пространства ключей → Результаты описывают контролируемую безопасность и стоимость эксплуатации систем, а не точность выполнения задач Здесь нет ни одной цифры про стоимость проверки или задержку в промышленной среде, и 30 рабочих процессов — это симуляция, а не рабочий трафик. Но проблема реальна: свежесть состояния не гарантирует валидность плана, и версионирование зависимостей может оказаться дешевле, чем очередное дообучение модели рассуждений. Протокол выглядит как транзакционная изоляция для агентных систем — только вместо блокировок БД используется проверка по графу зависимостей. #LLMAgents #PlanFence #multiagent #staleplan #arxiv