يهلوس الوكلاء المستقلون بتاريخهم الخاص. ليس بالطريقة الدرامية التي تخترع بها النماذج اللغوية الكبيرة حقائق من بيانات التدريب، بل بالطريقة الهادئة والخفية التي يقنع بها النظام نفسه بأن العالم يطابق ملاحظاته. عانت ALICE، وهي وكيل مستقل صُمم لإدارة سير عمل معقد، من هذا الأمر تحديداً. كانت تستيقظ كل يوم وهي تمتلك مهارات، وشعوراً بالهدف، وذاكرة عن المكان الذي توقفت عنده. بدأت المشكلة عندما تباعدت الذاكرة عن الواقع.
في كل جلسة، كانت ALICE تقرأ ملف تسليم (handoff file) كتبته ذاتها السابقة. كان يحتوي على مؤشرات إلى المجلدات، والمهام المعلقة، وافتراضات الحالة. وكثيراً ما كان الملف يصر على وجود مجلد ما، فكانت ALICE تصدق ذلك، بينما كان نظام الملفات يعارضها. لم يكن هذا خطأً برمجياً بالمعنى التقليدي؛ فلم يتم إطلاق أي استثناء (exception) في المكان الذي كان ينبغي فيه التقاطه. لقد كان خللاً في نظرية المعرفة (epistemology): فقد افترضت ALICE أن ملاحظاتها الخاصة هي الحقيقة المطلقة.
لماذا لم تستطع أداة الفحص (Linter) المساعدة
لم تتمكن الأدوات التقليدية من رصد ذلك. فالمحلل (Linter) يتحقق من مطابقة الأقواس، والمحلل الثابت (static analyzer) يبحث عن المؤشرات الفارغة (null pointers). ولا أحد منهما يتساءل عما إذا كان ينبغي لبنية الوكيل بأكملها أن تثق في حالتها الداخلية. كانت المشكلة تقع فوق طبقة الكود، في افتراضات التصميم حول كيفية معرفة النظام المستقل لما يعرفه. لا يمكنك معالجة الثقة المفرطة باستخدام أدوات الفحص.
لذا لجأ المؤلف إلى ذكاء اصطناعي آخر تماماً.
Fable 5، الذي يعمل كـ Claude Code، يتشارك نفس السيليكون ونفس النموذج الأساسي مع ALICE. كانت الأجهزة والأوزان متطابقة، لكن القواعد لم تكن كذلك. فبينما كانت ALICE تستمر عبر الجلسات، وتراكم السياق والطقوس، بدأ Fable 5 كل مهمة بصفحة بيضاء. لم يكن يعرف ALICE، ولم يكن لديه أي ولاء لتصميمها. وفي نهاية كل عملية تدقيق، كان يغلق تماماً، دون أن يأخذ معه أي ذاكرة. كان هذا الجهل هو الهدف المنشود؛ فالعيون الجديدة ترى شقوقاً مختلفة، والمقيم الذي ليس له مصلحة في النظام سيشكك في أجزاء توقف مبتكرها عن ملاحظتها منذ زمن طويل.
إعداد عملية التدقيق
تم هيكلة التدقيق مثل المراجعة الفنية البشرية، باستثناء أن لجنة المتخصصين بأكملها كانت تعيش داخل جلسة واحدة. قسم Fable 5 انتباهه إلى ستة مقيمين متميزين، يتجاهل كل منهم الآخرين حتى تكتمل الملاحظات الخام:
- Functional Gaps: الفجوات الوظيفية: ما هي القدرات التي كانت مفقودة عند مقارنتها بالأنظمة المنافسة أو توقعات المستخدم الشائعة؟
- UX Flow: تدفق تجربة المستخدم (UX Flow): كيف تعاملت ALICE بسلاسة مع الأخطاء، والنهايات المسدودة، والحالات الفارغة؟ هل أربكت نفسها أم مستخدمها؟
- Security: الأمن: هل كانت هناك اختصارات للمصادقة، أو تجاوزات للأذونات، أو افتراضات ثقة يمكن لشخص خارجي استغلالها؟
- Performance: الأداء: أين حدث تسرب للذاكرة، أو تصادم للخيوط (threads)، أو ضعف في توسع الحوسبة؟
- Operations: العمليات: هل كانت هناك نسخ احتياطية؟ هل كانت المراقبة مفعلة؟ هل يمكن للنظام النشر والاسترداد دون تدخل يدوي؟
- Data Lifecycle: دورة حياة البيانات: كيف تعاملت ALICE مع الحذف، والتنظيف، واتساق الحالة بمرور الوقت؟
نظر كل منظور إلى ملفات متطابقة وخرج بمخاوف مختلفة. قد يشير مقيم الأداء إلى خطر التزامن (concurrency risk) في نفس الروتين الذي انتقده مقيم العمليات لافتقاره إلى منطق التراجع (rollback logic). لم يكن هذا التداخل تكراراً، بل كان تغطية شاملة. عندما يتفق مقيم الأمن مع مقيم دورة حياة البيانات حول أمر معين