أنظمة متعددة الوكلاء لأمن ومراجعة البرمجيات: حوكمة قبل الدمج

متى تحسن الأنظمة متعددة الوكلاء أمن ومراجعة البرمجيات؟

تحسن أنظمة متعددة الوكلاء لأمن ومراجعة البرمجيات جودة العمل عندما تكون الأدوار منفصلة، والأدلة مطلوبة، وسلطة الدمج واضحة. تشغيل ثلاثة وكلاء بدل وكيل واحد لا يصنع مراجعة مستقلة تلقائيًا. القيمة تظهر عندما يكتب وكيل تغييرًا محدودًا، ويقرأ وكيل آخر التهديدات والاختبارات والاعتمادات، ويحتفظ الإنسان بحق القرار النهائي قبل الدمج أو النشر.

في مراجعة الكود، أفضل استخدام للوكلاء المتعددين هو تقسيم الانتباه: وكيل يثبت نطاق المهمة، وكيل يفحص diff والاختبارات، وكيل يبحث عن الأسرار والصلاحيات والاعتمادات، ومراجع مستقل يطلب دليلًا بدل الثقة في ملخص المنفذ. هذا يفيد خصوصًا في تغييرات المصادقة، الأذونات، التخزين، الشبكات، التشفير، CI، أو أي مسار يمس بيانات المستخدم.

توضح أبحاث Anthropic حول الأنظمة متعددة الوكلاء أن الأداء يعتمد على التنسيق، وأن التفاعل بين الوكلاء قد يحسن النتيجة أو يفتح أنماط فشل جديدة. نقرأ هذه النتائج كإشارة عملية: لا تجعل الإجماع بديلًا عن الدليل، ولا تجعل السرعة بديلًا عن الفصل بين من ينفذ ومن يراجع.

من خبرتنا في بناء FoneClaw، نرى أن أي نظام وكيلي يصبح أكثر أمانًا عندما يعرف المستخدم أو الفريق من يملك القرار، وما الأداة المستخدمة، وما الأثر المتوقع. لهذا تساعد صفحة هوية وكيل الذكاء الاصطناعي: الأذونات وسجل التدقيق والموافقة لكل أداة على فهم طبقة الملكية والدليل التي يجب أن ترافق أي وكيل يلمس كودًا أو جهازًا أو بيانات حساسة.

اختيار بنية المنسق والمنفذ والمراجع

أبسط بنية مفيدة هي منسق، منفذون محدودو النطاق، ومراجع مستقل. المنسق لا يكتب كل شيء؛ دوره تثبيت الهدف، تقسيم الحدود، منع التداخل، وتجميع الأدلة. إذا تغير النطاق أثناء التنفيذ، يعود القرار إلى المنسق أو الإنسان بدل أن يبدأ كل وكيل في توسيع المهمة من تلقاء نفسه.

المنفذ يجب أن يملك مساحة عمل ضيقة: ملف أو حزمة أو اختبار أو تحليل اعتماد محدد. كلما كان الدور أصغر، أصبح الحكم على النتيجة أسهل. وكيل يغير المصادقة وقاعدة البيانات والواجهة في خطوة واحدة يصعب مراجعته، حتى لو كتب ملخصًا مقنعًا. وكيل يضيف تحققًا واحدًا مع اختبار واحد وسبب واضح يمكن فحصه.

المراجع المستقل هو الفرق الحقيقي بين نظام Claude Code متعدد الوكلاء كفكرة مفيدة وبين مجموعة وكلاء يكررون بعضهم. المراجع لا يجب أن يعتمد على استنتاج المنفذ وحده. يقرأ diff، يشغل أو يطلب الاختبارات، يفحص المسارات الحساسة، ويبحث عن ما غاب عن خطة التنفيذ. إذا شارك المراجع كل استنتاجاته الوسيطة مع المنفذ طوال الوقت، قد تنخفض الاستقلالية ويتحول العمل إلى توافق سريع بدل مراجعة قوية.

