الـ agents اللي بتتحكم في الكمبيوتر (computer-use) دخلت مرحلة جديدة في أبريل 2026: نموذجين كبار تخطّوا مستوى الإنسان في بنشمارك OSWorld. Gemini 3.1 Ultra سجّل 75% و Claude Sonnet 4.6 سجّل 72.5% — مقابل 72.4% هو الـ human baseline. السؤال مش "هل النماذج بقت ذكية"، السؤال بالظبط: "هل بقى ينفع تسلّمها مهمة حقيقية من غير ما تتفرّج عليها كل ثانية؟".
المشكلة باختصار
OSWorld بنشمارك بيقيس قدرة النموذج على إنجاز مهام حقيقية على سطح المكتب: يفتح Excel، يعبّي فورم، يرتّب ملفات، يستخدم الـ terminal. قبل ستة شهور، أحسن نموذج كان يقف عند 45% تقريبًا، وكلنا عرفنا إن computer-use agents لسّه في مرحلة demo. دلوقتي بعد ما عدّينا خط الإنسان، سؤال "هل أستبدل workflow يدوي بـ agent" بقى له إجابة مختلفة — بس مش لكل الحالات.
ليه الرقم ده مهم فعلاً
الـ 72.4% اللي بيمثّل الإنسان في OSWorld مش متوسط مستخدم عادي — دي نتيجة مُقيّمين مدرّبين بيشتغلوا على المهام نفسها بدون ضغط وقت. لما نموذج يعدّي الرقم ده، ده معناه إنه في المهام المغطاة بالبنشمارك (عشرات المهام من أوفيس، تصفح، إدارة ملفات، تطوير) يقدر يسلّم شغل قابل للاستخدام بنفس مستوى الإنسان الماهر، في زمن أقل بكتير.
لكن ركز في الافتراض: البنشمارك بيقيس success rate على مهام محددة ومعزولة. الـ agent اللي بيعدّي OSWorld مش معناه إنه هيشتغل بنفس الكفاءة في بيئتك الإنتاجية. الفرضية إنك بتدور على workflow متكرر، محدد الدخل والخرج، ومش حساس جدًا للدقة المطلقة.
اللي بيحصل فعلاً لما تجرّبه
فيه ثلاث حالات بيظهر فيها الفرق الحقيقي بين agent و سكربت تقليدي:
- تعبئة بيانات متكررة من PDF لنظام CRM: مهمة بتاخد 4 دقائق يدوي. الـ agent بينجزها في 35 ثانية بدقة قريبة من 94% على عيّنة 50 ملف. الباقي محتاج مراجعة بشرية سريعة.
- ترتيب مجلد Downloads فيه 300 ملف: بدل Python script تكتبه أنت، بتقوله "رتّب دول حسب النوع والتاريخ". الـ trade-off: أبطأ (دقيقتين)، بس صفر كود وصفر صيانة.
- اختبار UI قبل deploy: بدل Playwright script، بتقول "افتح الصفحة، جرّب اللوجين، اتأكد إن الـ dashboard بتظهر". شغل QA يدوي بقى automated من غير ما تكتب selectors.
trade-offs مش بتتقال في الإعلانات
- التكلفة لسّه مرتفعة: استدعاء واحد كامل لـ computer-use flow متوسط بيكلّف $0.15 إلى $0.40. لو هتشغّله 1000 مرة في اليوم، ده $150–$400 يوميًا. احسب الـ ROI مقابل أوتوميشن تقليدي قبل ما تلتزم.
- الزمن: الـ agent أبطأ من سكربت مخصص بـ 5–20 مرة. لو المهمة بتتعاد آلاف المرات، اكتب كود. لو بتتعاد عشرات أو مئات، agent أرخص من حيث وقت التطوير والصيانة.
- الأمان: agent بيتحكم في الماوس والكيبورد (أو في VM) يقدر نظريًا يعمل أي حاجة. شغّله في sandbox بصلاحيات محدودة، مش على لاپتوپك الشخصي اللي فيه SSH keys و .env files.
- الـ determinism: نفس الـ prompt ممكن ياخد مسارات مختلفة شوية بين run والتاني. لو المهمة بتطلب reproducibility مطلقة، ده مش اختيارك.
مثال تنفيذي — شغّل agent في عشر دقائق
لو عايز تجرّب الفكرة بنفسك على Claude (نفس المنطق ينطبق على Gemini بـ SDK مختلف)، ده أقل setup ممكن في بيئة آمنة:
# 1) شغّل sandbox container — ده بيعزل الـ agent عن جهازك
docker run -it --rm \
-p 5900:5900 -p 8080:8080 \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
ghcr.io/anthropics/computer-use-demo:latest
# 2) افتح http://localhost:8080 وادخل الـ task
# مثال واقعي:
# "افتح invoices.csv من سطح المكتب، اجمع عمود total،
# واكتب الناتج في cell D1، وبعدين احفظ الملف"
# 3) في الـ production flow، استخدم الـ SDK مع حد أقصى للخطوات:
python run_agent.py \
--task-file tasks/invoice-sum.txt \
--max-steps 15 \
--model claude-sonnet-4-6 \
--timeout 180
ركز على --max-steps 15 و --timeout 180: دول حدود أمان. لو الـ agent دخل في loop، بيقف بدل ما يحرق credits أو يفضل يضغط على حاجة غلط لحد ما يكسر شيء.
متى لا تستخدم هذه الطريقة
computer-use agents ما ينفعوش في الحالات دي:
- مهام بتتعاد آلاف المرات يوميًا — اكتب سكربت مخصص، هيكون أسرع بـ 10x على الأقل وأرخص.
- مهام تعتمد على timing دقيق (مثل trading أو real-time) — الـ agent مش deterministic بما يكفي.
- بيئات فيها بيانات حساسة بدون sandbox — الخطر أكبر من المكسب.
- مهام لها API رسمية — استخدم الـ API مباشرة، متروحش من الـ UI وتاخد خسارة في السرعة والدقة.
- workflow غير مستقر والواجهة بتتغير كل أسبوع — الـ agent بيتعامل لكن بتكاليف إعادة تشغيل عالية.
الخطوة التالية
اختار workflow واحد بتعمله يدوي أكتر من 3 مرات في الأسبوع ومحدش فكر يأوتوميته لإنه معقّد شوية أو الواجهة بتاعته متغيّرة — زي "أسحب تقرير من dashboard، اعمله screenshot، ارفعه في قناة Slack". جرّب computer-use demo الأسبوع ده، قِس الوقت والتكلفة على 20 run، وقارنهم بوقتك اليدوي. لو الناتج إيجابي، ابنِ عليه. لو سلبي، جرّب سكربت تقليدي قبل ما تستسلم للخيار اليدوي.