Два ИИ-агента могут редактировать один и тот же файл, оба получают подтверждение «success», но в итоге сохраняются изменения только одного из них. В простом тесте с пятью одновременно работающими агентами четыре из пяти записей исчезли без каких-либо ошибок или записей в логах — это классическая аномалия «потерянного обновления» (lost-update), которая впустую тратит токены, оплаченные за исчезнувшую работу.

Почему это важно

Когда ИИ-агент записывает результат, используемый сервис берет плату за каждый сгенерированный токен. Если запись незаметно перезаписывается, провайдер все равно выставляет счет за вычисления, которые привели к отброшенному результату. В многоагентных конвейерах — роях агентов, параллельных воркерах для очистки данных или любой системе, где несколько ботов используют общий файл плана или черновик — такие скрытые потери могут превратиться в значительную утечку бюджета. Аномалия также угрожает целостности данных: последующие этапы могут опираться на неполную или устаревшую информацию, что приводит к каскадным ошибкам.

Как возникает эта аномалия

Первопричина заключается в состоянии гонки (race condition):

  1. Два (или более) агента считывают одну и ту же версию ресурса, например, JSON-файл плана.
  2. Каждый выполняет свои рассуждения или преобразования на основе этого снимка (snapshot).
  3. Оба агента отправляют операцию записи обратно в общее хранилище.
  4. Система хранения принимает вторую запись, перезаписывая первую без какого-либо обнаружения конфликта.
  5. Оба агента получают «ACK», подтверждающий успешную запись, хотя первый вклад уже потерян.

Подтверждение от системы хранения доказывает лишь то, что запись произошла; оно не гарантирует, что запись была безопасной относительно других одновременных обновлений. Журнал только для дозаписи (append-only log), который часто рекламируют как средство защиты, ведет себя так же: он фиксирует факт записи, но не предотвращает затирание предыдущих записей последующими.

Что делает механизм compare-and-set (CAS)

Механизм compare-and-set (CAS) добавляет проверку версии перед тем, как запись будет принята:

  • Read (Чтение): Агент получает текущий номер версии (или хеш) файла.
  • Compute (Вычисление): Агент выполняет свою работу, создавая новую версию файла.
  • Write (Запись): Агент отправляет новое содержимое вместе с версией, которую он прочитал изначально.
  • Validate (Валидация): Слой хранения сравнивает предоставленную версию с текущей. Если они различаются, запись отклоняется; в противном случае она выполняется, а версия увеличивается.

Если версия изменилась, агент понимает, что его данные устарели, и должен повторить весь цикл — чтение, вычисление, запись — используя свежую версию. Это превращает невидимую перезапись в явную ошибку, которую можно залогировать, повторить и учесть.

Цена безопасности

Механизм CAS не бесплатен. В той же симуляции с пятью агентами:

Сценарий Попыток записи Успешных вкладов Стоимость в токенах
Без CAS 5 1 5 единиц
С CAS 5 5 (после повторов) 9 единиц

Механизм добавляет дополнительные циклы «чтение-вычисление-запись» для агентов, столкнувшихся с конфликтом версий, что увеличивает расход токенов. Компромисс очевиден: без CAS вы незаметно теряете данные; с CAS вы платите небольшую надбавку, но получаете прозрачность каждого конфликта.

Насколько часто это происходит?

Даже при участии всего двух агентов тест показал 75%-ную вероятность потери одной из записей. При пяти агентах уровень потерь приблизился к 100%. Эти цифры говорят о том, что предположение «обычно всё в порядке» является опасным для любого многоагентного рабочего процесса промышленного уровня.

Контраргумент: когда можно обойтись без CAS

Если в системе на один ресурс приходится один агент или на более высоком уровне соблюдается строгая сериализация, дополнительные проверки CAS могут быть излишними. Однако расчет рисков должен включать скрытые затраты на повторное выполнение неудачной работы и потенциальное влияние отсутствующих данных на последующие этапы.

На что обратить внимание в дальнейшем

  • Поддержка инструментов: Ищите API хранилищ, которые предоставляют номера версий или ETag и поддерживают атомарные операции CAS «из коробки».
  • Метрики: Настройте мониторинг ваших агентов, чтобы фиксировать, как часто запись отклоняется из-за несоответствия версий. Рост частоты конфликтов сигнализирует о необходимости масштабирования ресурсов или пересмотра архитектуры рабочего процесса.
  • Стратегии повторов: Хорошо работает простое экспоненциальное увеличение задержки (exponential back-off), но помните, что повторные попытки увеличивают потребление токенов. Балансируйте лимиты повторов с допустимым уровнем потери данных.
  • Гибридные подходы: Некоторые команды сочетают журнал только для дозаписи (append-only log) для аудита с механизмом CAS для обеспечения согласованности, гарантируя наличие записи о произошедшем и защиту от перезаписи.

Итог

Аномалии потери обновления превращают AI-конвейеры, работающие на токенах, в черные дыры, через которые утекают деньги. Механизм контроля версий типа compare-and-set создает небольшие дополнительные затраты токенов, но превращает скрытую потерю данных в видимое событие, допускающее повторную попытку. Для любой системы, где несколько агентов используют общее состояние — базы данных, файлы планов или черновики — внедрение проверки версии перед записью является самой дешевой страховкой от скрытых издержек и нарушенных рабочих процессов.