🤖 كيف قمنا بتقليل وقت الاستجابة للحوادث بنسبة 90% باستخدام AI Agent Auditing

مشكلة إطفاء الحرائق

لو كنت بتشغل أنظمة إنتاج، هتكون عارف الكلام ده: تنبيه يفجر، وتدخل على خادم، وتقوم بتشغيل grep على سجلات، وتشوف لوحات التحكم، وتقضي 20 دقيقة عشان تفهم إزاي الحاجة اتكسرت. ولو ضربنا كده خمس تنبيهات في اليوم، هتكون خسرت ساعتين تقريبا في التبديل بين السياقات. لسه أنا بتشغل محفظتي ومشاريعي الجانبية على VPS من Dokploy مع PostgreSQL و Next.js وعدد من الخدمات الصغيرة. وكلما زاد عدد الخدمات، زاد الحمل المعرفي لاستجابة الحوادث. كنت محتاج طريقة أحسن، 그래서 بنيت نظام تدقيق وهمي للموكلين اللي قاطع وقت تحليل الأسباب الأساسية بنسبة 90%.

إيه هو تدقيق الوكيل؟

تدقيق الوكيل هو ممارسة تسجيل وتحديد وتأكيد ما بيعمله وكيل وهمي فعليا خلال سير عمل استجابة حادث آلي. مش كافى أنك تعطى وصول ل سجلاتك ل LLM وتأمل أنها هتلاقي العيب. انت محتاج:

مسارات التنفيذ الكاملة — كل مكالمة أداة، كل قرار
تقييم الثقة — هل الوكيل فعلا حل المشكلة أو बस كان يفكر انه حلها؟
بوابات الدورة البشرية — الإجراءات الحاسمة (إعادة تشغيل الخدمات، التراجع عن التوزيع) تحتاج موافقة
إعادة التشغيل بعد الموت — يجب أن تكون قادرا على تشغيل الحادث نفسه مع نفس الوكيل للتأكد من أنه سيتخذ نفس الخيارات

هيكلتنا

هنا البروتوكول اللي اتوصلنا له بعد ثلاثة تجارب:

interface AuditTrailEntry {
  timestamp: string;
  agentId: string;
  action: "query" | "execute" | "approve" | "rollback";
  tool: string; // e.g., "psql", "curl", "systemctl"
  input: unknown; // sanitized — no secrets
  output: string; // truncated to 2KB
  confidence: number; // 0.0 to 1.0
  duration_ms: number;
  approved_by?: string; // null if auto-executed
}

كل إجراء يقوم به الوكيل يتم تسجيله في جدول مخصص في PostgreSQL. لو حصل حاجة غلط، نكرر مسار التدقيق للوكيل ونسأله: "مع ما كنت عارف في هذه النقطة، هل كان هذا القرار صحيح؟" ده بيحصل ل两个 نمطين شائعين من الأخطاء:

إصلاحات متخيلة: الوكيل بيفكر انه أعد تشغيل خدمة لكن चलّى الأمر الغلط
سلاسل التوسع: الوكيل بياخد القرار الصحيح الأول، ثم يتسلسل إلى إجراءات متزايدة العدوانية

التأثير على التكلفة

كنا بنخسر تقريبا 15 دولار في اليوم على مكالمات API من Anthropic لاستجابة حادث الوكيل عبر جميع الخدمات. إضافة تسجيل تدقيق شامل زاد استخدام الرمز بنسبة 20% تقريبا — لكن قطع وقت المطورين في ما بعد الحوادث بنسبة 90%. قبل التدقيق: كل حادث يتطلب فترة ما بعد الحادث من 30-60 دقيقة لإعادة بناء ما حدث. بعد التدقيق: نفتح مسار التدقيق، نشوف كل قرار، ونصلح البرومت أو تكوين الأداة في 5 دقائق.

التطبيق العملي للعاملين المنفردين

مينفعش تكون محتاج منصة معقدة عشان تبتدي. هنا الإصدار الأدنى اللي أنا أشغله على VPS الخاص بي:

# سجل تدقيق بسيط — اخرج أي مخرجات وكيل عبر هذا 
#!/bin/bash
# audit-log.sh — يسجل stdin + البيانات الوصفية إلى PostgreSQL
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
AGENT_ID="${1:-unknown}"
ACTION="${2:-query}"
INPUT=$(cat)
psql "$DATABASE_URL" -c "
  INSERT INTO agent_audit_log (timestamp, agent_id, action, input, output)
  VALUES ('$TIMESTAMP', '$AGENT_ID', '$ACTION', '$(echo "$INPUT" | head -c 2000 | base64)', CURRENT_TIMESTAMP);
"

هذا труб خط الأوامر يسجل كل أمر قبل التنفيذ. ده غبى، لكن ده شغال. بعد أسبوع هتكون ليك بيانات كافية عشان تلاحظ الأنماط في ما يغلط فيه الوكيل.

الخلاصة

تدقيق وكيل وهمي مش بس للفرق المتخصصة في الامتثال للشركات. لو كنت تشغل أي نظام آلي يلمس الإنتاج — حتى VPS وحيد — انت محتاج مسار تدقيق. ده بيحول "أنا فاكر ان الوكيل كسف حاجة" إلى "الوكيل चलّى rm -rf /var/log الساعة 3:14 صباحا لأن البرومت قال 'نظّف مساحة القرص'". مستقبلك هيشكرك لما يرن الجرس الساعة 2 صباحا وتقدر تشوف بالظبط ما حدث بدل من التخمين.