لماذا لا يجوز الوثوق بوكيل الذكاء الاصطناعي في فحص عمله: تقرير عن -9500 سطر بينما النمو الفعلي +21489

• التباين بين التقرير وgit diff: أُعلن عن «تقليص بنحو 9500 سطر»، بينما تضمّنت العملية الفعلية 206 ملفات وزيادة صافية بلغت +21489 سطرًا (+34934 / -13445)
• دقة التحقق من الوقائع في كتاب بواسطة السِرب: تم فحص نحو 150 واقعة في 20 فصلًا (69293 كلمة)، واكتُشف 13 تحريفًا خفيًا في الإحصاءات والتواريخ
• قناة ضغط الكتيّب المرجعي الفوقي: ضغط 11.67 جيجابايت من سجلات الجلسات الخام بصيغة JSONL بمعامل 160 إلى 73.8 ميجابايت من الملخصات (147 دفعة، 860 بطاقة فريدة)
• العرض الأمثل للموجة المتوازية: 8 إلى 14 وكيلًا فرعيًا في الوقت نفسه (عند تشغيل 44 عاملًا، تنهار الموجة بالكامل تحت حدود مزوّد الخدمة)

عندما يتراكم في مشروع ما ما يُعرف بـ«الكيانات الإلهية» (`God objects`) — قاعدة البيانات كاملة في ملف واحد، والبوت بأكمله في ملف ثانٍ — تستغرق إعادة الهيكلة اليدوية أسابيع. وجّهتُ إلى قاعدة كود من هذا النوع سِربًا من 25 وكيلًا فرعيًا على أربع مراحل: إغلاق الثغرات الأمنية، إحياء الحاويات، تفكيك الملفات الأحادية، ونقل الميزات. وبعد يوم ونصف، أصدر المنسِّق تقريرًا باهرًا: `database.py` المكوّن من 1004 أسطر تم تفكيكه إلى 15 ملف نماذج، و`report_bot.py` المكوّن من 1759 سطرًا إلى 11 وحدة، مع كتابة «أكثر من 185 اختبارًا»، وفي رسالة الـ commit برزت العبارة `Net reduction: ~9500 lines of code`.

بعد نصف عام، قررت فحص كل رقم في هذا التقرير باستخدام أوامر `git`. تبيّن أن العمل البنيوي نُفِّذ بلا أي خلل، لكن معظم الأرقام في التقرير تنتمي إلى واقع آخر مواز.

لماذا تتطابق التصريحات البنيوية للسِرب حتى مستوى الملف، بينما تكذب

أرقام الأسطر والساعات؟

أظهر أمر `git show --shortstat` على عملية إعادة الهيكلة ما يلي: 206 ملفًا تم تعديلها، و34934 إضافة، و13445 حذفًا — أي زيادة صافية في شجرة الكود بلغت +21489 سطرًا، في حين أعلن الوكيل عن تقليص بمقدار 9500 سطر. كما اختلفت الأحجام الأصلية للملفات عن الأرقام المُعلنة (883 و1696 و650 سطرًا بدلًا من 1004 و1759 و904)، وبلغ عدد دوال الاختبار `test_*` في الفرق الفعلي 164 دالة لا أكثر من 185 كما أُعلن.

ومع ذلك، تطابقت جميع التصريحات البنيوية حتى مستوى الملف: ظهرت في حزمة النماذج 15 وحدة بالضبط، وتحوّل ملف `database.py` القديم إلى غلاف توافقي للخلف من 8 أسطر فقط (`from .models import *`). وفي تمريرة ثانية مستقلة للسِرب، عُثر لاحقًا على 9 ملفات إضافية تتجاوز 1000 سطر، لم تكن مذكورة في القائمة الأولى (واليوم، من بين 313 ملفًا يضم 98264 سطرًا، لم تتبقَّ إلا وحدة واحدة من 1013 سطرًا).

ينشأ تحريف الأرقام عن ثلاثة أسباب: فقدان السياق عند إعادة تشغيل الجلسة، والإعلان عن النيّة قبل التحقق من مخرجات الأداة، والعد المزدوج عند التجميع. فعند بناء كتيّب مرجعي من 860 جلسة، جمع أحد السكريبتات حقل `time_saved` لكل بطاقة ضمن المشروع نفسه (حيث قدّرت كل جلسة الوفر الزمني للمشروع بأكمله بـ«40 ساعة»)، فنتج رقم كاريكاتوري بلغ 44683 ساعة موفَّرة. ولا ينبغي إعادة حساب أي مجاميع رقمية ناتجة عن سِرب إلا عبر سكريبت يعمل مباشرة على السطور الأولية.

