/.well-known/agent-card.json
A2A v1.0 विनिर्देश द्वारा पंजीकृत well-known URI। नए क्लाइंट पहले इस पथ को प्राप्त करते हैं; इसे application/a2a+json कंटेंट टाइप के साथ सर्व करें।
डिस्कवरी टूल · A2A v1.0
A2A Agent Card डिस्कवरी URL जाँचें
A2A क्लाइंट एक well-known URL से JSON Agent Card प्राप्त करके एजेंट को खोजते हैं। किसी लाइव डोमेन पर दोनों नामकरण परंपराओं का परीक्षण करें और देखें कि क्लाइंट को वास्तव में क्या मिलता है।
एक ही आधार डोमेन से दोनों संभावित डिस्कवरी URL बनाता है।
लौटाए गए JSON को प्राप्त करता है और स्टेटस कोड व कंटेंट टाइप रिपोर्ट करता है।
जब संभव हो, प्रतिक्रिया को Agent Card JSON के रूप में पार्स करता है।
इंटरफेस, स्किल्स, प्रोवाइडर, मोड, क्षमताओं और सुरक्षा मेटाडेटा के लिए तैयारी जाँच चलाता है।
एक सार्वजनिक एजेंट डोमेन जाँचें
एक आधार डोमेन दर्ज करें। चेकर दोनों डिस्कवरी पथों को प्राप्त करता है, लौटाए गए JSON को पार्स करता है, और Agent Card तैयारी जाँच चलाता है।
डिस्कवरी कैसे काम करती है
एक well-known URL हर A2A इंटीग्रेशन शुरू करता है।
इससे पहले कि कोई दूसरा एजेंट आपकी सेवा को कॉल कर सके, वह आपके डोमेन पर well-known URI (RFC 8615) से Agent Card प्राप्त करता है, स्किल्स और सुरक्षा आवश्यकताओं का मूल्यांकन करता है, फिर पसंदीदा इंटरफेस को कॉल करता है। यदि Agent Card गायब है, पुराना है, या रीडायरेक्ट के पीछे छिपा है, तो इंटीग्रेशन शुरू होने से पहले ही विफल हो जाता है।
यह साइट वही करती है जो यह जाँचती है: AgentCard.net अपना Agent Card दोनों पथों पर प्रकाशित करता है, और दाईं ओर का उदाहरण असल दस्तावेज़ है।
हमारा लाइव Agent Card देखेंagentcard.net discovery
GET /.well-known/agent-card.json HTTP/1.1
Host: www.agentcard.net
HTTP/1.1 200 OK
Content-Type: application/a2a+json
{
"name": "AgentCard.net Toolkit",
"version": "1.0.0",
"supportedInterfaces": [
{ "url": "https://www.agentcard.net/api/agent-card",
"protocolBinding": "HTTP+JSON",
"protocolVersion": "1.0" }
],
"skills": [
{ "id": "generate-agent-card", ... },
{ "id": "validate-agent-card", ... },
{ "id": "check-well-known-discovery", ... }
]
}डिस्कवरी पथ
दो परंपराएँ, एक Agent Card।
/.well-known/agent.json
प्रारंभिक A2A कार्यान्वयन और कोडलैब उदाहरणों में उपयोग किया जाता है। कई तैनात क्लाइंट अभी भी केवल इस पथ की जाँच करते हैं, इसलिए यहाँ वही Agent Card सर्व करना एक सुरक्षित संक्रमण रणनीति है।
प्रकाशन पैटर्न
Agent Card डिस्कवरी को मजबूत बनाएँ।
डिस्कवरी विफलताएँ शायद ही कभी असामान्य होती हैं: एक रीडायरेक्ट, एक कैश्ड एरर पेज, या एक पथ तैनात और दूसरा भुला दिया गया। यह प्रकाशन रूटीन दोनों परंपराओं को एक ही अद्यतन Agent Card सर्व करते रहने देता है।
- 1
मानक पथ पर प्रकाशित करें
समीक्षित Agent Card को /.well-known/agent-card.json पर HTTPS के माध्यम से A2A सेवा वाले उसी डोमेन पर, application/a2a+json कंटेंट टाइप के साथ सर्व करें।
- 2
लेगेसी पथ को मिरर करें
जब तक पुराने क्लाइंट अभी भी प्रचलन में हैं, /.well-known/agent.json से समान दस्तावेज़ लौटाएँ — दोनों पथों पर भिन्न Agent Card रूटिंग को भ्रमित करते हैं।
- 3
Agent Card को सिंक्रोनाइज़ रखें
जब भी एंडपॉइंट, स्किल्स, क्षमताएँ, या प्रमाणीकरण बदलें, Agent Card को अपडेट करें, इसके version फ़ील्ड को बढ़ाएँ, और दोनों पथों को एक साथ फिर से तैनात करें।
- 4
हर बदलाव के बाद फिर से जाँचें
तैनाती, DNS परिवर्तन, गेटवे माइग्रेशन, या मार्केटप्लेस संपादन के बाद यह चेकर चलाएँ। विफलताएँ आमतौर पर रीडायरेक्ट, HTML एरर पेज, या भूले हुए पथ से जुड़ी होती हैं।
सामान्य प्रश्न
Well-known Agent JSON के सामान्य प्रश्न
क्या प्रकाशित करें, इसे कहाँ प्रकाशित करें, और दोनों परंपराओं के क्लाइंट को कैसे काम करते रहने दें।
मुझे कौन सा well-known Agent Card पथ उपयोग करना चाहिए?
A2A v1.0 /.well-known/agent-card.json को मानक डिस्कवरी पथ के रूप में पंजीकृत करता है। पुराना /.well-known/agent.json v1.0 से पहले का है लेकिन अभी भी कई तैनात क्लाइंट द्वारा जाँचा जाता है, इसलिए संक्रमण के दौरान दोनों पथों पर एक ही Agent Card प्रकाशित करना व्यावहारिक विकल्प है।
क्या दोनों पथों को समान JSON लौटाना चाहिए?
हाँ। दोनों पथों से एक ही सार्वजनिक Agent Card लौटाना उन क्लाइंट को सुसंगत रखता है जो केवल एक परंपरा का समर्थन करते हैं। भिन्न दस्तावेज़ एजेंट को अलग दिखाते हैं, यह इस पर निर्भर करता है कि क्लाइंट कौन सा पथ प्राप्त करता है।
Agent Card को किस कंटेंट टाइप के साथ सर्व किया जाना चाहिए?
विनिर्देश Agent Cards के लिए application/a2a+json पंजीकृत करता है। सामान्य application/json व्यवहार में व्यापक रूप से स्वीकृत है, लेकिन HTML कंटेंट टाइप एक विश्वसनीय संकेत है कि पथ Agent Card के बजाय एक एरर पेज लौटा रहा है।
क्या सार्वजनिक Agent Card निजी क्षमताओं को छिपा सकता है?
हाँ। सार्वजनिक Agent Card में केवल डिस्कवरी-सुरक्षित मेटाडेटा प्रकाशित करें, capabilities.extendedAgentCard को true सेट करें, और संवेदनशील स्किल्स को प्रमाणित GetExtendedAgentCard ऑपरेशन के माध्यम से उजागर करें।
तैनाती के बाद डिस्कवरी जाँच क्यों विफल होती है?
सामान्य कारण हैं: लॉगिन या मार्केटिंग पेज पर रीडायरेक्ट, स्टेटस 200 के साथ लौटाए गए HTML 404 पेज, CDN पर कैश्ड पुराना JSON, या दो well-known पथों में से केवल एक ही तैनात होना। चेकर हर पथ के लिए स्टेटस कोड और कंटेंट टाइप रिपोर्ट करता है, इसलिए विफलता तुरंत दिखाई देती है।
प्रकाशित करने से पहले
Agent Card को वैलिडेट करें, फिर URL जाँचें।
पहले JSON को पूर्ण वैलिडेटर से गुजारें, इसे दोनों well-known पथों पर प्रकाशित करें, और इस चेकर से डिस्कवरी की पुष्टि करें।