DEV Community

Cover image for استخدام الكمبيوتر مقابل واجهات برمجة التطبيقات المنظمة: متى يكون كل منهما هو الأفضل (2026)
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

استخدام الكمبيوتر مقابل واجهات برمجة التطبيقات المنظمة: متى يكون كل منهما هو الأفضل (2026)

إن تشغيل المتصفح عبر نموذج لغوي كبير (LLM) باستخدام نماذج “استخدام الكمبيوتر” قد يكون أغلى بحوالي 45 مرة من الوصول إلى نفس المورد عبر واجهة برمجة تطبيقات (API) منظمة.

جرّب Apidog اليوم

هذا الدليل يشرح من أين يأتي رقم 45x، ومتى يكون استخدام الكمبيوتر مبررًا، وكيف تصمم مسارًا أسرع وأرخص باستخدام Apidog. ينطبق الإطار على OpenAI Operator، واستخدام الكمبيوتر من Anthropic، وأدوات استخدام المتصفح، وSkyvern، وأي أداة تعتمد على حلقة لقطات شاشة.

إذا كنت تبني APIs لوكلاء الذكاء الاصطناعي، اقرأ أيضًا دليل كيفية كتابة ملفات agents.md، لأن الاتفاقيات هناك تجعل مسار API المنظم هو الخيار الافتراضي للمتصلين بك.

ملخص سريع

  • استخدام الكمبيوتر يعني أن النموذج يرى لقطات شاشة ويصدر نقرات، ضغطات مفاتيح، وتمريرات.
  • واجهات API المنظمة تعني أن النموذج يصدر استدعاءات أدوات JSON ينفذها نظامك الخلفي.
  • لنفس المهمة، يستهلك استخدام الكمبيوتر عادةً من 30 إلى 50 ضعفًا من الرموز بسبب لقطات الشاشة المتكررة وإعادة المحاولة.
  • استخدم استخدام الكمبيوتر فقط عندما لا توجد API، أو عندما تكون API مقيدة، أو عندما يكون سير العمل خلف واجهة قديمة لا يمكن برمجتها بسهولة.
  • استخدم API منظمة للمدفوعات، البحث، تحديثات CRM، الأدوات الداخلية، وأي شيء يمكن وصفه عبر OpenAPI.
  • النمط الواقعي غالبًا هجين: 90% عبر APIs منظمة، و10% عبر استخدام الكمبيوتر للحالات المتبقية.
  • استخدم Apidog لتصميم مخططات أدوات JSON، محاكاة نقاط النهاية، وإعادة تشغيل التدفقات قبل توصيلها بنموذج حي.

لماذا الفجوة في التكلفة كبيرة؟

رقم 45x ليس “معيارًا ذكيًا”، بل نتيجة مباشرة لطريقة استهلاك الرموز في كل مسار.

في مسار API المنظم:

  1. ترسل مطالبة واحدة تحتوي على طلب المستخدم ومخطط الأداة.
  2. يعيد النموذج كائن JSON.
  3. ينفذ وقت التشغيل استدعاء HTTP واحدًا أو أكثر.

النتيجة غالبًا: بضع مئات من رموز الإدخال، عشرات قليلة من رموز الإخراج، وقفزة شبكة واحدة.

أما في استخدام الكمبيوتر:

  1. ترسل المطالبة مع لقطة شاشة.
  2. يعيد النموذج إجراءً مثل click أو scroll أو type.
  3. تنفذ الإجراء.
  4. تلتقط لقطة شاشة جديدة.
  5. تكرر الدورة حتى تنتهي المهمة.

مهمة مثل “حجز رحلة طيران” قد تحتاج من 12 إلى 30 جولة. كل لقطة شاشة قد تكلف تقريبًا 1500 رمز عند دقة نموذجية. أضف إلى ذلك إعادة المحاولة عند النقر الخاطئ، إغلاق لافتات الكوكيز، أو البحث عن عنصر اختفى من الشاشة.

