استخدام المتصفح في الوكالات العميقة المُدارة

النقاط الرئيسية

• يسمح المتصفح بالوكلاء على الويب بتنفيذ أعمال لا يمكن للواجهات البرمجية التطبيقية القيام بها، بما في ذلك النقر والتمرير وتعبئة النماذج.
• تشغل Managed Deep Agents الآن متصفحًا لعناصرك، مع أدوات مُعدّة لتستخدام المتصفح بكفاءة مع السياق.
• تأتي نسخة Managed Deep Agents مع دعم لجلسات المتصفح بمقياس الخيوط ومقياس المستخدم. تسمح عمليات النقل من المستخدمين بالدخول إلى المواقع الإلكترونية والتفاعل معها باستخدام بيانات الاعتماد التي تُحفظ خلال الجلسات.

أصبح العملاء جيدين بما يكفي للعمل في مكان عملنا، وتمثل الكثير من هذه الأعمال داخل المتصفح. حجز السفر، وإلغاء الاشتراك، أو تقديم المطالب، كل ذلك يحدث على مواقع مُصممة للناس الذين ينقرون على الصفحات، بما في ذلك تلك التي لم يخطط العملاء لزيارتها. غالبًا لا توجد واجهة برمجة تطبيقية يمكن للعملاء استخدامها. استخدام curl لاسترداد الصفحة لا يعمل أيضًا، لأنه يعيد محتوى HTML قبل أن يقوم JavaScript بتمثيل الصفحة، ولا يمكن النقر على أي شيء.

الوكلاء الشخصيون مثل Instinct وMuse من Meta يعملان بهذه الطريقة بالفعل. حركة مرور الوكلاء في المتصفحات تنمو بسرعة أيضًا، وشهدت DataDome ارتفاعًا في طلبات الوكلاء في المتصفحات بنسبة 4.7 أضعاف فقط في شهر سبتمبر.

Managed Deep Agents يسمح لك ببناء ونشر الوكلاء في LangSmith دون الحاجة إلى تشغيل أي البنية التحتية. تكتب تعليمات وأدوات الوكيل، بينما يقوم LangSmith بتشغيل الأجهزة والوضع التشغيلي. اليوم، نضيف لهذه الوكلاء متصفحًا، حتى تتمكن من بناء وكلائك الخاصين الذين يعملون على الويب. Managed Deep Agents يشغل أيضًا المتصفح، ويوفر لأدوات الوكيل الخاصة به.

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

حيث يساعد المتصفح

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

حتى الآن، ظهرت حالتان استخدام شائعان:

• الإجراءات التي لا يمكن للواجهة البرمجية التغطية لها，مثل حجز الرحلة أو حجز المطعم. عندما يحتوي الموقع على واجهة برمجية لهذه المهمة، يجب على الوحدة استخدام تلك الواجهة البرمجية.
• اختبار من البداية إلى النهاية، مثل التحقق من تغييرات الواجهة الأمامية قبل دمجها. عندما يغير طلب الاستدعاء شكل نموذج التسجيل، يمكن لعنصر البرمجة أن يبدأ التطبيق في البيئة الاختبارية الخاصة به، ويفتح النموذج في المتصفح، ويضغط على العناصر للتحقق من أن التغيير يعمل بشكل صحيح. نستخدم هذه الطريقة في Open SWE، وهو عنصر البرمجة الخاص بنا.

إضافة قدرات استخدام المتصفح

لإضافة متصفح، تصدير browser من browser.py في رأس المشروع:

# browser.py
from managed_deepagents import define_browser

browser = define_browser(
    scope="thread",
    idle_ttl_seconds=600,
)

scope يتحكم في كيفية مشاركة جلسات المتصفح.

• scope="thread" (الإعداد الافتراضي) يمنح كل خيط عملية عرضة منفصلة للتصفح. تبدأ كل محادثة بنافذة تصفح جديدة، دون أي كوكيز أو تسجيلات من خيط آخر.
• scope="user" يشترك متصفحًا واحدًا بين خيوط المستخدم المُسجَل (انظر الهوية). يحصل كل خيط على نافذة خاصة به، لذا لا تتداخل محادثتان تتمان في نفس الوقت، ولكنهما يشتركان في الكوكيز وغيرها من حالة المتصفح. إذا قمت بالتسجيل في موقع ما في خيط معين، فإن خيطًا لاحقًا يمكنه استعادة تلك الجلسة بدلاً من البدء من الصفر.

يتوقف المتصفح بعد idle_ttl_seconds دون أي نشاط (10 دقائق بشكل افتراضي)، بحيث لا تُدفع فاتورة للمتصفح الذي لا يُستخدم أحده.

نقل المتصفح إلى المستخدم

بعض الخطوات لا تزال تحتاج إلى شخص، وأكثرها شيوعًا هو تسجيل الدخول. لا يجب أن تُعطي العامل كلمة المرور الخاصة بك، حيث ستصل إلى رسائل النموذج، وإلى سجلات العملية، وإلى مزود النموذج.

