← مقالات

الحدود بدل التعليمات: كيف تحافظ على السيطرة على وكلاء الذكاء الاصطناعي المستقلين

لماذا لا يمكن بناء السيطرة على وكلاء الذكاء الاصطناعي على التعليمات في الـ prompt — وكيف تبنيها على حدود تقنية. خمس حوادث في جلسة واحدة.

5 دقائق للقراءة
Telegramالأصل
الحدود بدل التعليمات: كيف تحافظ على السيطرة على وكلاء الذكاء الاصطناعي المستقلين

كلما أصبح وكلاء الذكاء الاصطناعي أكثر استقلالية، كلما حاولنا التحكم بهم بالطريقة المعتادة — نكتب قواعد في الـ prompt: «لا تلمس هذا»، «اعمل هناك فقط»، «لا تفعل ذلك أبدًا». خلال تجربة مع ثلاثة وكلاء متوازين جمعت في يومين مجموعة حية من الحالات التي تنكسر فيها هذه الطريقة — والتي تعمل فيها طريقة أخرى. أطروحة المقال بسيطة: التعليمات طلب ينفذه الوكيل باحتمالية معينة؛ الحدود خاصية للنظام لا تعتمد على الطاعة. عندما كان الوكيل واحدًا ويعمل تحت الإشراف، بدا الفرق أسلوبيًا. عندما أصبح الوكلاء كثيرين، اتضح أنه معماري.

خمس حوادث في جلسة واحدة

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

لم تكن هناك تعليمات — فحدث حادث. الوكيل، استعدادًا لمهمته، نفّذ git stash في الدليل العام وأخذ إلى الـ stash ملفاتي غير الملتزم بها التي لا علاقة لها بمهمته. لم «يخالف» أحد شيئًا: لم يكن هناك منع أصلًا. هذه خاصية جوهرية للتعليمات — تُكتب بعد الحوادث. القائمة الكاملة لما لا يجب أن يفعله الوكيل لا يمكن كتابتها.

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

حدود تقنية عملت بصمت. في التجربة نفسها لم يحدث أبدًا الحادث الأكثر توقعًا — «وكيل بدّل الفرع للجميع». ليس لأن الوكلاء كانوا حذرين، بل لأن git worktree لا يسمح فيزيائيًا بتسجيل فرع واحد في نسختي عمل. الحماية مدمجة في الأداة. لا تحتاج أن تتذكرها، ولا تحتاج أن تتبعها — هي موجودة فقط.

كانت التعليمات في مكان يجب أن تكون فيه الحدود. الاكتشاف الأكثر إزعاجًا: كان إنتاج هذه المدونة محميًا بسطر في الـ prompt. الـ push إلى master يشغّل النشر التلقائي، ولم يفصل بينه وبين كل وكيل سوى نص «لا git push». صمد — لكن هذا حظ، لا سيطرة: الحدود الحقيقية هنا هي صلاحيات الوصول، protected branch، token بلا حق كتابة. كان الطلب في مكان القفل.

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

المبدأ ليس جديدًا — الجديد هو الكيان فقط

مرّت الهندسة بهذا الدرس قبل LLM بوقت طويل. في نظام تويوتا الإنتاجي يُسمى المبدأ poka-yoke: جهاز العملية يمنع الخطأ، لا يقظة المنفّذ. قطعة لا يمكن إدخالها إلا بالاتجاه الصحيح أكثر موثوقية من لافتة «أدخلها بالاتجاه الصحيح». في هندسة المنصات يُسمى الشيء نفسه guardrails، وفي الأمن — defense in depth. في كل مكان فكرة واحدة: لا تعتمد على أن المنفّذ قرأ وفهم ولم ينسَ — اجعل الإجراء الخاطئ مستحيلًا أو مكلفًا.

“التعليمات طلب. الحدود خاصية للنظام. السيطرة التي تقوم على الطلبات ليست سيطرة، بل حظ بتراكم تراكمي.”

– الاستنتاج الرئيسي من يومين من العمل مع وكلاء متوازين

