Разговор агента — ещё не обязательство организации

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

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

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

Четыре вопроса, на которые одного сообщения недостаточно

В агентных стеках четыре разных вопроса слишком часто сжимаются до одного исходящего действия. Так делать не следует.

• Кто создал сообщение? Это вопрос идентичности агента или сервиса и аутентичности сообщения.
• Кто был уполномочен связать организацию обязательством? Это вопрос делегированных полномочий, заданных для конкретной транзакции.
• Какие именно условия были разрешены? Нужна стабильная форма представления предлагаемого обязательства, а не общее описание намерения.
• Достигли ли стороны согласованного состояния? Это вопрос протокола: каждая сторона должна видеть, было ли предложение получено, принято, просрочено, отменено, исполнено или осталось неразрешённым.

Криптографическая подпись помогает ответить на первый вопрос. RFC 9421 обеспечивает целостность и аутентичность выбранных компонентов HTTP-сообщения, но прямо рассматривает подпись лишь как часть полной системы безопасности. Приложение всё равно должно установить, подходят ли ключ подписи и алгоритм данному контексту. Следовательно, действительная подпись сама по себе не доказывает полномочия, намерение или согласие по условиям.

OAuth 2.0 Rich Authorization Requests дают полезный прецедент для второго вопроса. RFC 9396 определяет типизированные authorization_details для детализированных прав, требует от сервера авторизации отклонять неизвестные или некорректные типы деталей и связывает предоставленные детали с выданным токеном. Важный вывод не в том, что access token является договором. Он в том, что полномочия можно задавать вокруг конкретной транзакции, а не выводить из широкой роли вроде закупщика или операционного агента.

Поместите шлюз обязательств на границу протокола

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

Шлюз должен создавать и вести объект обязательства с неизменяемым идентификатором commitment ID и явным жизненным циклом. Практичная модель включает состояния: черновик, предложение, резервирование, авторизовано, отправлено, подтверждено получателем, принято, исполнено, просрочено и отменено. Названия могут отличаться. Важно, чтобы переходы между состояниями были явными, проверяемыми и долговечными, а не восстанавливались потом из текста или разрозненных логов.

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

Минимальная запись о переходе

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

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

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

Переговоры и обязательства — разные протоколы

Более ранняя спецификация OASIS ebXML Business Process остаётся полезным архитектурным прецедентом, но не агентным протоколом, который следует внедрять без изменений. Она описывает бизнес-транзакции как ограниченные протоколы между определёнными ролями, использует бизнес-сигналы для выравнивания состояния сторон и различает технический и бизнес-успех либо сбой. Её ключевой вклад — понимание, что транзакция не сводится к пересылке документа: это процесс, в котором независимые стороны устанавливают наблюдаемое общее состояние.

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

В primer OASIS Business Transaction Protocol есть ещё одно полезное различие: каждый участник самостоятельно управляет локальными ресурсами, тогда как обязательства принимаются перед более широкой транзакцией. В нём явно моделируются переговоры, подтверждение, отмена, истечение срока и скоординированное завершение. Автономным организациям нужна та же дисциплина: ни один участник не вправе считать, что внутреннее состояние удалённой системы известно, устойчиво или обратимо.

Проектируйте для смешанных исходов, а не для вымышленной атомарности

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

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

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

Операционное следствие

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

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

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

“Пусть агенты свободно общаются там, где безопасен поиск вариантов. Там, где меняется положение организации, требуйте управляемый объект протокола.

Источники

• RFC 9396, OAuth 2.0 Rich Authorization Requests: https://datatracker.ietf.org/doc/html/rfc9396
• RFC 9421, HTTP Message Signatures: https://www.rfc-editor.org/rfc/rfc9421.html
• Спецификация OASIS ebXML Business Process: https://docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en-html/ebxmlbp-v2.0.4-Spec-os-en.htm
• Primer OASIS Business Transaction Protocol: https://www.oasis-open.org/committees/business-transaction/documents/primer/Primerhtml/BTP%20Primer%20D1%2020020602.html