بناء وكلاء ذكيين يجرون معاملات عبر Anchor Browser ومدفوعات AgentCore

تحتاج وكلاء الذكاء الاصطناعي بشكل متزايد إلى الوصول إلى موارد ويب تُسعَّر بحسب كل طلب. على سبيل المثال، مجموعات البيانات المتميزة تتقاضى رسومًا عن كل استعلام، وواجهات برمجة التطبيقات البحثية تقيس الاستخدام بحسب كل استدعاء، والناشرون المحميون باشتراك يقيدون المحتوى خلف الدفع. عندما يصادف وكيل ذكاء اصطناعي أحد هذه الموارد، يعيد الخادم رمز HTTP 402 Payment Required. لا يملك الوكيل آلية دفع مدمجة، ولا ميزانية مرتبطة بالجلسة، ولا طريقة برمجية لتلبية الطلب. تتعطل المهمة وتتطلب تدخلًا يدويًا.

Anchor Browser مع المدفوعات الوكيلة يتولى إدارة مسارات عمل الدفع بين الآلات نيابةً عن الوكيل. طُوّر بالتعاون مع مركز أمازون ويب سيرفيس للابتكار في الذكاء الاصطناعي التوليدي - مصنع وكلاء الشركاء، وهي الآن متاحة على سوق AWS. تتناول هذه التدوينة كيفية Anchor Browser يتكامل مع مدفوعات Amazon Bedrock AgentCore بحيث تستطيع وكلاء الذكاء الاصطناعي الدفع مقابل الصفحات وواجهات برمجة التطبيقات المحمية بـ x402 بشكل مستقل. بروتوكول x402 هو معيار مفتوح للمدفوعات من آلة إلى آلة القائمة على HTTP. يستجيب الخادم برمز 402 Payment Required مع المبلغ وطرق الدفع المقبولة وعنوان الدفع الذي يستخدمه الوكيل لإكمال المعاملة.

Anchor Browser هو حل أتمتة متصفح قائم على السحابة مصمم خصيصًا لوكلاء الذكاء الاصطناعي. تعمل كل جلسة وكيل داخل بيئة متصفح مُدارة تحافظ على حالة المصادقة، وتتولى التنقل، وتلتقط طلبات الشبكة، وتوفر عرضًا مباشرًا لتفاعلات الصفحة.

توفر Amazon Bedrock AgentCore إمكانيات لبناء الوكلاء وربطها وتحسينها على نطاق واسع. وتُعد مدفوعات Amazon Bedrock AgentCore قدرة مُدارة بالكامل داخل AgentCore يمكن للوكلاء الذكية استخدامها لاكتشاف واجهات برمجة التطبيقات (APIs) وخوادم Model Context Protocol (MCP) ومحتوى الويب والوصول إليها والدفع مقابلها بشكل مستقل. تدير AgentCore payments الاتصال بالمحافظ، وتفرض حدودًا قابلة للتهيئة للإنفاق على مستوى البنية التحتية، وتعالج المدفوعات عبر بروتوكول x402. كما توفر إمكانية المراقبة لمحاولات الدفع والموافقات والرفوض والتسويات من خلال Amazon CloudWatch.

عندما يواجه وكيل يعمل في Anchor Browser استجابة 402، يقوم AgentCore payments بترخيص المعاملة وإكمالها ضمن الميزانية المحددة. ويستمر سير العمل دون انقطاع.

التحديات

عندما يواجه وكيل ذاتي موردًا محميًا بـ x402، يتوقف سير العمل. يرسل الوكيل طلبًا، مثل جلب تقرير بحثي مدفوع أو استدعاء واجهة برمجة تطبيقات مدفوعة لإثراء البيانات، فيستجيب الخادم برمز HTTP 402 Payment Required. وبدون آلية للدفع، تتحول المهمة التي كان من المفترض أن تعمل بشكل ذاتي إلى مهمة تتطلب تدخلًا بشريًا.

