GPT-6.1 Terra وComputer Use: ابنِ دورة أفعال محروسة

GPT-6.1 Terra هو نموذج OpenAI الجديد الموجّه للكفاءة في Visual Reasoning وComputer Use والكتابة الواضحة. يفيد الفرق التي تحتاج فحص الشاشات أو مقارنة الصور أو تشغيل البرمجيات بكثافة، لكن النمط الإنتاجي الآمن ليس «أعطِ النموذج Browser وثق بالنتيجة». وجّه إليه المهام المناسبة فقط، وشغّل كل Action داخل بيئة معزولة، وافحص كل فعل مقترح بسياسة برمجية، واطلب موافقة بشرية للخطوات المؤثرة، ثم تحقق من الحالة النهائية عبر مصدر موثوق قبل إعلان النجاح.

يغطي المقال الإصدار المعلن في 26 أكتوبر 2026 ووثائق API التي تم التحقق منها في 27 أكتوبر 2026. المواصفات والأسعار حقائق موثقة. أما أرقام Benchmarks وFactuality فهي نتائج أعلنتها OpenAI وليست ضمانًا مستقلًا. معمارية التنفيذ المحروس أدناه تحليل هندسي.

الخلاصة أولًا

استخدم GPT-6.1 Terra للأعمال البصرية والمكتبية المحدودة التي يهم فيها الزمن والتكلفة: استخراج بيانات من فاتورة، مطابقة صور المنتجات، فحص Dashboard، الكتابة من مادة بصرية، أو تنفيذ Workflow قصيرة داخل تطبيق مضبوط. احتفظ بـGPT-6.1 Sol أوAstra للبرمجة الأصعب والتخطيط طويل المدى، واستخدم Luna للقرارات الضيقة المتكررة عندما لا تحتاج رؤية أوتفاعلًا مع Desktop.

قبل وصول أي Action إلى Browser أوDesktop، طبّق أربع بوابات:

1. صادق على هدف العمل المطلوب؛
2. قيّد البيئة والحسابات وDomains والأفعال المتاحة؛
3. أوقف التنفيذ لموافقة بشرية قبل الأفعال غير القابلة للعكس أوعالية الأثر؛
4. اقرأ الحالة النهائية من مصدر Authoritative.

النموذج يقترح، وتطبيقك يقرر وينفذ ويثبت.

ماذا أطلقت OpenAI فعليًا؟

أضافت OpenAI النموذج gpt-6.1-terra إلى Responses API وChat Completions في 26 أكتوبر. تصف صفحة النموذج Context Window بحجم 1,050,000 Token، وحد Output يصل إلى 128,000 Token، وKnowledge Cutoff في 1 يونيو 2026، وReasoning Effort من none حتى max. استدعاء Tools يتطلب Responses API.

تسجل الأسعار القياسية للـShort Context مبلغ 1 دولار لكل مليون Input Token، و5 دولارات لكل مليون Output Token، و0.05 دولار لكل مليون Cached Input Token. هذه قيم الوثائق الحالية وليست ضمانًا دائمًا؛ إذ قد تغيّر Regional Processing وService Tiers وLong Context التكلفة الفعلية.

تقول OpenAI إن سعر Terra القياسي أقل 50% من GPT-5.6 Terra وGPT-6.1 Sol. كما تعرض نتائج أعلى في تقييماتها للرؤية وComputer Use، وأخطاء Fact أقل من GPT-5.6 Terra على تقييم داخلي. هذه النتائج سبب للاختبار وليست تفويضًا للترحيل التلقائي. وتوضح System Card أن ظروف البحث أوAPI قد تختلف عن ChatGPT الإنتاجي بسبب اختلاف Prompts وTools وإعدادات Reasoning.

اختر Terra حسب Workflow لا حسب ترتيب النموذج

لا توجّه حسب طول Prompt فقط. سجل Input Modality ومخاطر الفعل والدقة المطلوبة وعدد الخطوات المتوقع والـLatency المقبولة. النموذج الأرخص لكل Token قد يصبح أغلى لكل مهمة مكتملة إن كرر المحاولة أوأنتج Traces طويلة أوتطلب تدخلًا بشريًا مستمرًا.

ابنِ Guarded Computer-use Loop

تتكون الدورة الإنتاجية من Control Planes منفصلة:

