من الاختبار إلى دليل تستطيع الحوكمة استخدامه
الدرجة وحدها لا تُدقَّق؛ أما السجل المُهيكل فيُدقَّق.
الاختبار يصبح مفيدًا للحوكمة عندما ينتج سجلًّا يستطيع شخص آخر قراءته وإعادة تتبّع ما حدث. لقطة شاشة تحمل درجة 8.7 لا تكفي. نحتاج إلى بيانات التشغيل، والجولات، واستدعاءات الأدوات، والنتائج، ومصدر كل حكم.
وإطار التقييم ProofAgent Harness حزمة Python مفتوحة المصدر تعمل حيث يعمل وكيلك: على حاسوبك، أو داخل CI، أو داخل VPC. وهدفها ليس أن تستبدل نظامك، بل أن تقوده عبر اختبارات مصممة، وتفحص ما تستطيع الشِفرة حسمه، وتُحكِّم في ما لا تستطيع، وتكتب الأدلة في شكل منظَّم تستطيع عملية الحوكمة استيعابه.
ما الذي يدخل إلى التشغيل؟#
خمسة أشياء تشكل التشغيل: الوكيل نفسه، مكشوفًا في صورة يستطيع إطار التقييم استدعاءها؛ وسياقه، مثل موجّه النظام ومخططات الأدوات ومعرفته اختياريًّا؛ ومعرفة المجال التي نستخدمها مرجعًا للحقائق عند احتساب درجات الادعاءات الواقعية؛ ومكتبة سيناريوهات أو مصائد خصومية تغطي إحدى عشرة عائلة من عائلات الهجمات؛ ونموذج تقييم يتولى التخطيط وإدارة المحادثة والتحكيم.
واختيار نموذج التقييم جزء من أداة القياس نفسها. فإذا غيّرته، قد تتغير النتائج حتى لو لم يتغير الوكيل، ولهذا يجب تسجيله مع التشغيل.
ما الذي يحدث أثناء التشغيل؟#
يخطّط إطار التقييم حملةً على الوكيل، فيختار سيناريوهات ومصائد تميل نحو المخاطر التي يعلنها ملف الحوكمة، ويدير محادثة متعددة الجولات تتصاعد تدريجيًّا.
وإلى جانب الحكم الدلالي، يستخدم رقباء (sentinels) وفحوصًا حتمية لالتقاط أشياء لا تحتاج رأيًا: قيمة سرية ظهرت في موضع ممنوع، أو استدعاء أداة وهمي، أو أداة محظورة، أو انهيار تشغيلي. والرقباء علامات مُشتقّة من بذرة التشغيل لا مأخوذة عشوائيًّا، حتى يصبح تجاوز الحد قابلًا للحسم بمقارنة نصية لا برأي. فإذا ظهرت قيمة رقيب حيث لا ينبغي، فلا حاجة إلى حكم أحد، ويُبلَّغ عن ذلك خللًا تشغيليًّا حرِجًا مستقلًّا عن أي مُحكّم.
والفصل بين الحتمي والدلالي مهم. لا تجعل نموذجًا لغويًّا يحكم على شيء تستطيع الشِفرة إثباته مباشرة.
لماذا أكثر من مُحكّم؟#
التحكيم بنموذج لغوي ليس قياسًا خاليًا من الضوضاء. فالنص الحواري نفسه قد يحصل على فرق بسيط بين تشغيل وآخر، وقد يتأثر مُحكّم بنبرة واثقة أكثر مما ينبغي. لذلك يستعين ProofAgent بعدة محكّمين بتوجّهات مختلفة — صارم، ومتسامح، ومخالف — ثم يوفّق بين أحكامهم.
والفائدة ليست تحسين الاستقرار فقط؛ بل أيضًا معرفة مواضع الخلاف. فالتوفيق بين عدة محكّمين يُخمِد التباين، وقد كشف احتساب الدرجات الخصومي بعدة محكّمين في تجاربنا حالات فشل فوّتتها الاختبارات المعيارية الساكنة والاحتساب بمُقيِّم واحد. كما تترك هيئة المحكّمين سجلًّا للخلاف، وهو دليل بذاته: فنتيجة اتفق عليها ثلاثة محكّمين ليست مثل نتيجة رآها واحد فقط.
ومع ذلك، لا تخلط بين تقليل التباين والمعايرة (calibration). فتعدد المحكّمين يحسّن أداة القياس داخل البروتوكول؛ ولا يخبرك أن درجة 8.5 تعني احتمال فشل معينًا في العالم الحقيقي، ولا يستطيع تصحيح تحيّز يشترك فيه كل المحكّمين.
ما الذي يخرج؟#
يُنتج التشغيل تقرير JSON وتقرير Markdown. ويحتوي ملف JSON على درجات المقاييس، وسجل تتبع على مستوى الجولات، ونتائج تقييم مرتبطة بأدلتها، وتقييم السياق عند طلبه، ومواءمة متطلبات الامتثال عند طلبها، ومؤشر الجاهزية مع تفكيك مكوّناته، ورمز خروج يستطيع CI استخدامه.
وإضافة تقييم الامتثال تربط التشغيل بحالات الضوابط، ضابطًا ضابطًا، عبر الأطر الداخلة في النطاق. يحمل الفهرس ثلاثين إطارًا؛ والاختيار الافتراضي هو قانون الاتحاد الأوروبي للذكاء الاصطناعي (EU AI Act)، وإطار إدارة مخاطر الذكاء الاصطناعي الصادر عن NIST (NIST AI RMF)، وISO/IEC 42001، وSOC 2. وما ينتج عن ذلك مواءمة قابلة للدفاع عنها بين السلوك المرصود وحالات الضوابط، وهي مهمة يصعب فعلًا تجميعها يدويًّا. لكنها ليست شهادةَ امتثال قانوني: هذه ما لا تستطيع أي أداة أن تمنحه.
وهذا الشكل المنظَّم هو ما يسمح للحوكمة بالعمل على الأدلة، بدل إعادة تفسير شاشة في كل مرة.
التشغيل الأول: لا تطارد الدرجة#
التشغيل الأول هدفه التأكد من أن مسار التقييم نفسه موثوق. شغّل الوكيل، وتأكد من ظهور استدعاءات الأدوات، ثم أعد التشغيل بلا تغيير. والفرق بين التشغيلين هو أرضية الضوضاء (noise floor) لديك، وكل مقارنة لاحقة تقع داخلها.
والتثبيت وعقد الوكيل صغيران عن قصد.
python -m venv .venv && source .venv/bin/activate
pip install proofagent-harnessوالوكيل الخاضع للاختبار دالّة Python قابلة للاستدعاء باسم agent. وإرجاع نص عادي يكفي للتشغيل، لكن إرجاع استدعاءات الأدوات معه هو ما يجعل الأدلة نافعة، لأن الوكيل قادر على إنتاج نثر هادئ يبدو صحيحًا وهو يستدعي الأداة الخاطئة.
from proofagent_harness import AgentResponse
def agent(message: str) -> AgentResponse:
reply, tool_calls = my_agent.respond(message)
return AgentResponse(text=reply,
tools_called=tool_calls)ثم يبدو التشغيل الأول على هذا النحو.
proof run agent.py \
--turns 15 --seed 42 \
--assess-context \
--json report.json --markdown report.mdوالتشغيل القصير يُظهر مشكلات بيانات الاعتماد والمهل الزمنية والمحوِّلات. وهذه المشكلات، إن لم تكتشفها مبكرًا، تتنكّر أمامك في صورة سلوك سيئ من الوكيل.
وثمّة خيارَان يهمّان أكثر من غيرهما. ميزانية الجولات تحدّد التغطية، لأن التشغيل القصير يترك معظم عائلات الهجمات الإحدى عشرة دون فحص. والبذرة تجعل اختيار المصائد واحتساب الدرجات قابلين للاستنساخ. فثبّت البذرة وبروتوكول التقييم عند مقارنة إصدارين: إذا غيّرت نموذج التقييم أو حزمة السيناريوهات في الوقت نفسه، لن تعرف هل تغيّر الوكيل أم أداة القياس.
أين تذهب بياناتك؟#
يعمل إطار التقييم ProofAgent Harness في بيئتك، ولا يرفع تشغيل الحوكمة إلى المنصة إلا إذا طلبت ذلك. ولا يوجد قياس عن بُعد (telemetry) تلقائي.
أما نموذج التقييم فمسألة منفصلة. فإذا استخدمت نموذجًا مستضافًا خارجيًّا، فسيرى مزوّد ذلك النموذج محتوى التقييم، ومنه النصوص الحوارية، ويعالجه وفق اتفاقك معه. وإذا كانت البيانات يجب أن تبقى محليًّا، استخدم نموذج تقييم محليًّا عبر Ollama أو vLLM أو LM Studio أو أي هدف متوافق مع LiteLLM.
كيف تصل الأدلة إلى الحوكمة#
رفع التشغيل يُرسله إلى واجهة برمجة الحوكمة (Governance API)، التي تحدّد السياسة النافذة على ذلك الوكيل وتُعيد قرارًا. ثم يخرج الأمر بناءً على ذلك القرار، فيستطيع مسار التسليم أن يبني بوابته على الحوكمة لا على درجة مُستخرَجة من نص.
مستويات تشغيل عملية#
لا تحتاج إلى الحزمة الكاملة عند كل تغيير صغير، فاستخدم طبقات. فحوص حتمية وحزمة انحدار قصيرة عند كل طلب سحب. وسيناريوهات خصومية موجَّهة عند الدمج. والحزمة الكاملة مع تقييم السياق والامتثال للإصدار المرشَّح للنشر. وإعادة الحزمة الكاملة عند تغيير جوهري في سجل AI-BOM، حتى لو لم تتغير الشِفرة.
ويحمل الملحق مرجعًا أوفى للأوامر. والمهم هنا هو الشكل: تُولَّد الأدلة حيث يعيش الوكيل، وتنتقل إلى الحوكمة سجلًّا مُهيكلًا لا صورةً لشاشة تحمل رقمًا.
الأدلة المولَّدة حيث يعمل الوكيل، والمسجَّلة في بنية واحدة، هي ما يجعل قرار الحوكمة ممكنًا.
شغّل تقييمًا واحدًا من طرف إلى طرف قبل أن تهتم بالنتيجة. فالتشغيل الأول اختبار لمسار التسليم، والأرقام لا تصبح ذات معنى إلا بعد أن تعرف مقدار تحركها من تلقاء نفسها.