اليوم، يجب على المطوّرين بناء منظومة الدفع بأكملها. ويشمل هذا الجهد أربع فئات من التعقيد:

معالجة بروتوكول الدفع

• اكتشاف وتحليل تحدي 402 من استجابة HTTP، والتمييز بين الاستجابات التي تتطلب الدفع وبين أخطاء 4xx الأخرى.
• بناء ترويسة الدفع الصحيحة مع الإثبات التشفيري بالتنسيق الدقيق الذي يتوقعه التاجر.
• دعم عدة مخططات دفع (الصيغ الدقيقة exact و upto ومتغيرات البروتوكول) دون تثبيت منطق خاص بمورّد بعينه داخل الوكيل.
• الحفاظ على التوافق عبر تطبيقات x402 لدى التجار التي قد تتفاوت في تنسيق التحدي، أو العملات المستقرة المدعومة، أو توقيت التسوية.

الأمان وإدارة المفاتيح

• تخزين مفتاح خاص لتوقيع المدفوعات، وهو ما يتطلب تخزيناً آمناً للمفاتيح داخل بيئة معرّضة لمدخلات غير موثوقة.
• إدارة عمليات دورة حياة المحفظة، بما في ذلك تدوير المفاتيح، وتحديث بيانات الاعتماد، والتحول إلى مزوّد بديل عند التعطل.

المرونة التشغيلية

• إعادة إرسال الطلب الأصلي مع ترويسة الدفع مع الحفاظ على حالة الجلسة وملفات تعريف الارتباط وسياق الطلب.
• توفير خاصية الاعتداد (idempotency)، وهي أمر ضروري لعمليات المحافظ.
• فرض حدود إنفاق لكل جلسة ولكل معاملة مع تتبع الميزانية في الوقت الفعلي عبر تنفيذات الوكلاء المتزامنة.

قابلية الرصد والامتثال

• تسجيل كل محاولة دفع وموافقة ورفض وتسوية في سجلات تدقيق لأغراض الامتثال والتسوية المصرفية.

وفي غياب خدمة دفع مُدارة، يجب على الوكيل أن يستوعب حزمة الدفع بالكامل داخليًا. في كل استدعاء محمي بـ x402 يعيد استجابة 402، يجب على الوكيل تنسيق تدفق الدفع الكامل داخليًا، بما في ذلك:

• توقيع الإثبات.
• إرفاق الترويسة الصحيحة.
• إعادة محاولة الطلب.
• تسوية المعاملة.
• تسجيل النتيجة.

تتطلب كل خطوة من هذه الخطوات كودًا مخصصًا يجب على المطورين بنائه وتأمينه وصيانته. يوضح الشكل 1 هذه البنية. يحتوي الوكيل على ثمانية مكونات مترابطة بإحكام (المحفظة، المفاتيح الخاصة، ضوابط الميزانية، توقيع الإثبات، إرفاق الترويسة، منطق إعادة المحاولة، تسوية الدفع، والتسجيل). يتصل الوكيل بواجهة برمجة تطبيقات x402 مع تحدٍ 402 يتدفق بالعودة وإعادة محاولة تتدفق للأمام.

الشكل 1: حزمة الدفع للوكلاء

تمتد اعتبارات الأمان إلى ما هو أبعد من مجهود الهندسة.

الإنفاق غير المُتحكَّم فيه. دون حدود إنفاق صارمة تُفرَض على مستوى البنية التحتية، يمكن لخلل برمجي أو حلقة إعادة محاولة أو حقن تعليمات أو وصول غير مقصود أن يُطلق مدفوعات غير مقصودة. الوكيل الذي يعيد المحاولة على نقطة نهاية مدفوعة في حلقة يستمر في تفويض المدفوعات حتى يحدث تدخل يدوي.