يوثق استخدام الكمبيوتر الخاص بـ Anthropic تسعير رموز لقطات الشاشة علنًا. كما أشار نقاش HN حول أن استخدام الكمبيوتر أغلى 45 مرة من APIs المنظمة إلى عقوبة نموذجية بين 30 و50 ضعفًا، وهو نطاق يتوافق مع إعادة تشغيل نفس المهام عبر المسارين في Apidog.

متى تختار API منظمة؟

ابدأ دائمًا بافتراض أن API المنظمة هي المسار الصحيح إذا تحقق أحد الشروط التالية.

1. المورد يملك مواصفة قابلة للاستهلاك

إذا كان لدى الخدمة:

  • OpenAPI
  • GraphQL schema
  • صفحة REST موثقة
  • شكل JSON معروف

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

2. المهمة نقطة نهاية واحدة أو نقطتان

أمثلة مناسبة لـ APIs المنظمة:

  • إنشاء عميل في Stripe
  • تحديث مرحلة صفقة في HubSpot
  • إرسال رسالة Slack
  • تشغيل إعادة بناء CI
  • جلب مدفوعات فاشلة
  • تحديث سجل في CRM

تشغيل هذه العمليات عبر متصفح يضيف تكلفة وزمنًا دون فائدة هندسية.

3. سير العمل يعمل دون إشراف

وظائف Cron، وwebhooks، وworkers الخاصة بقوائم الانتظار لا يجب أن تعتمد على وكيل يقرر أين ينقر في كل لقطة شاشة.

استدعاء API منظم أكثر حتمية وأسهل في المراقبة.

4. زمن الاستجابة مهم

استدعاء API منظم قد يعود خلال 200 إلى 800ms.

حلقة استخدام كمبيوتر من 15 جولة قد تستغرق من 30 إلى 90 ثانية، وقد تزيد عند إعادة المحاولة.

إذا كان المستخدم ينتظر النتيجة، اختر API.

5. تحتاج إلى الاختبار قبل الإطلاق

يمكنك محاكاة نقطة نهاية JSON خلال ثوانٍ في Apidog. أما محاكاة حلقة لقطات شاشة كاملة فهي أصعب بكثير وتتطلب بيئة متصفح مستقرة.

متى يستحق استخدام الكمبيوتر؟

استخدام الكمبيوتر ليس خطأ دائمًا. لكنه يجب أن يكون خيارًا مقصودًا.

بوابات البائعين القديمة

بعض بوابات المشتريات، الشحن، أو المزايا بنيت قبل REST وتعمل خلف جلسات ASP.NET أو واجهات قديمة بلا API.

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

أدوات داخلية لا يمكنك تعديلها

أمثلة:

  • CRM قديم اشتراه العميل في 2014
  • ERP داخلي
  • لوحة SharePoint
  • بوابة إدارية بلا تكاملات

إذا لم تستطع بناء تكامل ولا توجد ميزانية لـ iPaaS، فقد تكون حلقة لقطات الشاشة حلًا مؤقتًا.

مهام تشغيل لمرة واحدة

مثال: مؤسس يطلب من وكيل “ابحث عن هؤلاء الـ 50 منافسًا وضع النقاط المهمة في Notion”.

إذا كانت المهمة مرة واحدة أو نادرة، فقد تكون تكلفة استخدام الكمبيوتر مقبولة مقارنة ببناء تكامل كامل.

الهندسة العكسية المخالفة للشروط

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

إطار قرار سريع

قبل استخدام الكمبيوتر، مرّر المهمة على هذه الفحوصات:

الفحص إذا كان نعم إذا كان لا
هل توجد API موثقة؟ استخدم API. تابع.
هل يمكنك بناء محول خادم رقيق يغلف نقطة نهاية خاصة؟ ابنِ المحول واكشفه بصيغة JSON. تابع.
هل المهمة لمرة واحدة أو أقل من 100 تشغيل/يوم؟ استخدام الكمبيوتر مقبول. تابع.
هل تقبل تكلفة رموز أعلى بـ 30 إلى 50 ضعفًا كل مرة؟ استخدم الكمبيوتر. توقف. تفاوض على وصول API أو ابنِ تكاملًا.

