قدمت Stripe مجموعة معايير لتقييم ما إذا كان بإمكان وكلاء الذكاء الاصطناعي إنشاء تكاملات Stripe حقيقية شاملة عبر خدمات الواجهة الخلفية وتطبيقات الواجهة الأمامية وتدفقات الدفع المستندة إلى المتصفح. الهدف المعياري هو قياس المدى الذي يمكن لأنظمة الذكاء الاصطناعي أن تتجاوز فيه توليد التعليمات البرمجية إلى سير عمل هندسة البرمجيات الكامل الذي يتطلب التنفيذ والاختبار والتحقق من الصحة في بيئات واقعية. وينصب التركيز على سيناريوهات التكامل على نمط الإنتاج في الأنظمة المالية حيث تكون الصحة أمرًا بالغ الأهمية والنجاح الجزئي ليس كافيًا.
تم بناء المعيار حول 11 بيئة قابلة للتكرار تحاكي مشاريع تكامل Stripe مثل ترحيل Checkout ونمذجة Billing API. تشتمل كل بيئة على قواعد تعليمات برمجية كاملة للتطبيق وقواعد بيانات ونصوص برمجية ومفاتيح اختبار Stripe API. يتم تقييم الوكلاء بناءً على مهام الواجهة الخلفية فقط، وسير العمل الكامل الذي يتضمن تدفقات الدفع المستندة إلى المستعرض، والتدريبات الخاصة بالمنتج مثل الاشتراكات وتكاملات Checkout.
يعمل الوكلاء من خلال أداة متسقة تعتمد على Goose وModel context Protocol (MCP)، مع إمكانية الوصول إلى المحطة الطرفية وأتمتة المتصفح وأدوات استرجاع الوثائق. لا تتطلب المهام إنشاء التعليمات البرمجية فحسب، بل تتطلب أيضًا تشغيل الخدمات والتفاعل مع واجهات برمجة التطبيقات (APIs) والتحقق من صحة السلوك الشامل باستخدام الاختبارات الآلية أو تدفقات المستخدم المحاكاة. يقوم مصنفو التقديرات الحتمية بالتحقق من صحة النتائج من خلال استدعاءات API وأتمتة واجهة المستخدم وفحص كائنات Stripe مثل جلسات Checkout. على الرغم من أن Stripe لا ينشر معدل نجاح إجماليًا واحدًا، إلا أن النتائج تختلف بشكل كبير حسب نوع المهمة، مع أداء أقوى في عمليات تكامل الواجهة الخلفية ونتائج أضعف عند الحاجة إلى التحقق من صحة الأنظمة وتتبع الحالة.
وفي تفاصيل التقييم، حقق Claude Opus 4.5 متوسط درجات بنسبة 92 بالمائة في مهام تكامل واجهة برمجة التطبيقات الكاملة عبر أربعة سيناريوهات، في حين وصل GPT 5.2 إلى 73 بالمائة في المهام المنظمة على غرار صالة الألعاب الرياضية عبر سيناريوهين. حافظت عمليات التشغيل الأفضل أداءً على متوسط 63 دورة تفاعل، مما يشير إلى تحسين التنفيذ على المدى الطويل، على الرغم من استمرار ظهور تدهور الصحة في سير العمل الممتد.
نتيجة قياس الأداء الكامل للمكدس (المصدر: منشور مدونة Stripe)
لاحظت كارول إل، مهندسة البرمجيات في Stripe، في منشور على LinkedIn أن القيد الأساسي هو التحقق من الصحة بدلاً من إنشاء التعليمات البرمجية.
لن يحل وكلاء الذكاء الاصطناعي محل مهندسي البرمجيات حتى الآن، على الأقل ليس عند إنشاء عمليات تكامل Stripe، حيث تتطلب الأنظمة المالية صحة صارمة ويفتقر الوكلاء الحاليون إلى طبقة تحقق مستقرة لسير عمل التكامل.
تم تسليط الضوء على وضعين للفشل المتكرر. في سيناريوهات ترقية SDK، يخطئ الوكلاء أحيانًا في تفسير إشارات التحقق من الصحة. عند إعطاء مدخلات Stripe غير صالحة، يلاحظون استجابات HTTP 400 المتوقعة ويستنتجون بشكل غير صحيح أن التكامل ناجح. وفي عمليات التشغيل الأكثر قوة، يقوم الوكلاء بإنشاء بيانات اختبار تركيبية واستخدامها للتحقق من صحة السلوك بشكل صحيح.
يظهر وضع الفشل الثاني في تدفقات الدفع المستندة إلى المستعرض. يتعين على الوكلاء إكمال عملية الدفع الكاملة من خلال واجهة الويب، بما في ذلك إدخال العنوان وتفاصيل البطاقة وإنتاج معرف جلسة الدفع. يمكن أن تؤدي تفاعلات الأداة إلى تعطيل حالة المتصفح، مثل تحويل التركيز بعيدًا عن حقول الإدخال. على الرغم من أن الاسترداد ممكن من خلال إجراءات التحديث أو إعادة التركيز، إلا أن الوكلاء غالبًا ما يفشلون في استرداد المهام وإنهائها قبل الأوان.
يلاحظ الممارسون الذين يراقبون المعيار ذلك
لا تزال العديد من تقييمات الوكلاء تفتقد مخاوف الإنتاج مثل عدم الكفاءة، وإعادة المحاولة، وأخطاء نطاق الترخيص، والتي تتسبب في كثير من الأحيان في فشل التكامل الحقيقي. ولذلك يسلط المعيار الضوء على القيود الأقل في إنشاء التعليمات البرمجية والمزيد في منطق التحقق من الصحة وإدارة الحالة والاسترداد في التنفيذ متعدد الخطوات.
يضع Stripe المعيار كإطار متطور لدراسة هندسة البرمجيات الوكيلة في بيئات واقعية. لقد كان مفتوح المصدر كجزء من مجموعة أدوات الذكاء الاصطناعي الخاصة به، مما يتيح المزيد من التجارب. من المتوقع أن تعمل التكرارات المستقبلية على تحسين التعامل مع إشارات التحقق الغامضة، واستمرارية حالة المتصفح، وصحة التكامل الشامل في الأنظمة الشبيهة بالإنتاج.
