Проектирование процесса оплаты с участием агентов: делегированные полномочия, устаревшие котировки, повторные попытки.

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

Почему она появилась

За короткий промежуток времени произошли три важных события.

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

Во-вторых, существует конкурирующий дизайн. Протокол Agent Payments Protocol от Google рассматривает полномочия как подписанные распоряжения, передаваемые в виде JWT с избирательным раскрытием информации. Одно распоряжение подтверждает, что пользователь одобрил покупку, а другое — одобрение оплаты; каждое из них может быть открытым, с заранее заданными ограничениями, или закрытым, связанным с конкретной корзиной.

В-третьих, исследования в области безопасности развивались быстро. Систематическое исследование AP2 выявило 48 отдельных угроз, сгруппированных в пять категорий; восемь из них отнесены к высокой степени серьезности, причем все они были проверены на реальной тестовой среде, а не просто описаны. Для интервьюера это идеальный материал, поскольку способы сбоев реальны и конкретны, и не требуется никаких уловок для придания вопросу глубины.

Задание в том виде, в котором оно поступает

Формулировки могут отличаться, но требования постоянно близки к следующим:

1. Покупатель просит ассистента купить что-либо, возможно, устанавливая такие ограничения, как максимальная цена или срок доставки.
2. Агент рассматривает нескольких продавцов, сравнивает варианты и выбирает одного.
3. Оплата происходит без прямого обращения агента к данным карты.
4. Покупатель может посмотреть, что было одобрено, а споры можно разрешить позже.
5. Никакие покупки не дублируются и не осуществляются за пределами того, на что фактически согласился покупатель.

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

Задача первая: делегированная полномочия

Покупатель отсутствует в момент совершения покупки, поэтому кто-то должен заменить его согласие.

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

Стандарты решают эту проблему тремя способами:

• Разрешение становится подписанным объектом с определенным диапазоном действия, а не просто хранением учетных данных.
• Этот объект разделяет намерение и его реализацию: открытый мандат содержит ограничения, такие как верхняя граница цены и категория, тогда как закрытый мандат привязан к конкретной корзине покупок.
• Учетные данные для оплаты заменяются токеном, действительным только для одного продавца и одной транзакции, так что украденный токен позволяет купить лишь один товар один раз.

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

Вторая проблема: привязка к данным, или почему тщательные агенты опираются на устаревшую информацию

Почти никто не поднимает этот вопрос сам по себе, но его можно измерить.

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

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

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

Последствия такого подхода в плане проектирования конкретны:

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

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

Третья проблема: попытки повтора и бесполезный ключ идемпотентности агента

Ключи идемпотентности упоминаются в каждом ответе, но в стандартной настройке скрывается один нюанс.

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

Такое поведение было моделировано непосредственно, а не предположительно: 5% ответов терялись после того, как оплата уже произошла, при до трех попытках:

• Когда агент генерирует новый ключ при каждой попытке, 4,98% заказов оплачиваются дважды, в среднем 1,052 раза на заказ.
• Когда ключ генерируется на сервере на основе данных корзины, количество дубликатов снижается до 0,00%, и каждый заказ оплачивается ровно один раз.

Значение 4,98%, полученное в результате моделирования, совпадает с точным значением вероятности в 5,00%, что имеет смысл, поскольку дубликаты возникают именно тогда, когда первый ответ исчезает.

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

Четвёртая проблема: кто является официальным продавцом

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

• При использовании общего токена продавец остаётся официальным продавцом, что позволяет платформе агентов избежать ответственности за расчёты, налоги и возвраты средств.
• Если же платформа покупает и перепродает товары, жизнь агента становится проще, но появляются дополнительные регуляторные требования.
• Необходимо заранее, в течение двух минут, сформулировать предположение, поскольку от него зависят все вопросы, связанные с возвратами средств, налогами и спорами.

Пятая проблема: требование к аудитируемости

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

Для каждой транзакции неизменно сохраняйте:

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

Пути для справки

Четкий ответ можно получить, проследив весь процесс покупки от начала до конца:

1. Покупатель указывает цель с определенными ограничениями, и платформа выдает открытое поручение с ограничениями по сумме, категории и сроку действия.
2. Агент собирает предложения от потенциальных продавцов, и каждый из них отвечает с ценой, сопровождаемой идентификатором и датой истечения срока.
3. Агент выбирает одно из предложений и запрашивает окончательный список товаров, который продавец подписывает.
4. Платформа создаёт закрытый мандат, связанный с хэшем этого списка товаров, проверяя его согласно ограничениям открытого мандата.
5. Для данного продавца выдаётся токен оплаты только на указанную сумму.
6. Продавец снова проверяет цену и наличие товаров, а затем подтверждает операцию с использованием ключа идемпотентности, полученного из хэша списка товаров.
7. Все данные, полученные на этапах с одного по шесть, сохраняются в хранилище для аудита до отправки любого ответа.
8. Если на шестом этапе обнаруживается несоответствие, процесс возвращается к второму этапу или к покупателю, если изменения превышают установленные им лимиты.

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

Оценка ответа во время тренировки

Баллы присуждаются ответам, которые:

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

Баллы снижаются за ответы, которые:

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

Почему стоит подготовиться к этому вопросу

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

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