أتمتة المتصفح عبر Kitesurf WebMCP: دليل تطبيقي
أتقن أتمتة المتصفح عبر Kitesurf WebMCP، بدءًا من ربط الأدوات واكتشاف الإجراءات وصولًا إلى تنفيذها والتحقق من النتائج وبناء مسار بديل آمن للإنتاج.

يتيح Kitesurf الآن للوكيل أن يسأل موقع الويب عن الإجراءات التي يوفّرها، ويستدعي الإجراء المطلوب بالاسم، ثم يتحقق من النتيجة من دون تخمين الزر الذي ينبغي النقر عليه. أما الفرق الهندسية التي تعتمد على نصوص هشة في أتمتة المتصفح، فالخيار العملي هو استخدام إجراءات WebMCP المنظّمة حين تكون متاحة، مع الإبقاء على مسار بديل مقصود لبقية الحالات. أضافت Cloudflare هذا الدعم في 28 سبتمبر 2026؛ لذلك لم يعد السؤال المفيد هو ما إذا كان Kitesurf يستطيع رؤية أدوات WebMCP، بل ما إذا كان فريقك قادرًا على الاتصال بها وفحصها وتشغيلها والتحقق منها بأمان.
الخلاصة: كيف تبدأ أتمتة المتصفح عبر Kitesurf WebMCP؟
لاستخدام Kitesurf WebMCP، صِل وكيلًا متوافقًا مع MCP بخدمة Cloudflare Browser Run عبر Chrome DevTools MCP، ووجّه نقطة WebSocket إلى browser=kitesurf، ثم فعّل فئة أدوات WebMCP التجريبية. عندها يحصل الوكيل على أمرين أساسيين: list_webmcp_tools لاكتشاف إجراءات الصفحة، وexecute_webmcp_tool لتنفيذ أحدها.
ابدأ بإجراء يقتصر على القراءة أو يمكن التراجع عنه. ويُعد Cloudflare Radar هدفًا موثقًا مناسبًا، لأنه يتيح إجراءات مثل navigate-to وset-location. افحص المخطط الذي يعيده Kitesurf، ولا تمرّر سوى الوسائط التي يقبلها هذا المخطط، ثم قارن النتيجة المنظّمة بحالة الصفحة الظاهرة. لا يُعدّ استدعاء الأداة ناجحًا حتى تتطابق النتيجتان.
هذا الشرح خطة اختبار موثقة، وليس ادعاءً بإجراء اختبار مباشر. لم يتوفر لهذا العمل حساب Cloudflare اختباري أو رمز Browser Run، ولذلك لن تجد أدناه نتيجة نجاح مختلقة.
ما الذي يغيّره Kitesurf WebMCP فعليًا؟
يؤدي MCP وWebMCP وظيفتين مختلفتين. يربط MCP الوكيل بالمتصفح البعيد، بينما يتيح WebMCP لموقع الويب نشر إجراءاته المسماة داخل ذلك المتصفح. يمكن تشبيه MCP بخط الهاتف وWebMCP بقائمة الخيارات على الطرف الآخر: يوصلك الخط إلى الوجهة، وتخبرك القائمة بما يمكن طلبه وما البيانات اللازمة لكل طلب.
من دون هذه القائمة، يقرأ الوكيل الصفحة عادةً، ويعثر على عنصر تحكم، وينقر عليه، وينتظر، ثم يعيد القراءة. أما مع WebMCP، فيستطيع الموقع إتاحة دالة مثل set-location بمدخلات محددة الأنواع. ويظل على الوكيل اختيار الإجراء الصحيح والتحقق من مخرجاته، لكنه لا يعود مضطرًا إلى استنتاج كل تفاعل من وحدات البكسل أو بنية الصفحة.