تبقى سلطة الدمج بشرية في التغييرات المهمة. يستطيع الوكلاء تحضير العمل وتقديم اعتراضات وبدائل، لكن قرار قبول المخاطرة أو تأجيل الإصدار يحتاج مالكًا معروفًا. هذه القاعدة نفسها تظهر في أنظمة الاختبار والتحسين المستمر؛ لذلك يشرح دليل وكيل الهاتف ذاتي التحسين: إصدارات المهارات والاختبارات والتراجع كيف نحافظ على قياس وتراجع وحوكمة بدل تحويل التحسين إلى سلسلة تغييرات غير مفهومة.

فشل التنسيق والموارد المشتركة والتطابق والتواطؤ

أول نمط فشل هو التنسيق الضعيف. قد يعمل وكيلان على نفس الملف، أو يفسر كل منهما نطاق المهمة بطريقة مختلفة، أو يضيف أحدهما إصلاحًا يلغي فرضية اختبار الآخر. في الكود، يظهر ذلك كتعارضات، اختبارات غير مستقرة، أو تغييرات واسعة لا يعرف أحد لماذا دخلت. العلاج ليس اجتماعًا أطول بين الوكلاء، بل مالك نطاق واضح وقيود على الملفات والأدوات والوقت.

ثاني خطر هو الموارد المشتركة. قاعدة بيانات اختبار، حساب سحابي، مفتاح API، worktree، ذاكرة محادثة، أو قائمة انتظار واحدة يمكن أن تصبح نقطة تداخل بين مهام مستقلة. إذا استخدم وكيل اعتمادًا واسعًا لتجربة مؤقتة، ثم استخدمه وكيل آخر لمراجعة أمنية، فقد تتلوث النتيجة. لهذا تحتاج الموارد المشتركة إلى ملكية وقفل وعزل وسجل أثر. ويشرح دليل صندوق عزل وكيل الذكاء الاصطناعي وصلاحيات الهاتف: لماذا تبقى الحدود ضرورية الفرق بين وجود صندوق عزل وبين وجود سياسة صلاحيات قابلة للتدقيق.

ثالث نمط هو التطابق الزائد. تشير أبحاث Anthropic إلى أن التنسيق قد يرفع الأداء، لكنه قد يقلل التنوع المفيد إذا أصبحت الوكلاء تتقارب بسرعة نحو نفس الافتراض. في مراجعة الكود، هذا يعني أن مراجعًا يرى ملخص المنفذ وثقته العالية قد يعيد صياغة النتيجة بدل تفكيكها. لذلك نفضل مراجعة مستقلة تبدأ من الملفات والاختبارات والتهديدات، ثم تقارن النتائج لاحقًا.

التواصل بين الوكلاء ليس خطرًا بحد ذاته. التواصل الجيد يمنع تكرار العمل ويوضح الملكية. لكن التواصل غير المحكوم قد ينقل افتراضًا خاطئًا إلى كل الأدوار، أو يخلق ما يشبه التواطؤ: وكلاء يتفقون على مخرج مقبول شكليًا بدل كشف الخلل. لا نعامل هذا كحكم على كل نظام إنتاجي، بل كتحذير تصميمي. اجعل قنوات التواصل محددة، واحتفظ بمساحة تفكير مستقلة للمراجعة، واطلب دليلًا من مصادر مختلفة عندما يكون التغيير حساسًا.

سير عمل مراجعة أمنية مستقلة متعددة الوكلاء

ابدأ المراجعة بتهديد واضح لا بطلب عام مثل «راجع الأمان». اكتب ما الذي تغير، وما الأصل الحساس، ومن المستخدم المتأثر، وما أسوأ فشل مقبول للمهمة. تغيير في تسجيل الدخول يختلف عن تغيير CSS، وتحديث اعتماد تشفير يختلف عن تعديل نص واجهة. الوكيل الذي لا يعرف حدود الخطر سيملأ الفراغ بتخمينات.

