Mission Control للعوامل البرمجية: تجربة موحدة في VS Code

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

تمت ترجمة هذا المنشور تلقائيًا. للنسخة الأصلية، انقر هنا.

Mission Control للعوامل البرمجية: تجربة موحدة في VS Code

يسهل فهم عامل مساعد برمجي واحد. لكن عدة عوامل تعمل في أماكن مختلفة ليس كذلك.

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

تعالج تجربة VS Code الموحدة للعوامل مشكلة التنسيق هذه من خلال جلسات العوامل: مكان واحد لتشغيل العوامل ورؤية حالتها وفتح محادثاتهم والتدخل عندما يتغير الخطة.

هذا يتعلق أقل بإضافة عامل آخر وأكثر بجعل عدة عوامل قابلة للإدارة.

عرض واحد لأنواع مختلفة من العمل

تصف المقالة الأصلية أربعة مشاركين مختلفين: GitHub Copilot المحلي، وعامل Copilot البرمجي في السحابة، و GitHub Copilot CLI، و OpenAI Codex لمشتركي Copilot المؤهلين.

لديهم نقاط قوة مختلفة:

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

توفر جلسات العوامل بيتًا مشتركًا لتلك المهام. يمكنك رؤية ما يعمل وما يفعله وأين يمكنك متابعة المحادثة.

هذا الوضوح مهم لأن العمل المستقل لا يزيل التنسيق. إنه يجعل التنسيق مهمة هندسية من الدرجة الأولى.

المقاطعات جزء من سير العمل

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

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

بالنسبة لعمل .NET، قد تكون المقاطعة بسيطة مثل:

Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.

التعليمات قصيرة لأن المستودع يحمل بالفعل السياق الأكبر. الجلسة هي المكان لتصحيح الاتجاه، وليس لإعادة صياغة النظام بأكمله.

العوامل المخصصة تحول عادات الفريق إلى أدوار

يقدم VS Code أيضًا عوامل متخصصة مثل Plan. بدلاً من التنفيذ فورًا، يطرح عامل التخطيط أسئلة حول النطاق والمكونات والمكتبات والقيود قبل إنتاج مواصفات التنفيذ.

هذا النمط مفيد خارج عامل مدمج. يمكن للفريق تحديد أدوار مركزة:

البحث يجمع الأدلة ويكتب سجل قرار قصير.
المراجعة تحقق من التغيير مقابل اتفاقيات المستودع.
الاختبار يحدد الحالات المفقودة ويقترح خطة اختبار.
الهندسة المعمارية تقارن الخيارات دون تعديل الملفات.

قد يبدو تعريف عامل مخصص صغير مثل هذا:

type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
 Ask about scope, constraints, existing patterns, and edge cases.
 Produce a concise specification before any implementation begins.

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

العوامل الفرعية تقلل تصادمات السياق

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

هذا ملاءمة جيدة لأسئلة مثل:

Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.

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

التحذير: عدد أكبر من العوامل يعني المزيد من التنسيق

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

حدد الحدود:

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

رأيي

مستقبل الوكالات المتعددة ليس طابور نوافذ الدردشة. إنه فريق صغير له أدوار وتسليمات ومسؤولية.

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

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

أفضل مراقبة مهمة هي التي تجعل الملكية واضحة.

Codex | The .NET Blog

Mission Control للعوامل البرمجية: تجربة موحدة في VS Code

Mission Control للعوامل البرمجية: تجربة موحدة في VS Code

عرض واحد لأنواع مختلفة من العمل

المقاطعات جزء من سير العمل

العوامل المخصصة تحول عادات الفريق إلى أدوار

العوامل الفرعية تقلل تصادمات السياق

التحذير: عدد أكبر من العوامل يعني المزيد من التنسيق

رأيي