«تأیید انسانی»؛ سد دفاعی جدید در برابر توهمات مالی عامل‌های هوش مصنوعی

تصور کنید حساب بانکی شما به یک مدل زبانی پیشرفته (LLM) با کارایی بالا متصل شده است؛ در این حالت، تنها یک کارت تأییدیه انسانی است که به عنوان تنها سد دفاعی، مانع می‌شود هوش مصنوعی در عرض چند ثانیه تمام موجودی شما را خرج کند. برای پرداختن به این چالش و رفع این نگرانی، توسعه‌دهنده‌ای به نام yama3133 (که یکی از سازندگان جامعه AWS در حوزه مهندسی هوش مصنوعی برای سال ۲۰۲۶ است)، یک نمونه اولیه یا اثبات مفهوم (PoC) را منتشر کرد. او با ادغام مدل Claude Sonnet 4.6 در یک عامل (Agent) با قابلیت پرداخت، نشان داد که دستیابی به هزینه‌های «ایمن-به-طراحی» (safe-by-construction) از طریق یک معماری سخت‌گیرانه مبتنی بر گیت‌های تأیید انسانی امکان‌پذیر است. این رویکرد در واقع پاسخی فنی به چالش‌های عملیاتی است، چرا که بسیاری از آزمایش‌های پیشین در دنیای واقعی نشان داده‌اند که عامل‌های هوش مصنوعی ممکن است با وجود هزینه‌های عملیاتی بالا، در کسب درآمد یا اجرای دقیق مأموریت‌های مالی با بن‌بست مواجه شوند.

دادن کیف پول به یک هوش مصنوعی معمولاً با ترس از دست دادن کنترل همراه است؛ جایی که یک توهم (Hallucination) — شبیه به شرایطی که مدل واقعیت‌ها را اشتباه تفسیر می‌کند — می‌تواند زنجیره‌ای از خریدهای ناخواسته و تصادفی را رقم بزند. طبق مستندات پروژه، اکثر گردش‌های کاری عامل‌محور فعلی سعی می‌کنند این مشکل را با حفاظ‌های متنی پیچیده (Prompt-based guardrails) حل کنند، اما این روش‌ها به دلیل ماهیت احتمالی مدل‌ها، به راحتی دور زده می‌شوند و قابل اعتماد نیستند. رویکرد جدید yama3133، دستورات مبهم متنی را با یک ابزار فنی سخت جایگزین کرده است: یک ردیف در پایگاه‌داده که باید توسط انسان به وضعیت «تایید شده» (APPROVED) تغییر یابد تا ابزار پرداخت بتواند اجرا شود.

پشته فنی (Technical Stack)
این عامل بر روی یک معماری پیشرفته طراحی شده است تا قابلیت اطمینان لازم برای محیط‌های عملیاتی را روی پلتفرم Vercel داشته باشد. این سیستم از Next.js 16 برای مدیریت بخش Frontend استفاده می‌کند و برای مدیریت وضعیت‌ها (State Management)، به‌ویژه ردیابی وظایف (wallet_agent_tasks)، تأییدیه‌ها و تراکنش‌ها، به DynamoDB متکی است. منطق هسته این برنامه روی AgentCore Runtime (که در کانتینرهای ARM64 اجرا می‌شود) قرار دارد و برای سازمان‌دهی و ارکستراسیون مدل Claude Sonnet 4.6 از Strands Agent بهره می‌برد.

بر اساس مستندات فنی پروژه، این سامانه دو نوع تعامل مالی مجزا را مدیریت می‌کند:

• ریزتراکنش‌ها (فاز ۱): در این مرحله از AgentCore Payments، سرویس Privy (StripePrivy) و استانداردهای x402 برای تسویه ارز دیجیتال USDC در شبکه base-sepolia استفاده می‌شود.
• خرید در دنیای واقعی (فاز ۲): این بخش شامل ادغام با Rakuten Ichiba برای جست‌وجوی کالاها و استفاده از Stripe Checkout (در حالت تست) برای انجام پرداخت‌های نهایی است.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های عامل‌محور اشاره کردیم، جداسازی لایه تصمیم‌گیری از لایه اجرا، کلید استقرار مدل‌ها در محیط‌های حساس است و این پروژه دقیقاً همین جداسازی را پیاده کرده است. در واقع، انتخاب میان پیاده‌سازی یک PoC سریع یا یک MVP کامل، همواره نقطه عطف تخصیص منابع در تیم‌های AI است تا مشخص شود کدام رویکرد بودجه مهندسی را بهینه‌تر مصرف می‌کند.

