در قسمت قبل گفتم Agentic Commerce یعنی هوش مصنوعی فقط پیشنهاد ندهد و بتواند به نمایندگی از ما اقدام کند. حالا ببینیم یک خرید واقعی از زیر دست چه بخشهایی رد میشود.
فرض کنید به Agent میگوییم:
یک مانیتور ۲۷ اینچ 2K برای برنامهنویسی پیدا کن. USB-C و ارسال تا فردا داشته باشد، بیشتر از ۱۰۰ میلیون تومان هم هزینه نکن. اگر گزینه مناسب پیدا شد، قبل از پرداخت از من تأیید بگیر.
این جمله برای ما روشن است، ولی سیستم باید آن را به چند مرحله دقیق و قابلکنترل تبدیل کند.
قبل از مراحل: چهار لایه را از هم جدا کنیم
یک اشتباه رایج این است که همه مسئولیتها را به مدل زبانی بدهیم، انگار LLM هم باید منظور کاربر را بفهمد، هم Policy را اجرا کند، هم پرداخت را انجام دهد و هم درباره موفقیت تراکنش تصمیم بگیرد. این معماری قابل اعتماد نیست.
بهتر است سیستم چهار لایه جدا داشته باشد:
- لایه Reasoning: هدف را میفهمد، برنامه میسازد و گزینهها را تحلیل میکند.
- لایه Control: هویت، مجوز، سقف مبلغ، Policy و نیاز به تأیید انسان را کنترل میکند.
- لایه Execution: از طریق Connector یا API با فروشنده، پرداخت و سرویس ارسال حرف میزند.
- لایه Observation: همه تصمیمها، Tool Callها، خطاها و تغییر وضعیت را ثبت و مانیتور میکند.
مدل میتواند احتمالاتی باشد، ولی اجرای پول باید قطعی و قابل تکرار باشد. این جداسازی باعث میشود اگر مدل تصمیم بدی گرفت، لایه کنترل جلوی تبدیل شدن آن به تراکنش را بگیرد.
۱. تبدیل خواسته کاربر به Intent
اولین کار، استخراج هدف و محدودیتهاست:
- نوع کالا: مانیتور
- اندازه و رزولوشن: ۲۷ اینچ و 2K
- ویژگی اجباری: USB-C
- زمان تحویل: حداکثر فردا
- سقف هزینه: ۱۰۰ میلیون تومان
- شرط اجرا: تأیید کاربر قبل از پرداخت
اینجا مدل زبانی برای فهم زبان طبیعی مناسب است، ولی نتیجه نباید به شکل متن آزاد وارد مرحله خرید شود. بهتر است خروجی به یک ساختار مشخص مثل JSON تبدیل و با Schema اعتبارسنجی شود. اگر ارز، مبلغ یا زمان تحویل نامشخص بود، Agent باید سؤال بپرسد، نه اینکه حدس بزند.
۲. احراز هویت و تعیین محدوده اختیار
Agent باید بداند از طرف چه کسی کار میکند و دقیقا چه اختیاری دارد. این دو موضوع یکی نیستند:
- Authentication: آیا این کاربر واقعا همان فردی است که ادعا میکند؟
- Authorization: این کاربر به Agent اجازه انجام چه کاری را داده است؟
اجازه خوب باید محدود باشد، مثلا فقط یک خرید، حداکثر ۱۰۰ میلیون تومان، در دسته تجهیزات کامپیوتری، تا پایان امروز و از فروشندههای مشخص. این همان اصل Least Privilege است: فقط دسترسی لازم، فقط برای زمان لازم.
برای خریدهای حساس میشود اجازه کاربر را با Passkey تأیید و بهصورت یک دستور امضاشده ثبت کرد. پروتکل AP2 گوگل به این دستور دیجیتال Mandate میگوید، مدرکی که نشان میدهد کاربر چه چیزی خواسته و Agent تا کجا اجازه داشته است. Google AP2
۳. پیدا کردن فروشنده و اطلاعات محصول
Agent حالا باید قیمت، موجودی، مشخصات، هزینه ارسال، گارانتی و شرایط مرجوعی را بگیرد. دو راه کلی وجود دارد:
راه اول این است که مثل یک کاربر وارد سایت شود و صفحهها را بخواند(Crawler). این روش شکننده است. ظاهر سایت عوض میشود، اطلاعات ممکن است مبهم باشد و بعضی سایتها هم ترافیک خودکار را Bot حساب میکنند.
راه بهتر، استفاده از API و داده ساختیافته است. چند پروتکل در این لایه نقش دارند:
- MCP به Agent اجازه میدهد به ابزارها و منابع داده متصل شود
- A2A برای ارتباط و واگذاری کار بین Agentهای مختلف است
- ACP جریان تجاری مثل کاتالوگ، سبد خرید، Checkout، پرداخت و سفارش را تعریف میکند.
- AP2 بیشتر روی اعتماد، اجازه کاربر و پرداخت Agentic تمرکز دارد.
لازم نیست همه کسبوکارها تمام این پروتکلها را همزمان پیاده کنند، ولی اصل ماجرا ثابت است: Agent باید به اطلاعات معتبر، لحظهای و قابل فهم برای ماشین دسترسی داشته باشد.
۴. مقایسه و تصمیمگیری
بعد از جمعآوری دادهها، Agent گزینهها را رتبهبندی میکند. این مرحله فقط پیدا کردن ارزانترین محصول نیست. ممکن است یک گزینه ۲۰ میلیون گرانتر باشد، ولی فردا تحویل شود، گارانتی بهتری داشته باشد و فروشندهاش قابل اعتمادتر باشد.
در معماری درست، مدل زبانی میتواند گزینهها را تحلیل کند، اما کنترلهای قطعی باید بیرون از مدل اجرا شوند. مثلا یک Policy Engine دوباره بررسی کند که:
- مبلغ از سقف تعیینشده بیشتر نیست
- همه ویژگیهای اجباری وجود دارند
- فروشنده در فهرست مجاز است
- قیمت و موجودی هنوز معتبرند
- تصمیم با Mandate کاربر مطابقت دارد.
مدل ممکن است اشتباه کند، ولی کد نباید اجازه دهد آن اشتباه مستقیم به تراکنش مالی تبدیل شود.
۵. تایید انسان در نقطه مناسب
قرار نیست برای هر قدم از کاربر سوال شود، در این صورت خودکارسازی ارزشش را از دست میدهد. از طرف دیگر، دادن اختیار کامل هم منطقی نیست.
راه بهتر، Risk-based Approval است. مثلا:
- خرید کمهزینه و تکراری از فروشنده همیشگی: بدون تایید دوباره
- خرید جدید زیر سقف مشخص: یک تایید ساده
- خرید گران، غیرقابلاسترداد یا غیرعادی: احراز هویت دوباره با Passkey
- خرید خارج از Policy: توقف کامل
به این حضور کنترلشده انسان در فرایند، Human in the Loop میگویند.
۶. پرداخت امن
در ایران به دلیل تفاوت مکانیزم خرید آنلاین با باقی دنیا، مساله Payment نیاز به یک راهکار جایگزین دارد.
در سیستم های پرداخت خارج از ایران، پرداخت بر اساس شرایط دریافت مشخصات کارت کاربر و ذخیره آن در سرویس های واسط و انجام عملیات پرداخت توسط سیستم های واسط از جانب مشتری می باشد.(یک جایی که شاید ما بهتر از باقی دنیا باشیم همین جاست. ولی فقط همین یه جا !)
در ایران نیازمند ورود یک بازیگر از سرویس های payment برای پیاده سازی سرویس های ش A2P می باشیم.
مسیر در حال حاظر توسط پیش رو های صنعت Payment ماننده Visa در حال پیاده سازی است. Visa در مدل Intelligent Commerce روی همین موارد کار میکند: توکن مخصوص Agent، احراز هویت کاربر، کنترل تطابق پرداخت با دستور اصلی و سیگنالهایی برای مدیریت تقلب و اختلاف. Visa Intelligent Commerce
در سمت فنی، درخواست پرداخت باید Idempotent هم باشد. یعنی اگر Agent بهدلیل قطع شبکه یک درخواست را دوباره ارسال کرد، کاربر دو بار شارژ نشود.
۷. پیگیری سفارش و مدیریت استثناها
بعد از پرداخت، Agent باید شناسه سفارش و رسید را ثبت کند و از طریق Webhook یا API وضعیت ارسال را دنبال کند. اگر کالا موجود نبود، قیمت تغییر کرد یا پرداخت رد شد، باید بداند دوباره تلاش کند، گزینه جایگزین پیشنهاد دهد یا کار را به انسان برگرداند.
لغو، Refund و مرجوعی هم باید بخشی از طراحی اولیه باشند، نه چیزی که بعدا اضافه شود. خریدی که Agent میتواند انجام دهد ولی نمیتواند درست پیگیری یا لغو کند، تجربه کاملی نیست.
این فرایند باید State Machine داشته باشد
یک خرید Agentic را بهتر است بهصورت یک State Machine طراحی کنیم، نه چند API جدا که معلوم نیست الان در چه وضعیتی هستند. وضعیتها میتوانند چیزی شبیه این باشند:
و در کنار آن وضعیتهای failed، cancelled و refunding هم وجود داشته باشند.
هر تغییر وضعیت باید شرط مشخص داشته باشد. مثلا سفارش فقط وقتی از awaiting_approval به authorized میرود که تأیید معتبر کاربر ثبت شده باشد. بعد از completed هم تلاش دوباره برای پرداخت نباید اثر مالی جدید ایجاد کند.
این مدل چند فایده دارد: بازیابی بعد از Crash سادهتر میشود، Retry قابلکنترل است، پشتیبانی میتواند بفهمد کار کجا متوقف شده و Audit هم یک مسیر روشن از تصمیم تا نتیجه دارد.
اگر چند Agent درگیر باشند چه؟
ممکن است یک Agent اصلی کار را بین Agentهای تخصصی تقسیم کند، یکی پرواز را پیدا کند، یکی هتل را رزرو کند و یکی پرداخت را انجام دهد. اینجا واگذاری اختیار باید همراه با Scope باشد. Agent فرعی نباید همان دسترسی کامل Agent اصلی را دریافت کند.
همچنین نتیجه هر Agent باید قبل از ورود به مرحله بعد اعتبارسنجی شود. اعتماد به Agent اصلی به معنی اعتماد خودکار به تمام Agentها و ابزارهای زیرمجموعهاش نیست.
پس زیر ظاهر ساده “برام بخر”، یک زنجیره جدی وجود دارد: فهم Intent، احراز هویت، مجوز محدود، دسترسی به داده، تصمیمگیری، کنترل Policy، پرداخت توکنیزه و ثبت کامل رویدادها.
در قسمت بعد میروم سراغ این سؤال که اصلا چرا کاربران و کسبوکارها باید وارد این فضا شوند و منفعت واقعی آن کجاست.