Logging لمهام AI Agent داخل المتصفح: ما الذي يسهل المراجعة لاحقًا

عندما يخطئ Agent، نحتاج إجابة: ماذا كان يحاول؟ أي حالة قرأ؟ ما Tools التي استدعاها؟ وماذا عادت؟ تسجيل screenshot لكل شيء أو prompt كامل قد يكشف بيانات حساسة ويزيد التكلفة. الأفضل event log منظم بمستويات.

ابدأ بهوية المهمة

سجل taskId و agentSession و user/workspace وهدف مختصر ومصدر التشغيل. هذه الحقول تربط الأحداث دون استخدام نص المحادثة كمفتاح.

سجل Tool calls structured

toolName و callId و start/end و status و errorCode و redacted args. للنتيجة، احفظ IDs وال metadata اللازمة لا payload كامل. استخدم policy redaction مركزية.

فرق reasoning عن evidence

لا تحتاج حفظ chain-of-thought. احفظ القرار القابل للمراجعة مثل selectedTool و preconditions والبيانات التي اعتمد عليها من النظام. هذا يكفي للتحقيق بدون تخزين reasoning داخلي.

أضف trace عند الفشل فقط

Screenshot أو DOM snippet مفيد لبعض errors. اجمعه عند failure أو sampling وبحدود حجم، مع mask للحقول الحساسة. اربطه ب ـcallId.

ابنِ timeline قابلًا للقراءة

رتب الأحداث بالوقت واعرض spans لل ـTools والانتظار البشري والشبكة. timeline تكشف بسرعة هل التأخير في Agent أم browser أم external service.

ضع Data Classification قبل تحديد ما تسجله

قسّم الحقول إلى public و internal و sensitive و secret. URL قد يكون internal أو حساسًا إذا يحوي query، screenshot قد يحتوي PII، وال Tool args قد تحمل token. اربط كل فئة بسياسة retention و redaction و access. عند إضافة Tool جديدة، يجب تعريف تصنيف حقولها قبل دخولها logging العام. هذا يمنع توسع السجل تدريجيًا حتى يصبح مخزن أسرار لا يدرك الفريق حساسيته، ويجعل حذف البيانات أو الاستجابة لطلب privacy أكثر قابلية للتنفيذ.

افصل Logs التشغيلية عن Audit Logs

Operational logs تساعد debugging ويمكن حذفها بسرعة، بينما audit logs تثبت من نفذ action وقد تحتاج حماية واحتفاظ أطول. لا تخلط الاثنين في stream واحد بنفس صلاحيات القراءة. Audit تسجل أحداثًا منتقاة و immutable قدر الإمكان، operational قد تحتوي stack traces وتفاصيل تقنية أكثر. الفصل يقلل وصول المطورين إلى بيانات تدقيق لا يحتاجونها ويمنع أن سياسة تنظيف debug تحذف سجلًا مطلوبًا للمراجعة.

راجع قابلية البحث في السجلات تحت حادث حقيقي

اختبر نظام Logging بسؤال تشغيلي واقعي: ما Tool التي غيّرت هذا البروفايل بين 10:00 و 10:05، وما النتيجة؟ إذا احتجت قراءة آلاف الأسطر يدويًا فالبنية غير كافية. وفّر فهارس على taskId و callId و resourceId و errorCode، مع correlation بين Agent events و browser process logs. الهدف من structured logging أن يختصر زمن التحقيق، لا أن ينتج JSON كثيرًا فقط.

اختبار التحكم قبل منح الصلاحية

في «Logging لمهام AI Agent داخل المتصفح: ما الذي يسهل المراجعة لاحقًا» اختبر النظام بأداة قراءة أولًا ثم أداة تغيير منخفضة المخاطر، مع تسجيل المدخل والقرار والنتيجة دون أسرار. افصل بين ما يستطيع النموذج اقتراحه وما يستطيع تنفيذه، وضع approval أو policy على الأفعال الحساسة. جرّب مدخلًا غامضًا ومدخلًا يحتوي تعليمات متعارضة، وتأكد أن حدود الصلاحيات لا تتغير بسبب صياغة المستخدم. القيمة هنا ليست في عدد الأدوات التي يستطيع ال ـAgent استدعاءها، بل في أن كل استدعاء يمكن تفسيره ومراجعته وإيقافه عند فشل شرط الأمان أو عدم اكتمال السياق.