انكشاف المفاتيح. عندما توجد المفاتيح الخاصة داخل بيئة تشغيل الوكيل، فإنها تتشاراك بيئة تنفيذ واحدة مع صفحات ويب غير موثوقة وأدوات خارجية وتبعيات خارجية. قد تكشف هذه المتجهات عن غير قصد بيانات الاعتماد التي تتحكم في أموال حقيقية.

انكشاف مسار التوقيع. إذا كانت البنية التحتية للتوقيع متاحة من بيئة التشغيل، فيمكن لجهة تهديد أن تحاول الوصول إلى المفتاح أو إعادة توجيه المدفوعات إلى عنوان تحت سيطرة غير مصرح بها. يتطلب التخفيف الفعّال ألا يدخل المفتاح إلى بيئة التشغيل من الأصل.

تُقدِّم الوكلاء القائمون على المتصفح قيدًا إضافيًا: يجب أن يتم الدفع ضمن جلسة المتصفح نفسها. وإلا فإن تسجيلات الجلسة والعرض المباشر لن يطابقا ما نُفِّذ فعليًا.

الحل

تعالج Anchor Browser وAgentCore payments هذا التعقيد بنقل حزمة الدفع بأكملها إلى بنية تحتية مُدارة.

على عكس استدعاء أداة عديم الحالة، يوفر Anchor Browser متصفح سحابيًا حقيقيًا بهوية دائمة وسير عمل قابل للتكرار ومحدد، وسياق الجلسة اللازم لتسجيل الدخول والتنقل وإنهاء المهام بشكل موثوق. تتم المصادقة والتنقل وطلبات الشبكة والتسجيلات والعرض المباشر داخل جلسة المتصفح نفسها. وعندما يكون الدفع مطلوبًا، تتم المعاملة داخل تلك الجلسة. يلتقط التسجيل التسلسل الكامل من الطلب إلى 402 إلى الدفع إلى تسليم المحتوى. يتضمن وكلاء Anchor أداة x402 مدمجة تتعامل مع استدعاءات واجهات برمجة التطبيقات المدفوعة بشكل أصلي ضمن سياق المتصفح. لا تتطلب الأداة المدمجة أي تغييرات على سير العمل الحالي القائم على Playwright أو Puppeteer أو Chrome DevTools Protocol.

يعمل AgentCore payments كطبقة الدفع. في مركز الخدمة يوجد Payment Manager، وهو المورد الأعلى مستوى الذي ينسق عمليات الدفع لحساب AWS. يتطلب إنشاء Payment Manager تحديد نوع مُفوِّض ودور IAM. ثم يوفِّر AgentCore هوية حمل عمل مقابلة في Amazon Bedrock AgentCore Identity.

تصل المكونات المتبقية Payment Manager إلى البنية التحتية للمحفظة الخارجية:

• يُدمج PaymentConnector Payment Manager مع مزود محفظة خارجي، إما Coinbase Developer Platform (Coinbase CDP) أو Stripe Privy.
• يخزِّن PaymentCredentialProvider بيانات اعتماد مزود المحفظة بشكل آمن في AgentCore Identity.
• يحدد PaymentInstrument عنوان المحفظة المحدد الذي تُسحب منه الأموال.

يُنشئ Anchor Browser المحافظ عبر AgentCore payments باستخدام مزود محفظة مدعوم، دون وضع أسرار المحفظة أو المفاتيح الخاصة داخل بيئة تشغيل الوكيل. يتعامل AgentCore payments مع عمليات المحفظة عبر المزود المُهيَّأ. لاكتشاف نقاط النهاية، يوفر AgentCore خادم Coinbase x402 Bazaar MCP server من خلال Amazon Bedrock AgentCore Gatewayمنسَّقًا، بحيث يمكن للوكلاء اكتشاف نقاط نهاية x402 المتاحة بنظام الدفع لكل استخدام برمجيًا.