توضح وثائق WebMCP لدى Cloudflare أن Kitesurf يملك تطبيقه الخاص، ولذلك لا يحتاج إلى جلسة Chrome Lab. ويمكن للصفحات تسجيل أدوات برمجية عبر document.modelContext، كما يتعرف Kitesurf على أدوات النماذج التعريفية التي تحمل السمتين toolname وtooldescription.
ربط عميل MCP بخدمة Kitesurf
ستحتاج إلى Node.js 20.19 أو إصدار أحدث، وعميل متوافق مع MCP، ومعرّف حساب Cloudflare، ورمز API بصلاحية Browser Rendering - Edit. تشرح إعدادات عميل MCP لدى Cloudflare خطوات الضبط في Claude Desktop وClaude Code وCursor وOpenCode. وإذا كانت هذه أول مرة تنشئ فيها اتصال MCP، فسيمنحك دليل أفضل خوادم MCP سياقًا مفيدًا لفهم دور الخادم المحلي.
يقدّم إعلان إطلاق Kitesurf من Cloudflare إعداد العميل المحلي التالي:
{
"mcp": {
"kitesurf": {
"type": "local",
"command": [
"npx",
"-y",
"chrome-devtools-mcp@latest",
"--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
"--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
"--category-experimental-webmcp"
],
"enabled": true
}
}
}استخدم بنية الإعداد التي يتوقعها عميلك، مع الحفاظ على وسيطات الأمر كما هي. واحفظ معرّف الحساب والرمز الحقيقيين ضمن أسرار تُحمّل من متغيرات البيئة، لا في ملف إعدادات يُضاف إلى المستودع. لا تنسخ معاملات Chrome Lab إلى هذا الرابط؛ إذ يستخدم Kitesurf القيمة browser=kitesurf، ولا يحتاج إلى lab=true، ولا يقبل keep_alive.
للخيار الأخير أهمية خاصة. فالعَلَم --category-experimental-webmcp هو الذي يضيف list_webmcp_tools وexecute_webmcp_tool إلى Chrome DevTools MCP. وقد يعمل الاتصال بصورة سليمة تمامًا، بينما يظل أمرا WebMCP غائبين إذا لم تضفه.
تنفيذ مهمة واحدة والتحقق منها على Cloudflare Radar
يثبت أصغر اختبار مفيد أربعة أمور: نجاح الاكتشاف، وإمكانية قراءة المخطط، وإرجاع التنفيذ للبيانات، وانعكاس النتيجة على الصفحة.
- اطلب من الوكيل المتصل فتح
https://radar.cloudflare.com/. نفّذ المهمة داخل حساب اختباري، وتجنب أي إجراء له تبعات مالية أو تدميرية أو تمتد إلى الحساب بأكمله. - استدعِ
list_webmcp_tools. احفظ اسم كل أداة ووصفها ومخطط مدخلاتها. قد تتغير المجموعة المتاحة بعد التنقل أو تنفيذ إجراء آخر، لذا يرتبط هذا الجرد بحالة الصفحة الحالية. - إذا ظهر إجراء آمن مثل
set-location، فاختره واقرأ المخطط الذي أعاده. لا تخمّن أسماء الوسائط اعتمادًا على هذا المقال؛ فالمخطط المباشر هو العقد الذي يجب الالتزام به. - استدعِ
execute_webmcp_toolبقيمة موقع صالحة وفق المخطط. وسجّل اسم الأداة والوسائط والنتيجة المنظّمة والوقت المنقضي وحالة الصفحة الظاهرة بدقة. - قارن الاستجابة بما يعرضه Radar. ثم أعد تشغيل
list_webmcp_toolsبعد تغير الحالة، وسجّل أي إجراءات أُضيفت أو أُزيلت.
يمكن استخدام توجيه مباشر للوكيل مثل الآتي:
افتح Cloudflare Radar. استخدم أدوات WebMCP حين تكون متاحة. اعرض الأدوات الحالية أولًا، وأرني مخطط إجراء آمن لتغيير الموقع، ثم انتظر القيمة التي أختارها ونفّذ الإجراء، واعرض البيانات المعادة بجوار حالة الصفحة الظاهرة. لا تتابع إذا لم تتطابق النتيجتان.

