سلسلة مسرعات TrueFoundry: بناء أتمتة ويب مرنة عندما لا توجد واجهات برمجة التطبيقات

‍

فجوة واجهة برمجة التطبيقات (API)

إنه سيناريو مألوف في الساعة العاشرة صباحًا لفرق العمليات: هناك سير عمل حاسم يحتاج إلى الأتمتة—التحقق من مخزون الموردين، أو إجراء تحليل تنافسي للأسعار، أو تأمين الحجوزات—ولكن المنصة المستهدفة لا توفر وصولاً برمجيًا.

بينما نعيش في عصر الترابط، تحبس العديد من المنصات عالية القيمة بياناتها خلف "خنادق رقمية". تفتقر هذه المنصات إلى واجهات برمجة تطبيقات عامة (APIs)، مما يجبر المطورين على الاعتماد على استخلاص الويب كحل بديل. ومع ذلك، فإن الاستخلاص التقليدي هش للغاية. فهو يعتمد على "محددات هشة"—مسارات CSS أو XPaths مبرمجة بشكل ثابت (مثل div.btn-primary) والتي تتعطل بمجرد أن يغير مطور الواجهة الأمامية اسم الفئة إلى btn-submit.

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

التحول: من المحددات إلى القصد الدلالي

الابتكار الأساسي في هذا المسرّع هو الابتعاد عن نموذج كائن المستند (DOM) والتوجه نحو نموذج كائن إمكانية الوصول (AOM).

في نص برمجي تقليدي، إذا انتقل زر من شريط جانبي إلى رأس الصفحة، تفشل الأتمتة. في هذا النظام الوكيلي، نوفر لمحرك الاستدلال لقطة من شجرة إمكانية الوصول (Accessibility Tree). هذا تمثيل دلالي للصفحة مصمم لقارئات الشاشة، حيث يتم تجريد عناصر div الخاصة بالتصميم للكشف عن الفائدة الأساسية للواجهة.

يتيح ذلك للنظام الاستدلال بناءً على القصد بدلاً من الإحداثيات: "أرى أداة تقويم؛ سأنقر على تاريخ 'الخامس عشر' لأنه يطابق طلب المستخدم." إذا خضع الموقع لإعادة تصميم ولكن الدور الدلالي للزر ظل "تأكيد الحجز"، فإن الوكيل يتعافى ذاتيًا وينجح سير العمل.

البنية: نمط المتحكم-العامل

قمنا بهيكلة التطبيق باستخدام نمط متخصص المتحكم/العامل نمط. بدلاً من نص برمجي متكامل، لدينا وكلاء متميزون يستخدمون بلاي رايت للتنفيذ و LLMs لاتخاذ القرارات.

الشكل 1: البنية عالية المستوى

كما هو موضح في الرسم التخطيطي للبنية، فإن متحكم سير العمل يدير الحالة، ويفوض المهام إلى مكونين متخصصين:

1. وكيل البحث (الاكتشاف): يدير هذا الوكيل مرحلة "التسوق" غير الخطية.
   
   • إنشاء عناوين URL ديناميكية: بدلاً من النقر عبر خمس صفحات هبوط، يقوم بإنشاء معلمات استعلام (على سبيل المثال، ?cuisine=italian&party_size=4) للانتقال مباشرة إلى النتائج.
   • الاستخراج السياقي: يحدد "البطاقات" في واجهة المستخدم لاستخراج التقييمات والأسعار والفتحات الزمنية دون الحاجة إلى علامات HTML محددة.
   • التنقل التكيفي: يتعامل مع النوافذ المنبثقة وإشعارات ملفات تعريف الارتباط كـ "عقبات" يجب تجاهلها بدلاً من أخطاء تتسبب في تعطل النص البرمجي.