يعيد AgentCore payments هيكلة معمارية الدفع. تنتقل العمليات الحساسة خارج بيئة تشغيل الوكيل وإلى طبقة خدمة مُدارة. لا يحتفظ Anchor Agent سوى بمكوّنين متعلقين بالدفع: جلسة ميزانية وأداة x402. أما البنية التحتية، بما فيها المصادقة وأسرار المحفظة وحدود الدفع والمراقبة وتوقيع إثبات الدفع، فتقع في طبقة AgentCore payments. يوضح الشكل 2 اتصال Anchor Agent بطبقة AgentCore payments المُدارة، التي تتعامل مع تكامل مزود المحفظة مع Coinbase CDP أو Stripe Privy.

الشكل 2: يتكامل Anchor Browser مع AgentCore payments

كيف يعمل مسار الدفع

تصف الخطوات التالية ما يحدث من البداية إلى النهاية، من لحظة مواجهة جلسة المتصفح لمورد محمي بـ x402 إلى لحظة استلام الوكيل الاستجابة ومواصلة المهمة.

1. ينشئ Anchor Browser جلسة AgentCore PaymentSession مخصصة لجلسة المتصفح. عند بدء الجلسة مع تشغيل x402، يوفِّر Anchor Browser جلسة PaymentSession عبر AgentCore payments، لربط جلسة المتصفح بأداة دفع وميزانية مُهيَّأين.
2. يتلقى المتصفح استجابة HTTP 402 Payment Required. ينتقل الوكيل إلى عنوان URL أو يقوم بطلب fetch أو XMLHttpRequest (XHR). يرد التاجر بتحدٍ 402 يحدد المبلغ وطرق الدفع المقبولة وعنوان الدفع.
3. يختار المتصفح طريقة دفع متوافقة. تقرأ Anchor Browser حمولة تحدّي 402 وتطابق طريقة الدفع المطلوبة مع الأداة المرتبطة بـ PaymentSession.
4. يتحقق AgentCore من ميزانية الجلسة ويُنشئ إثبات الدفع التشفيري. يتحقق AgentCore payments من أن مبلغ الدفع يقع ضمن حد الإنفاق للجلسة. ثم توقّع الخدمة المعاملة باستخدام مزود المحفظة المُهيأ (Coinbase CDP أو Stripe Privy) وتعيد الإثبات التشفيري. لا تدخل أي مفاتيح تشفيرية إلى المتصفح أو بيئة تشغيل الوكيل.
5. يعيد المتصفح المحاولة في الطلب الأصلي مع ترويسة الدفع. يُرفق المتصفح الإثبات الموقّع كـ PAYMENT-SIGNATURE لـ x402 v2 أو X-PAYMENT لـ x402 v1، ثم يعيد المحاولة في الطلب الأصلي مرة واحدة بالضبط.
6. يتحقق التاجر من الدفع ويسوّيه، ثم يعيد المورد المحمي. يُصادق التاجر على الإثبات التشفيري، ويسوّي المعاملة على البلوكتشين، ويقدّم المحتوى. ويواصل الوكيل المهمة.

تبقى بيانات اعتماد المحفظة لدى AgentCore ومزود المحفظة المُهيَّأ طوال هذه العملية.

المتطلبات الأساسية

قبل البدء، تأكد من أن لديك مفتاح API صالحاً لـ Anchor Browser (ANCHOR_API_KEY). لإنشاء واحد، راجع دليل Quick Start الخاص بـ Anchor Browser.

إعداد مدفوعات x402 التلقائية

يتطلب إعداد المدفوعات الوكيلة لـ Anchor Browser خاصية جلسة واحدة. اضبط session.x402 على true. القيمة الافتراضية للخاصية هي false. عند التمكين، يمكن لجلسة المتصفح الوصول تلقائياً إلى المواقع المحمية بـ x402 مع مدفوعات موقعة من مدفوعات AgentCore وإعادة المحاولة داخل نفس جلسة المتصفح. تمكين session.x402 يخوِّل المتصفح إجراء مدفوعات حقيقية من أداة الدفع المُهيَّأة.

توضح الأمثلة التالية كيفية إنشاء جلسة مُمكَّنة بالدفع لـ Anchor Browser باستخدام cURL وJavaScript:

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