تعامل مع الأدلة كسجل اختبار صغير، لا كسجل محادثة. احتفظ على الأقل بالحقول التالية:
بهذا يتحول العرض التجريبي إلى اختبار يمكن لفريق هندسي تكراره. كما يَفصل فشل WebMCP عن فشل استدلال الوكيل: فإذا غابت الأداة المسماة، تكون الواجهة قد أخفقت قبل التنفيذ؛ وإذا نجح الاستدعاء وخالفت الصفحة النتيجة، يكون الخلل قد وقع في التطبيق أو التحقق بعد التنفيذ.
متى يحتاج Kitesurf إلى مسار بديل؟
لا يشكّل Kitesurf WebMCP طبقة تحكم شاملة في المتصفح. وحدوده الحالية هي التي تحدد مهام الإنتاج الآمنة التي يمكن توجيهها عبره.
- لا تظهر عبر CDP الأدوات المسجلة داخل iframe أو نافذة منبثقة. اعتبرها غير متاحة للوكيل، واستخدم مسار متصفح تقليديًا أو مسارًا بشريًا أو أداة في الصفحة العليا إن كنت تملك الموقع.
- لا تظهر جلسات Kitesurf في
wrangler browser list، ولا توفر عرضًا مباشرًا. لذلك لا يستطيع الوكيل إكمال أداة تتوقف انتظارًا لموافقة شخص. - بالنسبة إلى إجراء يتطلب التأكيد، يتمثل المسار اليدوي الذي توثقه Cloudflare في لوحة WebMCP ضمن قسم Application في ساحة تجارب Kitesurf. هذا تسليم إلى شخص، وليس أتمتة تعمل بلا إشراف.
- لا يطبّق Kitesurf سياسة أذونات
toolsفي WebMCP ولا تصفية الأدوات بحسب المصدر. اكتشاف الأداة لا يعني منح الإذن؛ لذلك احتفظ بقائمة سماح منفصلة للنطاقات والإجراءات وهويات الاختبار. - قائمة الأدوات مرتبطة بالحالة. أعد سردها بعد التنقل أو بعد أي إجراء يغيّر الصفحة، قبل افتراض أن الأداة التالية ما زالت موجودة.

