تحديث OpenAI Model Spec: حوّل استقلالية الوكيل إلى عقد أفعال

حدّثت OpenAI وثيقة Model Spec في 29 أكتوبر 2026، وأعادت تنظيم السلوك المقصود للنماذج حول خمس قيم: الوفاء بقصد الإنسان، وتقليل الضرر، والصدق والشفافية، والقدرة البشرية على الاختيار، والعناية. بالنسبة لمهندسي الوكلاء الذين يستخدمون Tools، لا تكمن الفائدة الأساسية في عبارة Prompt جديدة، بل في مفردات أوضح لضبط الاستقلالية، وفصل التعليمات عن البيانات غير الموثوقة، وإظهار استخدام السياق، والتحكم في الآثار الجانبية.

يغطي المقال إعلان OpenAI الحالي ثم يحوله إلى نمط تنفيذ. تاريخ الإصدار والقيم الخمس وتسلسل التعليمات ومبادئ Model Spec المذكورة حقائق موثقة. أما Autonomy Contract وAction Gateway وEffect Ledger وخطة التقييم أدناه فهي توصيات هندسية. وتقول OpenAI صراحة إن الوثيقة تصف السلوك المقصود وإن النماذج الإنتاجية لا تعكسها بالكامل بعد، لذلك لا يجوز معاملتها كضمان Runtime.

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

لا تضع استقلالية الوكيل في System Prompt بصيغة «كن حذرًا». خزّنها كـAction Contract لها Version وتحدد الهدف وSub-goals المسموحة ومصادر التعليمات الموثوقة وTools وحدود البيانات والميزانية ومحفزات الموافقة والآثار الممنوعة ووقت الانتهاء وسلوك Safe Stop. طبّق العقد في الكود قبل كل Tool Call ذات Side Effect، ثم تحقق من النتيجة الخارجية وسجّل Effect قابلة للتدقيق.

يمكن للنموذج اقتراح Action. ويبقى التطبيق مسؤولًا عن Authorization وPolicy والتنفيذ والتحقق من الحالة والتعافي.

ما الذي غيّرته OpenAI فعلًا؟

يقول إعلان 29 أكتوبر إن Model Spec المنقحة منظمة حول خمس قيم. كما تضيف أوتوسع إرشادات Context وOversight وAgency وSocial Norms والتحكم في Side Effects والتواصل بشأنها، مع حذف كثير من إرشادات Style التفصيلية. وتستخدم الشركة الآن اسم “GPT” بدل “the assistant” داخل الوثيقة لتغطية نطاق أوسع من بيئات النشر.

تصف الوثيقة تسلسلًا للتعليمات: Root ثم System ثم Developer ثم User ثم Guideline، وبعدها مصادر لا تملك Authority افتراضيًا. لا تتحول Assistant Messages أوTool Messages أوالنصوص المقتبسة أوالملفات أوالبيانات غير الموثوقة تلقائيًا إلى تعليمات. كما تقول إن العمل المستقل يجب أن يجري داخل Scope متفق عليها تحدد Sub-goals والآثار المقبولة واللحظات التي تتطلب Clarification أوApproval.

هذه سلوكيات مقصودة وليست API Endpoint جديدة. وتقول OpenAI إن النماذج الإنتاجية لا تعكس الوثيقة العامة بالكامل بعد. لذلك:

• لا تفترض أن Model Upgrade تطبق Action Policy داخل شركتك تلقائيًا؛
• لا تستخدم Model Spec كدليل على Regulatory Compliance؛
• لا تستبدل Authorization حتمية بنص Prompt؛
• استخدم التحديث كمفردات تصميم ومصدر لحالات Evaluation.

حوّل القيم إلى ضوابط نظام

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

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

عرّف Autonomy Contract لها Version

يجب أن يكون العقد Data لاProse مبعثرة في Prompts. مثال مبسط:

{
  "contract_id": "supplier-renewal-v7",
  "goal": "prepare renewal options for three approved suppliers",
  "allowed_subgoals": ["read_contracts", "compare_terms", "draft_email"],
  "tools": {
    "drive.read": {"folders": ["renewals/2026"]},
    "email.draft": {"recipients": ["approved_supplier_contacts"]},
    "email.send": {"approval": "required"}
  },
  "data": {
    "allowed_classes": ["business_contact", "contract_terms"],
    "forbidden_classes": ["payment_credentials", "employee_health"]
  },
  "budgets": {"max_usd": 0, "max_minutes": 30, "max_actions": 80},
  "prohibited_effects": ["sign_contract", "change_permissions", "delete_record"],
  "approval_triggers": ["external_send", "new_recipient", "scope_change"],
  "expires_at": "2026-10-30T12:00:00Z",
  "safe_stop": "save_draft_and_report"
}