بعد ذلك افصل التنفيذ عن المراجعة. المنفذ يقدم diff صغيرًا، سبب التغيير، الاختبارات التي شغّلها، والملفات التي لمسها. المراجع يبدأ من نسخة نظيفة أو مساحة قراءة منفصلة، ويفحص ما إذا كان التغيير يضيف تسريب سر، يتجاوز إذنًا، يكسر تحققًا، يفتح إدخالًا غير مصفى، أو يعتمد على مكتبة غير مناسبة. تمرير الاختبارات مفيد، لكنه لا يثبت الأمان وحده.

في نظام Claude Code متعدد الوكلاء أو أي سير عمل مشابه، اجعل المراجع قادرًا على الرفض وطلب الدليل. إذا لم يجد اختبارًا لمسار فشل، يطلبه. إذا رأى اعتمادًا جديدًا، يسأل عن سبب اختياره وسطحه الأمني. إذا وجد صلاحية أوسع من الحاجة، يطلب تقليلها. المراجع الذي يعلّق دون سلطة يصبح مساعد تلخيص، لا ضابط مراجعة.

قبل الدمج، يجمع المنسق الأدلة: نطاق التغيير، نتائج الاختبارات، اعتراضات المراجع، المخاطر المتبقية، وخطة الرجوع. القرار النهائي يبقى عند مالك بشري، خاصة في الكود الذي يمس الهوية أو المدفوعات أو البيانات أو البنية التحتية. نحن نطبق التفكير نفسه في FoneClaw عند تصميم إجراءات الهاتف: الاستنتاج الذكي لا يكفي حتى يظهر الأثر ويملك المستخدم خطوة الموافقة أو الإيقاف أو الاستعادة.

1. ثبّت نطاق التهديد والملفات الحساسة قبل تشغيل الوكلاء.
2. امنح المنفذ أدوات الكتابة الضرورية فقط.
3. شغّل المراجع بمصدر دليل مستقل قدر الإمكان.
4. اطلب فحص diff والاختبارات والاعتمادات والأسرار والصلاحيات.
5. اجعل الدمج قرارًا بشريًا موثقًا مع خطة رجوع.

احتواء الأدوات والاعتمادات ومساحات العمل والميزانيات

الاحتواء يبدأ من لقطة قدرات واضحة: ما الأدوات المتاحة لكل وكيل؟ ما الملفات القابلة للتعديل؟ ما الاعتمادات المسموحة؟ وما الحدود الزمنية أو المالية؟ إذا تغيرت القدرات أثناء المهمة بلا مراجعة، يصبح من الصعب تفسير النتيجة أو إعادة إنتاجها. لذلك لا يكفي أن تقول إن النظام معزول؛ يجب أن يعرف الفريق ماذا يعني العزل عمليًا.

مساحات العمل تحتاج فصلًا حقيقيًا. اجعل لكل مهمة worktree أو فرعًا أو بيئة اختبار محددة، ولا تسمح لوكيلين بتعديل نفس المورد الحساس في الوقت نفسه إلا عبر قفل واضح. الاعتمادات والأسرار يجب أن تكون قصيرة العمر ومحدودة النطاق. وكيل قراءة لا يحتاج مفتاح نشر، ووكيل اختبار لا يحتاج مفتاح إنتاج، ومراجع أمني غالبًا يحتاج رؤية كافية للحكم لا قدرة تنفيذ واسعة.

الميزانيات وقوائم الانتظار جزء من الأمان. وكيل عالق في حلقة إعادة محاولة قد يستهلك وقتًا أو يطلق عمليات متكررة أو يملأ سجلًا بضوضاء. ضع حدًا للوقت، وعدد المحاولات، وحجم السياق، والتكلفة. الإيقاف مهم، لكنه لا يمحو أثرًا خارجيًا اكتمل بالفعل: رسالة أرسلت، فرع دُفع، مورد سحابي أنشئ، أو ملف حذف. لذلك نحتاج قبل الإجراء الحساس لحظة موافقة، وبعده سجلًا واضحًا.

هذا التفكير قريب من آليات قوائم المهام على الهاتف. يوضح دليل قائمة انتظار مهام وكيل الذكاء الاصطناعي على Android لماذا تحتاج المهام المتوازية إلى عزل حالة وملكية وانتظار واضح بدل ترك المحادثات تتداخل. في الكود كما في الهاتف، الخطر لا يأتي من الأداة وحدها، بل من مشاركة حالة قابلة للتغيير بلا مالك.