ابزارها و سازوکارها
این عامل برای جلوگیری از رفتارهای غیرقابل پیش‌بینی، تنها به ۶ تابع مشخص @tool دسترسی دارد که قابلیت‌های آن را تعریف می‌کنند. این مجموعه ابزاری به دو دسته جست‌وجو و اجرا تقسیم شده است:

• ابزارهای اکتشاف (Discovery Tools): شامل search_paid_resources (برای کاتالوگ x402) و search_rakuten_items است. در ابزار جستجوی راکوتن، کاربران می‌توانند یک سقف قیمت (max_jpy) و تعداد نتایج (hits) را تعیین کنند که مقدار پیش‌فرض آن ۵ مورد است.
• ابزارهای تأیید (Approval Tools): توابع request_payment_approval و request_purchase_approval. این ابزارها یک درخواست متوقف (Pending) را در DynamoDB می‌نویسند که شامل شناسه منبع یا کالا، مبلغ (به دلار یا ین ژاپن) و توجیه دلیل خرید است.
• ابزارهای اجرا (Execution Tools): تابع execute_x402_payment (که از generate_payment_header در AgentCore Payments برای تسویه استفاده می‌کند) و تابع execute_stripe_checkout (که یک جلسه پرداخت Stripe Checkout ایجاد کرده و URL آن را بازمی‌گرداند).

منطق تأیید و ایمنی
مکانیسم حیاتی ایمنی در توابع request_*_approval نهفته است. وقتی مدل هوش مصنوعی تصمیم می‌گیرد چیزی بخرد، پرداخت را به صورت مستقیم اجرا نمی‌کند؛ بلکه ردیفی در جدول wallet_agent_approvals در DynamoDB ایجاد کرده و سپس متوقف می‌شود.

در این حالت، زنجیره ابزار به‌طور منطقی مسدود شده است. مدل نمی‌تواند به توابع اجرایی پیشروی کند مگر اینکه یک انسان از طریق رابط کاربری (UI) با تراکنش تعامل داشته و آن را تأیید کند. این طراحی تضمین می‌کند که LLM نمی‌تواند «از مسیر خارج شود» زیرا از نظر فنی اجازه دسترسی به فراخوانی نهایی API را به‌طور مستقل ندارد.

در لایه Backend، سیستم Next.js 16 App Router از طریق هندلرهای مسیر (Route Handlers) خاص این فرآیند را مدیریت می‌کند. هندلر GET در مسیر /api/approvals وضعیت‌های «PENDING» را اسکن می‌کند، در حالی که هندلر POST از یک UpdateCommand همراه با ConditionExpression استفاده می‌کند تا اطمینان حاصل شود که تنها ردیف‌های در انتظار به وضعیت تصمیم‌گیری‌شده تغییر می‌یابند و زمان دقیق تصمیم را از طریق Date.now()/1000 ثبت می‌کند.

غلبه بر چالش‌های پیاده‌سازی
ساخت این عامل دو «تله» فنی بزرگ را آشکار کرد که توسعه‌دهنده مجبور به حل آن‌ها شد. نخست اینکه تنظیمات امضاکننده (Signer) در Privy را نمی‌توان به‌طور کامل در سمت سرور (Server-side) به پایان رساند. توسعه‌دهنده متوجه شد که فراخوانی ProcessPayment منجر به خطای AccessDeniedException با پیام «اعتبارات Privy نامعتبر است» می‌شود.

اگرچه PaymentManager و PaymentInstrument (کیف پول کریپتویی داخلی) می‌توانستند از طریق boto3 ایجاد شوند، اما کلید احراز هویت (Authorization Key) به عنوان یک امضاکننده در کیف پولی که توسط CreatePaymentInstrument در AWS ساخته شده بود، ثبت نشده بود. برای حل این مشکل، نیاز بود که الگوی privy-io/aws-agentcore-sdk به‌صورت محلی اجرا شود و از رابط کاربری مرورگر «Connect agent» برای فراخوانی API داخلی Privy و افزودن کلید احراز هویت به لیست additional_signers استفاده گردد.