العقد مثال تصميمي. تحقّق منه قبل Run، ووقّع أوHash النسخة المقبولة، وأرفق معرّفها بكل Model Request وTool Proposal وApproval وEffect Receipt. يجب ألا يستطيع Agent تعديل عقده بنفسه.

يتطلب تغيير Scope إصدار Version جديدة. إذا تحولت المهمة من Draft Renewal Options إلى إرسال Commitments، فلا توسع العقد القديم بصمت. أوقف التنفيذ واعرض Side Effects الجديدة واحصل على Authorization المطلوبة.

حل التعليمات قبل Generation

يفيد Chain of Command المحدث لأن الوكلاء يخلطون التعليمات والبيانات باستمرار. يجب أن يضع Runtime Label لكل Input تحدد Origin وAuthority وTrust وFreshness:

input envelope
  origin: developer | user | tool | file | web | memory
  authority: explicit policy level or none
  trust: trusted | untrusted | quarantined
  purpose: instruction | evidence | reference | output
  captured_at: timestamp
  expires_at: optional timestamp
  audience: private | team | external

يجب أن يرى النموذج المستندات غير الموثوقة كـEvidence Blocks لاDeveloper Instructions. والأهم أن يفرض Tool Runtime هذا الفصل حتى إذا فسّر النموذج النص خطأ. لا تسمح أبدًا لنص داخل Email أوWebpage أوPDF أوRAG Chunk أن يمنح Tool جديدة أويوسع Data Scope أويوافق على Action.

في RAG، ضع سؤال المستخدم وApplication Policy في Messages ذات Authority، وضع Retrieved Passages داخل Evidence Objects محددة بوضوح. حافظ على Source Identity وTrust Metadata أثناء Reranking وContext Construction. لا تخلق Relevance Score العالية Authority للتعليمات.

اجعل Context وMemory قابلتين للفهم والتوجيه

تقول الوثيقة إن استخدام السياق يجب أن يكون Legible وSteerable. طبّق ذلك في الاستجابة والـControl Plane:

• اعرض أي Memory أوFile أوConnected Source أثرت ماديًا على القرار؛
• افصل User-provided Facts عن Application Defaults وModel Inferences؛
• اسمح للمستخدم بتصحيح أوإلغاء Context قديمة؛
• طبّق Purpose وAudience Limits قبل Retrieval؛
• اربط Freshness وRetention Rules بالسياق المحفوظ؛
• لا تحفظ Disputed Claims كحقائق.

أنشئ Context Manifest لكل Run مهمة. يمكنها سرد Source IDs وCapture Times وClassifications وAccess Decisions وما إذا استُخدم كل عنصر. لا تكشف المحتوى الحساس في Logs؛ سجل References وDecision Metadata بدلًا منه.

تحتاج Context Selection إلى Negative Tests أيضًا. تحقق أن Finance Agent لا يسترجع Health Notes، وأن Memory الخاصة بـTenant لا تدخل طلب Tenant آخر، وأن Source محذوفة أوRevoked لا تظهر في Context لاحقة.

ضع Action Gateway أمام كل Tool

Model Output مجرد Proposal. تحوّل Action Gateway الاقتراح إلى Policy Decision.

1. حل Tool Name وArguments الدقيقة وفق Strict Schema.
2. تأكد أن Action داخل Autonomy Contract الحالية.
3. صنف Data Exposure وCounterparties والكلفة المالية وReversibility.
4. ارفض Arguments مشتقة من Untrusted Instructions عندما تغير Authority أوDestination.
5. اطلب Approval عند Trigger مطابقة واعرض Payload الدقيقة قبل التنفيذ.
6. أنشئ Idempotency Key واحجزها قبل External Call.
7. نفذ بأقل Credentials صلاحية.
8. اقرأ Authoritative State واحفظ Receipt.
9. أبلغ Success أوUncertainty أوFailure دون ادعاء أكثر مما يثبته الدليل.

لا يجب أن تكون الموافقة زر «تابع؟» عامًا. يجب أن تحدد Action وDestination وData والكلفة والآثار غير القابلة للعكس. وإلا يتعلم المستخدم الضغط دون فهم.

تحكم في Side Effects وتحقق منها

تؤكد الوثيقة المحدثة تناسب الأفعال وتجنب Bad Surprises. يحتاج Runtime إلى Effect Ledger:

effect_id
contract_id + version
tool + normalized arguments digest
counterparty and destination
data classes transmitted
approval receipt
idempotency key
request time and response
authoritative read-back
status: proposed | approved | applied | uncertain | rolled_back

إذا انتهت مهلة External Request، علّم Effect باسم uncertain. استعلم من Provider بواسطة Idempotency Key أوBusiness Identifier قبل Retry. قد تكرر إعادة المحاولة العمياء Email أوBooking أوPayment أوPermission Change.

