Проектування процесу оплати з використанням агентів: делеговані повноваження, застарілі котирування, повторні спроби.
Покроковий огляд проектування системи для покупок за допомогою агентів: обов’язки, застарілі пропозиції, неефективні ключі ідемпотентності, офіційний продавець, записи аудиту та посібник з оцінки.
Джерела: Design an Agentic Checkout: 2026 System Design Question With No Template Yet
Розробка системи оформлення покупок раніше була простим етапом на співбесіді, адже приклад рішення був поширений скрізь, і кваліфікований кандидат міг його відтворити за двадцять хвилин. У сучасній версії між покупцем та продавцем вводиться програмний агент, через що майже всі припущення, закладені у стандартне рішення, порушуються. Для цього не існує канонічної статті, яку можна було б запам’ятати, і саме тому це питання продовжує ставитися.
Чому воно з’явилося
За короткий проміжок часу відбулося три значущі зміни.
По-перше, з’явився відкритий стандарт. Протокол Agentic Commerce Protocol, розроблений спільно OpenAI та Stripe, визначає, як покупці, їхні агенти, продавці та системи обробки платежів взаємодіють між собою. Основою є спільний токен оплати: агент може завершити покупку, навіть не бачачи даних картки, а продавець залишається офіційним оператором платежів.
По-друге, конкуруючий дизайн. Протокол Agent Payments Protocol від Google розглядає авторитет як підписані доручення, які передаються у вигляді JWT з обмеженим розкриттям інформації. Одне доручення підтверджує, що користувач схвалив покупку, а інше — схвалення оплати; кожне з них може бути відкритим, заздалегідь фіксуючи обмеження, або закритим, прив’язаним до одного остаточного кошика.
По-третє, дослідження безпеки розвиваються швидко. Систематичне дослідження AP2 перелічує 48 окремих загроз, згрупованих у п’ять сімей; вісім з них оцінені як серйозні за ступенем небезпеки, причому всі вони були перевірені на реальному тестовому середовищі, а не лише описані. Для інтерв’юера це ідеальний матеріал, адже способи збою є реальними та конкретними, і не потрібні жодні трюки, щоб надати запитанню глибини.
Запит, як він надходить
Формулювання можуть відрізнятися, але вимоги завжди залишаються майже такими ж:
- Покупець просить асистента придбати щось, можливо, вказуючи обмеження, такі як максимальна ціна чи термін доставки.
- Агент переглядає кількох продавців, оцінює варіанти та обирає одного.
- Оплата здійснюється, причому агент ніколи не має доступу до первинних даних картки.
- Покупець може переглянути те, що було схвалено, а суперечки можна вирішити пізніше.
- Жодна покупка не копіюється та не здійснюється поза межами того, на що фактично погодився покупець.
П’ята вимога потребує уважного перечитування, адже саме там міститься все складне. Ці п’ять рядків створюють усі складні підзадачі, і кандидат, який починає з опису цього порівняння, а не з нанесення схем, вже відокремлюється від більшості конкурентів. Практика розв’язання задач, пов’язаних із інфраструктурою реальних платежів, — це швидкий спосіб опанувати необхідну лексику, адже тут у формі агентних моделей зустрічаються такі поняття, як бухгалтерський облік, ідемпотентність та врегулювання.
Перша задача: делеговані повноваження
Покупець відсутній у момент покупки, тому щось має замінити його згоду.
Слабка версія рішення зберігає спосіб оплати у базі даних, щоб агент міг стягнути гроші після того, як користувач погодиться. Це призводить до проблем, адже погодження о 10:00 на кавомолку вагою менше 80 фунтів не покриває вартість того, що агент обирає о 10:04. У цій прогалині можуть опинитися модель, набір інструментів чи навіть спотворений опис продукту.
Стандарти вирішують цю проблему трьома способами:
- Дозвіл стає підписаним об’єктом із визначеним діапазоном дії, а не просто наявністю посвідчення.
- Цей об’єкт розділяє намір та виконання: відкритий дозвіл містить обмеження, такі як верхня межа ціни та категорія, тоді як закритий дозвіл прив’язується до конкретного кошика покупок.
- Креденціалі оплати замінюються токеном, дійсним лише для одного продавця та однієї операції, тож вкрадений токен дозволяє купити лише один товар один раз.
Аспекти, які варто наголосити: обмежуйте кожну субсидію за сумою, продавцем, категорією та терміном дії; вимагайте остаточну версію угоди перед будь-якими грошовими переказами, щоб підписаний документ та придбаний товар були ідентичними; а також розглядайте доручення як сам запис про авторизацію, а не як форму, що полегшує використання картки.
Друга проблема: зв’язок даних, або чому ретельні агенти використовують застарілу інформацію
Майже ніхто не піднімає це питання без прямого запиту, і його можна виміряти.
Ретельний агент з покупками читає багато пропозицій перед тим, як зробити вибір. Та пропозиція, яка перемагає, була прочитана на початку порівняння, що означає: чим ретельніший агент, тим застарілішою є його найкраща інформація.
У симуляції до цього додано графік. Агент запитує кожного продавця по черзі, витрачаючи на кожного від трьох до восьми секунд, потім аналізує все протягом п’яти–п’ятнадцяти секунд та ухвалює рішення. Ціни та наявність товарів змінюються за законом Пуассона, і результатом є ймовірність того, що обраний варіант вже змінився на момент ухвалення рішення.
Привертає увагу певна закономірність. Перехід від одного продавця до двадцяти подвоює ймовірність ухвалення застарілого рішення при кожному рівні зміни, тож саме та поведінка, яку бажають покупці, підриває власні дані, які використовує агент. За умов досить агресивного динамічного ціноутворення одна з трьох ретельних порівнянь закінчується варіантом, який вже змінився.
Наслідки такого проектування є конкретними:
- Котирування – це об’єкти, які генерує сервер; кожен з них має ідентифікатор та короткий термін дії.
- Остаточне схвалення пов’язане з хешем заповненої корзини, що саме й забезпечує закритий мандат.
- Під час оформлення продавець знову перевіряє ціну та наявність товару та відхиляє замовлення у разі будь-яких розбіжностей, замість того щоб мовчки його виконати.
- У разі відхилення система пропонує нову ціну та надсилає покупцеві повідомлення, якщо зміна порушує встановлені ним обмеження.
Кандидати часто забувають про останній пункт. Відхилення застарілого замовлення — це правильна поведінка, і без циклу перепропозиції помилка в ціноутворенні просто перетворюється на проблему надійності.
Третя проблема: спроби повторного виконання та марна ключова значення ідемпотентності агента
Ключові значення ідемпотентності згадуються у кожній відповіді, але у звичайній налаштуванні прихований підводний камінь.
Зазвичай клієнт генерує ключ та надсилає його знову під час спроби. Агенти порушують цей принцип. Якщо відповідь зникає, агент часто не надсилає ідентичний запит; він планує все заново, що призводить до створення нового запиту з новим ключем, і сервер розглядає його як нову спробу.
Цю поведінку було симульовано без припущень, враховуючи, що 5% відповідей втрачаються після того, як оплата вже відбулася, протягом трьох спроб:
- Коли агент генерує новий ключ для кожної спроби, 4,98% замовлень оплачуються двічі, у середньому 1,052 рази на замовлення.
- Коли ключ генерується на сервері на основі даних кошика, кількість дублікатів знижується до 0,00%, і кожне замовлення оплачується рівно один раз.
Симульовані 4,98% узгоджуються з теоретичною ймовірністю у 5,00%, що має сенс, адже дублікат виникає саме тоді, коли зникає перша відповідь.
Висновок: створюйте ключ ідемпотентності на основі чогось, що схвалив покупець, а не на основі чогось, що вигадав замовник. Хеш, який пов’язує завершене замовлення з кошиком, вже виконує цю функцію, тому додаткових зусиль не потрібно.
Четверта проблема: хто є офіційним продавцем
Це бізнес-питання, прикидане під системне, і саме воно визначає модель даних.
- З використанням спільного токена продавець залишається офіційним продавцем, тож платформа агента уникає відповідальності за розрахунки, податки та повернення коштів.
- Якщо ж платформа купує та перепродає товари, життя агента стає простішим, але з’являється ціла низка регулюючих вимог.
- Необхідно заздалегідь, протягом двох хвилин, сформулювати припущення, адже від нього залежать всі питання повернення коштів, податків та суперечок.
П’ята проблема: можливість аудиту як вимога
Одна з п’яти груп загроз у аналізі AP2 повністю стосується принципу підзвітності, тобто зберігання доказів та можливості аудиту. Люди ігнорують цей аспект, проте саме він визначає, чи можна буде вирішити суперечку через шість місяців.
Для кожної транзакції необхідно незмінно зберігати:
- Обидві версії підписаного доручення – відкриту та закриту.
- Точний хеш кошика, який був схвалений, а також його вміст.
- ID пропозиції разом із датою її видачі та закінчення терміну дії.
- Версію агента та моделі, які виконували дії, а також умови делегування повноважень.
- Кожну відмову та причину її виникнення, адже відмови свідчать про те, що механізми контролю функціонували належним чином.
Шлях для пошуку інформації
Чітка відповідь можна отримати, простеживши всю покупку від початку до кінця:
- Покупець визначає мету з певними обмеженнями, а платформа видає відкрите доручення, обмежене сумою, категорією та терміном дії.
Кожен із восьми кроків існує тому, що інакше певна конкретна проблема залишилась б без захисту, і саме зв’язок кожного кроку з його проблемою є тим, що насправді оцінює співрозмовник.
Оцінка відповіді під час тренування
Особлива похвала належить відповідям, які:
- описують модель делегування протягом двох хвилин та дотримуються її;
- розділяють відкритий грант та закрите зобов’язання та пояснюють, чому обидва необхідні;
- згадують про проблему застарілості без попередження, бажано з приблизною цифрою;
- створюють ідемпотентність на основі схваленого стану, а не на основі даних, наданих користувачем;
- розглядають історію аудиту як обов’язкову вимогу, а не просто як журнал подій.
Бали втрачаються через відповіді, які:
- уявляють агента як швидку людину, хоча більшість труднощів виникає саме через відмінності між ним та людиною;
- надають агенту будь-які повторно використовувані облікові дані;
- вважати, що повторна спроба — це та сама заявка, надіслана знову;
- проєктувати сценарій відхилення без наступного кроку;
- відкладати питання щодо відповідальності та обов’язків оператора на кінець, хоча саме вони визначають модель даних.
Чому варто підготуватися до цього запитання
Польська мова перестала бути корисним показником під час найму, коли готові відповіді на кожне класичне запитання стали доступні безкоштовно. Агентський процес оплати є сучасним прикладом ситуації, де такого швидкого рішення немає. Протоколи існують лише кілька місяців, дослідження загроз ще новіші, а компроміси щодо оптимальних рішень ще не досягнуті.
Це означає, що механізм нагородження більше не стимулює використання баз запитань, які орієнтовані на стандарти навичок: міркування на основі справді зрозумілих обмежень. Хороше оволодіння цим також підготовлює до будь-яких запитань, які можуть замінити його, адже основний підхід залишається незмінним. Варто запитати, що зміниться, коли те, що знаходиться по інший бік API, більше не буде людиною.
Пов’язана література
- Сім шаблонів циклів агентів та ситуації, коли кожен з них не спрацьовує: ReAct, Maker-Checker та інші — практичний каталог дизайнів циклів агентів, від моделей типу „планувати-діяти-перевіряти“ до механізмів звернення до людини, із рекомендаціями щодо ситуацій, коли кожен з них підходить, коли його варто уникати та як обирати.