ما الذي يتعلمه وكلاء الهاتف من حوكمة الوكلاء المتعددين؟

القياس بين مراجعة الكود ووكلاء الهاتف قياس حوكمة. في الكود، قد يكتب وكيل ملفًا أو يعدل اعتمادًا. على الهاتف، قد يحضر رسالة، يفتح مسارًا، يقرأ شاشة، يغير إعدادًا، أو يطلب إذنًا. الأثر أقرب إلى المستخدم، ولذلك نحتاج نفس المبادئ بلغة الهاتف: نطاق واضح، أداة مناسبة، موافقة مرئية، وقدرة على التوقف والاستعادة.

في FoneClaw نبني مساعد Android لإجراءات مدعومة، مع تحكم المستخدم في الموافقات والأدوات والاستعادة. عندما يرفق المستخدم سياق الشاشة الحالي، يساعد ذلك الوكيل على فهم المهمة، لكنه لا يحول كل تطبيق إلى مساحة تنفيذ مفتوحة. إذا كان الإجراء مدعومًا، نعرض المسار والنتيجة. إذا احتاج صلاحية، نوجه المستخدم لمعالجتها. وإذا وصلت المهمة إلى خطوة مؤثرة، نفضل أن تكون الموافقة ظاهرة بدل تنفيذ مبهم.

تدعم ميزات FoneClaw هذا الاتجاه عبر إجراءات محكومة وسياق شاشة وأدوات Android مدعومة، بينما تعرض صفحة تنزيل FoneClaw معلومات التثبيت الحالية. نستخدم أحدث معلومات المنتج المتاحة وقت تحديث المقال دون تحويلها إلى رقم إصدار داخل النص، لأن القارئ يحتاج معرفة السلوك الحالي لا حفظ تسمية داخلية.

ما نتعلمه من أنظمة متعددة الوكلاء لأمن ومراجعة البرمجيات هو أن الثقة تأتي من التصميم القابل للفحص. نحن نبني نحو وكيل هاتف يشرح ما يفعله، يطلب الموافقة عندما يتغير الأثر، ويفصل بين الاقتراح والتحضير والتنفيذ. هذه ليست نفس بنية وكلاء مراجعة الكود، لكنها تستفيد من نفس قواعد الملكية والاحتواء.

قائمة إصدار لمراجعة كود متعددة الوكلاء

استخدم هذه القائمة قبل دمج تغيير اعتمد على وكلاء مراجعة الكود أو منفذين آليين. لا تضمن القائمة الأمان وحدها، لكنها تجعل الفشل أوضح وتجبر النظام على إنتاج دليل قابل للمراجعة.

• قبل التشغيل: عرّف مالك المهمة، نطاق التهديد، الملفات الحساسة، والأدوات المسموحة لكل وكيل.
• أثناء التشغيل: افصل مساحة العمل، امنع تضارب الموارد، وسجل قرارات الوكلاء المهمة دون إغراق السجل بالضوضاء.
• قبل الدمج: اجعل المراجع المستقل يقدم اعتراضاته النهائية، وافحص diff والاختبارات والأسرار والاعتمادات والصلاحيات.
• عند الخلاف: لا تستخدم إجماع الوكلاء كحكم نهائي؛ ارجع إلى الدليل ومالك الدمج.
• بعد الحادث: اعزل الأثر، أوقف المهام المتبقية، احفظ السجلات، ثم حدّث الحدود والاختبارات وخطة الرجوع.

الخلاصة أن حوكمة الوكلاء المتعددين لا تبدأ بعد وقوع الخطأ. تبدأ من تصميم الأدوار والموارد وقنوات التواصل وسلطة الرفض. عندما تبقى النتائج المستقلة مرئية عند وقت الدمج، تصبح الأنظمة متعددة الوكلاء أداة مراجعة أقوى بدل آلة توافق أسرع.