نظرة عامة
تعمل كل مهمة heartbeat كحلقة وكيلية — يتلقى النموذج التعليمات، ويستدعي الأدوات، ويقرأ النتائج، ويستدعي مزيداً من الأدوات، ويكرر ذلك حتى تكتمل المهمة. كل تكرار هو رحلة API كاملة تُرسل السياق المتراكم بأكمله: موجِّه النظام، تعريفات الأدوات، جميع الرسائل السابقة، جميع نتائج الأدوات، وأي صور.
تشرح هذه الصفحة كيف تتراكم التكاليف، وما هي الحدود الصلبة، وكيف تُبقي أتمتاتك فعّالة.
كيف تتراكم التكاليف
عاملان يقودان تكلفة أي تشغيلة:
التكرارات — كل دورة حلقة هي استدعاء API واحد. قد تستغرق مهمة “بحث وتلخيص” بسيطة من 5-10 تكرارات. تستغرق مهمة computer-use (النقر عبر واجهة) عادة 30-60+ لأن كل دورة نقر-لقطة شاشة-تحليل هي تكرار واحد.
تراكم السياق — ينمو سجل الرسائل مع كل تكرار. تبقى نتائج الأدوات (خاصة محتوى صفحات الويب ولقطات الشاشة) في السياق لجميع الاستدعاءات اللاحقة. تشغيلة 60 تكراراً حيث يُضيف كل تكرار ~1K رمز تعني أن التكرار الأخير يُرسل ~60K رمز من السجل المتراكم فوق موجِّه النظام الأساسي.
صيغة التكلفة لكل تكرار هي تقريباً:
cost = (system_prompt + tools + message_history) × input_rate
+ model_output × output_rate
لماذا يهيمن Computer-Use على التكلفة
computer-use هو فئة الأدوات الأكثر تكلفة بفارق كبير. إليك السبب:
- كل لقطة شاشة هي ~85-100K رمز (JPEG مشفّر بـ base64)
- كل إجراء نقر وكتابة وتمرير يتطلب لقطة شاشة للتحقق من النتيجة
- كل تكرار لاحق يحمل جميع لقطات الشاشة السابقة في سجل الرسائل
- يجب على النموذج “رؤية” حالة الشاشة ليقرر إجراءه التالي — لا يوجد اختصار
- لا يمكن ضغط لقطات الشاشة أكثر دون إضعاف قدرة النموذج على قراءة النص وتحديد عناصر الواجهة
تنقسم أتمتة نموذجية تمزج البحث ونشر computer-use كالتالي:
| المرحلة | التكرارات | الأدوات المستخدمة | نمو السياق | حصة التكلفة |
|---|
| البحث | 5-10 | web_search، web_fetch | عالٍ — كل عملية جلب تضيف 10-15K حرف | ~25% |
| الكتابة | 1-3 | file_write | منخفض — يُولّد النموذج النص | ~5% |
| نشر computer-use | 30-50+ | screenshot، click، type، wait | عالٍ جداً — كل لقطة شاشة ~100K رمز | ~70% |
اختيار النموذج
ليست كل أتمتة بحاجة إلى نموذج استدلال متطور. اختر بناءً على الطلب الإدراكي للمهمة:
Claude Opus 4.7 — 5 / 25 USD لكل MTok (إدخال / إخراج)
الأفضل للمهام التي تتطلب:
- استدلال أو تخطيط متعدد الخطوات معقد
- كتابة دقيقة يجب أن تطابق صوتاً/نبرة محددة
- التعامل مع مواقف غامضة أو جديدة
- المهام التي يكون فيها قرار خاطئ مكلفاً (مثل النشر علناً)
Claude Sonnet 4.x — 3 / 15 USD لكل MTok (إدخال / إخراج)
الأفضل للمهام التي تتطلب:
- بحث وتلخيص مُهيكل
- كتابة قائمة على القوالب (تنسيقات املأ الفراغ)
- أتمتة واجهة computer-use (أهداف النقر عادة لا لبس فيها)
- أتمتة يومية روتينية حيث يكون التدفق محدداً جيداً
هذا هو الافتراضي الموصى به لمعظم مهام heartbeat. إنه أرخص 40% من Opus بقدرة استخدام أدوات قابلة للمقارنة.
Claude Haiku 4.5 — 1 / 5 USD لكل MTok (إدخال / إخراج)
الأفضل للمهام التي تتطلب:
- استخراج أو تنسيق بيانات بسيط
- عمليات أداة واحدة (بحث واحد، جلب واحد، انتهى)
- مهام كبيرة الحجم ومنخفضة المخاطر
لا يُوصى به لـ computer-use. قد يكافح Haiku مع تنقل واجهة معقدة واستدلال بصري متعدد الخطوات. التزم بـ Sonnet أو Opus لأي سير عمل يقود متصفحاً.
DeepSeek V4 Pro — 0.435 / 0.87 USD لكل MTok (إدخال / إخراج)
الافتراضي الموصى به لمعظم مستخدمي وولف فيش. بعد تخفيض السعر الدائم بنسبة 75% (مايو 2026)، يقدم DeepSeek V4 Pro أداءً وكيلياً حدودياً بتكلفة أقل بـ 29–34 ضعفاً من Opus 4.7 أو GPT-5.5 على أحمال الإخراج، و~11 ضعفاً على الإدخال. الرموز المخزّنة مؤقتاً تكلف 0.003625/MTok—مجانيةعملياً.مرخّصبـMIT،فيمكنكاستضافتهذاتياًبتكلفة0 إن كانت لديك البنية التحتية.
الأفضل لـ: كل شيء عدا computer-use. البحث، استدعاء الأدوات، الكتابة، الأتمتة متعددة الخطوات — كلها بجزء بسيط من التكلفة. أكثر طريقة فعّالة من حيث التكلفة لتشغيل وولف فيش يومياً.
نماذج OpenAI
تتبع نماذج OpenAI نفس النمط — GPT-5.5 بسعر 5/30 USD لكل MTok هو الأحدث، GPT-4o بسعر 2.50/10 USD لكل MTok مقارب لتسعير Sonnet، بينما نماذج o3/o4 بسعر 10-15/40-60 USD لكل MTok هي نماذج استدلال متميزة. يوفّر التخزين المؤقت التلقائي للبادئة في OpenAI خصماً 50% على رموز الإدخال المخزّنة دون الحاجة إلى أي تكوين.
النماذج المحلية (Ollama)
تكلفة API صفرية ولكنها أبطأ بكثير، وتفتقر إلى موثوقية استخدام الأدوات، ولا يمكنها تنفيذ computer-use. مناسبة للتلخيص أو توليد المسودات دون اتصال — وليس لسير عمل مستقل متعدد الأدوات.
التكاليف المتوقعة حسب نوع الأتمتة
تفترض هذه التقديرات Claude Sonnet 4.x مع تفعيل التخزين المؤقت للموجِّه. مع DeepSeek V4 Pro، اقسم هذه التكاليف على ~29–34 ضعفاً على أحمال الإخراج.
| نوع الأتمتة | التكرارات | التكلفة المقدّرة | ملاحظات |
|---|
| بحث ويب واحد + تلخيص | 3-5 | 0.01-0.05 USD | سياق ضئيل، سريع |
| بحث متعدد المصادر + تقرير | 10-20 | 0.50-2.00 USD | عمليات جلب متعددة تُنمي السياق |
| بحث + كتابة + حفظ ملف | 15-25 | 1.00-3.00 USD | الكتابة تضيف رموز إخراج |
| بحث + كتابة + نشر عبر API | 15-25 | 1.00-3.00 USD | نفس التكلفة عند استخدام API مباشر |
| بحث + كتابة + نشر عبر computer-use | 40-70 | 5.00-15.00 USD | لقطات الشاشة تهيمن على التكلفة |
| مهمة computer-use خالصة (تعبئة نموذج، تنقل في واجهة) | 20-50 | 3.00-10.00 USD | تعتمد على تعقيد الواجهة |
| معالجة ملف بسيطة (قراءة، تحويل، كتابة) | 3-8 | 0.05-0.50 USD | سياق ضئيل |
| عمليات Git (commit، PR، فرع) | 5-15 | 0.10-1.00 USD | نتائج الأدوات صغيرة |
التخزين المؤقت للموجِّه
يستخدم كل من Anthropic وOpenAI تخزيناً مؤقتاً قائماً على البادئة. تُخزّن API أطول بادئة مطابقة من طلبك (موجِّه النظام، الأدوات، الرسائل المبكرة) وتفرض سعراً مخفضاً للجزء المخزّن في الاستدعاءات اللاحقة. التخزين المؤقت هو أهم رافعة تكلفة على الإطلاق — تشغيلة 60 تكراراً مخزّنة بشكل جيد تكلف أقل بـ 5-10 أضعاف من تشغيلة يكسر فيها التخزين المؤقت كل تكرار.
Anthropic
| السعر |
|---|
| كتابة في التخزين المؤقت | 1.25x سعر الإدخال الأساسي (علاوة 25% على أول كتابة) |
| قراءة من التخزين المؤقت | 0.10x سعر الإدخال الأساسي (خصم 90% على الإصابات) |
| TTL | 5 دقائق كحد أدنى (يُمدد تلقائياً عند الاستخدام) |
OpenAI
| السعر |
|---|
| كتابة في التخزين المؤقت | 1.0x سعر الإدخال الأساسي (بدون علاوة) |
| قراءة من التخزين المؤقت | 0.50x سعر الإدخال الأساسي (خصم 50%) |
| تلقائي بالكامل — لا حاجة لأي تكوين |
ما يكسر التخزين المؤقت
- أي تغيير في موجِّه النظام قبل نقطة فاصل التخزين المؤقت يُبطل كل شيء بعده
- تغيير تعريفات الأدوات بين الاستدعاءات يكسر سلسلة التخزين المؤقت
- إعادة ترتيب الرسائل يكسر مطابقة البادئة
يضع موجِّه نظام وولف فيش المحتوى المتقلب (عداد التكرار، عدد الأدوات) في النهاية تماماً، بعد كل المحتوى المستقر. يضمن هذا أن تظل أقسام الهوية والتعليمات والأدوات والذاكرة والمهارات مستقرة في التخزين المؤقت عبر التكرارات.
ضغط السياق
يضغط وولف فيش سجل الرسائل تلقائياً لمنع فيضان السياق. يستخدم النظام دفاعاً من ثلاث طبقات:
- تقدير الرموز المحافظ (1.5 حرف/رمز) يلتقط معظم حالات الفيضان قبل حدوثها
- المعايرة عبر عدد الرموز الفعلي من استجابة النموذج السابقة تلتقط الحالات التي يكون فيها التقدير متفائلاً
- إعادة المحاولة عند خطأ فيضان 400 تفرض الضغط وتُعيد المحاولة إذا قلّلت كلتا الطبقتين من التقدير
يعمل الضغط مرة واحدة قبل كل تكرار لنموذج اللغة — عندما يتجاوز السياق الميزانية، تُلخَّص الرسائل القديمة بنموذج اللغة في دفعات متوازية من 7. يعمل ضغط قسري أيضاً كمسار استرداد إذا أرجع النموذج خطأ فيضان سياق 400.
الضغط ضروري للمهام الثقيلة — مهمة قراءة 41 إيميلاً تستخدم ~541 ألف رمز بعد 15 قراءة، وستتجاوز ميزانية 967 ألف بدون الضغط. المقابل هو وقت الساعة: يضيف الضغط 3-9 دقائق لكل جولة لأن كل رسالة تُلخَّص بنموذج اللغة.
القيود الصلبة
هذه قيود حالية حتى مايو 2025. بعضها مخطط لتحسينه.
- نافذة السياق هي السقف الصلب. تشغيلة تتراكم فيها رموز أكثر من نافذة سياق النموذج ستُحفّز الضغط. الدفاع ذو الثلاث طبقات يتعامل مع معظم الحالات، لكن الجلسات الطويلة جداً مع العديد من نتائج الأدوات الكبيرة ستقضي وقتاً كبيراً في جولات الضغط. كل جولة تتطلب استدعاءات نموذج لغة لتلخيص الرسائل، مما يضيف 1-9 دقائق حسب حجم المحتوى وسرعة المزود.
- لا يوجد اختيار نموذج لكل مهمة بعد. تستخدم جميع مهام heartbeat حالياً النموذج المُكوَّن في الإعدادات. تدفع مهمة بحث فقط ومهمة نشر computer-use نفس السعر لكل رمز. تجاوز النموذج لكل مهمة ميزة مخطط لها.
- لا تصفية قدرات لكل مهمة. تُحمَّل جميع قدرات الأدوات لكل مهمة. مهمة لا تحتاج إلا إلى
web_search وfile_write لا تزال تحمل تعريفات الأدوات لـ computer-use وgit وnotion وغيرها. النفقات صغيرة (~7K رمز، مخزّنة) لكنها ليست صفراً.
- التخزين المؤقت قائم على البادئة فقط. إذا تغيّرت رسالة مبكرة (مثلاً، تم تعديل نتيجة أداة)، يُبطل كل شيء بعدها في سلسلة التخزين المؤقت. نظام الضغط مُصمم لتعديل الرسائل القديمة العميقة في البادئة فقط ومن غير المرجح أن تكسر حد التخزين المؤقت النشط.
- لا يمكن ضغط لقطات الشاشة. يتلقى النموذج لقطات الشاشة كصور JPEG بمستوى جودة ثابت. لا توجد طريقة لتقليل تكلفة رموزها دون تقليل الدقة، مما سيُضعف قدرة النموذج على قراءة النص وتحديد عناصر الواجهة.
- تقدير التكلفة تقريبي. قد تختلف التكاليف الفعلية بنسبة ±5% بسبب التقريب على مستوى الطلب وترقية طبقة التخزين المؤقت واختلافات حساب الرموز بين الاستجابة المتدفقة ونظام الفوترة.
التوصيات
تنطبق هذه على كل نوع أتمتة. كلما اتبعت المزيد منها، قلت تكلفتك لكل تشغيلة.
استخدم Sonnet للمهام الروتينية
ما لم تتطلب المهمة استدلالاً متطوراً، يُقدّم Sonnet 4.x أداء استخدام أدوات قابلاً للمقارنة بتكلفة أقل بنسبة 40% من Opus. احفظ Opus للمهام عالية المخاطر حيث تهم جودة الحكم — المنشورات العامة، التنسيق المعقد، المواقف الغامضة.
فضّل تكاملات API على computer-use
إذا كان للخدمة الهدف API (أو خادم MCP)، فاستخدمه. يكلف منشور LinkedIn API أقل من دولار مقابل حوالي 10 دولارات عبر computer-use. ينطبق نفس المنطق على Slack والبريد الإلكتروني وGitHub وNotion — أي شيء له تكامل مباشر.
حافظ على التعليمات دقيقة
التعليمات الغامضة (“تأكد أن كل شيء يبدو مثالياً”) تجعل النموذج يتحقق بشكل مفرط بلقطات شاشة إضافية وحلقات تمرير. التعليمات المحددة (“خذ لقطة شاشة واحدة للتأكيد، ثم انشر”) تقلل التكرارات.
تجنب حلقات التحقق غير الضرورية
أخبر النموذج بأن يثق بالمحتوى القائم على الملفات بدلاً من التمرير عبر معاينات الواجهة. المحتوى صحيح في المصدر — التحقق البصري من كل سطر هدر.
اجمع البحث قبل computer-use
نظّم المهام بحيث تحدث جميع عمليات البحث على الويب والجلب أولاً (تكرارات خفيفة)، ثم الكتابة، ثم مرحلة computer-use أخيراً. هذا يقلل عدد التكرارات المثقلة بلقطات الشاشة التي تحمل سياق البحث.
راقب لوحة معلومات الاستخدام
تعرض صفحة الإعدادات > الاستخدام تقسيمات الرموز لكل نموذج، ومعدلات إصابة التخزين المؤقت، والتكلفة لكل محادثة. استخدمها لتحديد التشغيلات المكلفة بشكل غير متوقع وضبط التعليمات وفقاً لذلك.
الشيء الأكثر تأثيراً الذي يمكنك فعله هو تجنب computer-use عند وجود API مباشر. كل شيء آخر تحسين على الهوامش. إذا كنت تنشر على خدمة لها تكامل API أو MCP، فإن هذا التغيير الواحد يقطع تكلفتك 5-10 أضعاف.
مستقبل أتمتة المتصفح
computer-use المعتمد على لقطات الشاشة هو فئة الأدوات الأكثر تكلفة في وولف فيش، لكنه أيضاً الأقوى والأكثر عمومية في الغرض. يعمل مع أي موقع، أي واجهة، أي سير عمل — لأنه يقود المتصفح تماماً كما يفعل الإنسان. لا API لتكوينه، لا OAuth لإعداده، لا رمز بوت للحفاظ عليه. يكتب، ينقر، يمرر، ويقرأ الشاشة.
هذا أيضاً ما يجعله أصلياً. من منظور المنصة، لا يوجد بوت — يوجد متصفح حقيقي، جلسة مستخدم حقيقية، حركات فأرة حقيقية، وضغطات مفاتيح حقيقية. تتجاوز الأتمتة المعتمدة على لقطات الشاشة كشف البوتات وتحديات CAPTCHA وحدود معدل API لأنها لا تستخدم أياً من تلك الأسطح. إنه نفس المتصفح الذي تستخدمه يدوياً، يقوم بنفس الإجراءات التي ستقوم بها، فقط أسرع.
استخدم هذا على مسؤوليتك وفهمك للتكاليف الإجمالية. كل لقطة شاشة هي ~85-100K رمز. يمكن أن تكلف جلسة نشر بـ 40 تكراراً 5-15 دولاراً اعتماداً على النموذج. تشغيله يومياً يتراكم. القوة والأصالة تأتيان بسعر حقيقي — في كل من إنفاق API وحقيقة أنك تؤتمت إجراءات على منصات قد يكون لها شروط خدمة تحكم النشر الآلي.
ما نعمل عليه
سيبقى computer-use المعتمد على لقطات الشاشة خياراً من الدرجة الأولى — إنه النهج الأكثر موثوقية والأكثر قابلية للنقل والأكثر “يعمل فقط”. لكننا نبحث بنشاط في بدائل أرخص يمكنها التعامل مع أنماط أتمتة المتصفح الشائعة دون تكلفة الرموز لكل لقطة شاشة:
- أتمتة المتصفح بدون رأس — قيادة نسخة Chromium بدون رأس عبر Playwright أو Puppeteer. لا حاجة للقطات شاشة للتنقل أو تعبئة النماذج أو النقر. يقرأ الوكيل DOM مباشرة، وهو أرخص بأضعاف مضاعفة من تشفير لقطة شاشة. المقايضة: تُكتشف المتصفحات بدون رأس بسهولة أكبر من قِبل أنظمة حماية البوتات، ويفقد الوكيل القدرة على التحقق بصرياً مما يراه.
- حقن JavaScript وفحص DOM — بدلاً من أخذ لقطة شاشة لفهم الصفحة، احقن JavaScript لقراءة مواقع العناصر ومحتوى النص وحالة الصفحة مباشرة. يحصل الوكيل على بيانات منظمة بدلاً من صورة. المقايضة: هشّ إذا تغيرت بنية DOM للموقع، ولا يعمل لمهام التحقق البصري.
- النُهج الهجينة — استخدم فحص DOM للتنقل وإدخال البيانات (رخيص)، ولكن ارجع إلى لقطة شاشة واحدة للتحقق البصري قبل الإجراءات الحرجة مثل النقر على “Post” أو “Submit” (مكلف ولكن آمن). يمكن أن يقطع هذا تكاليف computer-use بنسبة 60-80% مع الحفاظ على فحص الأمان النهائي.
- تكامل إضافة المتصفح — إضافة متصفح مخصصة تكشف حالة الصفحة وحقول النموذج وأهداف الإجراءات للوكيل دون لقطات شاشة. أغنى من بدون رأس، أرخص من computer-use، وربما غير مرئية لكشف البوتات. المقايضة: تتطلب تثبيت إضافة وصيانة.
- قراءة شجرة إمكانية الوصول — استخدام API إمكانية الوصول في المتصفح للحصول على تمثيل منظم للصفحة. مشابه لكيفية عمل قارئات الشاشة. يحصل الوكيل على تسميات العناصر وأدوارها وحالاتها دون أي عرض بصري. المقايضة: ليست كل المواقع تحتوي على ترميز إمكانية وصول جيد.
- جسور خوادم MCP — خوادم MCP مخصصة لأهداف عالية القيمة (LinkedIn، Twitter/X، Slack، Gmail) تغلّف واجهاتها على الويب أو واجهات API في واجهات أدوات نظيفة. يستدعي الوكيل
linkedin_post(content) بدلاً من التنقل في متصفح. المقايضة: كل هدف يحتاج إلى خادم MCP خاص به، وتغييرات API للمنصة قد تكسرها.
ستُضاف هذه النُهج إلى جانب computer-use المعتمد على لقطات الشاشة، وليس كبدائل. تعتمد الأداة الصحيحة على المهمة — متصفح بدون رأس مثالي لتعبئة نموذج، لكن لقطة شاشة حقيقية وحدها يمكن أن تخبرك ما إذا كانت واجهة معقدة قد عُرضت بشكل صحيح. سيقدم وولف فيش جميعها ويتيح لك الاختيار بناءً على تحملك للتكلفة واحتياجات الموثوقية والمنصة المحددة التي تستهدفها.
لا يوجد جدول زمني لهذه بعد. computer-use المعتمد على لقطات الشاشة هو طريقة أتمتة المتصفح الوحيدة المتاحة اليوم. البدائل أعلاه هي اتجاهات بحث نشطة، وليست ميزات شحن. سنوثّق كل واحدة عند توفرها.