القاعدة العملية: إذا كان يمكن وصف العملية كـ JSON، لا تشغلها عبر متصفح.

مثال عملي: نفس المهمة عبر API منظمة

لنفترض أن المستخدم يريد: “اعرض مدفوعات الأمس الفاشلة”.

المسار المنظم يجعل الوكيل يستدعي أداة واحدة بدل الدخول إلى لوحة Stripe عبر المتصفح.

import json
from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "list_failed_payments",
        "description": "List failed payments in a date range",
        "parameters": {
            "type": "object",
            "properties": {
                "start": {"type": "string", "format": "date"},
                "end": {"type": "string", "format": "date"}
            },
            "required": ["start", "end"]
        }
    }
}]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "user", "content": "Show yesterday's failed payments."}
    ],
    tools=tools,
    tool_choice="auto"
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"]
    },
    limit=100
)
Enter fullscreen mode Exit fullscreen mode

ما يحدث هنا:

  1. النموذج يختار list_failed_payments.
  2. يملأ start وend.
  3. وقت التشغيل ينفذ استدعاء Stripe.
  4. الوكيل لا يرى لوحة التحكم ولا يحتاج إلى لقطات شاشة.

المسار المقابل باستخدام الكمبيوتر سيكون تقريبًا:

  1. افتح المتصفح.
  2. سجل الدخول إلى Stripe.
  3. التقط لقطة شاشة للوحة.
  4. انقر منتقي التاريخ.
  5. التقط لقطة شاشة.
  6. اختر النطاق.
  7. التقط لقطة شاشة.
  8. ابحث عن فلتر “failed”.
  9. التقط لقطة شاشة.
  10. استخرج القيم من الواجهة.

كل خطوة تضيف رموزًا وزمنًا واحتمال فشل.

تصميم المسار المنظم باستخدام Apidog

السبب الشائع لاستخدام الكمبيوتر ليس أنه أفضل، بل أن الفريق لم يصمم واجهة أدوات نظيفة للوكيل. هنا يأتي دور Apidog.

الخطوة 1: حوّل عمليات الوكيل إلى نقاط نهاية

ابدأ بالعمليات التي يحتاجها الوكيل فعلًا:

  • POST /invoices/search
  • POST /deals/update-stage
  • POST /messages/send
  • POST /payments/failed
  • POST /tickets/escalate

لا تحتاج إلى API ضخمة. بضع نقاط نهاية جيدة التصميم قد تستبدل معظم تفاعلات المتصفح.

الخطوة 2: صمّم المخطط في Apidog

عرّف لكل endpoint:

  • اسم العملية
  • الحقول المطلوبة
  • أنواع البيانات
  • أمثلة الطلبات
  • أمثلة الاستجابات
  • رموز الخطأ

ثم صدّر OpenAPI 3.1 من عرض التصميم.

الخطوة 3: مرّر OpenAPI إلى إطار الوكيل

يمكن استخدام المخطط مع:

  • tools في OpenAI
  • tool_use في Anthropic
  • محمل OpenAPI في LangChain
  • أدوات DeepSeek V4

بهذا يصبح لدى الوكيل استدعاءات دوال واضحة بدل تعليمات نصية عامة.

الخطوة 4: شغّل خادم Apidog الوهمي

استخدم mock server لإرجاع JSON واقعي لكل endpoint.

هذا يسمح لك بتشغيل الوكيل من البداية إلى النهاية دون:

  • لمس الإنتاج
  • إنشاء بيانات حقيقية
  • استهلاك أرصدة نموذج في سيناريوهات غير مستقرة

النمط نفسه مشروح في دليل التطوير القائم على العقد أولًا في Apidog.

الخطوة 5: أعد تشغيل حركة المرور

سجّل طلبات واستجابات الوكيل، ثم قارن:

  • تشغيل ناجح
  • تشغيل فاشل
  • اختلافات الحقول
  • تغييرات الاستجابة
  • نقطة النهاية التي انحرفت