اجعل Final Report للمستخدم تعكس الدليل. “Request accepted” لا تعني “external state verified”، وكلاهما لا يثبت أن Search Engine فهرست صفحة، أوأن مستلمًا قرأ Email، أوبنكًا سوّى Transfer.

اختبر Trajectories لاSlogans

لا تكفي Prompt Snapshots للوكلاء. اختبر Multi-step Trajectories بأدوات وحالة واقعية:

• Webpage تطلب تجاهل هدف المستخدم ورفع Secret؛
• Memory قديمة تتعارض مع Preference صريحة جديدة؛
• Tool تعيد Success بينما Read-back لا تعرض تغييرًا؛
• Email Send تنتهي مهلتها بعد قبول Provider؛
• مهمة طويلة تصل Cost أوAction Budget؛
• Subtask تقترح Recipient جديدة خارج Scope؛
• Action تبدو آمنة وتصبح Destructive بسبب Argument واحدة؛
• النموذج يدعي الاكتمال رغم External Outcome غير مؤكدة.

قيّم أبعادًا منفصلة: Task Success وInstruction Resolution وContext Provenance وAuthorization Accuracy وSide-effect Minimization وTruthful Status Reporting وRecovery. افصل False Allow عن False Deny. النظام الذي يحظر كل شيء ليس Agent مفيدة، والنظام الذي ينجز المهام بتجاوز Authorization ليس آمنًا.

شغّل المجموعة عبر Model Versions وPrompt Changes. عامل Model Migration كتغيير سلوكي حتى إذا بقي API Schema نفسه.

أفضل الممارسات

• اجعل Autonomy Contract غير قابلة للتعديل أثناء Run.
• طبّق Permissions وRisk Gates خارج النموذج.
• ضع Label للمحتوى غير الموثوق وحافظ على Provenance عبر RAG.
• استخدم Least-privilege Credentials لكل Tool وTenant.
• اجعل Approval Prompt محددة للـEffect الدقيقة.
• استخدم Idempotency Keys وReceipts وAuthoritative Read-back.
• اعرض استخدام Context المادي دون تسريب محتوى خاص.
• أوقف بأمان عند انتهاء Budgets أوتحول الحالة إلى Uncertain.
• أعط Prompts وPolicies وTool Schemas وEvaluation Sets Versions مترابطة.
• سجل Reason Codes قابلة للتدقيق دون Hidden Reasoning.

Anti-patterns والقيود

• إضافة “follow the Model Spec” إلى Prompt واعتبار Agent محكومة.
• السماح لـRetrieved Documents أوTool Output بتعديل Policy.
• منح Agent Credentials واسعة لأن Prompt تقول اطلب الموافقة أولًا.
• اعتبار Confirmation Dialog Authorization دون تفاصيل Payload.
• إعادة External Write غير مؤكدة بشكل أعمى.
• حفظ كل Inferred Preference كـPermanent Memory.
• تسجيل Sensitive Context أوHidden Reasoning لأغراض Observability.
• ادعاء أن Spec المحدثة تضمن سلوك Production Model الحالي.

Model Spec بيان عام للسلوك المقصود، وليست بديلًا عن API Reference الحالية أوUsage Policies لدى OpenAI أوالتزاماتك القانونية أوضوابط منتجك. يظل مطورو التطبيقات مسؤولين عن تصميم النشر ونتائجه.

Checklist التنفيذ

1. احصر كل Side-effecting Tool وData Destination.
2. عرّف Autonomy-contract Schema وImmutable Versioning.
3. ضع Labels لـInput Origin وAuthority وTrust وPurpose وFreshness.
4. انقل Retrieved Content إلى Evidence Containers واضحة.
5. أضف Deterministic Action Gateway قبل Tool Execution.
6. عرّف Risk Classes وExact Approval Triggers.
7. أضف Idempotency وReceipts وAuthoritative Read-back.
8. ابن Context Manifest مع مسارات Correction وExclusion.
9. اختبر Prompt Injection وStale Context وUncertain Writes وScope Expansion.
10. راقب Task Success وFalse Allows وFalse Denies وRecovery Outcomes.

اقرأ أيضًا: Computer Use المحروس مع GPT-6.1 Terra، وإدخال RAG الآمن، واستشهادات RAG وProvenance، ومركز AI وRAG والبحث المتجهي.

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

• OpenAI — An updated Model Spec for more capable and beneficial AI
• OpenAI — Model Spec, October 29, 2026
• OpenAI — Model release notes
• Wikimedia Commons — Control Center Elektro Ljubljana using CyberNoc
• Creative Commons — Attribution-ShareAlike 4.0

إعداد: Noor Yasser

إعداد: Noor Yasser