एजेंट क्लाइंट प्रोटोकॉल (ACP)

 (agentclientprotocol.com)
15 पॉइंट द्वारा GN⁺ 2025-09-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Agent Client Protocol(ACP) कोड एडिटर और AI कोडिंग एजेंट्स के बीच कम्युनिकेशन को मानकीकृत करने के लिए बनाया गया एक प्रोटोकॉल है
  • पहले किसी एडिटर को किसी खास एजेंट से जोड़ने के लिए अलग कस्टम इंटीग्रेशन काम की ज़रूरत होती थी, जिससे कम्पैटिबिलिटी की सीमाएँ और डेवलपर lock-in जैसी समस्याएँ पैदा होती थीं
  • ACP, Language Server Protocol(LSP) की तरह एक मानकीकृत कम्युनिकेशन तरीका देता है, जिससे एक बार इम्प्लीमेंट करने पर सभी compatible एडिटर और एजेंट्स के बीच आसानी से कनेक्शन संभव हो जाता है
  • एडिटर में एजेंट को subprocess के रूप में चलाया जाता है, JSON-RPC over stdio से कम्युनिकेशन होता है, और UI एलिमेंट्स में diff display तथा Markdown-आधारित output का समर्थन मिलता है
  • अभी Zed, neovim(CodeCompanion plugin) आदि ACP को सपोर्ट करते हैं, और एजेंट पक्ष में Gemini CLI compatible है; आगे चलकर सपोर्ट का दायरा बढ़ने वाला है

परिचय

  • Agent Client Protocol(ACP) एक open protocol है, जिसे remote development, port forwarding, command execution जैसी server-client इंटरैक्शन्स को मानकीकृत करने के उद्देश्य से डिज़ाइन किया गया है
  • मौजूदा समस्या: AI कोडिंग एजेंट्स और एडिटर्स आपस में काफ़ी करीबी रूप से जुड़े होते हैं, लेकिन interoperability डिफ़ॉल्ट रूप से सुनिश्चित नहीं होती
    • हर एडिटर को जिन एजेंट्स को सपोर्ट करना हो, उनके लिए custom integration बनानी पड़ती है
    • एजेंट्स को यूज़र्स तक पहुँचने के लिए किसी खास एडिटर API को इम्प्लीमेंट करना पड़ता है
    • इससे integration overhead, सीमित compatibility, और डेवलपर निर्भरता जैसी समस्याएँ पैदा होती हैं
  • ACP का समाधान: ACP, एजेंट्स और एडिटर्स के बीच standardized protocol उपलब्ध कराता है
    • ACP इम्प्लीमेंट करने वाला एजेंट सभी compatible एडिटर्स में काम कर सकता है
    • ACP सपोर्ट करने वाला एडिटर, ACP-compatible एजेंट्स के पूरे ecosystem तक पहुँच सकता है
    • यह स्वतंत्र innovation को संभव बनाता है और डेवलपर्स को अपने workflow के लिए सबसे उपयुक्त टूल चुनने की आज़ादी देता है

ACP का अवलोकन

  • काम करने का तरीका: यूज़र मुख्य रूप से कोड एडिटर में काम करता है और किसी विशेष काम के लिए एजेंट को बुलाता है
    • एजेंट, एडिटर के subprocess के रूप में चलता है
    • कम्युनिकेशन के लिए stdio के माध्यम से JSON-RPC का उपयोग होता है
  • डेटा फ़ॉर्मैट: MCP के JSON फ़ॉर्मैट का पुन: उपयोग किया जाता है, और diff display जैसे एजेंट कोडिंग UX एलिमेंट्स के लिए custom types शामिल हैं
  • टेक्स्ट फ़ॉर्मैट: यूज़र की पढ़ने की सुविधा के लिए डिफ़ॉल्ट रूप से Markdown फ़ॉर्मैट का उपयोग किया जाता है
    • HTML rendering के बिना भी समृद्ध formatting संभव है
  • प्रोटोकॉल अभी विकासाधीन है, लेकिन दिलचस्प user experiences बनाने के लिए पर्याप्त रूप से परिपक्व है

वर्तमान समर्थन स्थिति

  • एडिटर
  • एजेंट
    • Gemini: Gemini CLI के माध्यम से ACP समर्थन
    • अतिरिक्त एजेंट समर्थन नियोजित है