هدف المستخدم
  -> فحص الهوية والسياسة
  -> Browser أوDesktop معزول
  -> النموذج يقترح Actions
  -> Validator يسمح أويرفض أويطلب Approval
  -> Executor ينفذ Batch محدودة
  -> Screenshot + Structured State
  -> Completion Verifier مستقل
  -> Audit Record + النتيجة

يجب ألا يحصل النموذج على Infrastructure Credentials خام أوSession عامة لنظام التشغيل. امنحه Browser Profile قصيرة العمر، وأقل Account Role ممكنة، وNetwork Allowlist. احتفظ بالأسرار داخل Execution Service. وعند الحاجة إلى Login استخدم Trusted Handoff أوToken Exchange بدل إظهار Password في Prompt أوScreenshot History.

تصف وثائق OpenAI دورة تحافظ على البيئة، وتعيد Screenshots، وترسل computer-call output مرة أخرى عبر Responses API. الـDriver لديك هو Security Boundary؛ وعليه فرض سياسة الأفعال قبل كل Click أوKeystroke أوNavigation أوFile Operation.

افحص Actions قبل التنفيذ

حوّل السياسة إلى كود، لا إلى تعليمات قد يسيء النموذج فهمها:

type Decision = "allow" | "deny" | "approve";

function decide(action: Action, ctx: SessionContext): Decision {
  if (!ctx.allowedDomains.has(action.domain)) return "deny";
  if (action.kind === "download" && !ctx.downloadsEnabled) return "deny";
  if (action.kind === "submit" || action.kind === "delete") return "approve";
  if (action.kind === "type" && containsSecret(action.text)) return "deny";
  return ctx.remainingSteps > 0 ? "allow" : "deny";
}

افحص Destination الفعلية لاLabel الظاهرة فقط. زر باسم Continue قد يرسل طلبًا نهائيًا، والرابط قد يعيد التوجيه إلى Domain غير مسموحة، وUpload قد يكشف بيانات شخصية أوConfidential. أعد تقييم السياسة بعد Navigation لأن Origin وسياق الحساب وحالة الصفحة قد تتغير.

افصل Observation عن Proposal وعن Effect

تفشل Computer-use Agents كثيرًا لأن Screenshot تُعامل كدليل وسلطة معًا. احفظ ثلاثة Records مستقلة:

• Observation: Screenshot Hash وURL وAccessibility Snapshot والوقت؛
• Proposal: Model Action وReasoning Effort وResponse ID وPolicy Decision؛
• Effect: نتيجة Executor مع Authoritative Read-back.

مثلًا، ظهور “Invoice saved” على الشاشة لا يكفي. استعلم من Invoice API أو اقرأ Record الناتجة من صفحة موثوقة، وقارن Invoice ID والعميل والمبلغ والحالة. قد تكون Toast قديمة أوخلف Modal أوظهرت قبل Commit في Backend.

احمِ النظام من Indirect Prompt Injection

قد تحتوي أي صفحة أوPDF أوEmail أوصورة خارجية نصًا يطلب من Agent تجاهل المهمة أوكشف البيانات أوفتح موقع آخر. تقول System Card إن تقييمات OpenAI تشمل Indirect Prompt Injection، لكن فريق المنتج يبقى مسؤولًا عن Runtime Boundary.

عامل محتوى الصفحة كبيانات غير موثوقة:

• أبقِ هدف المستخدم وسياسة التطبيق خارج Page Content؛
• امنع Navigation إلى Domains لا تحتاجها المهمة؛
• امنع قراءة Tabs غير المرتبطة وClipboard وLocal Files؛
• احجب Tokens والبيانات الشخصية من Screenshots عند الإمكان؛
• اطلب Approval عندما تطلب الصفحة Credentials أوPayment أوإفصاحًا حساسًا؛
• أنهِ Session إذا خرج التطبيق من Workflow المتوقعة.

تعليمات Prompt مفيدة لجودة المهمة، لكنها ليست Authorization System.

اجعل Approval محددة

موافقة عامة مثل “اسمح لهذا Agent” واسعة جدًا. يجب أن تعرض الموافقة الأثر المعلّق بدقة:

بعد الموافقة اربط Authorization بـAction Digest. إذا تغير المبلغ أوDestination أوPayload تنتهي الموافقة. ولا تسمح لموافقة عرض Record أن تتحول بصمت إلى موافقة Edit أوSubmit.

ضع Budgets وقواعد Recovery

تحتاج كل Run حدودًا للخطوات وWall Time وTokens وDownloads وUploads والآثار الخارجية. أوقف Agent إذا دار بين الصفحات أوكرر Action فاشلة. احفظ Checkpoint تمثل Workflow State، لاBrowser Memory فقط، حتى يبدأ Recovery من حالة Business معروفة.