لذلك، عندما يصل الوكيل إلى صفحة تسجيل الدخول، ينفّذ browser_handoff مع سبب، مثل “يرجى تسجيل الدخول إلى Acme Travel حتى أتمكن من الاستمرار”. في LangSmith Studio، وهو واجهة المستخدم حيث تتواصل مع الوكيل وتصحح أخطاءه، تحصل على بطاقة تفاعلية باستخدام نفس المتصفح. تقوم بتسجيل الدخول بنفسك، نقر على Hand back، ويستمر الوكيل في العمل من حيث توقف، وهو بالفعل مسجل الدخول. يتم تنفيذ عملية handoff مع كل متصفح مُدار ويعمل تلقائيًا في Managed Deep Agents channels مثل Slack، لذلك لا يوجد شيء إضافي يجب تنصيبه.

هذا الأمر مهم للغاية عند استخدام `scope="user"`. مع نطاق المستخدم، يظل تسجيل الدخول موجودًا في خيوطك اللاحقة، لذا يطلب الخادم منك تسجيل الدخول مرة واحدة، بنفس الطريقة التي يحفظ بها متصفحك الخاصك.

كيف يعمل من الداخل

يتطلب العميل شيئين لاستخدام الويب: متصفح، ومجموعة من الأدوات لتشغيله. يدير Managed Deep Agents كلا الشيئين.

المتصفح. برنامج Managed Deep Agents يشغل المتصفح في غرفة تجريبية LangSmith، بشكل منفصل عن العميل. إنه متصفح عن بعد، لذا لا يتم تشغيل أي شيء على جهازك. على عكس معظم المتصفحات عن بعد، يحتوي أيضًا على رابط خاص إلى غرفة التجريب الخاصة بالعميل، وهذا هو ما يجعل الاختبارات من نهاية إلى نهاية ممكنة (أكثر تفصيلاً أدناه).

الأدوات. يضيف Managed Deep Agents أدوات المتصفح إلى الوكيل:

• browser_snapshot يقرأ شجرة الإمكانية في الصفحة ويرقم العناصر التفاعلية باستخدام أسماء فريدة.
• browser_run يعمل على الصفحة، إما بأوامر مجمعة مثل click وfill أو باستخدام JavaScript الذي يستخدم كائن page من نوع Playwright، الذي يقوم Stagehand بتحويله إلى أوامر خاصة به.
• browser_screenshot يلتقط الصورة المعروضة للصفحة.
• browser_handoff ينقل المتصفح إلى شخص، الذي يعيده عند انتهائه (انظر أعلاه).

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

تم بناء الأدوات على Stagehand، وهو SDK مفتوح المصدر من بويربرايزبيس لبناء وكالات المتصفح. وقد اختبرناها وتعديلها وفقًا دورة تطوير الوكالات: إجراء اختبارات للمتصفح، قراءة السجلات في LangSmith، والتحقق من كل تغيير باستخدام الاختبارات. على 100 مهمة من WebVoyager، وهي اختبار للمهام اليومية على المواقع الإلكترونية، نجحت 90% من المهام بتكلفة إجمالية قدرها $1.98. كانت هذه أعلى نسبة نجاح بين الأدوات السبعة التي اختبرناها. أما أقربها، وهو خادم MCP الخاص ببويربرايزبيس، فقد نجح بنسبة 89% بتكلفة 9 أضعاف المبلغ المذكور.

تدعم هذه الإعدادات كلا الحالتين من الاستخدام، بطرق مختلفة قليلاً.

إجراءات لا يمكن للواجهة البرمجية التغطية عليها

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

اختبار من البداية إلى النهاية

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

• العامل يسيطر على المتصفح من خلال أدوات المتصفح الخاصة به، كما في الحالة السابقة.
• يتصل المتصفح بالتطبيق من خلال جسر localhost. عندما يفتح المتصفح localhost:5173，تنتقل الطلب عبر رابط خاص إلى المنفذ 5173 داخل وضع السبورة الخاص بالموظف. لا يحتاج التطبيق إلى عنوان URL عام. هنا، يعني localhost وضع السبورة الخاص بالموظف.

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

عندما يمر الاختبار، يمكنك طلب من العامل أن يحفظ خطواته كملف اختبار، لأن كل استدعاء browser_run هو جزء من سيناريو Playwright العادي. في التشغيلات اللاحقة، سيُعاد تشغيل ذلك الملف دون استدعاءات النموذج حتى يتغير الصفحة.

الخلاصة

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

أضف متصفحًا إلى الوكيل المُدار باستخدام define_browser. لمنح وكيل عميق مفتوح المصدر متصفحًا، حيث تجلب متصفحك الخاص (مثل المتصفح المُستضاف من Browserbase)، راجع دليل استخدام المتصفح.

شكر وتقدير

شكرًا لـ شون ماكجوير، ميغيل غونزاليس، وكايل جيونغ من Browserbase على مساعدتهم في مشروع Stagehand وهذا المنشور.