أضافت OpenAI ميزة Computer Use إلى Agents API في 29 سبتمبر 2026. تتيح الميزة للوكيل العمل داخل متصفح تستضيفه OpenAI، بينما يتابع التطبيق المدمج Session Events ويتعامل مع موافقات الوصول إلى المواقع ويمرر مدخلات تسجيل الدخول عند الحاجة. هذا تغير مهم للفرق التي تحتاج Browser Automation من دون تشغيل Browser Runtime بنفسها.
القدرة الأساسية سهلة الوصف، لكن حدود الإنتاج ليست كذلك. يقلل المتصفح المستضاف أعمال البنية التحتية، لكنه لا ينقل تفويض المنتج أو إدارة بيانات الدخول أو سياسة المعاملات أو التحقق من النتيجة إلى النموذج. تبقى هذه مسؤوليات التطبيق. التصميم الصحيح يعامل Computer Use كنظام تنفيذ قابل للاسترجاع والمراقبة، لا كـMacro Recorder أكثر ذكاءً.
التحول المعماري هو تنفيذ مُدار
تقدم Agents API بيئة Codex Harness مُدارة مبنية حول Agents وEnvironments وDurable Sessions وEvents وItems. ولتشغيل Computer Use، ينشئ التطبيق Session تحتوي أداة `computer_use`، ويحدد Environment من نوع `openai_hosted` ويفعّل Desktop. بعد ذلك يتابع التطبيق الأحداث بينما يراقب الوكيل المتصفح ويتفاعل معه.
ينقل ذلك تجهيز المتصفح وإدارة الجلسة واسترجاع البيئة إلى خلف API. وقد يبسّط النماذج الأولية ويزيل مساحة تشغيل كبيرة: Browser Images وDisplay Servers والتحديثات وProcess Supervision ونقل Screenshots. لكن حدود الثقة ما زالت تعبر ثلاثة أنظمة: تطبيق المستخدم، وبيئة الوكيل المستضافة، والموقع الهدف. لكل منها صلاحيات وأنماط فشل مختلفة.
اجعل التطبيق هو سلطة السياسة. يستطيع الوكيل اقتراح التنقل أو التفاعل، وتستطيع البيئة المستضافة التنفيذ، لكن التطبيق يقرر أي Origins يمكن الوصول إليها، وأي هوية يمكن استخدامها، وأي أفعال حساسة، وما الدليل الذي يثبت الاكتمال. إذا عاشت هذه القرارات داخل Prompt فقط فهي إرشاد وليست Enforcement.
موافقة Origin ليست موافقة على المعاملة
يطلب المتصفح موافقة قبل الوصول إلى Origin جديد. يستقبل التطبيق Pending Action، ويعرض Origin والسبب، ثم يرسل Approve أوDeny أوCancel. تحذر وثائق OpenAI صراحة من أن موافقة Origin لا تضمن تأكيدًا قبل كل شراء أو حذف أو فعل ذي أثر.
يجب أن يقود هذا الفرق التصميم. الموافقة على `https://shop.example` تعني أن المتصفح يستطيع الوصول إلى النطاق، ولا تعني أن كل طلب أو Refund أو تعديل حساب عليه مصرح. يحتاج نظام الإنتاج إلى Action Gate مستقلة مدعومة بحالة التطبيق. في الشراء مثلًا قد تتطلب Approved Cart Digest والعملة والإجمالي والتاجر وحد التغير المسموح. وفي تعديل إداري قد تتطلب Resource ID دقيقة وMutation مسموحة.
لا تعتمد على أن الوكيل سيختار طوعًا استدعاء Approval Function في اللحظة الصحيحة. إذا كان التأكيد إلزاميًا، قيد البيئة بحيث لا تستطيع تنفيذ التغيير من دون Capability يصدرها الخادم، أو استخدم Browser Runtime تتحكم فيه مع Interception Point قبل الفعل. يجب أن تكون طبقة الإنفاذ خارج قرار النموذج.
المصادقة تبقى خارج سياق النموذج
يستطيع المتصفح المستضاف طلب تسجيل الدخول عبر Approval Events مخصصة. يعرض التطبيق الحقول أو خيارات المصادقة المطلوبة، ثم يعيد قيم المستخدم عبر Browser-authentication Response المخصصة. ووفق الوثائق، تبقى القيم المرسلة خارج Model Input وتحذف من Authentication Response Items في سجل الجلسة.
هذا الفصل مفيد، لكنه الطبقة الأولى فقط. عامل كل قيمة، بما فيها البريد الإلكتروني، كبيان حساس. أخفِ الحقول، وامنع القيم من Logs وAnalytics، وامسح Local State بعد الإرسال مباشرة، ولا تضع Credentials في Messages عادية أوFunction-tool Results. استخدم أقل حساب وصلاحيات تكفيان للمهمة.
استجابة `202` تعني قبول الإرسال، لا نجاح تسجيل الدخول. يجب أن يواصل التطبيق متابعة الأحداث ويتحقق من حالة المتصفح الناتجة. تصبح Automatic Retries خطرة خصوصًا هنا: عند فقد Acknowledgement تكون النتيجة مجهولة. استرجع Session نفسها وافحص Pending Actions قبل تحديد الحاجة إلى إعادة الإرسال.
صمّم الجلسة كآلة حالات قابلة للاسترجاع
تفشل Browser Automation بطرق ملتبسة: ينقطع Event Stream، أو تنتهي صلاحية موافقة، أو يتأخر التنقل، أو ينجح إرسال بيانات الدخول بينما يفقد Client الإقرار. إعادة المهمة كلها قد تكرر العمل أو تبدأ Mutation ثانية. لذلك يصبح Session ID وحالة Pending Actions بيانات عمل، لا تفاصيل نقل مؤقتة.
استخدم حالات واضحة وCheckpoints دائمة:
CREATED -> RUNNING -> WAITING_ORIGIN_APPROVAL
-> WAITING_AUTHENTICATION
-> VERIFYING_RESULT
-> COMPLETED
-> FAILED_REVIEW_REQUIRED
عند الانقطاع: استرجع الجلسة نفسها، وافحص required_actions،
ثم استأنف Event Stream ولا تعِد إرسال المهمة تلقائيًا.احفظ Session ID وRoot Turn ID وTask Idempotency Key وApproved Origins وPending Request IDs وآخر Event Cursor تمت معالجتها. عند فقد الاتصال قبل الإقرار، سجل النتيجة Unknown. استرجع الجلسة أولًا، ولا تعِد بناء Form إلا للطلبات التي ما زالت Pending. قد تنتهي Authentication Requests، كما أن وجود Response مسجلة لا يثبت اكتمال تسجيل الدخول.
افصل Transport Recovery عن Business Retry. إعادة وصل Event Stream يجب ألا تنشئ Task جديدة. وإعادة فعل تحتاج دليلًا أن المحاولة السابقة لم تُنفذ، أو Destination Operation تدعم Idempotency. إن لم يتوفر أي منهما، توقف للمراجعة بدل التخمين.
نشاط المتصفح Telemetry وليس إثباتًا
تظهر عمليات Computer Use كـActivity Items لها Title وStatus وScreenshot اختيارية. يمكن استخدامها في Progress UI وتشخيص ما بعد التشغيل، لكن اكتمال Activity Item لا يمثل Final Answer ولا يثبت نجاح المهمة كلها. قد يكتمل Click وينتهي إلى معاملة فاشلة أوValidation Message أوRecord خاطئ.
عرّف Outcome Verification قبل التنفيذ. قد تتطلب مهمة قراءة Final URL وقيمة مستخرجة تطابق Schema. وقد تتطلب مهمة كتابة Identifier صادرًا من النظام الهدف وRead-after-write Check وسجلًا دائمًا في التطبيق. في الأعمال عالية القيمة، قارن Postcondition بالنية المعتمدة بدل الوثوق بالسرد النصي.
Screenshots أدلة حساسة. قد تحتوي بيانات حساب أوعناوين أوفواتير أوTokens. ضعها خلف حدود التفويض نفسها الخاصة بالحساب، ولا ترسلها إلى Application Logs العامة، وحدد Retention Period واضحة. فعّل إخراج Screenshots فقط عندما يحتاج المنتج إليها؛ يستطيع الوكيل مراقبة المتصفح حتى عندما لا تعاد الصور في API Output.
استخدم بوابتين مستقلتين للشبكة
يتحكم Network Configuration في البيئة المستضافة بالوجهات الخارجية التي يستطيع المتصفح والكود الوصول إليها. وموافقة Origin قرار منفصل ولا تتجاوز Network Policy. استخدم الاثنين.
يجب أن تكون Network Policy ضيقة ومخصصة للمهمة: اسمح بالتطبيق الهدف والـOrigins اللازمة فقط للموارد أوRedirects. وعلى طبقة الموافقة عرض الوجهة وسبب طلبها بوضوح. ويبقى محتوى الموقع غير موثوق؛ لا يستطيع نص داخل صفحة توسيع الصلاحيات أو استبدال تعليمات المستخدم.
يحد هذا الفصل من أثر Prompt Injection. قد تقنع صفحة خبيثة الوكيل بطلب Origin إضافي، لكنها لا تستطيع الوصول إليه إذا منعته Network Policy. وفي الاتجاه الآخر، لا تلغي Network Policy الواسعة حاجة التطبيق إلى الموافقة على كل Origin. لا يكفي أي من الضابطين منفردًا.
أطلقه بعقد قابل للقياس
ابدأ بمهام Read-only عامة يمكن التحقق من نجاحها آليًا. ابنِ Evaluation Set تشمل Redirects وAuthentication Prompts وصفحات بطيئة وPop-ups وأزرارًا ملتبسة وNetwork Denial وموافقات منتهية وEvent Streams منقطعة. قِس Task Completion وFalse-success Rate والتدخل البشري وزمن الإكمال ونتائج الاسترجاع، لا مجرد حركة المتصفح.
بعد ذلك أضف Authenticated Read Workflows بحساب منخفض الصلاحيات. اختبر ألا تظهر Credentials في رسائل يراها النموذج أوEvents تظهر لمستخدم غير مخول أوLogs. ومرّن Cancellation وSession Deletion والاسترجاع من كل Pending-action State.
لا تنتقل إلى Writes قابلة للتراجع إلا بعد ذلك. ضع Mutations خلف Capability يفرضها التطبيق مع Idempotency Key وPostcondition متحقق منها. وأبقِ المشتريات عالية الأثر والتغييرات التدميرية وعمليات الصلاحيات خارج المتصفح المستضاف ما لم تستطع المعمارية ضمان الموافقة عند Action Boundary.
سجل Model وInstruction Version وAllowed Origins وNetwork Policy وTool Configuration ومعرفات Session وTurn وقرارات الموافقة ونتيجة التحقق. احذف الجلسات المكتملة بعد جلب الأدلة الضرورية فقط. النضج التشغيلي هو القدرة على شرح ما حدث والاسترجاع بأمان، لا إعادة تشغيل المهمة فحسب.
القرار العملي
أهمية Computer Use في Agents API أنها تجمع تنفيذ المتصفح داخل Durable Managed Session فيها موافقات وتسليم آمن لتسجيل الدخول وسجل نشاط واسترجاع. يمكن أن تقصر المسافة من Agent Prototype إلى منتج يعمل. لكنها لا تلغي الحاجة إلى Product Architecture وSecurity Architecture.
استخدمها عندما لا تكون صيانة المتصفح ميزة تميز منتجك، وعندما تستطيع حصر المهام والتحقق منها واسترجاعها. أبقِ التحكم في Network Policy وCredentials وAction Authorization وPostconditions داخل التطبيق. إذا لم يستطع Workflow تحديد المسموح ومعيار النجاح والتصرف بعد نتيجة مجهولة بدقة، فهو غير جاهز لتنفيذ متصفح مستقل.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