بعد الاتصال عبر Chrome DevTools Protocol، يتنقل الوكيل بشكل طبيعي. لا تحتاج إلى تضمين مفتاح محفظة أو ترويسة دفع في كود الأتمتة الخاص بك. يتعامل المتصفح مع تحديات 402 وتوقيع المدفوعات وإعادة المحاولات بشفافية لطلبات تنقّل المستندات وfetch وXHR.

حدود جلسة الدفع وسلوكها

يفرض Anchor Browser ضوابط الحماية التالية على مستوى الجلسة من خلال تكامل مدفوعات AgentCore. تعمل كل جلسة متصفح جاهزة للدفع ضمن حدود إنفاق ووقت مُهيَّأة. للحصول على حدود محددة، راجع الوثائق التقنية لـ Anchor Browser.

إذا كانت استجابة التاجر مشوهة، أو لم تُعرض شبكة متوافقة، أو نُفدت الميزانية، أو رفضت مدفوعات AgentCore الدفعة، يُعيد المتصفح استجابة 402 الأصلية إلى الصفحة دون تغيير. ويمكن عندئذٍ لكود الأتمتة الخاص بك معالجة 402 كخطأ HTTP قياسي.

تتحكم خاصية جلسة x402 في المدفوعات للموارد الخارجية فقط. ولا تُستبدل الخاصية أرصدة Anchor ولا تدفع مقابل جلسة المتصفح.

كود الأتمتة لـ Anchor Browser

يبقى كود الأتمتة الخاص بك لـ Anchor Browser دون تغيير. يوضح المثال التالي أنه لا يلزم أي كود خاص بالدفع:

const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');

لا منطق محفظة، ولا بناء لترويسة دفع، ولا كود لإعادة المحاولة. يتنقل الوكيل إلى عنوان URL. إذا أعاد الخادم 402، ينسّق Anchor Browser مع مدفوعات AgentCore لتوقيع إثبات الدفعة، ويعيد الطلب بالترويسة المناسبة للدفع، ويوصل المحتوى إلى الصفحة. يتلقى كود الأتمتة الخاص بك الصفحة النهائية المُقدَّمة دون أي إشارة إلى حدوث دفعة.

ينطبق هذا النمط بشكل موحّد على الصحف المدفوعة، وبيانات الأسواق المالية المرخّصة، ووثائق API المقيَّدة، وقواعد بيانات البحث المحدودة الاستخدام، وغيرها من الموارد التي تحجب المحتوى خلف تحدٍ من نوع 402.

استخدام أداة x402 المدمجة لمكالمات API

الموارد المدفوعة لا تقتصر على صفحات الويب. فالكثير منها عبارة عن APIs تتوقع POST أو PUT أو طرق HTTP أخرى. من الأمثلة الشائعة خدمات إثراء البيانات، ونقاط نهاية الاستدلال المتميزة، وواجهات API للمحتوى المرخّص. لهذه الحالات، تتضمن وكلاء Anchor Browser أداة x402 مدمجة تستدعيها مثل واجهة HTTPS قياسية ضمن سياق المتصفح.

يُجري وكيلك استدعاء API عبر fetch أو XHR. إذا أعاد الخادم تحدي 402، ينسّق المتصفح توقيع الدفعة عبر مدفوعات AgentCore ويعيد الطلب بالترويسة الموقعة للدفع. يتلقى كودك الاستجابة كأن نقطة النهاية كانت مجانية. الأداة غير مرتبطة بمورّد أو نموذج أو إطار عمل محدد. تعمل الدفعة كقدرة على مستوى الجلسة تحت أدواتك الحالية، ولا تلزم أي تغييرات في كود الوكيل.

// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
  const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ company_domain: 'example.com' }),
  });
  return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);

لا يتلقى كود الأتمتة الخاص بك بيانات اعتماد المحفظة. المدفوعات التلقائية متاحة فقط عندما تُضبط session.x402 على true وتبقى خاضعة لحدود الإنفاق والانتهاء الموضحة في القسم السابق.