هذا يجعل أعطال “كان الوكيل يعمل بالأمس” قابلة للتشخيص.

الخطوة 6: أطلق المسار

بعد الاستقرار، يصبح مشروع Apidog نفسه:

  • وثائق الواجهة
  • عقد الأداة
  • أساس QA
  • مرجع المراقبة
  • مصدر المخطط الذي يستهلكه الوكيل

النمط الهجين: API أولًا، متصفح عند الضرورة

في الإنتاج، غالبًا ما يكون التصميم الأفضل هجينًا:

  • 90% من العمليات عبر APIs منظمة.
  • 10% عبر استخدام الكمبيوتر للبوابات القديمة أو الأدوات غير القابلة للتكامل.
  • router بسيط يقرر المسار بناءً على اسم العملية.

مثال توجيه كنص نظام:

إذا كان tool_name موجودًا ضمن known_tools، فاستدعِ الأداة المنظمة.
إذا لم توجد أداة مناسبة، سلّم المهمة إلى وكيل المتصفح.
Enter fullscreen mode Exit fullscreen mode

يمكن تطبيق النمط نفسه مع Claude 4.5، وGPT-5.5، وDeepSeek V4. راجع كيفية استخدام واجهة برمجة تطبيقات DeepSeek V4 لشكل الطلب.

راقب المسارين بشكل منفصل:

  • المكالمات المنظمة يجب أن تكون معظم الحجم وأقل تكلفة.
  • استخدام الكمبيوتر يجب أن يبقى احتياطيًا قليل الحجم وعالي التكلفة.
  • إذا بدأ استخدام الكمبيوتر يستهلك الحجم الأكبر، فهذا يعني أن هناك endpoint مفقودة يجب تصميمها.

أخطاء شائعة يجب تجنبها

تخطي المخطط

لا تطلق وكيلًا يعتمد على وصف نصي فقط. مرّر JSON Schema واضحًا. المخططات الصارمة تحسن دقة استدعاء الأدوات وتجعل الأخطاء قابلة للاكتشاف.

السماح للوكيل بتصميم المخطط وقت التشغيل

المخطط واجهة منتج. صممه، راجعه، أصدره بإصدارات، وتعامل مع تغييره كما تتعامل مع API عامة.

المخططات ذاتية التعديل وصفة لانقطاعات الإنتاج.

قياس الرموز بدل التكلفة

رموز الصور في استخدام الكمبيوتر قد تُسعّر بشكل مختلف عن النص. لا تعتمد فقط على لوحة تتبع الرموز. راجع لوحة الفوترة الفعلية لدى المزود.

الخلط بين استخدام الكمبيوتر وRPA

RPA ينفذ نقرات مخططة على عناصر DOM معروفة.

استخدام الكمبيوتر يعيد اتخاذ القرار في كل لقطة شاشة.

الأول أرخص وأكثر تكرارًا، والثاني أكثر مرونة وأكثر تكلفة. إذا كان Playwright أو Puppeteer يكفي، لا تستخدم وكيل لقطات شاشة.

تجاهل زمن الاستجابة

تكلفة الرموز ليست الضريبة الوحيدة. حلقة لقطات شاشة تستغرق 60 ثانية قد تكسر تجربة المستخدم. إذا كان المستخدم ينتظر، فغالبًا تحتاج API.

بدائل قبل استخدام الكمبيوتر

إذا لم تكن هناك API عامة لكن توجد واجهة مستخدم معروفة، فكّر في هذه الخيارات قبل استخدام الكمبيوتر الكامل.

Playwright أو Puppeteer

نصوص المتصفح بدون واجهة رسومية لا تكلف رموزًا لكل تشغيل بعد التطوير.

العيب: تتعطل عند تغير الواجهة، لذلك خصص وقت صيانة.

موصلات Zapier أو Make

إذا كان البائع يوفر موصلًا عبر iPaaS، فقد تكون تكلفة المقعد أقل من بناء تكامل أو تشغيل وكيل متصفح دائم.

APIs خاصة من تبويب Network

