Какой уровень изоляции должен управлять решением агента?

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

Представим процесс, который собирает рекомендацию из карточки клиента, сервиса запасов, политического документа, внутренней базы знаний и кэшированной оценки риска. Каждое чтение может быть допустимым. У каждого источника могут быть собственные гарантии согласованности. Но между первым чтением и внешним действием запас могут зарезервировать, карточка клиента — измениться, политика — обновиться, а оценка риска — замениться. Рассуждение агента останется связным, однако его фактическая основа уже не обязана описывать единое состояние организации.

Это прежде всего не проблема авторизации. Авторизация отвечает на вопрос, вправе ли субъект совершить эффект. Изоляция решения отвечает на другой: было ли состояние, обосновавшее эффект, достаточно согласованным с учётом его последствий. Управляемому рантайму нужны оба механизма — и их нельзя смешивать.

Решение как логическая транзакция чтения

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

Это архитектурное развитие известных идей изоляции БД, а не утверждение, что произвольные SaaS API, люди и физические системы можно включить в одну ACID-транзакцию. Рантайм не способен навязать сериализуемость внешнему сервису без его участия. Но он способен определить требуемую согласованность собственного решения, сохранить свидетельства наблюдённого состояния и не допустить эффект, если эти свидетельства больше не соответствуют требованию.

Поэтому вопрос должен быть поставлен прямо: какое изменение допустимо между чтением основания решения и его внешним эффектом, не делая решение недействительным? Ответом должен стать явный класс изоляции, присвоенный решению, а не случайное следствие времени вызовов инструментов.

Свежие чтения не образуют согласованного представления

Распространённый, но небезопасный подход — запросить у каждого источника самое новое доступное значение и назвать результат актуальным. Новизна — свойство отдельного источника. Согласованность — отношение между чтениями. Несколько сильных чтений могут быть свежими по отдельности, но не описывать одно взаимно повторяемое состояние при параллельных записях. Документация Spanner проводит это различие: чтения в одной транзакции только для чтения могут использовать согласованное представление, тогда как отдельные сильные чтения не обязаны быть взаимно повторяемыми.

Не решает проблему и близость по настенным часам. Запросы к пяти системам за несколько миллисекунд не создают снимок организации. Согласованные чтения зависят от версионированного состояния и механизма упорядочивания. Согласованные MVCC-чтения Spanner хорошо это показывают: синхронизированные часы сами по себе не устанавливают отношение между состояниями, нужное для решения.

Практический вывод для агентных рантаймов прост. «Прочитано примерно в 10:03» — слабое свидетельство. «Объект X прочитан в версии V, с ограничением свежести F, в составе снимка решения S» — свидетельство, которое можно проверить позднее.

Классы изоляции должны соответствовать последствиям

Максимальная изоляция нужна не каждой задаче. Агент, готовящий черновик с низким риском, может использовать знания с ограниченной устарелостью: он должен раскрывать или ограничивать бюджет свежести, но не обязан ждать глобально стабильного представления. Это осознанный компромисс. Spanner предоставляет чтения с ограниченной устарелостью именно как выбор между свежестью и возможными преимуществами локальности или задержки.

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

Стабильный снимок ценен, но не всесилен. PostgreSQL указывает, что Repeatable Read даёт стабильный снимок транзакции, однако аномалии сериализации всё ещё возможны. Более широкая литература по уровням изоляции также показывает: отсутствие грязных, неповторяемых и фантомных чтений само по себе не гарантирует сериализуемость. Если бизнес-правило охватывает записи или ресурсы, рантайм должен определить способ его защиты; одного снимка может быть недостаточно.

Практическая шкала изоляции решения

