Browser Agent: كيف يخطط وكيل AI وينفذ ويتحقق داخل المتصفح؟

Browser Agent: كيف يخطط وكيل AI وينفذ ويتحقق داخل المتصفح؟

معمارية Browser Agent تفصل التخطيط عن التنفيذ والتحقق، وتستخدم Tools محددة وذاكرة حالة و Guardrails بدل التحكم الحر غير المقيد.

دليل عملي

معمارية Browser Agent تفصل التخطيط عن التنفيذ والتحقق، وتستخدم Tools محددة وذاكرة حالة وGuardrails بدل التحكم الحر غير المقيد.

5خطوات
عمليالمستوى

Browser Agent ليس نموذجًا ينظر إلى صفحة ثم ينقر حتى ينتهي. النظام الموثوق يفصل أربع طبقات: فهم الهدف، تخطيط خطوات قصيرة، تنفيذ عبر Tools محددة، ثم تحقق من النتيجة قبل الانتقال. لو غاب التحقق يمكن للوكيل أن يفسر مجرد اختفاء زر على أنه نجاح. ولو كانت الأدوات عامة جدًا، يصبح كل خطأ في التخطيط قادرًا على تنفيذ أثر واسع. لذلك جودة ال ـAgent تأتي من معمارية التنفيذ أكثر من طول ال ـPrompt.

حوّل هدف المستخدم إلى حالة قابلة للقياس

قبل التخطيط، صغ الهدف في مدخلات ونجاح واضح. «سجل الدخول» يحتاج تحديد Profile والوجهة وما الذي يثبت نجاح الدخول. «اجمع أسعارًا» يحتاج قائمة أهداف وحقولًا متوقعة وقواعد توقف. كلما كان شرط النجاح محددًا قل اعتماد الوكيل على الانطباع البصري. احتفظ أيضًا بقيود المستخدم: لا ترسل، لا تحذف، لا تغير إعدادات الحساب مثلًا.

خطط على مدى قصير ثم أعد التقييم

خطة من عشرين خطوة تُكتب مرة واحدة ستصبح قديمة بعد أول Redirect أو Modal. الأفضل خطة قصيرة: ما الخطوتان أو الثلاث التاليتان؟ بعد تنفيذ كل خطوة، اقرأ الحالة الجديدة وحدّث الخطة. هذا يقلل الانحراف ويجعل Recovery أسهل. لكن لا تجعل إعادة التخطيط مفتوحة بلا حد؛ استخدم budget للخطوات والوقت.

خطوات عملية

  1. فسر الحالة الحالية والهدف.
  2. اختر Tool واحدة أو خطوة قصيرة.
  3. نفذها بمدخلات محددة.
  4. تحقق من تغير الحالة المتوقع.
  5. أعد التخطيط أو توقف عند النجاح/الفشل.

الأدوات يجب أن تحمل معنى لا مجرد Click

Tool مثل `click(x,y)` ضرورية أحيانًا، لكن لو لديك قدرة داخلية مثل `open_profile(profileId)` أو `download_file(url)` أو `submit_form(formId,data)` فهي أكثر ثباتًا وقابلية للتدقيق. ابدأ بأدوات دلالية عندما تكون تحت سيطرتك، واستخدم الرؤية والنقر للواجهات الخارجية التي لا تملك API لها. كل Tool تحتاج schema، timeout، نتيجة منظمة، وتصنيفًا للمخاطر.

قائمة مراجعة

  • Read tools منفصلة عن Write tools.
  • الأداة الحساسة تعرف Target بوضوح.
  • Timeout و retry policy محددان.
  • النتيجة تعيد ID أو state يمكن التحقق منه.
  • لا توجد Tool عامة تمنح shell أو filesystem بلا حدود عند عدم الحاجة.

التحقق مرحلة مستقلة

بعد الضغط على Save لا تعتبر العملية ناجحة لأن زر Save اختفى. ابحث عن رسالة نجاح، قيمة محفوظة، URL جديد، أو نتيجة من API. عند عمليات لها أثر خارجي، التحقق قبل Retry مهم لمنع التكرار. إذا كانت النتيجة غير محسومة، استخدم حالة `unknown/manual_review` بدل التخمين.

ذاكرة المهمة ليست ذاكرة المستخدم

احتفظ داخل Run بمتغيرات مثل currentProfile و stepOutputs و visitedUrls و attempts. هذه الذاكرة مؤقتة ومحددة بالمهمة. لا تخلطها بذاكرة طويلة المدى عن المستخدم إلا بتصميم واضح وموافقة مناسبة. وعند الاستعادة بعد crash، اقرأ checkpoint الموثق بدل محاولة إعادة بناء كل شيء من محادثة النموذج.

قائمة مراجعة

  • Run state لها ID.
  • كل خطوة لها output مختصر.
  • Secrets تحفظ كمراجع لا كنصوص في prompt.
  • Checkpoint قبل الأثر الحساس.
  • نهاية المهمة تنظف الحالة المؤقتة غير المطلوبة.
هل تريد الاحتفاظ بالمقال أو إعادة استخدامه؟
مجتمع إيجي تاجعن المجتمع

شارك في تقييم ونقاش المقال

رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.

تفاعل مع المقالاختر التفاعل المناسب، ويمكنك تغيير رأيك لاحقًا.
قيّم جودة المقاللا توجد تقييمات بعد — كن أول من يقيّم.

نقاش القراء

النقاش

جارٍ تحميل التعليقات…

بعد هذه المادة

تابع القراءة

كل مواد الأتمتة وسير العمل
من نفس القسم04
  1. 02
  2. 03
  3. 04
اختيار القراء

الأكثر قراءة

الترتيب الكامل
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
يتجدد مع النشر

أحدث المواد

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06