2. وكيل الحجز (المعاملة): بمجرد تحديد هدف، يتولى هذا الوكيل التفاعل الدقيق وعالي الدقة الذي يحافظ على الحالة.
   
   • تخطيط النماذج الدلالي: يربط بيانات المستخدم بحقول الإدخال بناءً على التسميات (الاسم الأول) بدلاً من المعرفات العشوائية (input#user_fname).
   • الاستدلال الزمني: يتنقل عبر محددات الوقت ويتعامل مع حالات "نفاد الكمية"، وهو قادر على تطبيق منطق مثل اختيار موعد الساعة 7:15 مساءً إذا كان الموعد المطلوب في الساعة 7:00 مساءً غير متاح.

البنية التحتية: TrueFoundry وبروتوكول سياق النموذج (MCP)

يتطلب تشغيل هذه العوامل في بيئة الإنتاج مستوى تحكم قويًا. نحن نستخدم الـ منصة TrueFoundry لإدارة البنية التحتية و بروتوكول سياق النموذج (MCP) لتوحيد تكامل المتصفح.

الشكل 2: كيف تدعم TrueFoundry دورة حياة التطبيق

• بوابة TrueFoundry للذكاء الاصطناعي: يوفر هذا الإدارة الموحدة والمراقبة اللازمتين. يمكننا مراقبة كل "فكرة" لدى العامل مركزيًا، وتسجيل لقطات AOM وأشجار القرار. الأهم من ذلك، أنه يفرض تحديد المعدل، مما يضمن أن تتصرف عواملنا بمسؤولية ولا ترهق الخوادم المستهدفة.
• MCP والعزل: يقوم MCP بتجريد إمكانيات المتصفح وتحويلها إلى أدوات موحدة. تضمن المنصة أن كل جلسة مستخدم تعمل في حاوية معزولة. هذا يعني أن ملفات تعريف الارتباط الخاصة بجلسة المستخدم أ والتخزين المحلي الخاص به منفصلة ماديًا عن تلك الخاصة بالمستخدم ب، مما يلغي خطر تلوث البيانات المتبادل.

تجربة المستخدم: الاستقلالية الخاضعة للإشراف

لسير العمليات التفاعلية، نحن نطبق نمط "تحقق ثم نفذ" نمط. يقوم العامل بالعبء الأكبر من عملية الاكتشاف ولكنه يتطلب تأكيدًا بشريًا قبل التنفيذ النهائي.

الخطوة 1: تحديد الهدف والاكتشاف

يقبل النظام مدخلات اللغة الطبيعية ويقوم بتطبيعها إلى تنسيق JSON منظم (الموقع، الوقت، حجم المجموعة) لوكيل البحث.

الخطوة 2: بوابة التأكيد

عند العثور على موعد متاح، يتوقف وكيل الحجز مؤقتًا. يعرض التفاصيل للمستخدم ويدخل في حالة انتظار، ولا يستمر إلا بعد تلقي إشارة واضحة.

الهندسة للحالات الهامشية: مشكلة جدار حماية تطبيقات الويب (WAF)

الاختبار الأكثر أهمية لوكيل الويب هو قدرته على التعامل مع سيناريوهات "التدخل البشري" (HITL). غالبًا ما تستخدم المواقع الحديثة جدران حماية تطبيقات الويب (WAFs) التي تطلق اختبارات CAPTCHA أو رموز التحقق عبر البريد الإلكتروني عندما تكتشف الأتمتة.

يفشل السكربت القياسي هنا. يستخدم نظامنا آلة حالة الإيقاف المؤقت والاستئناف.

الشكل 3: منطق حالة معالجة الاستثناءات

كما هو مفصل في الرسم البياني أعلاه (الخطوات 7-11)، عندما يكتشف الوكيل مطالبة تحدي:

1. يوقف التنفيذ ويُعلم المستخدم عبر واجهة الدردشة.
2. تظل جلسة المتصفح نشطة (يتم الاحتفاظ بها ضمن مدة بقاء الحاوية - TTL).
3. بمجرد أن يقدم المستخدم الرمز، يستأنف الوكيل الجلسة بسلاسة لإكمال الحجز.

الخلاصة: تشغيل الويب

ننتقل من "استخراج بيانات الويب" إلى "تشغيل الويب". من خلال الاستفادة من Playwright لـ "الأيدي" والاستدلال الدلالي لـ "العيون"، يمكننا التعامل مع الويب الموجه للبشر كواجهة برمجية.

يوضح هذا المسرّع أنه بالهندسة المعمارية الصحيحة—التفسير الدلالي، والتنسيق ذي الحالة، والبنية التحتية الآمنة مثل TrueFoundry—يمكننا بناء أتمتة مرنة تسد فجوة واجهة برمجة التطبيقات (API).

استكشف مسرّعات TrueFoundry