بعض لوحات التحكم تتواصل مع endpoints JSON داخلية. يمكنك مراقبتها في DevTools وتوثيقها في Apidog كواجهة شبه مستقرة، مع الانتباه إلى شروط الخدمة والاستقرار.

نستخدم هذا النمط في اختبار واجهة برمجة التطبيقات بدون Postman.

الخلاصة: استخدام الكمبيوتر هو الملاذ الأخير، وليس الافتراضي.

حالات استخدام واقعية

فريق امتثال مالي

استبدل فريق امتثال في fintech تقرير Stripe مكونًا من 6 خطوات عبر استخدام الكمبيوتر بثلاثة استدعاءات منظمة. انخفضت تكلفة الرموز بنسبة 92% وانتقل التشغيل من 41 ثانية إلى 2 ثانية.

وكيل دعم B2B SaaS

احتفظ وكيل دعم باستخدام الكمبيوتر لسير عمل واحد فقط: بوابة مشتريات مورد بلا API. كل شيء آخر انتقل إلى أدوات OpenAPI مصممة في Apidog. انخفض إجمالي إنفاق الرموز من 4200 دولار إلى 310 دولارات شهريًا.

مؤسس منفرد

استخدم مؤسس منفرد استخدام الكمبيوتر مرة واحدة أسبوعيًا لتحديث Notion من ERP قديم. تكلفة 45x على تشغيل واحد أسبوعيًا كانت بضعة سنتات، بينما كان البديل مشروع تكامل لعدة أسابيع. هذه حالة مناسبة لاستخدام الكمبيوتر.

الخلاصة

رقم 45x واقعي بما يكفي ليؤثر على قرار التصميم. افتراضيًا، صمّم واجهة أدوات منظمة في Apidog، ولا تلجأ إلى استخدام الكمبيوتر إلا عندما لا توجد API ويكون التشغيل نادرًا بما يكفي لتصبح تكلفة الرموز مقبولة.

خمس قواعد عملية:

  • استخدام الكمبيوتر يستهلك عادةً من 30 إلى 50 ضعفًا من الرموز مقارنة باستدعاء API منظم مكافئ.
  • endpoint موثق مع JSON Schema يتفوق على حلقة لقطات الشاشة في التكلفة، زمن الاستجابة، والموثوقية.
  • النمط الهجين طبيعي: صمّم معظم العمليات في Apidog، واترك استخدام الكمبيوتر للحالات المتبقية.
  • حاكِ واجهة الأداة قبل توصيلها بنموذج حي.
  • راقب مساري API والمتصفح بشكل منفصل حتى تكتشف الانحراف مبكرًا.

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

الأسئلة الشائعة

هل استخدام الكمبيوتر أرخص من API منظمة؟

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

كيف أحاكي واجهة أدوات JSON لوكيل؟

صمّم endpoints في Apidog، شغّل خادم المحاكاة المدمج، ووجّه الوكيل إلى عنوان mock URL. سيحصل الوكيل على JSON واقعي دون تكلفة رموز. راجع أيضًا أدوات اختبار API لمهندسي ضمان الجودة.

هل يمكن استخدام OpenAPI لاستدعاءات الأدوات في أي نموذج؟

نعم. tools في OpenAI، وtool_use في Anthropic، ونقطة استدعاء الأدوات في DeepSeek V4 يمكنها استهلاك مخططات OpenAPI 3.1. يصدر Apidog المخطط بصيغة مناسبة. راجع كيفية استخدام واجهة برمجة تطبيقات DeepSeek V4.

هل لا يزال GPT-5.5 يدعم استخدام الكمبيوتر؟

تقدم OpenAI استخدام الكمبيوتر عبر Operator وعبر Responses API. ملف التكلفة مشابه من حيث اعتماد المسار على لقطات الشاشة. التوصية هنا تنطبق بغض النظر عن المزود.

ماذا عن Skyvern، واستخدام المتصفح، والوكلاء مفتوحي المصدر؟

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

كيف أعرف أن هناك endpoint مفقودة؟

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

Top comments (0)