• Ограниченная устарелость: допускаются входные данные не старше объявленного предела. Подходит для низкорисковой работы, где задержка не нарушает правила.
• Стабильный снимок: значимые источники чтения привязываются к взаимно определённой точке или набору версий — в пределах их возможностей. Нужен, когда решению требуется согласованная основа.
• Проверка в стиле сериализуемости: перед эффектом подтверждается, что зависимости чтения и защищаемые инварианты всё ещё допускают решение. Нужна, когда параллельное изменение может сделать действие неверным.
• Явная координация: дефицитный ресурс или ресурс, связанный с инвариантом, резервируется, блокируется либо координируется иным способом, когда одной проверки недостаточно для безопасного разрешения гонки.

Манифест чтений — это запись решения

Изоляция должна быть проверяемой. По мере рассуждения агента управляемый рантайм должен формировать версионированный манифест чтений. Для этого контракта не обязательно хранить каждый токен диалога модели. Но необходимо сохранить входные данные, которые существенно обосновали решение, и условия их чтения.

• Источник и запрос, идентификатор объекта или область поиска для каждого существенного входа.
• Наблюдаемая версия, идентификатор редакции, ETag, временная метка транзакции либо иной доступный маркер чтения.
• Ограничение свежести и класс изоляции, выбранный для решения.
• Версия политики, классифицировавшая решение и установившая необходимую проверку.
• Зависимости от межзаписных инвариантов, резервирований или механизмов координации — где они применимы.
• Результат проверки непосредственно перед эффектом, включая конфликты, отмены и повторные запуски.

Такая запись не создаёт гарантий, которых источник дать не может. Кэш без надёжного маркера версии не становится участником снимка. Манифест делает ограничение видимым: политика может отклонить источник для решения с серьёзными последствиями, принять его только в пределах указанного бюджета устарелости или потребовать подтверждения из более сильного источника.

Конфликт отменяет рассуждение, а не только финальный вызов

Самое важное эксплуатационное правило следует из сериализуемого выполнения. PostgreSQL может отклонить транзакцию, если конкурентное исполнение создаёт недопустимый порядок, и приложение должно повторить всю транзакцию. Для агента эквивалентное правило строже, чем повтор одного вызова инструмента.

Если проверка перед эффектом обнаружила изменение существенного входа или защищаемого инварианта, рантайм должен отменить решение и заново выполнить рассуждение на новом снимке. Повтор только финального API-вызова предполагает, что исходный вывод остаётся верным. Именно это предположение конфликт и ставит под сомнение.

При повторном запуске агент может выбрать то же действие. Может прийти к другой рекомендации, запросить проверку человеком или установить, что теперь никакое действие не допустимо. Это не сбои автономности. Так рантайм сохраняет различие между правдоподобным ответом и действительным организационным решением.

Сделайте изоляцию частью операционной модели

Автономные организации не получат единого глобального менеджера транзакций для баз данных, баз знаний, очередей, API поставщиков и человеческой работы. И не следует делать вид, что получат. Им нужен контракт решения: честный в отношении возможностей источников и строгий в отношении последствий.

Классифицируйте решение до начала рассуждения. Фиксируйте существенные чтения как версии, а не как неструктурированный след. Проверяйте необходимые зависимости непосредственно перед эффектом. Если контракт нарушен — отменяйте решение и рассуждайте заново. Сочетайте это с авторизацией в момент коммита, но сохраняйте раздельность вопросов: разрешение может оставаться действительным при устаревшем основании решения, а свежая основа не даёт разрешения.

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

Источники

• PostgreSQL, «Transaction Isolation»: https://www.postgresql.org/docs/current/transaction-iso.html
• Berenson et al., «A Critique of ANSI SQL Isolation Levels»: https://www.microsoft.com/en-us/research/publication/a-critique-of-ansi-sql-isolation-levels/
• Google Cloud Spanner, «Timestamp bounds»: https://docs.cloud.google.com/spanner/docs/timestamp-bounds
• Google Cloud Spanner, «TrueTime and external consistency»: https://docs.cloud.google.com/spanner/docs/true-time-external-consistency