استخدم Idempotency Keys للآثار المدعومة بـAPI. وفي الأنظمة المعتمدة على Browser فقط، أنشئ Client Reference يمكن البحث عنها قبل Retry. بعد Timeout افحص الحالة الموثوقة قبل ضغط Submit مجددًا؛ فقد يكون الفعل الأول نجح بينما ضاعت Response.

قيّم Trajectory كاملة

لا تقيم الإجابة النهائية فقط. ابنِ Suite من مهام كاملة ممثلة للإنتاج مع Expected States وProhibited Actions:

أعد تشغيل المهام نفسها على GPT-5.6 Terra وGPT-6.1 Terra بالـReasoning Effort نفسها كما توصي OpenAI. قارن الجودة وعدد Actions ونسبة الإكمال والتكلفة. ثم نفذ Shadow Phase قبل نقل Production Traffic.

خطة ترحيل آمنة

1. احصر Visual وComputer-use Workflows الحالية.
2. أخرج المهام التي يتجاوز أثرها الصلاحية الذاتية.
3. عرّف النجاح والأفعال الممنوعة ونقاط Approval.
4. اختبر النموذجين القديم والجديد على السيناريوهات نفسها والجهد نفسه.
5. شغّل Terra بنمط Shadow دون آثار خارجية.
6. نفذ Canary على حسابات داخلية أوTenants منخفضة المخاطر.
7. راقب Verified Completion وPolicy Blocks والتكلفة وRecovery.
8. وسّع فقط عندما تحقق الأدلة Thresholds الخاصة بالـWorkflow.
9. احتفظ بـRollback فوري للنموذج والمسار.

عند ترحيل Tool Calls من Chat Completions توجه OpenAI المطورين إلى Responses API. تعامل معها كـContract Migration: اختبر Response IDs وTool-call Parsing وImage Inputs وReasoning Settings وRetries وRetention Behavior بدل تغيير اسم النموذج فقط.

Best practices

• ابدأ بـmedium Reasoning Effort وارفعه فقط عندما تثبت القياسات أن الجودة تستحق زمنًا وTokens إضافية.
• وجّه حسب مخاطر Workflow وModality لاحسب Label «أفضل نموذج».
• نفذ داخل Sessions معزولة وقصيرة العمر وLeast-privilege Identities.
• طبق Allowlists وقواعد Approval في Driver.
• تحقق من Side Effects عبر Authoritative Read-back.
• احتفظ بـObservations وProposals وDecisions وEffects للتدقيق.
• قس Cost per Verified Outcome لاPrice per Token فقط.
• اختبر Indirect Prompt Injection بصفحات ووثائق واقعية.

Anti-patterns

• منح Agent Browser Profile لموظف حقيقي.
• وضع الأمن كله في System Prompt.
• السماح بكل Domains لأن الصفحة الأولى موثوقة.
• اعتبار Screenshot أوSuccess Toast إثباتًا للإكمال.
• Retry لزر Submit دون فحص النجاح السابق.
• إرسال كل المهام إلى Terra لأن Token Price أقل.
• تكرار نتائج OpenAI التسويقية كضمانات مستقلة للمنتج.

الخلاصة التنفيذية

يجعل GPT-6.1 Terra الأعمال البصرية والمكتبية عالية الحجم أكثر قابلية اقتصاديًا. لكنه لا يلغي العمل الهندسي الصعب: Identity وIsolation وPolicy وApprovals وIdempotency وVerification وEvaluation. تبنَّ Terra عندما تستفيد Workflow مقاسة، وأبقِ Control Plane في التطبيق—لا في النموذج—مسؤولة عن كل أثر خارجي.

اقرأ أيضًا: توجيه GPT-6.1 Sol في الإنتاج، وتقييم MCP Agents كاملة، وArtifact Workflows في OpenAI Agents API، ومركز AI وRAG وVector Search، وخدمات Applied AI.

المراجع الأساسية

• OpenAI — Introducing GPT-6.1 Terra
• OpenAI API — GPT-6.1 Terra model
• OpenAI API — Using GPT-6
• OpenAI API — Computer use
• OpenAI API — Pricing
• OpenAI Deployment Safety Hub — GPT-6.1 Terra addendum
• Wikimedia Commons — Modern office workspace featuring a computer
• Creative Commons Attribution 2.0

إعداد: Noor Yasser