यह पोस्ट स्वचालित रूप से अनुवादित की गई है। मूल संस्करण के लिए, यहाँ क्लिक करें.
कोडिंग एजेंट्स के लिए मिशन कंट्रोल: VS Code में एक एकीकृत अनुभव
एक ही कोडिंग सहायक को समझना आसान है। कई एजेंट्स जो अलग-अलग जगहों पर काम करते हैं, वह नहीं।
एक एजेंट VS Code में स्थानीय रूप से चलता है। दूसरा क्लाउड में एक GitHub समस्या पर काम करता है। एक CLI एजेंट टर्मिनल में रहता है। एक तृतीय-पक्ष कोडिंग एजेंट के पास एक अलग सेशन मॉडल और अलग सीमाएं हो सकती हैं। साझा दृश्य के बिना, डेवलपर्स काम की देखरेख करने की तुलना में अधिक समय ट्रैकिंग में बिताते हैं।
VS Code का एकीकृत एजेंट अनुभव एजेंट सेशन के साथ उस समन्वय समस्या को हल करता है: एजेंट्स लॉन्च करने, उनकी स्थिति देखने, उनकी बातचीत खोलने और योजना बदलने पर हस्तक्षेप करने के लिए एक जगह।
यह एक अन्य एजेंट जोड़ने की तुलना में कई एजेंट्स को प्रबंधनीय बनाने के बारे में अधिक है।
विभिन्न प्रकार के कार्य के लिए एक दृश्य
स्रोत लेख चार अलग प्रतिभागियों का वर्णन करता है: स्थानीय GitHub Copilot, क्लाउड में Copilot कोडिंग एजेंट, GitHub Copilot CLI, और योग्य Copilot सदस्यों के लिए OpenAI Codex।
उनकी शक्तियां अलग-अलग हैं:
- एक स्थानीय एजेंट वर्तमान वर्कस्पेस की जांच कर सकता है और तेजी से परिवर्तन कर सकता है।
- एक क्लाउड कोडिंग एजेंट एक समस्या पर अतुल्यकालिक रूप से काम कर सकता है और एक pull request खोल सकता है।
- एक CLI एजेंट टर्मिनल-भारी वर्कफ़्लो और परिचालन आदेशों के लिए उपयुक्त है।
- दूसरा प्रदाता एक अलग मॉडल या तर्क शैली प्रदान कर सकता है।
एजेंट सेशन उन कार्यों को एक सामान्य घर देता है। आप देख सकते हैं कि क्या चल रहा है, यह क्या कर रहा है, और बातचीत को कहां उठाया जाए।
वह दृश्यमानता महत्वपूर्ण है क्योंकि स्वायत्त कार्य समन्वय को हटाता नहीं है। यह समन्वय को एक प्रथम-श्रेणी इंजीनियरिंग कार्य बनाता है।
बाधाएं वर्कफ़्लो का हिस्सा हैं
स्रोत एक सरल अवलोकन करता है: “प्रॉम्प्ट भेजना और महसूस करना सामान्य है कि आप कुछ महत्वपूर्ण भूल गए हैं।” पहले, विकल्प अक्सर प्रतीक्षा करना या रद्द करना था। चैट संपादकों के साथ, आप एक सक्रिय सेशन खोल सकते हैं और एजेंट के काम करते समय जानकारी जोड़ सकते हैं।
यह वास्तविक सहयोग के करीब है। आवश्यकताएं बदलती हैं। एक परीक्षण एक धारणा को प्रकट करता है। एक समीक्षक नोटिस करता है कि एक API पिछड़ा संगत रहना चाहिए। उपयोगी एजेंट वह नहीं है जिसे कभी सुधार की आवश्यकता नहीं है; यह वह है जो बिना पूरे कार्य को खोए सुधार को अवशोषित कर सकता है।
.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.
मुख्य एजेंट कार्यान्वयन पर केंद्रित रहता है जबकि अनुसंधान एजेंट एक संकीर्ण प्रश्न को संभालता है। यही सिद्धांत टीमों पर भी लागू होता है: स्पष्ट प्रतिनिधिमंडल कई एजेंट्स को अतिव्यापी अधिकार के साथ शुरू करने की तुलना में बेहतर परिणाम देता है।
चेतावनी: अधिक एजेंट्स का मतलब अधिक समन्वय है
एजेंट सेशन गतिविधि दिखा सकते हैं, लेकिन यह संघर्षपूर्ण स्वामित्व को हल नहीं कर सकता। दो एजेंट्स एक ही क्षेत्र को संपादित कर सकते हैं फिर भी एक मर्ज समस्या बना सकते हैं। एक क्लाउड एजेंट और एक स्थानीय एजेंट असंगत धारणाएं बना सकते हैं। एक कस्टम एजेंट एक सिफारिश तैयार कर सकता है जिसे दूसरा एजेंट नजरअंदाज करता है।
सीमाएं निर्धारित करें:
- एक एजेंट किसी दिए गए शाखा के लिए कार्यान्वयन का मालिक है।
- अनुसंधान एजेंट्स कलाकृतियां लौटाते हैं, अनट्रैक किए गए संपादन नहीं।
- Pull requests समीक्षा सीमा बनी रहती हैं।
- एजेंट नाम और प्रॉम्प्ट बताते हैं कि वे क्या बदल सकते हैं।
- सेशन आउटपुट बनाए रखा जाता है जब यह एक महत्वपूर्ण निर्णय की व्याख्या करता है।
मेरा दृष्टिकोण
बहु-एजेंट भविष्य चैट विंडो की कतार नहीं है। यह भूमिकाओं, हस्तांतरण, और जवाबदेही वाली एक छोटी टीम है।
एजेंट सेशन मूल्यवान है क्योंकि यह उस वास्तविकता को स्वीकार करता है। यह डेवलपर्स को ऐसे कार्य के लिए एक नियंत्रण सतह देता है जो पहले से ही संपादक, टर्मिनल, और क्लाउड में हो रहा है। अगला उत्पादकता लाभ अधिक एजेंट्स से कम और उनकी सीमाओं को पठनीय बनाने से अधिक आएगा।
एक .NET टीम के लिए, मैं एक योजना एजेंट और एक कार्यान्वयन एजेंट के साथ शुरू करूंगा। योजना आउटपुट को मुद्दे या pull request विनिर्देश के रूप में उपयोग करें, फिर कार्यान्वयन एजेंट को उस सीमा के अंदर काम करने दें। अधिक भूमिकाएं जोड़ने से पहले पुनः कार्य को मापें।
सर्वोत्तम मिशन कंट्रोल अभी भी वह है जो स्वामित्व को स्पष्ट बनाता है।
