معظم أنظمة الأذونات الخاصة بوكلاء البرمجة تعتمد على قوائم السماح: قراءة الملفات نعم، كتابة الملفات نعم، تشغيل الاختبارات نعم، وكل ما عدا ذلك يتطلب السؤال. ينجح هذا الأسلوب إلى أن يصنف شخص ما الوكيل بأنه «موثوق بالكامل» للتخلص من كثرة المطالبات، فيقوم الوكيل بتشغيل git push --force بعد ظهر يوم الجمعة.
موقفنا هو أن أربع فئات من الإجراءات يجب أن تتوقف لطلب إذن بشري في كل مرة، بصرف النظر عن مدى الثقة في الوكيل أو في صاحب الطلب. مستويات الثقة تحدد كمية الأشياء الأخرى التي تحتاج إلى موافقة. أما هذه الفئات الأربع فلا تمر أبدًا في صمت.
الفئات الأربع
1. الدفع إلى فرع مشترك. الالتزام (commit) على فرع ميزة هو مجرد اقتراح. أما الدفع (push) إلى main أو release فهو قرار يرثه الفريق بأكمله، وغالبًا ما يرتبط به نشر للخدمة. السؤال عنه غير مكلف، لكن التراجع عنه باهظ الثمن.
2. الحذف. ملفات، وفروع، وجداول، ووحدات تخزين (buckets)، وموارد. الحذف هو العملية الوحيدة التي لا يمكن فيها التراجع عن تخمين خاطئ للنية عبر تخمين ثانٍ. الوكلاء واثقون من أنفسهم، والحذف الواثق هو الطريقة التي تُختبر بها النسخ الاحتياطية عمليًا.
3. إنفاق المال. استدعاء واجهة برمجة تطبيقات مدفوعة، أو حجز مورد، أو شراء نطاق، أو إرسال حملة بريدية. الشخص الذي أرسل الطلب قد لا يعلم أن طلبه يكلّف أي شيء، لكن الشخص الذي يدفع الفاتورة يجب أن يعلم.
4. التعامل مع بيانات الاعتماد. قراءة ملف مفاتيح، أو تصدير متغيرات البيئة، أو تسجيل الدخول إلى خدمة، أو إتمام المصادقة الثنائية. أي شيء هنا يتعلق بالهوية، والهوية ملك لمالك الجهاز، وليست لأي شخص موجود في الغرفة.
لماذا يجب على وضع «الثقة الكاملة» أن يتوقف هنا أيضًا
يصف وضع الإذن علاقة الشخص بالوكيل: للقراءة فقط، أو التعديل دون دفع، أو الثقة الكاملة. هذا هو مستوى الدقة المناسب لمئات الاستدعاءات العادية التي يجريها الوكيل في الجلسة الواحدة. لكنه مستوى الدقة الخاطئ للفئات الأربع المذكورة أعلاه، لأنها نادرة أو غير قابلة للإلغاء أو باهظة التكلفة، ولأن التكلفة تقع على عاتق شخص آخر غير صاحب الطلب.
لذا فإن القاعدة في muti بسيطة: لا يمكن لأي قالب أذونات أن يضبط هذه الفئات الأربع لتعمل بصمت. حتى في وضع «الثقة الكاملة»، تتوقف وتُبرز في الخط الزمني. تكون المطالبة نادرة بما يكفي لئلا تكون مزعجة، وتكون الفئات دقيقة بما يكفي ليكون الجواب بديهيًا في العادة.
كيف ينعكس هذا على أوضاع أذونات Claude Code
يمتلك Claude Code بالفعل تدرجًا في الصلاحيات: plan (للقراءة فقط)، وdefault (السؤال قبل التعديلات والأوامر)، وacceptEdits (تنفيذ التعديلات والسؤال قبل الأوامر)، وbypassPermissions (لا يسأل عن شيء). تصف هذه الأوضاع مدى سؤال الوكيل لك أنت. بينما تصف الإجراءات الأربعة ما يجب أن يسأل المالك حين يطلب شخص آخر ذلك. وكلاهما يتكامل مع الآخر.
العمود الأخير هو ما تضيفه الغرفة، وهو نفسه في كل صف. راجع أوضاع الأذونات بالتفصيل.
من الذي ينبغي سؤاله
هذا هو الجزء الذي تتجاهله معظم التصاميم. عندما يحتاج وكيل مشترك إلى إنسان، أي إنسان تحديدًا؟
- بيانات الاعتماد تذهب إلى المالك. تسجيلات الدخول، ورموز المصادقة الثنائية، والوصول إلى المفاتيح تتعلق بهوية المالك. لذا تُوجّه إلى المالك بصرف النظر عمن بدأ المهمة. يرى صاحب الطلب حدوث استلام للمهمة، ولا يرى السر نفسه.
- الأسئلة المتعلقة بالنية تذهب إلى صاحب الطلب. سؤال مثل «هل قصدت قاعدة بيانات staging؟» يتعلق بما كان الشخص يريده. لذا يُوجّه إلى من قدّم الطلب.
- كلاهما يرى الخط الزمني نفسه. لا يحتاج أي منهما إلى نقل السياق إلى الآخر؛ فالسؤال وإجابته يوجدان في المحادثة نفسها مع مجريات العمل.
تُوجّه مطالبات بيانات الاعتماد والإجراءات الخطيرة إلى المالك؛ وتُوجّه أسئلة النية إلى صاحب الطلب؛ وكلاهما يرى التفاعل.
تشريح بطاقة الموافقة الجيدة
الموافقة التي يمكن للشخص اتخاذ قرار بشأنها في خمس ثوانٍ تتكون من خمسة أجزاء.
وفّر ثلاثة أزرار: Approve، وDecline، والمتابعة للقراءة فقط. الخيار الثالث يستهان بقيمته كثيرًا؛ فهو يسمح للعمل بالاستمرار بينما تنتظر الخطوة الخطرة البت فيها.
اجعل الرد على الموافقات متاحًا في أي مكان يتواجد فيه المالك بالفعل: سطر الأوامر، أو الهاتف، أو بطاقة تفاعلية على منصة الدردشة. يجب أن يسري القرار المتخذ في مكان واحد على كل الأماكن. واضبط وقت انتهاء للصلاحية حتى لا تُنفّذ بطاقة منسية بعد أسبوع.
إرهاق الموافقات هو العدو الحقيقي
كل مطالبة تظهر تُدرّب الشخص الذي يراها. فإذا زادت عن الحد، سيبحث عن الإعداد الذي يعطّلها تمامًا. ثلاثة أمور تحافظ على بقاء المعدل منخفضًا دون التساهل في القواعد الأربع:
- حدد نطاق الوكيل. تخصيص دليل عمل واحد لكل وكيل يعني تقليل عدد الملفات التي يمكنه لمسها، وبالتالي تقليل المطالبات المتعلقة بلمسها.
- استخدم الأوضاع العادية للاستدعاءات العادية. وضع القراءة فقط للاستكشاف، والتعديل دون دفع لمعظم الأعمال. واحتفظ بوضع «الثقة الكاملة» للأشخاص الذين تسمح لهم أصلًا بالكتابة على لوحة مفاتيحك.
- اجعل القوالب الافتراضية واضحة وصريحة. وفّر قوالب معدّة مسبقًا ومسماة بوضوح: القراءة فقط، والتعديل دون دفع، والثقة الكاملة؛ حتى لا يضطر أحد لبناء سياسة أمان من الصفر ويقع في أخطاء.
سجل التدقيق
يجب أن ينتج عن كل طلب وكل موافقة سطر واحد يمكن للمالك تصديره: صاحب الطلب، ومتخذ القرار، والتوقيت، والقاعدة المستدعاة، وما حدث، والموارد المستخدمة. ليس لأن هناك من سيقرأه يوميًا، بل لأن اليوم الذي يحدث فيه خطأ ليس اليوم المناسب لبدء التسجيل.
الأسئلة الشائعة
ألا يؤدي السؤال في كل مرة إلى إبطاء الوكيل؟ فقط في هذه الفئات الأربع، وهي نادرة في الجلسة العادية. تكلفة التوقف المؤقت تُقاس بالثواني، بينما تُقاس تكلفة الخطأ بالساعات أو بالمال.
ماذا عن استخدام المالك لوكيله الخاص؟ لا يخضع المالك لأوضاع الأذونات على وكيله الخاص، ولكن الإجراءات الأربعة تظل مسجلة في الخط الزمني ليبقى السجل مكتملًا.
هل يمكن لصاحب الطلب الموافقة لنفسه؟ لا. الموافقة من حق مالك الجهاز حصريًا. يمكن لصاحب الطلب الإلغاء (Cancel)، أو إعادة المحاولة، أو إضافة سياق توضيحي.
تأتي الغرف في muti بهذه القواعد مفعلة افتراضيًا ودون أي طريقة لإيقافها. إذا كان هذا يبدو لك الإعداد الافتراضي الصحيح، فامنح وكيلك غرفة الآن.
نُشر في · حُدّث في