چالش دوم مربوط به سیستم سخت‌گیرانه تشخیص بات در API شرکت Rakuten بود. درخواست‌ها به نقطه اتصال IchibaItem/Search/20260401 با خطای ۴۰۳ و پیام REQUEST_CONTEXT_BODY_HTTP_REFERRER_MISSING رد می‌شدند. حتی افزودن هدر Referer نیز شکست خورد چون سیستم رشته User-Agent: wallet-agent/0.1 را شناسایی می‌کرد. توسعه‌دهنده این مشکل را با جعل یک User-Agent شبیه به مرورگر (Mozilla/5.0 Macintosh) و ترکیب آن با هدرهای Referer و Origin حل کرد.

رابط کاربری و بومی‌سازی
برای اینکه این نمونه اولیه (PoC) در سطح جهانی قابل دسترس باشد، توسعه‌دهنده یک رابط کاربری ۸ زبانه را پیاده‌سازی کرد که از زبان‌های ژاپنی، انگلیسی، چینی، کره‌ای، فرانسوی، ایتالیایی، اسپانیایی و عربی پشتیبانی می‌کند. سیستم با استفاده از localStorage و navigator.language زبان کاربر را به‌طور خودکار تشخیص می‌دهد و از یک دیکشنری تخت با ۳۱ کلید برای ترجمه استفاده می‌کند. برای زبان عربی، رابط کاربری به‌طور پویا جهت سند را به «rtl» (راست به چپ) تغییر می‌دهد (document.documentElement.dir).

در لایه بصری، از فونت LINE Seed JP Bold از طریق next/font/google استفاده شده که به عنوان متغیر CSS --font-line-seed در Tailwind CSS تعریف شده است. این انتخاب باعث ایجاد یک زیبایی‌شناسی دوستانه و گرد-ضخیم می‌شود که با دنیای طراحی اپلیکیشن LINE همسو است.

درس‌های کلیدی آموخته شده
در طول توسعه مخزن wallet-agent چندین نتیجه معماری مهم به دست آمد:

• ادغام Frontend: دیوار امضاکننده Privy در سمت سرور قابل حل نیست؛ بنابراین مرحله «اتصال عامل» باید از روز اول در جریان نمایش (Demo flow) گنجانده شود.
• CI/CD: در حالی که دستور agentcore configure تعاملی است، استفاده از پرچم -ni همراه با یک مخزن ECR شخصی‌سازی شده و Dockerfile، امکان استقرار مبتنی بر CI را فراهم می‌کند.
• محدودیت‌های Vercel: محدودیت ۶۰ ثانیه‌ای تایم-اوت در طرح Hobby برای فراخوانی همزمان عامل‌هایی که زمان اجرای طولانی دارند کافی نیست و نیاز به استفاده از الگوی Poll یا waitUntil است.
• ایمنی: یک ابزار ساده «کارت تأیید انسانی» کافی است تا مدل LLM را در فازهای مختلف پرداخت، به‌صورت ساختاری ایمن کند.

این معماری نشان می‌دهد که آینده تجارت با هوش مصنوعی، نه «بات‌های» کاملاً خودگردان، بلکه عامل‌های بسیار کارآمدی هستند که تحقیقات و آماده‌سازی سبد خرید را انجام می‌دهند و trigger نهایی مالی را به انسان می‌سپارند. با انتقال بار ایمنی از «استدلال مدل» به «معماری سیستم»، توسعه‌دهندگان می‌توانند عامل‌ها را در محیط‌های حساس بدون ریسک خطاهای مالی فاجعه‌بار مستقر کنند.

گام بعدی شما

• اگر در حال توسعه عامل‌های مالی هستید، به جای تکیه بر پرامپت، یک «لایه تایید سخت» (Hard Approval Layer) در پایگاه‌داده ایجاد کنید.
• برای دور زدن سیستم‌های تشخیص بات در APIهای تجاری، از شبیه‌سازی کامل هدرهای مرورگر (User-Agent, Origin) استفاده کنید.
• در پروژه‌های مبتنی بر Vercel، برای توابع طولانی‌مدت از الگوی waitUntil یا Poll استفاده کنید تا با محدودیت ۶۰ ثانیه‌ای مواجه نشوید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.