الفوائد الرئيسية

نقل عملية الدفع هذه من كود التطبيق إلى طبقة البنية التحتية:

لا توجد بنية تحتية للمدفوعات لبنائها. لا SDK للمحفظة للتكامل، ولا محلل لاستجابة 402 لكتابته، ولا حلقة إعادة محاولة لتنفيذها، ولا منطق بناء ترويسات لصيانته، ولا سجلات تدقيق مخصصة لبنائها. يتولى AgentCore payments إدارة حزمة الدفع بأكملها.

لا تغييرات على الأدوات الحالية. تستمر نصوص Playwright، وأتمتات Puppeteer، وأوامر Chrome DevTools Protocol، وتدفقات الوكلاء في Anchor Browser في العمل تماماً كما كانت من قبل. الدفع هو قدرة جلسة مرتبطة بالمتصفح، وليس تعديلاً على منطق الوكيل أو المطالبات أو تعريفات الأدوات.

المفاتيح الخاصة لا تدخل بيئة التشغيل. تحدث عمليات التوقيع والتسوية داخل AgentCore payments. يتواصل الخدمة مع Coinbase CDP أو Stripe Privy عبر تخزين آمن لبيانات الاعتماد في AgentCore Identity. لا تمتلك بيئة تشغيل الوكيل صلاحية الوصول إلى مواد المفاتيح التي يمكنها تحويل الأموال.

يتم فرض الميزانيات على مستوى البنية التحتية. تعمل كل جلسة ضمن حدود إنفاق محددة يفرضها AgentCore قبل تفويض أي عملية دفع. يوفر Amazon Bedrock AgentCore Observability سجلات تدقيق كاملة للمدفوعات عبر Amazon CloudWatch. عندما تصل الجلسة إلى حد الإنفاق، يرفض AgentCore payments عملية الدفع.

تكتمل المهام المدفوعة بنجاح. تُحمَّل صفحات GET المدفوعة. تعيد استدعاءات API المدفوعة الاستجابات. يكمل الوكيل سير العمل بدلاً من التوقف عند استجابة 402 والحاجة إلى تدخل يدوي.

الفوترة موحدة. يسوّي Anchor Browser رسوم x402 الخاصة بالأطراف الثالثة كأرصدة على نفس الفاتورة الخاصة بوقت جلسات المتصفح. لا توجد إدارة منفصلة لحفظ العملات الرقمية، ولا رصيد USDC لمراقبته، ولا تسوية على السلسلة (on-chain) يعيد فريق المالية التسوية لها.

الخاتمة

يوفر Anchor Browser، المتكامل مع مدفوعات AgentCore، لعملاء الذكاء الاصطناعي (AI agents) القدرة على التعامل مع تحديات الدفع x402 بشكل مستقل للصفحات المحمية باشتراك ونقاط نهاية API المدفوعة. تبقى بيانات اعتماد المحفظة خارج كود الوكيل، ولا حاجة إلى بنية تحتية مخصصة للمدفوعات.

مع انتقال المزيد من الويب إلى التسعير لكل طلب، لا يمكن للوكلاء الذين يفتقرون إلى آلية دفع إكمال المهام التي تتضمن موارد مدفوعة. تعالج هذه التكاملة تلك الفجوة: يكمل الوكلاء سير العمل المدفوع من البداية إلى النهاية، ويعملون ضمن ميزانيات محددة، مع مراقبة كاملة عبر AgentCore Observability، ودون وجود مواد تشفيرية للمفاتيح في بيئة التشغيل.

للبدء، استكشف الموارد التالية:

• المدفوعات التلقائية عبر x402 في Anchor Browser
• دليل مطور مدفوعات AgentCore
• مدفوعات AgentCore مع تكامل المتصفح
• Anchor Browser على AWS Marketplace

نبذة عن المؤلفين