النمط الصادق للاستخدام في الإنتاج هو موجّه يختار WebMCP أولًا عندما يتوفر إجراء مسمى مناسب، وينتقل إلى أتمتة المتصفح التقليدية عند غيابه، ويسلّم المهمة إلى شخص عندما تتطلب موافقة. لا تُخفِ هذه الفروع خلف توجيه متفائل واحد.
الجدوى التجارية في الصيانة، لا في سعر المتصفح وحده
يتوفر Kitesurf مجانًا خلال مرحلته التجريبية وضمن حدود الحساب، لكن Cloudflare لم تؤكد أن أسعار التجاوز العامة المدفوعة لخدمة Browser Run تنطبق على هذه المرحلة المجانية. ويتناول مقال منفصل أسعار Kitesurf وحدود الاستخدام الحالية، بما في ذلك أسباب عدم بناء نموذج تكلفة دائم على عرض تجريبي.
لدى هذا السوق أصلًا ميزانية فعلية لبنية المتصفح التحتية. تعرض Browserbase خططًا مدفوعة بسعر $20 و$99 شهريًا، بينما تعرض Browserless خططًا بسعر $25 و$140 شهريًا عند الفوترة السنوية. تغطي هذه المنتجات احتياجات أوسع للبنية التحتية، لذا لا تعني المقارنة أنها بدائل متكافئة. لكنها تثبت أن الفرق تدفع بالفعل لتشغيل وكلاء المتصفح.
يغيّر WebMCP بندًا آخر في الميزانية: صيانة المحددات، وإعادة المحاولات، ومراجعة المشغّلين. لكنه لا يلغي المتصفح أو النموذج أو ضوابط الأمان أو التحقق من النتائج أو المسار البديل. قِس المهمة نفسها بالطريقتين، وقارن الوقت المنقضي والمحاولات الفاشلة والتدخلات البشرية والإصلاحات الهندسية. لا تحتفظ بـKitesurf إلا حين يكون الانخفاض المقاس في أعباء الصيانة أكبر من جهد الدمج.
سبع حالات استخدام مرتبة بحسب الأكثر استفادة
تفترض كل حالة أدناه أن الصفحة المستهدفة تتيح فعلًا أداة WebMCP مناسبة؛ إذ لا يستطيع Kitesurf ابتكار إجراء غير موجود في الموقع.
تقدّم الحالة الأولى أوسع قيمة، لأن معظم الفرق ستتعامل مع ويب مختلط لسنوات. فالموجّه الذي يعرف متى لا ينبغي استخدام WebMCP أنفع من عرض تجريبي ينجح في صفحة واحدة مُعدّة مسبقًا.
ثلاثة منتجات تستحق البناء
1. موجّه يبدأ بـWebMCP مع مسار بديل
أنشئ طبقة سياسات لفرق الوكلاء تسرد أدوات الصفحة، وتطابق الإجراء الذي طلبه المستخدم مع مخطط مسموح به، ثم توجّه المهمة إلى execute_webmcp_tool أو أتمتة المتصفح التقليدية أو قائمة انتظار بشرية. هذه أقوى فرصة لأنها تعالج فجوة التبني بدل انتظار كل موقع كي يطبّق WebMCP.
الطلب المحيط بهذه المهمة واضح بالفعل: يحصد browser automation نحو 720 عملية بحث شهريًا، بينما يحصد الاستعلام التجاري browser automation tools نحو 260، وتبلغ تكلفة النقرة فيه $34.28. ويحتاج أصغر إصدار قابل للبيع إلى موصل واحد لعميل MCP، وقائمة سماح للنطاقات والإجراءات، ومطابق للمخططات، وسجل تنفيذ، ومهايئ واحد للمسار البديل.
المشكلة هي مدى التغطية. فما زال انتشار WebMCP محدودًا، وقد تتغير مجموعات الأدوات بتغير حالة الصفحة، ولا يستطيع Kitesurf إظهار أدوات iframe أو النوافذ المنبثقة عبر CDP. لذلك يُعد محرك المسار البديل جزءًا من المنتج، لا ميزة اختيارية يمكن إضافتها لاحقًا.
2. مراقب تراجع WebMCP
قدّم لمالكي المواقع فحصًا مجدولًا يسجّل أسماء الأدوات المعلنة ومخططاتها، وينفّذ إجراءً اختباريًا واحدًا يمكن التراجع عنه، ويقارن النتيجة بالصفحة الظاهرة، ثم ينبّه عند وجود اختلاف. يحصد website automation نحو 590 عملية بحث شهريًا، وتبلغ تكلفة النقرة $33.88. أما الاستعلام المفرد المرتبط browser automation tool فقد نما بنسبة 24% على أساس سنوي في بيانات الاقتراحات.
يستطيع الإصدار الأولي مراقبة قائمة قصيرة من المسارات المملوكة باستخدام بيانات اعتماد اختبارية، وتخزين جرد الأدوات قبل التنفيذ وبعده، وإنتاج سجل فشل موجز يضم الوسائط والنتيجة والوقت وحالة الصفحة. لكن التحدي يكمن في الحالة: فقد تعني الأداة المفقودة أن المسار أو حالة الجلسة غير صحيحين، لا أن الإصدار معطل؛ لذا يحتاج المنتج إلى تنقل قابل للتكرار وبيانات اختبار مضبوطة.
3. مدقق جاهزية WebMCP
أنشئ خدمة فحص مسبق لفرق الويب تحدد رحلات العملاء التي تتيح أدوات في الصفحة العليا، والإجراءات الموجودة خلف iframe أو نافذة منبثقة، وتلك التي تتطلب موافقة شخص. ومؤشر الطلب عملي: يحصد playwright browser automation نحو 320 عملية بحث شهريًا، وقد نما بنسبة 129% على أساس سنوي، بينما يحصد website automation نحو 590.
يستقبل أصغر إصدار مسارات موقع مملوك وهوية اختبار، ثم يسرد الأدوات المتاحة ويصنّفها ويصدر تقرير تطبيق مرتبًا بحسب الأولوية. أما القيد الحقيقي فهو قابلية الرصد: بما أن Kitesurf لا يستطيع إظهار أدوات iframe أو النوافذ المنبثقة المتداخلة عبر CDP، فلا يستطيع المدقق استنتاج عقودها المقصودة من Kitesurf وحده. ويلزمه إدخال من مالك الموقع أو طريقة فحص ثانية للتمييز بين الأداة المخفية والأداة الغائبة.
الحدود والخلاصة الصريحة
استخدم Kitesurf WebMCP الآن في المهام المحدودة والقابلة للتراجع، حين يكون الإجراء المنظّم أفضل بوضوح من سلسلة نقرات. ولا تجعله المسار الوحيد لسير عمل حرج، أو تجربة دفع متداخلة، أو مهمة يجب أن تنتظر موافقة بشرية مباشرة.
الميزة قيّمة، لكن إطلاقها يسبق جاهزية المنظومة المحيطة بها. يمكن لنموذج الإجراءات المسماة أن يقلل الالتباس ويسهّل تشخيص الأعطال، لكنه لا يجعل كل موقع مهيأً للوكلاء، ولا يحوّل الحمولة المعادة إلى دليل على أن الصفحة نفذت الإجراء الصحيح. خطوة التحقق هي الحد الفاصل الأهم في المنتج.
كيف أربط عميل MCP بخدمة Kitesurf WebMCP؟
شغّل Chrome DevTools MCP كخادم MCP محلي، ووجّه نقطة WebSocket إلى رابط Browser Run الخاص بحسابك في Cloudflare مع browser=kitesurf، ومرّر رمز Browser Run في ترويسة التفويض، ثم أضف --category-experimental-webmcp.
هل يحتاج Kitesurf WebMCP إلى lab=true أو keep_alive؟
لا. لدى Kitesurf تطبيقه الخاص من WebMCP ويستخدم browser=kitesurf. وهو لا يحتاج إلى lab=true ولا يقبل keep_alive.
لماذا لا يستطيع الوكيل رؤية أداة WebMCP؟
تحقق أولًا من وجود عَلَم فئة WebMCP التجريبية. ثم تأكد من أن الأداة موجودة في حالة الصفحة الحالية. لا تظهر الأدوات الموجودة داخل iframe أو الصفحات المنبثقة عبر اتصال CDP في Kitesurf، وقد تتغير القائمة المتاحة بعد التنقل.
كيف أوافق على إجراء WebMCP ينتظر تدخل شخص؟
لا توفر جلسة وكيل Kitesurf عرضًا مباشرًا، لذلك لا يمكنها إكمال هذا التأكيد. شغّل الإجراء يدويًا من لوحة Application > WebMCP في ساحة تجارب Kitesurf، أو وجّهه إلى مسار منفصل يتحكم فيه شخص.
إذا أردت بناء هذا الاتصال ونظام اختبار التحقق وسياسة المسار البديل لوكيل يعمل في الإنتاج، يمكنني مساعدتك في بناء النظام الإنتاجي.
- آخر تحديث
- 30 سبتمبر 2026
- التصنيف
- Build