مع وكلاء الذكاء الاصطناعي يصبح هذا المبدأ القديم أكثر حدة لثلاثة أسباب. الوكلاء كثيرون — احتمالية فشل التعليمات تتضاعف مع كل تشغيل لكل وكيل. الوكلاء سريعون — بين «بدأ يخطئ» و«أفسد الأمر» تمر ثوانٍ، لا يلحق الإنسان بالتدخل. والوكلاء حرفيون لكنهم غير موثوقين: ينفذون نص الـ prompt بجدية أكبر من أي مبتدئ، ومع ذلك باحتمالية — والالتزام الاحتمالي بالقواعد على نطاق واسع يضمن المخالفة.

كيف تبدو الحدود عمليًا

الطبقات التي بنيتها بعد هذه الجلسة — من نظام الملفات إلى التحقق:

  • نظام الملفات: لكل وكيل — نسخة عمل خاصة به (git worktree، الذي توصي به Anthropic للجلسات المتوازية، وهو مدمج في Claude Code)، وعلى مستوى نظام التشغيل — sandbox: sandboxing في Claude Code يعزل نظام الملفات والشبكة بأدوات نظام التشغيل القياسية — وفقًا لبيانات Anthropic، قلّل ذلك طلبات الصلاحيات الداخلية لديهم بنسبة 84%، ويبقى prompt-injection الناجح محبوسًا في الداخل.
  • صلاحيات الكتابة: prod و master محميان بالصلاحيات لا بالـ prompt — protected branch، رموز بلا حق push، حسابات منفصلة للوكلاء. يمكن أن تبقى الطلبات في الـ prompt، لكن كطبقة ثانية.
  • Runtime: worktree لا يعزل قواعد البيانات والمنافذ والحاويات — فهي مشتركة بين جميع النسخ. الوكلاء الذين يشغّلون الاختبارات والخوادم يحتاجون موارد لمرة واحدة: قاعدة بيانات مؤقتة، منفذ خاص، حاوية لكل وكيل.
  • أذونات الإجراءات: العمليات غير القابلة للتراجع تمر عبر تأكيد أو مصنّف — مثل auto mode في Claude Code، الذي يقيّم كل إجراء بدلًا من أن يسأل عن كل شيء أو لا يسأل عن أي شيء. هذه حدود لا تتحرك إلا بقرار صريح من الإنسان.
  • التحقق عبر الآثار: لا تثق بتقرير الوكيل عن نفسه، بل بالآثار على القرص. وكيلي المعلّق كان يبدو في الواجهة عاملًا؛ وقد شخّصه غياب ملفات جديدة في نسخته خلال عشرين دقيقة. الـ commits إلى فرعه الخاص هي الفكرة نفسها: نتيجة تصمد أمام الفشل وأمام تفاؤل الوكيل.

التعليمات في هذا المخطط لا تختفي — بل تصبح الطبقة الأخيرة لا الأولى. «اعمل في مجلدك» في الـ prompt ما زال مفيدًا: فهو يقلل تكرار المحاولات. لكن بين المحاولة والكارثة يجب أن تقف حدود لا أمل.

تحفظات صادقة

الحدود ليست مطلقة: تُتجاوَز البيئات المعزولة، ويخطئ المصنّفون، والتحليلات المنشورة للتجاوزات تُظهر ذلك بانتظام. لذلك تُبنى الحدود طبقات — كما كل شيء في الأمن. والحدود أغلى من التعليمات عند البداية: إعداد worktree والصلاحيات والبيئة المعزولة يستغرق ساعات، وكتابة سطر في الـ prompt ثوانٍ. عدم التماثل في مكان آخر: الحدود تُدفع مرة واحدة، والتعليمات — باحتمال فشل في كل تشغيل. عندي أثبت إعداد العزل جدواه من أول إعادة تشغيل للتجربة، التي مرّت دون أي تعارض.

الخلاصة

سؤال السلسلة — كيف ندمج وكلاء AI في العمل الحقيقي دون فقدان السيطرة. جواب هذه المقالة: السيطرة ليست ما يُكتب للوكيل، بل ما يُبنى حوله. قبل أن تضيف إلى الـ prompt «لا تفعل X أبدًا» أخرى، اسأل نفسك: هل يمكن جعل X مستحيلًا تقنيًا؟ إن كان الجواب نعم — فهذا هو المكان الصحيح للجهد. فليطلب الـ prompt؛ ولتمنع المنظومة.

المصادر والمراجع

← كل المقالات