ما هو وضع خطة GitHub Copilot
يوفر GitHub Copilot في تعليمة Visual Studio برمجية ثلاثة وكلاء مدمجين، كل منهم يعمل تحت مستوى مختلف من الاستقلالية وله علاقة مختلفة بمساحة عملك:
- الوكيل: وكيل تنفيذ مستقل بالكامل. يقوم بتفكيك الهدف إلى مهام فرعية، وينفذ استدعاءات الأدوات (قراءة الملفات، الكتابة، أوامر الطرفية، استدعاءات خوادم MCP)، ويطبق التغييرات مباشرة على مساحة العمل الخاصة بك. تستمر حلقة الوكيل حتى يتحقق الهدف أو تصل إلى غموض لا يمكن حله.
- اسأل: وكيل أسئلة بدون حالة مع وصول إلى مساحة العمل للقراءة فقط. يمكنه التفكير في كودك، شرح المفاهيم، واقتراح الأساليب، لكنه لا يكتب أو ينفذ أي شيء.
- الخطة: عامل يعتمد على التفكير أولا ويعمل في نموذج متعمد ذو مرحلتين. يأتي البحث والتركيب أولا، ثم التنفيذ، مع وجود بوابة مراجعة بشرية إلزامية بين المرحلتين.
التمييز الذي يهم في عمل العمليات لا يقتصر فقط على السلامة. الأمر يتعلق بمكان الحكم البشري في الحلقة الوكائلية. مع الوكيل، تراجع المخرجات بعد الحدث. مع وكيل الخطة، تقوم بمراجعة النهج والموافقة عليه قبل إجراء استدعاء أداة واحد يعدل الوضع.
كيف يعمل وكيل الخطة داخليا
وكيل الخطة هو مثال على نمط وكالتي أوسع يسمى التخطيط والتنفيذ، حيث يتم فصل التفكير فيما يجب فعله عن التنفيذ. فهم كيفية جمع الوكيل للمعلومات في كل مرحلة يساعدك على كتابة محفزات أفضل وتفسير مخرجاته بشكل أكثر نقدية.
المرحلة الأولى: جمع السياق
عندما تقدم طلبا، لا يقوم وكيل الخطة بإنشاء خطة فورا. يبدأ أولا ببناء نموذج سياق لبيئتك عن طريق استدعاء مجموعة من أدوات القراءة فقط بالتتابع:
- تعداد ملفات مساحة العمل: يقوم الوكيل بمسح شجرة ملفات مساحة العمل الخاصة بك لفهم هيكل المشروع. ما هي اللغات والأطر وملفات التكوين الموجودة.
-
الملف المستهدف: بناء على شجرة الملفات، يقرأ الوكيل الملفات ذات الصلة بطلبك. بالنسبة لموجه البنية التحتية، يقرأ وحدات Bicep الموجودة، وملفات المعلمات، وأي
bicepconfig.json. بالنسبة لموجه PowerShell، يقرأ السكريبتات الموجودة، وقوائم الوحدات، والتكوينPSScriptAnalyzer. -
تعليمات مخصصة: يقرأ
.github/copilot-instructions.mdالوكيل إذا كان موجودا في جذر مساحة العمل. يعامل هذا الملف كسياق موثوق يشكل كل خطة ينشئها الوكيل في تلك المساحة الذهنية. -
ذاكرة الجلسة: يقرأ
/memories/session/الوكيل لالتقاط أي سياق من نفس المحادثة سابقا. الخطط السابقة، الإجابات على الأسئلة التوضيحية، أو الحقائق التي ذكرتها سابقا.
لا يتم إجراء أي مكالمات شبكة خارجية إلى مواقع التوثيق أو واجهات برمجة التطبيقات خلال هذه المرحلة. معرفة الوكيل بخدمات Azure أو واجهات PowerShell أو بناء جملة Bicep تأتي من بيانات التدريب الخاصة به، وليس من عمليات البحث الحية.
المرحلة الثانية: توضيح الأسئلة
إذا كان السياق المجمع في المرحلة الأولى غير كاف لإنتاج خطة واضحة، يطرح الوكيل أسئلة توضيحية. هذه الأسئلة لا تولد بشكل عشوائي. تتوافق هذه النقاط مع نقاط قرار في التنفيذ حيث تؤدي الإجابات المختلفة إلى خطط مختلفة ذات معنى.
بالنسبة لمحفز العمليات، تشمل نقاط القرار النموذجية:
- النطاق: أي اشتراك أو مجموعة موارد أو خادم مستهدف؟
- التبعيات: هل يحتاج المورد الجديد إلى الإشارة إلى شيء موجود بالفعل، أم يجب أن ينشئ تبعياته الخاصة؟
- القيود: هل هناك قواعد تسمية، أو متطلبات امتثال، أو حدود ميزانية تستبعد بعض الأساليب؟
- استراتيجية الاختبار: هل يجب أن تتضمن الخطة خطوة تحقق أولية أو "ماذا لو"، وإذا كان الأمر كذلك، في أي بيئة ممكنة؟
جودة الأسئلة التي يطرحها الوكيل هي إشارة مفيدة. إذا لم يطرح الوكيل أسئلة توضيحية وأعد فورا خطة لموضوع معقد وغير محدد، تعامل مع الخطة الناتجة بعناية أكبر. لقد وضع افتراضات قد لا تتناسب مع بيئتك.
المرحلة 3: توليف الخطة
مع وجود سياق كاف، يقوم الوكيل بتركيب خطة منظمة. وهذا يتطلب التفكير حول:
- ترتيب التبعيات: ما هي الموارد أو خطوات التكوين التي يجب إنشاؤها قبل أن يتمكن الآخرون من الرجوع إليها.
- سطح المخاطر: أي الخطوات قابلة للعكس وأيها لا، وأين يجب وضع بوابات التحقق.
- محاذاة الأدوات: أي Azure CLI أوامر أو أوامر PowerShell أو Bicep التركيبات مناسبة بالنظر إلى القيود وأي أنماط موجودة في مساحة العمل.
- إغلاق التحقق: ما هي الأدلة التي تؤكد نجاح كل خطوة، وكيف يمكن جمع تلك الأدلة دون تدخل بشري.
يتم كتابة /memories/session/plan.md مخرجات الخطة تلقائيا، مما يجعلها متاحة للرجوع إليها طوال بقية المحادثة.
المرحلة 4: التكرار
الخطة ليست نهائية بعد الجيل الأول. كل طلب متابعة تقدمه يجعل الوكيل يعيد الدخول في مرحلة التوليف مع السياق المحدث. بما في ذلك الخطة السابقة، وملاحظاتك، وأي قيود جديدة أدخلتها، يتم أخذها في الاعتبار. العميل لا يعيد البدء من الصفر؛ يعامل الخطة السابقة كمسودة سابقة يمكن تعديلها.
هذه الحلقة التكرارية هي المكان الذي يكسب فيه وضع الخطة معظم قيمته في العمل التشغيلي. يمكن دمج المتطلبات التي تظهر أثناء المحادثة دون فقدان السياق الذي تم تأسيسه في الأدوار السابقة.
الوصول إلى وكيل الخطة
يمكنك الوصول إلى وكيل الخطة بطريقتين:
-
اختيار الوكلاء: افتح عرض الدردشة (
Ctrl+Alt+I)، واختر خطة من قائمة الوكلاء. -
أمر Slash: اكتب
/planمتبوعا بوصف مهمتك في مربع إدخال الدردشة. على سبيل المثال:
/plan Create a PowerShell script to audit all expired user accounts in Active Directory
كيف تبدو الخطة
عندما ينشئ وكيل الخطة خطة، عادة ما ينتج ثلاثة أقسام:
- الملخص: نظرة عامة عامة على ما تحققه الخطة والنهج الذي تتبعه. مكتوبة لتكون مفهومة من قبل المنفذين التقنيين وأصحاب المصلحة غير التقنيين على حد سواء.
- خطوات التنفيذ: مهام مرتبة تصف الملفات التي يجب إنشاؤها أو تعديلها، وأي كود يجب كتابته، وكيفية اتصال المكونات ببعضها البعض. يتم ترتيب الخطوات لاحترام التبعيات. على سبيل المثال، يجب أن توجد شبكة فرعية قبل أن يتمكن NSG من الإشارة إليها.
-
خطوات التحقق: إجراءات للتأكد من أن التنفيذ يعمل بشكل صحيح، مثل تشغيل
az deployment what-ifأو التحقق من الامتثال ل DSC معTest-DscConfiguration، أو التحقق من صحة المورد بعد النشر. يتم تحديد نطاق خطوات التحقق بحيث يمكن تنفيذها دون الحاجة إلى وصول الإنتاج.
على سبيل المثال، إذا طلبت من وكيل Plan إنشاء سياسة وسم مجموعة موارد Azure، قد تتضمن الخطة خطوات لإنشاء ملف JSON لتعريف السياسة، وتعيين السياسة لمجموعة إدارة، والتحقق من الامتثال عن طريق تشغيل أمر Azure CLI.
أين تخزن المخططات
يقوم وكيل الخطة تلقائيا بحفظ خطة التنفيذ الخاصة به في ملف ذاكرة الجلسة عند /memories/session/plan.md. يمكنك الوصول إلى هذا الملف عن طريق تشغيل أمر Chat: Show Memory Files في لوحة الأوامر واختيار plan.md. نظرا لأن ذاكرة الجلسة تمسح عند انتهاء المحادثة، فإن الخطة لا تكون متاحة في الجلسات اللاحقة. إذا كنت بحاجة للحفاظ على خطة، قم بنسخها إلى ملف في مستودعك قبل إغلاق الجلسة.
وضع الخطة مقابل وضع الوكيل
الفرق بين وضع الخطة ووضع الوكيل ليس في الأساس في القدرات. كلاهما يمتلك الوصول إلى نفس النموذج الأساسي. الفرق يتعلق بموقع بوابة المراجعة البشرية في الحلقة الوكائلية وعقد التأثير الجانبي الذي يعمل تحت مظله كل وضع.
| Dimension | وكيل الخطة | عامل |
|---|---|---|
| الآثار الجانبية أثناء التفكير | لا أحد؛ للقراءة فقط | يكتب الملفات، ويشغل الأوامر، ويدعو الأدوات |
| بوابة المراجعة البشرية | قبل بدء أي تطبيق | بعد اكتمال التنفيذ (أو أثناء حدوث أخطاء) |
| قابلية عكس حالة منتصف المهمة | دائما قابل للعكس؛ لم تجر أي تغييرات | يعتمد على ما تم إعدامه |
| مناسب لسير عمل إدارة التغيير | نعم؛ الخطة هي القطعة الأثرية المقدمة للموافقة | لا؛ الناتج هو العنصر الأثري، الذي قد يكون قد تم تطبيقه بالفعل |
| استخدام نافذة السياق | أدنى؛ لا توجد نتائج استدعاء أداة من خطوات التنفيذ | أعلى؛ يجمع النتائج من استدعاءات الأدوات المنفذة |
| التعامل مع الغموض | يطرح الغموض كأسئلة قبل المتابعة | يفترض ويتقدم بالأعمال؛ قد يفشل أو يتطلب التراجع |
التأثير العملي على فرق العمليات هو التالي: عندما تتضمن المهمة موارد مترابطة متعددة، أو خطوات لا رجعة فيها (مثل تغييرات مخطط قاعدة البيانات أو تعديلات قواعد الجدار الناري)، أو تتطلب مسار موافقة موثق، فإن وضع الخطة هو الخيار الصحيح هيكليا، وليس فقط الخيار الأكثر أمانا.
استخدم وضع الوكيل عندما تكون المهمة محدودة، وحالة مساحة العمل قابلة للعكس بسهولة، والتكرار السريع أهم من النهج المعتمد مسبقا.
تسليم التنفيذ
بعد إنهاء الخطة، لديك عدة خيارات للمضي قدما:
- نفذ في نفس الجلسة: اختر بدء التنفيذ للسماح للوكيل بتنفيذ الخطة مباشرة في مساحة عملك. يستقبل الوكيل وثيقة الخطة كسياقه الأولي ويبدأ في تنفيذ خطوات التنفيذ.
- الاستمرار في Copilot CLI: اختر بدء التنفيذ>الاستمرار في Copilot CLI لتشغيل التنفيذ كجلسة خلفية. Copilot CLI ينشئ شجرة عمل Git؛ نسخة معزولة من مستودعك في الملف الحالي. لذا فإن التنفيذ يعمل ضد حالة نظيفة دون التأثير على شجرة العمل لديك.
- الاستمرار في وكيل سحابة: التسليم إلى وكيل سحابة Copilot يعمل على بنية GitHub التحتية. يقوم وكيل السحابة بتنفيذ الخطة الفعلية، ويفتح طلب سحب، وينشئ خط أنابيب CI/CD، ويؤسس سجل موافقة قابل للتدقيق.
آلية التسليم مهمة من الناحية المعمارية: مستند الخطة المكتوب عليه /memories/session/plan.md يصبح مواصفات مهمة وكيل التنفيذ. جودة وخصوصية الخطة تتحكم مباشرة في جودة التنفيذ. الخطة الغامضة تنتج تنفيذا غامضا، والخطة التي تحتوي على بوابات تحقق صريحة تتسبب في توقف وكيل التنفيذ للتحقق عند كل بوابة قبل المضي قدما.