ماذا يجب أن يفعل وكيل ذكاء اصطناعي عندما يكون الدليل ناقصاً؟

01 — احتفظ بعدم اليقين

غياب البيانات ليس دليلاً سلبياً.

تبدأ أخطاء أتمتة كثيرة باختصار يبدو بريئاً: الحقل فارغ، إذن الإجابة no. هذا منطق closed-world وقد يكون مناسباً داخل قاعدة بيانات محكومة، لكنه خطر عندما يجمع agent دليلاً من سيرة ذاتية غير كاملة أو موقع أو وصف وظيفة أو مصدر خارجي.

يستخدم OpportunityOS في معماريته العامة تمييزاً open-world: UNKNOWN لا تعني FALSE، وABSENT لا تعني INELIGIBLE. إذا لم تُسجل أهلية عمل في دولة ما فهذا لا يثبت عدم الأهلية. وإذا لم تظهر أداة في مستند واحد فهذا لا يثبت غياب المهارة.

النتيجة العملية: يجب أن ينجو عدم اليقين من normalization. إذا حوّلت طبقة ingestion المجهول إلى false، فكل نموذج لاحق سيرث حقيقة واثقة لكنها مختلقة.

02 — اربط الادعاء بالدليل

Provenance يجب أن تقيد التوليد، لا أن تزيّنه بعد الكتابة.

إظهار citation بجوار نص مولد مفيد، لكن الحوكمة تحتاج invariant أقوى: الادعاء الجوهري لا يُنشأ إلا من حقائق يملك النظام صلاحية استخدامها. في OpportunityOS يمثل Truth Graph ونموذج EvidenceClaim سلطة الحقيقة لادعاءات المؤسس.

يسمح product constitution العام للـCVs والمقترحات والمخرجات الأخرى باختيار الحقائق المتحققة وإعادة ترتيبها وتلخيصها وإعادة صياغتها. لكنه لا يسمح باختراع جهات عمل أو تواريخ أو مسميات أو مهارات أو شهادات أو إنجازات أو نتائج. عندما لا يكفي الدليل، يجب حذف الادعاء أو إحالته للمراجعة.

بهذا تنتقل provenance إلى ما قبل التوليد. لا نسأل بعد الكتابة هل أستطيع العثور على مصدر يشبه الجملة؛ نسأل أولاً أي دليل متحقق يسمح لهذه الجملة أن توجد.

03 — افصل التأهيل عن التخمين

الرفض الصلب يحتاج تعارضاً صلباً.

عندما يرتب agent الفرص قد يغريه تحويل كل unknown إلى عقوبة كي ينتج قائمة مرتبة نظيفة دائماً. النتيجة تبدو حاسمة لكنها قد تستبعد فرصاً لمجرد أن الدليل ناقص.

يفصل OpportunityOS القيود الصلبة عن الترتيب الناعم. hard rejection يحتاج requirement صريحاً مع conflict متحقق أو policy مطبقة. نقص الدليل قد يقلل الثقة أو ينشئ review task أو يبقى unknown، لكنه لا يتحول إلى حقيقة كي يرضي scoring function.

هذا نمط حوكمة عام: عدم اليقين يغيّر الثقة ومسار العمل، لا ontology بصمت.

04 — افصل القدرة عن الصلاحية

القدرة على ملء النموذج ليست إذناً بإرساله.

غالباً يستطيع agent توليد إجابة والتنقل في صفحة والعثور على زر Submit قبل أن يستحق النظام صلاحية إنشاء التزام خارجي. جمع هذه القدرات داخل حد صلاحية واحد خطأ معماري كبير.

لذلك يعلن OpportunityOS ثلاثة أوضاع للفعل. DRY_RUN يعد ويختبر بلا mutation خارجي. ASSISTED يستطيع التنقل والملء والرفع حيث يُسمح لكنه لا يرسل. CONTROLLED_SUBMIT مخصص للأفعال التي اجتازت تدريجاً مستقلاً ومتطلبات pre-submit والصلاحيات المطلوبة.

الفصل يجعل التصعيد مرئياً ويخلق مكاناً واضحاً تتوقف عنده CAPTCHA أو MFA أو إقرار غامض أو شروط تغيرت أو نتيجة سابقة غير مؤكدة، بدلاً من أن يدعو النظام إلى التخمين.

05 — اجعل الأثر غير المؤكد حالة

بعد فعل خارجي غامض لا تفترض الفشل ثم تعاود الإرسال.

الأنظمة الموزعة تعلمنا أن timeout لا يخبرنا هل وقع الأثر البعيد أم لا. workflows الوكيلة ترث المشكلة نفسها. قد تنتهي مهلة طلب submission بعد أن يكون الخادم الخارجي قد قبله؛ إعادة المحاولة عمياء قد تنشئ طلبات أو رسائل أو معاملات مكررة.

workflow محكوم يحتاج حالة uncertain outcome صريحة ومسار reconciliation. يجمّد agent الفعل المتأثر، ويفحص الأدلة الدائمة إن وجدت، ثم يتعافى بصورة مقصودة. عبارة لم أرَ نجاحاً لا تساوي لم يحدث شيء.

هذا شكل آخر من open-world reasoning: الغموض التشغيلي يستحق حالة خاصة، لا إجباراً على boolean مريح.

06 — ضع التعلم بعد الحقيقة

التحسين لا يجب أن يصنع طريقاً أضعف حول نموذج الصلاحيات.

يمكن لfeedback ونتائج الفرص أن تحسن اختيار المصادر والترتيب وكفاءة التشغيل. لكن لا ينبغي لها إعادة كتابة حقائق تاريخية أو إرخاء provenance أو توسيع صلاحيات الفعل بصمت لمجرد أن reward signal يكافئ throughput أعلى.

في معمارية OpportunityOS العامة تأتي المراقبة والتعلم downstream من عقود الحقيقة والصلاحية نفسها. يستطيع learning loop اقتراح سلوك أفضل، لكن deterministic truth والقيود المصرح بها تظل الحدود التي يعمل داخلها.

هنا تتحول الحوكمة من نص policy إلى architecture: القاعدة الأقوى هي التي لا يستطيع module أدنى تجاوزها بالمصادفة.

07 — صمّم توقفاً قابلاً للشرح

الوكيل المفيد يجب أن يستطيع شرح لماذا توقف.

رفض اختراع دليل ناقص ليس فشلاً في autonomy. وطلب مراجعة قبل فعل خارجي مؤثر ليس كذلك. النظام يصبح أكثر فائدة عندما يميز بين لا أستطيع استنتاج هذه الحقيقة، أستطيع إعداد هذا الفعل، ولدي صلاحية لتنفيذه.

يتعامل NIST AI Risk Management Framework مع الثقة كمسألة إدارة مخاطر عبر دورة الحياة، لا كصفة وحيدة للنموذج. تطبيقي العملي لهذا في المنتجات الوكيلة هو تحويل evidence وuncertainty وauthority إلى هياكل بيانات صريحة يمكن اختبارها عندما تكون صياغة النموذج مقنعة والدليل ضعيفاً.