Проблема порядка
Автономные агенты отказывают специфическим образом: они действуют прежде, чем кто-либо проверил, было ли действие оправдано. План выглядел разумно, вызов инструмента был корректно сформирован, и побочный эффект наступил. И только позже, в логе или в задаче сверки, всплывает несоответствие. К этому моменту платёж уже прошёл, удаление уже распространилось, а исходящее сообщение уже прочитано.
Это эссе отстаивает одну позицию: проверка исполнения окупается только тогда, когда она находится между планом и побочным эффектом. Это означает, что слой проверки должен быть синхронной зависимостью вызова инструмента, а не асинхронным потоком аудита. Постфактумная проверка порождает доказательства после ущерба и не может изменить прогон. Проверка на пути выполнения добавляет задержку к каждому вызову инструмента, поэтому её нужно ограничивать только необратимыми действиями.
Порядок и есть контроль. Всё остальное — инструментация.
Два места для проверки
Есть ровно два места, где может находиться шаг проверки, и их свойства противоположны.
Постфактумная проверка выполняется после возврата вызова инструмента. Она дешева, легко добавляется и порождает полезные артефакты: журналы аудита, отчёты о дрейфе, алертинг. Она не может изменить прогон. Если проверка срабатывает, побочный эффект уже реален. Постфактумные проверки — это то, как команды обнаруживают, что агент неделю писал некорректные записи. Это ценное открытие и плохой контроль.
Проверка на пути выполнения выполняется между планом и вызовом инструмента. Вызов инструмента не исполняется, пока проверка не вернёт вердикт. Это единственный порядок, способный предотвратить плохой побочный эффект, и единственный порядок, который стоит задержки на каждом прошедшем через шлюз вызове. Синхронный шлюз в цикле, управляемом моделью, не бесплатен: он добавляет сетевой round trip, может истечь по таймауту и сам может отказать. Инженерный вопрос не в том, платить ли эту цену, а в том, где её платить.
Классификация действий по обратимости
Правило ограничения области — обратимость. Действие необратимо, если для его отмены требуется содействие, которого у агента нет, или если сама отмена является побочным эффектом.
Допускают сэмплирование и асинхронный разбор:
- Чтения. Чтение, вернувшее устаревшие или неверные данные, исправимо повторным чтением. Шлюз только на авторизацию и egress, не на содержимое.
- Черновики. Черновик, который никогда не отправлен, инертен. Разбор может быть асинхронным.
- Записи в staging. Записи в staging-пространство имён или в append-only буфер допускают отложенный разбор при условии, что продвижение в production само проходит через шлюз.
Нуждаются в синхронных проверках:
- Платежи и переводы. Движение денег — каноническое необратимое действие. Отмена — это возврат, который зависит от контрагента.
- Удаления. Жёсткие удаления и любое удаление с каскадом нуждаются в синхронном шлюзе. Мягкие удаления — другой класс.
- Исходящие сообщения. Email, чат, вебхуки и публичные посты нельзя «прочитать обратно». Отзыв — не откат.
- Внешние записи. Любая запись в систему за пределами границы доверия, включая сторонние API и общие базы данных, меняет состояние, которым агент не владеет.
Классификация должна объявляться для каждого инструмента, а не выводиться для каждого вызова. Инструмент, который иногда чтение, а иногда запись, — это два инструмента. Неоднозначность в классе обратимости сама по себе является дефектом.
Что проверка может на самом деле утверждать
Синхронный шлюз хорош ровно настолько, насколько хороши предикаты, которые он вычисляет. Четыре стоит построить, и они компонуются.
Форма аргументов против объявленной схемы. Входной контракт инструмента — это схема, и проверка валидирует предложенные аргументы против неё перед вызовом. Это ловит дрейф типов, отсутствующие обязательные поля и класс отказов, когда модель выдаёт правдоподобно выглядящий объект с неверной структурой. Валидация схемы дешева и должна находиться на пути выполнения для каждого необратимого инструмента.
Назначение против контракта egress. Каждый инструмент объявляет, куда ему разрешено отправлять данные: какой хост, какой аккаунт, какой канал. Проверка сравнивает разрешённое назначение с этим контрактом. Это тот контроль, который не даёт уговорить агента отправить полезную нагрузку на адрес, появившийся в извлечённом содержимом. Контракт egress — это статический allowlist; проверка — это сравнение во время выполнения.
Остаток бюджета против потолка расходов прогона. Прогон несёт бюджет. Перед необратимым действием проверка читает остаток бюджета и предлагаемую стоимость и отказывает, если действие превысит потолок. Это не лимит на вызов; это лимит на прогон, поэтому цикл из отдельных мелких действий не может агрегироваться в крупное. Механизм — счётчик, который шлюз атомарно уменьшает вместе с действием,
тке бюджета.
Происхождение записываемых значений. Это наименее распространённый и наиболее важный предикат. Каждое значение, которое будет сохранено, несёт тег происхождения: получено из результата инструмента, получено из пользовательского ввода, получено из завершения модели. Проверка отказывается записывать значение, чьё происхождение — генерация моделью, в поле, требующее источника из инструмента или от пользователя. Именно это не даёт агенту отмыть галлюцинированный факт в запись. Без этого беглое завершение становится строкой в базе данных, а строка переживает контекст, который её породил.
Отслеживание происхождения требует дисциплины выше по потоку: результаты инструментов должны помечаться тегами на границе, а планировщик должен сохранять теги через преобразования. Это реальная работа, и это разница между шлюзом, который проверяет форму, и шлюзом, который проверяет смысл.
Стоимость и поведение при отказах
Шлюз теперь на критическом пути, поэтому его режимы отказа — это режимы отказа прогона.
Fail closed при таймауте проверки, и сделать это поведением по умолчанию, а не флагом конфигурации. Шлюз, который истекает по таймауту и пропускает действие, — не шлюз. Если проверка не может вернуть вердикт в пределах своего дедлайна, действие не исполняется, а прогон выводит таймаут как ошибку первого класса. Превращение этого в флаг приглашает выставить флаг в разрешающее значение во время инцидента, а затем оставить его там. Безопасное поведение должно быть единственным поведением, либо небезопасное должно требовать явного, аудируемого переопределения, которое само записывается.
Измеряйте собственный уровень ложноположительных срабатываний слоя проверки. Шлюз, блокирующий легитимные действия, — это шлюз, который отключают. Уровень ложноположительных срабатываний — это доля корректных действий, которые шлюз отклоняет. Его следует отслеживать по каждому предикату, потому что проверка схемы и проверка происхождения отказывают по-разному. Шумный предикат происхождения будет первым, что оператор отключит, а как только он отключён, путь отмывания снова открыт. Честный компромисс в том, что ужесточение предиката снижает ложноотрицательные и повышает ложноположительные, и выживание шлюза зависит от удержания второго числа достаточно низким, чтобы никому не хотелось его убирать.
Есть и стоимость второго порядка. Каждая синхронная проверка — это зависимость, а зависимости отказывают. Шлюз должен быть доступнее инструментов, которые он охраняет, иначе он сам становится отказом. Обычно это означает, что предикаты вычисляются локально против кэшированных контрактов и счётчиков, а не через вызов удалённого сервиса политик на каждое действие.
Что это оставляет от цикла
Архитектура, вытекающая из аргумента о порядке, невелика. Инструменты объявляют класс обратимости. Необратимые инструменты объявляют схему, контракт egress, взаимодействие с бюджетом и требование к происхождению. Цикл агента вызывает шлюз, а шлюз вызывает инструмент. Постфактумная проверка всё ещё существует, но её задача — находить предикаты, которые следует добавить, а не ловить действия, которые уже произошли.
Неудобная часть в том, что это выталкивает проверку в горячий путь системы, где её задержку и её ложноположительные срабатывания ощущает каждый прогон. В этом и смысл. Контроль, который не ощущается прогоном, не управляет прогоном. Альтернатива — асинхронный поток аудита — это запись о том, что агент сделал, а запись — не решение.