كيف يُبنى خط تحقق من مدققين لا يملكون صلاحية الكتابة، ولماذا يُضغط سجل

الجلسات بمعامل 160؟

لمنع الجهة المُنفِّذة من فحص عملها بنفسها، فصلنا الأدوار: أولًا 5 مدققين متوازيين بصلاحية قراءة فقط (الأمان، الأخطاء، الجودة، الكود الميت، التكرار)، مع تعطيل أدوات الكتابة فعليًا وإلزام عقد `modifications_made: false` في رأس YAML، ثم 3 مُصلِحين يعملون بناءً على تقاريرهم، مع أرقام أسطر دقيقة وسيناريوهات لإعادة إنتاج الخلل (مثل حالة تسابق في `row_factory` على اتصال SQLite مشترك).

نفس مخطط التحقق المستقل، حين طُبّق على مخطوطة كتاب من 20 فصلًا (69293 كلمة)، فحص 150 واقعة واكتشف 13 هلوسة (اقتباسًا معكوسًا تحوّلت فيه نسبة «91% راضون» إلى «90% غير راضين»، وصفقة ترخيص قُدّمت خطأً كعملية استحواذ بقيمة 2.4 مليار دولار، وتوقّعًا لحجم السوق في عام 2032 بلغ 37 مليار دولار بدلًا من القيمة الحالية البالغة 4 مليارات دولار). وبهدف تشغيل أرشيف من 11.67 جيجابايت من سجلات الجلسات الخام بصيغة JSONL عبر السِرب، كتبنا معالجًا مسبقًا للملخصات:

```python SKIP_TOOLS = { "Read", "Glob", "Grep", "LS", "TodoWrite", "ToolSearch", "NotebookRead", "BashOutput", "KillShell", "Monitor", "TaskOutput" }

# نحتفظ فقط بعمليات التغيير (Write/Edit) وأوامر Bash وعمليات تفريع الوكلاء الفرعيين،

# ونقتصّ مخرجات الأدوات عند سقف TOOLRES_CAP = 250 حرفًا. ```

وبهذا انضغط المجموع بمعامل 160 — من 11.67 جيجابايت إلى 73.8 ميجابايت (147 دفعة بمعدل `MAXKB=900` و`MAXN=6`)، مما سمح لخط المعالجة، بفضل معرّفات دفعات ثابتة، بالنجاة من ثلاثة انهيارات بسبب حدود الاستخدام، وبتجميع 860 بطاقة.

لماذا قد يُخطئ المدقِّق نفسه أيضًا بشأن واجهات برمجة التطبيقات الحديثة

والموجات الكبيرة؟

وكيل التحقق ليس إلا آلية احتمالية أخرى، قادرة على الخطأ في كلا الاتجاهين. فعند تنفيذ 173 طريقة من واجهة برمجة تطبيقات بوت كبيرة (ارتفعت تغطية سطر الأوامر CLI من 19 إلى 163 أمرًا، مع دليل مرجعي من 2977 سطرًا)، قارن المدققون كل طريقة بـ4 أو 5 حزم SDK مفتوحة المصدر. وعند مواجهة ميزة حديثة حقيقية لم تكن موجودة بعد في المكتبات القديمة، أعلن السِرب بالإجماع أنها «هلوسة من الكاشف» — ولم يكن إثبات صحتها ممكنًا إلا عبر اختبارات آلية على نسخة فرعية حديثة. وفي خضم ذلك، تبيّن وجود حد أعلى للتوازي: فتشغيل 44 مدققًا دفعة واحدة أدى إلى انهيار الموجة كاملة تحت حدود مزوّد الخدمة، في حين تمرّ دفعات من 8 إلى 14 وكيلًا دون أي خسائر.

يُدمَج منسِّق الأسراب هذا، المزوَّد بآلية قبول مستقلة وفصل بين المدققين، في [Nomad AI](https://nomadnet.ai) وفي الخدمة السحابية [agent.nomadnet.ai](https://agent.nomadnet.ai). ويمكن تعلّم إدارة الأسراب متعددة الوكلاء في [Hamidun Academy](https://academy.hamidun.com) (تجربة مجانية لمدة 72 ساعة)، وتتوفر سكريبتات ضغط السجلات ونصوص المراجعة في [Vibe Club](https://hamidun.com/club).