निष्कर्ष

  • ACP, LSP की सफलता से प्रेरणा लेकर AI कोडिंग एजेंट्स और एडिटर्स के बीच interoperability में बड़ा सुधार लाता है
  • डेवलपर्स किसी खास एजेंट या एडिटर पर निर्भर हुए बिना, सर्वोत्तम टूल संयोजन को स्वतंत्र रूप से चुन सकते हैं
  • प्रोटोकॉल का विस्तार ecosystem scalability को बढ़ाता है और डेवलपर workflows की दक्षता तथा लचीलापन बेहतर कर सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-01
Hacker News की राय

  • Claude से AI agent और IDE/editor के बीच communication protocol बनाने को कहने, Node, Python, Rust libraries भी बनवाने, और landing page वाली website तक तैयार करवाने का ख़याल आया

    • सच कहूँ तो यह जाँचने का लालच है कि क्या Gemini इस protocol को implement करने वाला Sublime Text plugin इस्तेमाल कर सकता है। हाल में ज़्यादातर users VSCode की तरफ़ झुक रहे हैं, इसलिए नए tools अक्सर सिर्फ़ उसी का support देते हैं। मैं Sublime का support बंद होने की वजह से मजबूरन migrate नहीं करना चाहता। Sublime वाकई एक बेहतरीन editor है, और इसे किसी बड़ी company का backing भी नहीं है।

    • और अपने निशान छिपाने के लिए शायद ऐसा agent भी बनाया जा सकता है जो सिर्फ़ Gemini को support करे।

    • मज़ेदार है, काफ़ी self-centered इच्छा है।

  • उम्मीद है यह project बहुत सफल हो। Zed collaboration की बुनियाद की तरफ़ लौट रहा है, और लगता है यह रुझान agentic IDE category में भी बदलाव ला सकता है। ऐसा हुआ तो Zed को सीधे competition में समय लगाने की ज़रूरत नहीं पड़ेगी और उसका differentiation भी बनेगा। CLI agents के बीच इसे कितना adoption मिलेगा, यह जानने की उत्सुकता है। (Gemini CLI का पहले से integrate होना भी अच्छा लगा।) LLM और coding assistant बाज़ार में कड़ी competition हमेशा स्वागतयोग्य है। मुझे लगता है ऐसे बदलाव लगातार एक-दूसरे के बीच switching cost कम करते रहेंगे।

    • मैं भी लगभग Zed पर switch करने ही वाला हूँ। जिन features वाले editor की मैं कई सालों से तलाश कर रहा था, उनमें से लगभग सब इसमें हैं। कई शानदार features तो ऐसे हैं जिनकी मैंने कल्पना भी नहीं की थी। मौजूदा हालात से निराश होकर मैंने खुद editor का prototype बनाने की भी कोशिश की थी, लेकिन एक अच्छा editor बनाना वाकई बहुत मेहनत माँगता है। Zed ने वह मेहनत की है। उनके खुले तौर पर collaborate करने के प्रयास का स्वागत है।

    • मैं दिल से कह रहा हूँ, उम्मीद है यह बदलाव घटिया VS Code forks के ख़त्म होने का कारण बने। Zed को भी उसका हक़ का recognition मिलना चाहिए। लगता है AI editors ने सचमुच industry की सारी oxygen खींच ली है।

  • मैं Claude Code के लिए ACP इस्तेमाल करने वाला tool बना रहा हूँ (क्योंकि मैं CC और Zed अक्सर इस्तेमाल करता हूँ)। अभी तक Claude Code SDK और ACP Client library के साथ काफ़ी सफलता मिली है। अभी थोड़ा polish करना बाकी है, कल तक थोड़ा और सुधारकर इसे open करने का इरादा है।

  • agentcommunicationprotocol.dev नाम का एक ACP पहले से मौजूद है, इसलिए नाम को लेकर confusion हो सकता है। दोनों projects में फ़र्क़ है, फिर भी यह बात खटकती है।

    • मार्च 2025 में IBM ने Agent Communication Protocol (ACP) की घोषणा की थी, लेकिन अब उसने ACP नाम छोड़कर ACP से जुड़ा काम Google के Agent2Agent (A2A) protocol के साथ मिलाने का फ़ैसला किया है। यह फ़ैसला ऐसे समय आया है जब ACP की सारी development teams विघटन की ओर बढ़ रही हैं, और industry Linux Foundation के नेतृत्व में A2A को समर्थन देने की दिशा में जा रही है। इसका मक़सद AI agent standards के fragmentation से बचना और community-led open protocol पर एकजुट होना है। यहाँ विस्तार से देखें

  • मेरी सबसे बड़ी जिज्ञासा यह है कि LSP server या LSP protocol के extension से LLM की ज़रूरतों को क्यों कवर नहीं किया जा सकता।

    • क्योंकि LSP के दौर में AI boom नहीं था। AI इस समय कुछ वैसा दौर देख रहा है जैसा शुरुआती JavaScript libraries के विस्फोट का था, जहाँ ढेरों tools बेतरतीब फैल जाते हैं। पुराने अनुभव और जमा ज्ञान को लगभग पूरी तरह नज़रअंदाज़ करके, ग़लत tools से ग़लत problems हल की जा रही हैं। आख़िर में यह तरीका JS libraries की तरह सिर्फ़ complexity और inefficiency ही बढ़ाएगा। जब problem को ग़लत तरीके से हल किया जाता है, तो नई problems निकलती हैं, और फिर उन्हें ढकने के लिए और ग़लत solutions जोड़ने पड़ते हैं।

  • मैं AI को असली human developer की तरह treat करना पसंद करता हूँ। उदाहरण के लिए, मैं AI से feature implementation, bug fix, या refactoring करने को कहता हूँ, फिर उसके commit को पढ़ता हूँ। अगर commit पसंद नहीं आता, तो git reset --hard करके prompt सुधारता हूँ और AI से फिर करवाता हूँ। मैं इस तरीके को "prompt coding" कहता हूँ। मेरे coding environment और AI के बीच सीधे interaction की ज़रूरत नहीं है। वह एक human developer की तरह काम करे, मेरे editor को छुए बिना। संबंधित विवरण

    • आजकल कहा जाता है कि prompting बेहतर हो गई है, लेकिन उस हिस्से को लेकर मुझे कुछ शक है। AI कुछ बहुत specific tasks में मददगार है, लेकिन अभी भी बहुत बकवास निकलती है। ख़ासकर API जैसी चीज़ें गढ़ लेना अब भी बर्दाश्त करना मुश्किल है।

    • मैं AI से commit तक नहीं करवाता। AI के नतीजों के कई हिस्सों को मुझे लगभग हमेशा खुद ठीक करना पड़ता है। बार-बार reprompt करने में समय बर्बाद करने के बजाय, अगर पहली बार में मनचाहा जवाब न मिले तो मैं सीधे खुद ठीक कर देता हूँ। लेकिन अगर शुरुआत से ही वह मेरी मंशा समझकर code दे दे, तब AI पर भरोसा काफ़ी बढ़ जाता है।

  • उम्मीद है यह idea और फैले। एक बात को लेकर जिज्ञासा है: file search और unsaved files के बीच का फ़र्क़। असल में agents file system search के लिए अक्सर ripgrep जैसी चीज़ें इस्तेमाल करते हैं, लेकिन अगर protocol unsaved files को भी पढ़ने-लिखने दे, तो accuracy की समस्या आ सकती है। ripgrep unsaved files को search नहीं कर सकता।

  • मैं सच में चाहता हूँ कि Anthropic इस protocol को Claude Code में अपनाए। कम-से-कम VSCode जितनी integration तो मिलनी ही चाहिए। और कम-से-कम editor diagnostics तक access मिल जाए, तो भी अच्छा होगा।

  • MCP भी शुरुआत में stdio पर JSON-RPC के साथ शुरू हुआ था। GitHub Codespaces, devcontainers, और "background agents" जैसे environments आने के बाद शायद JSON over SSE जैसी प्रगति भी हो सकती है, यह सोचने लायक है। मेरा मौजूदा dev environment यह है कि local पर Claude Code चलता है और app container में चलती है। Agent स्वायत्त रूप से docker compose exec backend चला सकता है। Git worktree workflow अपनाने में रुकावट database engine sharing (local resources की कमी) और शुरुआती migration time है। इस बोझ को cloud पर offload करना भी एक दिलचस्प scenario है।

  • उम्मीद है ऐसे protocols फैलें ताकि मुझे हमेशा किसी एक legacy IDE से बँधा न रहना पड़े।