ما المقصود باستخدام الحاسوب، وما أهميته؟ استخدام الحاسوب فكرة بسيطة ذات آثار واسعة: فبدلًا من مطالبة النماذج بالإجابة عن الأسئلة، نطلب منها تشغيل البرمجيات؛ فتتنقل بين المواقع، وتملأ النماذج، وتنقر عبر مسارات العمل، وتنجز المهام كاملةً وبشكل مستقل.
يفتح ذلك الباب أمام فئة كبيرة من مهام العالم الحقيقي الموزعة حاليًا بين واجهات متعددة، مثل إتمام الحجوزات والمشتريات الإلكترونية، والتخطيط متعدد الخطوات للسفر، ومسارات العمل الإدارية التي لا يتوفر لها نظير واضح عبر واجهة API. هذه المشكلات ليست جديدة. الجديد هو إمكانية حلها باستخدام نماذج عامة الأغراض.
أظهرت أنظمة حديثة من Anthropic وOpenAI وكلاء لا يكتفون بتنفيذ الإجراءات، بل يستدلون بشأن الحالة، ويتعافون من الأخطاء، ويبنون فورًا حلولًا مخصصة لكل مهمة. يحوّل هذا المتصفح إلى بيئة تنفيذ عامة للوكلاء، لكنه يطرح سؤالًا تصميميًا مباشرًا: ما مقدار هذه البيئة الذي ينبغي كشفه للنموذج؟
كانت إجابة الأنظمة المبكرة هي تغليف المتصفح ضمن مجموعة ثابتة من الإجراءات الآمنة المحددة مسبقًا. وكما سنوضح في هذا المنشور، بدأ هذا النهج يبلغ حدوده.
هناك نزعة مألوفة عند بناء وكلاء المتصفح: لا تثق بالنموذج أكثر من اللازم.
لذلك نغلّف المتصفح. ونتيح أدوات محددة مسبقًا مثل click وtype وscroll وselect وread_text. ونبسّط نموذج كائن المستند (DOM). ونقلّص فضاء الإجراءات. ونحاول جعل السلوك مفهومًا وقابلًا للتحكم عبر تجريدات نصممها بأنفسنا.
هذه نقطة انطلاق منطقية. لكنها تصبح أيضًا، على نحو متزايد، البنية الخاطئة على المدى الطويل.
مع تحسن النماذج الرائدة، لم يعد القصور يقتصر على افتقار النموذج إلى الأدوات. بل يكمن في إجباره على العمل عبر تجريدات تحجب قدرًا مفرطًا من تفاصيل النظام الأساسي. نضغط بيئة فوضوية وديناميكية في واجهة إجراءات ثابتة، ثم نطلب من النموذج أن يحقق أداءً جيدًا رغم فقدان هذه المعلومات.
وأصبحت هذه المقايضة أقل جاذبية.
التحول الذي نستكشفه بسيط في وصفه، لكنه كبير الأثر. بدلًا من التعامل مع الوكيل بوصفه أداة لاختيار إجراءات محددة مسبقًا، نتعامل معه بوصفه منشئ برامج يعمل داخل بيئة تشغيل مقيّدة.
أصبحت النماذج بارعة للغاية، ولم تعد بحاجة إلى حواجز الحماية التجريدية التي تضعها؛ بل تحتاج إلى فضاء الإجراءات الكامل لتصميم المهمة وتنفيذها وتكرار المحاولة حتى تحقق هدفها.
يتناول هذا المنشور ذلك التحول، من أتمتة المتصفح كثيفة التجريد إلى الاستخدام المقيّد للحاسوب، وما يتغير عند تصميم الأنظمة بهذه الطريقة.
المشكلة ليست أن واجهات الإجراءات الثابتة خاطئة من حيث المبدأ. بل إن الويب لا يتوافق معها.
تُبنى الواجهات الحديثة باستخدام React وVue وAngular، مع تحديثات غير متزامنة للحالة، وأنظمة أحداث اصطناعية، وأدوات مصغّرة مضمّنة من جهات خارجية تعمل داخل إطارات iframe متعددة المصادر ولها دورات حياة خاصة بها. لا يكون الغلاف الذي يقول «اكتب في حقل الإدخال هذا» صحيحًا إلا إذا وافقت الصفحة على تعريفك للكتابة. وكثير من الصفحات لا يوافق. غالبًا ما يتجاوز تعيين قيمة مباشرة آلية اكتشاف التغييرات في إطار العمل بالكامل. يبدو حقل الإدخال ممتلئًا. لكن التحقق لا يبدأ أبدًا. ويبقى النموذج معطّلًا.
يمكنك ترقيع ذلك. يمكنك إضافة حالات خاصة لمدخلات React، وإرسال أحداث blur بعد التركيز، وانتظار خمول الشبكة قبل قراءة الحالة. كل رقعة صحيحة في سياقها المحدود. لكنها تتراكم معًا لتنتج نظامًا تزداد صعوبة صيانته ويصبح أكثر تخصيصًا للمواقع التي سبق أن واجهتها.
المشكلة الأعمق هي أنك ترمّز في طبقة التجريد افتراضات حول كيفية عمل التفاعلات، ثم تكتشف أن للويب افتراضات مختلفة.
لنتأمل نموذج دفع مضمّنًا عبر Stripe أو Adyen داخل إطار iframe متعدد المصادر. لا يستطيع الغلاف الوصول إليه مباشرة لأنه يعمل ضمن مصدر منفصل. لا تستطيع أداة read_text رصد حالته الداخلية. ولا تستطيع أداة type التعامل مع حقول إدخاله. هنا يصل الوكيل القائم على الأغلفة إلى طريق مسدود. فقد صُمم التجريد للمستند الرئيسي. بينما تقع المهمة الفعلية في مكان لا يستطيع التجريد رؤيته.
ويظهر تعارض مشابه في مسارات أقل وضوحًا. قد لا تستجيب قائمة منسدلة يتحكم فيها إطار العمل للنقرات المباشرة إطلاقًا، لأن العنصر الظاهر ليس عنصر التحكم الفعلي. وقد تتطلب سلسلة من أحداث لوحة المفاتيح لتشغيل انتقال الحالة الأساسي. تبدو واجهة المستخدم من الخارج قابلة للنقر. يقول التجريد: «انقر». ولا يحدث شيء.
أو لنتأمل مسارًا متعدد الخطوات في نافذة مشروطة، تتأخر فيه تحديثات DOM الظاهرة عن تغييرات الحالة الداخلية. يعتمد الإجراء الصحيح التالي على انتقال في الحالة لم ينعكس بعد في العناصر التي يستطيع الغلاف رؤيتها. ينتهي الأمر بالوكيل القائم على الأغلفة إلى التصرف مبكرًا أو قراءة حالة قديمة، لأنه يعمل وفق رؤية ناقصة للنظام.
في كل حالة، يحجب التجريد الإشارات التي يحتاج إليها الوكيل فعليًا.
أما النموذج الذي يعمل على مستوى أدنى، فيفحص DOM الفعلي، ويستدل بشأن حدود الإطارات، وينشئ تسلسل التفاعل المناسب لذلك السطح تحديدًا، ولذلك يمكنه التعامل مع هذه الحالات. ليس السبب أن النموذج أذكى بطبيعته. بل إنه يستطيع الوصول إلى المعلومات التي حُجبت عنه سابقًا.
التغيير الذي نعمل على تحقيقه بسيط في وصفه: بدلًا من مطالبة النموذج بالاختيار من إجراءات محددة مسبقًا، نتيح له سطح تنفيذ منخفض المستوى ونقيّده عبر سياسات بيئة التشغيل، لا عبر تصميم التجريدات.
ينبع هذا الخيار التصميمي من تحول أوسع في القطاع بدأ يفضّل الأدوات الأولية منخفضة المستوى، التي تستفيد من قدرة الوكيل المتأصلة على التصحيح في أثناء التشغيل وإنتاج شفرة عالية الجودة، بدلًا من أدوات محددة ومبرمجة مسبقًا تكون متينة لكنها تحرم النموذج من التكيف مع البيئات المختلفة.
يكفي النظر إلى نجاح Claude Code بوصفه خيارًا أساسيًا في مجموعات أدوات كثير من المطورين، وإلى توجه القطاع الأوسع نحو الوكلاء العاملين عبر الطرفية. لا تكمن أكبر مزايا Claude Code في النموذج نفسه، بل في منظومة التقييم منخفضة المستوى. إن منح النموذج أدوات أقل عددًا، وأكثر نمطية، وأدنى مستوى، أي الطرفية، يحسّن أداء استدعاء الأدوات، ويرجع ذلك أساسًا إلى قدرة الوكيل على الاستدلال وإنشاء نصوص برمجية مخصصة للمهمة، بدلًا من محاولة استخدام أدوات معمّمة تستهلك نطاق السياق.
في حالة أتمتة المتصفح عمليًا، يعني ذلك أن النموذج يستطيع فحص حالة الصفحة الفعلية مباشرة، والتنقل بين الإطارات، وإنشاء شفرة تفاعل مخصصة للواجهة الحالية، بدلًا من إسقاط كل شيء على مجموعة ثابتة من الإجراءات المنشأة مسبقًا.
يتصرف النموذج بدرجة أقل كأداة اختيار، وبدرجة أكبر كمؤلف لمنطق التشغيل. فهو يفحص الحالة الراهنة، ويستدل بشأن الواجهة، وينشئ منطق التفاعل المناسب لذلك الموقف تحديدًا. ويمكنه بناء تسلسلات متعددة الخطوات، والتكيف مع المسارات غير المعتادة، والتحقق من النتائج قبل المتابعة. وعندما يفشل إجراء، يرى النموذج الخطأ الأساسي ويصحح مساره ذاتيًا. هذا النهج أقوى وأكثر خطورة، لكنه أقرب بكثير إلى الطبيعة الحقيقية للمشكلة.
ومن المهم أن إزالة طبقة التجريد لا تجعل النظام أقل انضباطًا. بل تنقل موضع هذا الانضباط.
ينتقل العمل الذي كان يجري ضمن تصميم الأغلفة ومعالجة الحالات الحدّية إلى ثلاثة مواضع: المطالبة، التي تصبح شكلًا من أشكال التدريب التشغيلي؛ وبيئة التشغيل، التي تفرض حدودًا مثل نطاق التنقل والإجراءات الحساسة وسلوك إعادة المحاولة؛ وطبقة التقييم، التي لا تقيّم نجاح المهمة فحسب، بل أيضًا صحة الخطوات الوسيطة. تجريدات هشّة أقل. وأنظمة محيطة أقوى.
من نتائج هذا التحول أن شفرة المنتج غالبًا ما تصبح أبسط، حتى مع ازدياد قدرات النظام ككل. بدلًا من ترميز أنماط التفاعل في أغلفة قابلة لإعادة الاستخدام، ينشئ الوكيل السلوك في أثناء التشغيل. أنت تدير مجموعة صغيرة من العناصر الأولية القوية وبيئة تنفيذ مقيّدة، بدلًا من توسيع نطاق الأدوات المتخصصة ومنطق الحالات الحدّية باستمرار.
يغيّر هذا أيضًا طريقة تعميم النظام. يُعمّم الوكيل القائم على الأغلفة جيدًا على المهام المشابهة للأغلفة التي أنشأتها بالفعل. أما وكيل بيئة التشغيل المقيّدة، فيُعمّم على المهام التي تشترك في بنية تنفيذ أساسية، حتى عندما تختلف الواجهة الظاهرة.
فعلى سبيل المثال، قد يبدو التفاعل مع نموذج بحث أو مسار حجز أو صفحة إعدادات مختلفًا تمامًا على مستوى واجهة المستخدم. لكنها تشترك في العمق في أنماط مثل قراءة الحالة، وتشغيل الأحداث، والتحقق من النتائج، ومعالجة التحديثات غير المتزامنة. ينتقل النظام الذي يعمل على هذا المستوى بين المهام بصورة أكثر سلاسة.
المكوّن القابل لإعادة الاستخدام ليس قائمة الإجراءات، بل قدرة النموذج على فحص الحالة والتصرف بأمان والتحقق من النتائج.
أوضح درس مستفاد من هذا العمل هو أن الموثوقية لا تتحقق بمنح النموذج مزيدًا من الدوال المساعدة. بل تتحقق غالبًا بمنحه عددًا أقل من العناصر الأولية الأقوى، وتقييدها بالطرق المناسبة. تؤدي المساعدة المفرطة إلى ترسيخ افتراضات ثابتة حول كيفية تنفيذ المهمة. تحدّد القيود حدود التشغيل الآمن، وتتيح للنموذج اكتشاف حلول موضعية أفضل.
يتطلب سطح التنفيذ الأقوى أيضًا نموذج أمان أكثر دقة. بمجرد ألا يعود الوكيل مقيدًا بمجموعة صغيرة من الإجراءات المحددة مسبقًا، فإنه يعمل فعليًا مباشرة على برمجيات حقيقية. وهذا يغيّر مستوى المخاطر فورًا.
هناك أربعة اعتبارات ينبغي مراعاتها في التصميم:
كشف البيانات. عندما يتفاعل الوكيل مع واجهات حقيقية، فإنه غالبًا ما يصادف معلومات حساسة. وهذا يتطلب نهجًا منضبطًا لإخفاء البيانات والتحكم في الوصول. يجب ألا تُكشف البيانات إلا عند ضرورتها للتنفيذ، كما يجب التعامل بعناية مع السجلات وآثار التنفيذ حتى لا تصبح قابلية الرصد أكثر أجزاء النظام حساسية.
نطاق التنفيذ. يجب ألا يتمكن الوكيل القوي من العمل دون ضوابط. عمليًا، يعني ذلك تقييد المواقع التي يمكنه الانتقال إليها، والنطاقات التي يمكنه الوصول إليها، والأنظمة المسموح له بالتفاعل معها. وينبغي فرض هذه القيود على مستوى بيئة التشغيل، لا تركها مجرد أعراف ضمن المطالبة.
الثقة في البيئة. قد تتضمن الواجهات الحديثة تعليمات أو محتوى أو مسارات مضللة أو عدائية عمدًا. ويمثل حقن المطالبات عبر محتوى الصفحة سطح هجوم حقيقيًا. يحتاج النظام إلى تسلسل هرمي واضح للتعليمات وفحوص تحقق وشروط إنهاء، لمنع الوكيل من اتباع إرشادات غير مقصودة.
طيف الاستقلالية. لا ينبغي أن تكون جميع الإجراءات مستقلة بالكامل. ففي كثير من بيئات الإنتاج، من المهم التعامل مع الاستقلالية بوصفها طيفًا. يمكن أن يتمتع النظام بقدرة وكيلية عالية في الاستكشاف والتنفيذ، مع استمرار اشتراط الموافقة على فئات معينة من الإجراءات.
المبدأ الأساسي واضح: منح النموذج مزيدًا من القوة يتطلب تعزيز النظام المحيط به. الاستقلالية بلا سياسات ليست جاهزة للإنتاج.
توقفنا عن طرح السؤال: ما إجراءات المتصفح المناسبة التي ينبغي إتاحتها؟
وبدأنا نسأل: كيف نتيح للنموذج فضاء إجراءات كاملًا، وكيف نضع حوله سياسات لبيئة التشغيل تحافظ على أمانه؟
تغيّر إعادة الصياغة هذه ما تعطيه الأولوية. فتقل أهمية تصنيفات الإجراءات واكتمال الأغلفة. وتزداد أهمية سياسات بيئة التشغيل وقابلية الرصد والتقييم على مستوى كل خطوة. لا تغني قدرات النموذج عن تصميم النظام، ولا العكس. كلما تحسنت النماذج، ازدادت أهمية عمل النظام بدلًا من أن تتراجع.
غالبًا ما تنجح وكلاء المتصفح في العروض التوضيحية لأن المهمة محدودة والبيئة متعاونة. أما أنظمة الإنتاج فتتطلب شيئًا مختلفًا: تنفيذًا مقيّدًا، وسلوكًا مزودًا بأدوات القياس، وتقييمًا يميّز النتيجة الصحيحة من النتيجة التي تحققت بالمصادفة.
تصميم أقل للأغلفة. وهندسة أكثر للأنظمة.
ورغم تركيزنا على وكلاء المتصفح، فإن ذلك يشير إلى منظور أوسع لاستخدام الحاسوب بوصفه تخصصًا في هندسة الأنظمة.