Gemini Spark AI Agent به یک کیف‌پول نیاز دارد، نه یک کارت
گوگل در ۱۹ مه ۲۰۲۶ از Gemini Spark رونمایی کرد: یک دستیار عاملی ۲۴/۷ که ایمیلهای جیمیل شما را میخواند، پاسخ‌ها را پیش‌نویس میکند، رزرو انجام می‌دهد و بعد از اینکه لپ‌تاپ را می‌بندید هم به کارش ادامه می‌دهد. این سیستم قرار است یک دستیار عاملی همیشهفعال باشد که نیمه کسل‌کننده صندوق ورودی‌تان را در ساعات خواب شما مدیریت کند.
اما زیر تمام دموهای جیمیل، مشکلی نهفته است که هیچ‌کس روی صحنه حاضر نبود آن را بلند بگوید. لحظه‌ای که یک عامل بدون حضور شما اقدام میکند، تمام فرض‌های بنیادین پرداخت‌های کارتی فرو می‌ریزند. هیچ انسانی نیست که روی «تایید» ضربه بزند. هیچ تلفنی نیست که کد ۳-D Secure را دریافت کند. نه کارت حاضر است، نه دارنده کارت، نه جلسه.
به نظرم این ماجرای اصلی عرضه Gemini 3.5 است و تقریباً هیچ ربطی به ایمیل ندارد.
چرا یک دستیار عاملی همیشهفعال نمیتواند از کارت شما استفاده کند
زیرساخت کارت‌ها بر پایه حضور یک انسان بنا شده است. کل پشته ضدکلاهبرداری، از CVV گرفته تا ۳-D Secure، کد SMS، و بررسی‌های سرعت تراکنش، برای این طراحی شده که ثابت کند یک انسان پشت تراکنش است. Spark دقیقاً نقطه مقابل آن است؛ یک فرآیند در ابر گوگل که ساعت ۳ بامداد بیدار میشود تا یک پرواز لغو‌شده را دوباره رزرو کند.
اگر یک عامل مستقل را روی ریلهای ویزا اجرا کنید، سریع به دیوار می‌خورید:
- تراکنش‌های بدون کارت حاضر از یک آی‌پی دیتاسنتر پرچم‌گذاری یا رد میشوند.
- چالش‌های ۳-D Secure به سراغ انسانی می‌روند که خوابیده است.
- مسئولیت شارژبک برای خریدی که هیچ انسانی تایید نکرده، گردن فروشنده می‌افتد.
- هیچ راه تمیزی وجود ندارد که به یک عامل سقف هزینه ۴۰ دلاری بدهید که هر روز ریست شود و نتوان آن را تخلیه کرد.
جایگاه‌بندی AI Ultra خود گوگل دقیقاً به همین دلیل روی بسته‌بندی اشتراکی تکیه میکند، چون پرداخت‌های مبتنی بر هر اقدام هنوز حل‌نشده‌اند. شما یک حق اشتراک ماهانه ثابت به گوگل می‌پردازید، گوگل هزینه‌های عامل را می‌پوشاند، و هیچ‌کس مجبور نیست بفهمد عامل چطور باید به یک طرف ثالث پرداخت کند. این مدل کار میکند، تا زمانی که عامل بخواهد چیزی خارج از باغ دیواردار گوگل بخرد.
طرف تقاضا بالاخره سر رسید
برای دو سال، جامعه پرداخت‌های عاملی ریل‌هایی برای مشتری‌ای ساخت که وجود نداشت. این شکاف را در پرداخت‌های عامل هوش مصنوعی: Anvita، x402، و چه کسی ریل را دارد بررسی کردم؛ فناوری آماده بود، اما عامل‌های خودگردان خرج‌کننده وجود نداشتند.
Spark معادلات را تغییر می‌دهد. گوگل در شرف ارسال ده‌ها میلیون عامل همیشهفعال است که در نهایت به انجام تراکنش نیاز خواهند داشت. این دقیقاً همان تقاضایی است که ریل‌ها منتظرش بودند.
پشته‌ای که پدیدار شده، در معنای درستی کسل‌کننده است:
- x402 کد وضعیت HTTP 402 خاموش‌مانده‌ی «Payment Required» را احیا میکند تا یک سرور بتواند قیمتی اعلام کند و یک عامل بتواند آن را درون‌خطی، با استیبلکوین، در قالب یک درخواست واحد پرداخت کند.
- AWS AgentCore مسیری برای پرداخت اضافه کرد تا عامل‌هایی که در ابر آمازون اجرا میشوند بتوانند بدون نیاز به تأیید انسانی برای هر هزینه، تسویه کنند.
- Pay.sh و ابزارهای مشابه، USDC روی Base را در قالبی می‌پیچند که یک عامل می‌تواند آن را مثل هر API دیگری فراخوانی کند.
وجه مشترک: USDC روی Base. نهایی‌سازی ارزان، کارمزدهای کمتر از یک سنت، و استیبل‌کوینی که خزانه‌داری شرکتی واقعاً می‌تواند بدون اینکه تیم انطباق به اعتراض برخیزد، آن را نگه دارد.
چرا USDC روی Base، به طور خاص
پرداخت‌های عاملی، ریزپرداخت هستند. یک عامل ممکن است برای استعلام از یک API آب‌وهوا ۰.۰۰۳ دلار بپردازد یا برای خرید یک مجموعه داده ۲ دلار. گس شبکه اصلی اتریوم از خود پرداخت گران‌تر می‌شد. Base در این چرخه بیش از ۱ میلیارد دلار حجم روزانه DEX تسویه کرد و کارمزدهایش در کسری از سنت قرار دارد؛ تنها رژیم کارمزدی که در آن ریزپرداخت‌های با سرعت ماشین منطقی هستند.
استیبل‌کوین‌ها از زنجیره مهمتر هستند. یک عامل نمیتواند دارایی نوسانی نگه دارد؛ نوسان ۴ درصدی قیمت بین مجاز کردن و تسویه یک پرداخت، کاملاً غیرقابل‌قبول است. USDC به دلار است، قابل بازخرید، و توسط یک نهاد تنظیم‌شده صادر میشود. پس از آنکه وضع مقررات AML قانون GENIUS صادرکنندگان استیبلکوین را به رژیم نظارتی شبه‌بانکی کشاند، یک مدیر مالی می‌تواند نگهداری USDC را تأیید کند؛ کاری که هرگز با یک توکن بدون پشتوانه ممکن نبود.
وضوح نظارتی همان کلید اصلی است، نه پردازش تراکنشها. بارها دیده‌ام که معاملات نهادی دقیقاً روی همین سوال متوقف میشوند: «چه کسی مسئول است و آیا صادرکننده تحت نظارت است؟»
بخش سخت پرداخت‌ها نیست. بخش سخت اختیار است
دادن کیف پول به یک عامل هوش مصنوعی بیست درصد ساده‌ترین کار است. هشتاد درصد بقیه مربوط به حاکمیت است:
- سقف هزینه‌ای که پایدار بماند. کیف پول عامل نیاز به سقف سختی دارد که روی زنجیره اجرا شود، نه یک محدودیت نرم در کد اپلیکیشن که با مهندسی پرامپت بتوان از آن گذشت.
- تفویض اختیار قابل ابطال. شما عامل را برای سفارش مجدد مواد غذایی مجاز می‌کنید، نه برای جابه‌جایی پس‌اندازتان. این محدوده‌بندی باید رمزنگاریشده باشد، نه یک چک‌باکس ساده.
- قابلیت حسابرسی. هر پرداخت عامل باید به سیاستی که یک انسان تعریف کرده قابل انتساب باشد. «هوش مصنوعی تصمیم گرفت» پاسخی نیست که یک ناظر بپذیرد.
اینجاست که خطر تزریق پرامپت واقعی میشود. قبلاً دیده‌ایم که یک کلید لو رفته چه میکند، نگاه کنید به سوءاستفاده Polymarket. حالا تصور کنید آن کلید در دست عاملی است که تمام روز ایمیلهای ناشناس میخواند و می‌تواند پول خرج کند. سطح حمله کل صندوق ورودی است.
چه چیزی را باید دنبال کرد
گوگل امسال USDC را وارد Spark نخواهد کرد. نسخه اول همه چیز را از طریق Google Pay و صورت‌حساب داخلی گوگل هدایت میکند، چون این کنترل‌پذیر است و چون گوگل ترجیح می‌دهد مالک ریل باشد تا اجاره‌کننده آن.
اما عاملی که ساعت سه بامداد پرواز شما را رزرو میکند، در نهایت می‌خواهد به فروشنده‌ای پرداخت کند که گوگل با او رابطه صورت‌حساب ندارد. وقتی آن اتفاق بیفتد، ارزان‌ترین مسیر یک پرداخت استیبلکوین روی یک پروتکل باز است، نه یک یکپارچه‌سازی کارت اختصاصی برای هر فروشنده. ریلی برنده میشود که یک عامل بتواند بدون اجازه گرفتن از یک غول پرداخت آن را فراخوانی کند.
کیف پول برای عامل در راه است. تنها سوال باز این است که آیا این یک دفتر کل بسته در درون گوگل خواهد بود یا یک دفتر کل باز که هر کسی می‌تواند روی آن بسازد. من روی باز شرط می‌بندم، به همان دلیلی که وب بر AOL پیروز شد.