Claude Managed Agents: सेटअप, ant apply और SDK के फायदे-नुकसान

Claude Managed Agents Anthropic का होस्ट किया गया एजेंट हार्नेस है, जो लिखने के समय बीटा में है। यह एजेंट लूप, सैंडबॉक्स और सेशन लॉग को Anthropic की ओर से चलाता है, और रनटाइम को टोकन के अलावा $0.08 प्रति सेशन-घंटे पर बिल करता है, निष्क्रिय समय मुक्त है। आप उस लेयर को खुद बनाए रखने की जगह इवेंट भेजते हैं और परिणाम स्ट्रीम करते हैं। यह पोस्ट सेवा द्वारा होस्ट किए गए विषय का दस्तावेजीकृत वॉकथ्रू है, ant apply फ़ाइल-आधारित वर्कफ़्लो कैसे काम करता है, और Agent SDK कब भी बेहतर विकल्प है।

नोट: Managed Agents लिखने के समय एक बीटा सेवा है। यहां सब कुछ के साथ इसी तरह व्यवहार करें।

Claude Managed Agents आपके लिए क्या होस्ट करता है

संक्षिप्त संस्करण: Anthropic एजेंट हार्नेस, कंप्यूट सैंडबॉक्स, और सेशन लॉग चलाता है। आप इवेंट भेजते हैं और परिणाम HTTP पर वापस स्ट्रीम करते हैं। बस। आप कंटेनर जीवनचक्र, टूल निष्पादन पরिवेश, या क्षणिक विफलताओं के लिए रिट्राई तर्क नहीं संभालते।

अधिक विशेष रूप से, यहाँ देखें कि Anthropic के पक्ष में क्या आता है:

• एजेंट लूप। Claude तय करता है कि कब एक टूल को कॉल करना है, परिणाम को प्रोसेस करता है, और बिना ऑर्केस्ट्रेशन लिखे पुनरावृत्ति करता है।
• अंतर्निहित टूल। Bash, फाइल ऑपरेशन, वेब सर्च, सभी agent_toolset_20260401 टूल प्रकार के माध्यम से सुलभ। आप इन्हें स्वयं तार नहीं देते।
• प्रति-सेशन सैंडबॉक्स। प्रत्येक सेशन को अपना अलग-थलग निष्पादन वातावरण मिलता है। कोई क्रॉस-सेशन लीक नहीं।
• टिकाऊ सेशन लॉग। यदि आपका एप्लिकेशन स्ट्रीम छोड़ता है, तो सेशन गायब नहीं हुआ। आप फिर से जुड़ते हैं और पकड़ते हैं।
• MCP इंटीग्रेशन। कस्टम टूल MCP सर्वर के रूप में संलग्न होते हैं। Claude टूल को ट्रिगर करता है; आपकी सेवा प्रोटोकॉल पर परिणाम लौटाती है। आपकी डिप्लॉय में बंडल करने के लिए कुछ नहीं।
• प्रॉम्प्ट कैशिंग। प्लेटफ़ॉर्म स्तर पर अंतर्निहित, जो एक बार आपके सिस्टम प्रॉम्प्ट लंबे हो जाएँ तो मायने रखता है।

आप अपनी ओर क्या रखते हैं: एजेंट परिभाषा, आपके MCP सर्वर कार्यान्वयन, और कोई भी व्यावसायिक तर्क जो तय करता है कि कब एक सेशन शुरू या बंद करना है। यह एक पूर्ण हार्नेस की तुलना में बहुत छोटी सतह है जिसे आप स्वामित्व में रखते हैं।

Hatchworks बुनियादी ढाँचे का विभाजन स्पष्ट रूप से कवर करता है: अनुमान एक कंटेनर प्रदान किए जाने से पहले शुरू हो सकता है, जो अक्सर कोल्ड-स्टार्ट एजेंटों के लिए तेज़ हो जाता है भले ही हर टूल कॉल एक सेवा सीमा पार करता हो।

Managed Agents, Agent SDK, या Claude Code चुनना कब सही है

जो भ्रम मुझे सबसे अधिक दिखाई देता है वह है लोग इन तीनों को विनिमेय मानते हैं। वे नहीं हैं।

Claude Code एक टर्मिनल टूल है। किसी डेवलपर के लिए स्थानीय रूप से कार्य चलाने के लिए बेहतरीन। कोई ऐसी चीज नहीं जो आप किसी उत्पाद में एम्बेड करते हैं।

[Agent SDK](/blog/claude-agent-sdk-guide-2026/) एजेंट लूप को आपकी अपनी प्रक्रिया के अंदर, आपकी अपनी बुनियादी ढांचे पर चलाता है। सीधी फाइल सिस्टम एक्सेस, निजी नेटवर्क कनेक्टिविटी, निष्पादन वातावरण पर पूर्ण नियंत्रण। आप SDK को चुनते हैं जब आपको सेवा सीमा के बिना स्थानीय फ़ाइल लेखन जैसी चीजें, पहले से भुगतान किया गया मौजूदा बुनियादी ढांचा, या मॉडल स्तर पर बहु-प्रदाता लचीलापन की आवश्यकता होती है (हालांकि अभी के लिए SDK के साथ आप Claude तक सीमित हैं)।

Managed Agents होस्ट किया गया उत्तर है। आप टिकाऊ सत्र, सैंडबॉक्स की गई कंप्यूट, और इसे बनाए बिना अंतर्निहित अवलोकनीयता प्राप्त करते हैं। लागत मॉडल प्रति सत्र-घंटा है, अकेले प्रति टोकन नहीं, इसलिए यह छोटे केंद्रित सत्रों को पुरस्कृत करता है और लंबे निष्क्रिय सत्रों को दंडित करता है।

यहाँ निर्णय तालिका है:

एक बात ध्यान देने योग्य है: जैसा कि hidekazu-konishi.com पर SDK गाइड में नोट किया गया है, एक सामान्य मार्ग SDK के साथ स्थानीय रूप से प्रोटोटाइप करना है और एक बार जब आप होस्ट किए गए सैंडबॉक्स चाहते हैं तो Managed Agents में माइग्रेट करना है।

यदि आपकी विशिष्ट चुनौती इसके चारों ओर पूर्ण एजेंटिक उत्पाद बनाना है, तो हमारा एजेंटिक इंजीनियरिंग कार्य आपको कुछ गलत मोड़ से बचा सकता है।

एक एजेंट बनाएं और एक सत्र का निरीक्षण करें

यह एक प्रलेखित वॉकथ्रू है, कोई सत्यापित उत्पादन चलना नहीं है। मैं आधिकारिक दस्तावेज़ से प्रक्रिया का वर्णन कर रहा हूँ; यहाँ किसी भी कोड को सचित्र मानें जब तक आप इसे अपनी स्वयं की कुंजी के विरुद्ध नहीं चलाते।

चलता हुआ एजेंट पाने के लिए चार कदम लगते हैं।

1. एक एजेंट परिभाषा बनाएं। यह वह जगह है जहाँ आप वर्णन करते हैं कि एजेंट क्या कर सकता है: इसके पास किन अंतर्निहित उपकरणों तक पहुंच है, यह किन MCP सर्वरों को कॉल कर सकता है, और इसकी सिस्टम प्रॉम्प्ट क्या है।
2. एक निष्पादन वातावरण बनाएं। प्लेटफॉर्म आपकी एजेंट परिभाषा के लिए एक सैंडबॉक्स प्रदान करता है।
3. एक सत्र शुरू करें। आप अपने उपयोगकर्ता के इनपुट के साथ एक प्रारंभ ईवेंट भेजते हैं। सत्र ID तुरंत वापस आ जाता है।
4. ईवेंट स्ट्रीम करें। उपकरण कॉल, मध्यवर्ती परिणाम, और अंतिम प्रतिक्रिया सभी स्ट्रीम पर आते हैं। आप उन्हें अपने एप्लिकेशन में संभालते हैं।

सात आधिकारिक SDKs (Python, TypeScript, Go, Java, C#, Ruby, PHP) में, उस प्रवाह का आकार सुसंगत है भले ही सिंटैक्स भिन्न हो। agent_toolset_20260401 टूल प्रकार वह है जो एक एकल घोषणा में पूर्ण अंतर्निहित टूलसेट को अनलॉक करता है। आप bash, फ़ाइल ऑप्स, और वेब सर्च को अलग-अलग गणना नहीं करते हैं।

एक बार जब सत्र चल रहा हो, तो आप सत्र लॉग एंडपॉइंट के माध्यम से इसका निरीक्षण कर सकते हैं। यह वह जगह है जहाँ टिकाऊपन लाभ ठोस रूप से दिखाई देता है। स्ट्रीम छोड़ें, पुनः कनेक्ट करें, और लॉग जहाँ आप छोड़ गए थे वहाँ से दोहराता है। लंबे समय तक चलने वाले कार्यों के लिए जहाँ क्लाइंट डिस्कनेक्ट हो सकता है, यह बहुत मायने रखता है।

ant apply और claude-lock.json के साथ संसाधनों का प्रबंधन करें

ant CLI SDK से एक अलग उपकरण है। इसे Homebrew के माध्यम से इंस्टॉल करें। यह आपके एजेंट संसाधनों (एजेंट, वातावरण, MCP सर्वर पंजीकरण) को कॉन्फ़िग फ़ाइलों में घोषित करने के लिए एक फ़ाइल-आधारित वर्कफ़्लो प्रदान करता है, फिर उन्हें प्लेटफॉर्म पर लागू करता है।

ant apply दस्तावेज़ मुख्य कमांड का वर्णन करता है:

ant apply

इससे पहले कि आप उत्पादन को स्पर्श करें, ड्राई-रन फ्लैग चलाएं:

ant CLI SDK से एक अलग उपकरण है। इसे Homebrew के माध्यम से इंस्टॉल करें। यह आपके एजेंट संसाधनों (एजेंट, वातावरण, MCP सर्वर पंजीकरण) को कॉन्फ़िग फ़ाइलों में घोषित करने के लिए एक फ़ाइल-आधारित वर्कफ़्लो प्रदान करता है, फिर उन्हें प्लेटफॉर्म पर लागू करता है।

यह दिखाता है कि apply क्या करेगा। आधिकारिक दस्तावेज़ों से एक महत्वपूर्ण चेतावनी: --dry-run apply के समय भी 0 exit कर सकता है भले ही plan को block किया जाएगा। एक स्वच्छ dry-run को पूर्ण apply की सफलता की गारंटी न मानें। पहले staging environment में वास्तविक apply को verify करें।

claude-lock.json फ़ाइल वह lockfile है जो आपके deployed resources की मौजूदा स्थिति को रिकॉर्ड करती है। इसे package-lock.json की तरह सोचें — यह resource versions को pin करती है और आपके द्वारा declare किए गए और platform के चला रहे कोड के बीच drift को रोकती है। किसी भी ant apply के बाद, lockfile नई स्थिति को प्रतिबिंबित करने के लिए update हो जाती है। इसे commit करें। code review में इसमें किए गए परिवर्तनों को meaningful के रूप में treat करें।

एक serialisation point जो लोगों को confuse करता है: partial applies। अगर ant apply बीच में fail हो, तो कुछ resources नई स्थिति में होंगे और कुछ नहीं। lockfile partial update को reflect करेगी। ant apply को फिर से चलाने से पहले, lockfile को उससे check करें जो actually deployed हुआ है, अगर ज़रूरत हो तो manually reconcile करें, फिर फिर से चलाएं। checking के बिना एक broken partial state पर दूसरा apply चलाने से resources एक confused intermediate condition में रह सकते हैं।

यह Terraform जैसे tools से अलग है जिनके पास CLI में एक अलग plan step है। कोई ant plan नहीं है। dry-run ही वह है जो आपके पास preview के लिए है। अपने CI को accordingly design करें।

CI में परिवर्तनों की समीक्षा करें और Partial Failures को संभालें

Multiple developers को same Managed Agents environment के विरुद्ध चलाने वाली teams के लिए, CI से बजाय local machines से changes apply करना strongly recommended है। अन्यथा आपको lockfile पर race conditions मिलते हैं।

यहाँ वह workflow है जो मैं suggest करूंगा:

1. PR खुलता है। CI ant apply --dry-run चलाता है और output को PR comment के रूप में post करता है।
2. Reviewer diff को check करता है, जिसमें कोई भी lockfile changes शामिल हैं।
3. main में merge पर, CI staging environment के विरुद्ध ant apply चलाता है।
4. Production को केवल staging apply के बाद ही promote करें और जब sessions सही तरीके से behave करें।

Serialisation requirement मुख्य operational constraint है। आप एक ही environment के विरुद्ध दो ant apply calls को parallel में नहीं चला सकते। अगर आपकी CI system multiple merges को तेजी से queue कर सकती है, तो pipeline level पर एक lock enforce करें (अधिकांश CI platforms के पास इसके लिए concurrency group setting है)।

Partial failure handling के लिए, checklist ऐसी दिखती है:

• एक failed apply के तुरंत बाद lockfile को check करें। नोट करें कि कौन से resources update हुए और कौन से नहीं।
• ant apply को blindly फिर से न चलाएं। पहले error को read करें।
• अगर partial state को investigate करते हुए छोड़ना सुरक्षित है, तो ऐसा करें। अगर resources एक broken intermediate state में हैं, तो आपको re-apply करने से पहले manually rollback करने की ज़रूरत हो सकती है।
• एक बार resolve होने पर, full apply से पहले ant apply --dry-run को फिर से चलाएं यह confirm करने के लिए कि plan सही दिख रहा है।

क्योंकि --dry-run एक blocked plan पर 0 exit कर सकता है, review step को अगर dry-run भी clean दिख रहा है तो skip न करें।

Beta सीमाएं, Costs और एक Deployment Checklist

Managed Agents एक beta service है। यह पदनाम कुछ भी production-critical के लिए मायने रखता है। Features बदल सकते हैं। Pricing बदल सकता है। Beta में availability guarantees GA जैसी नहीं हैं।

लागत। प्रकाशित दर $0.08 प्रति सेशन-घंटे है, केवल तब मीटर किया जाता है जब कोई सेशन चल रहा हो (निष्क्रिय समय बिल नहीं किया जाता है), टोकन को मानक मॉडल दरों पर अतिरिक्त रूप से चार्ज किया जाता है। यह छोटे, कार्य-केंद्रित सेशन के लिए अपेक्षाकृत अनुमानित बनाता है। दीर्घकालीन सेशन के साथ पर्याप्त टूल उपयोग, आप सेशन अवधि को सक्रिय रूप से मॉनिटर करना चाहेंगे। vibecodingacademy गाइड इसे संदर्भ में रखता है: लागत-प्रतिस्पर्धात्मकता इंजीनियरिंग समय पर निर्भर करती है जो आप समान स्व-प्रबंधित बुनियादी ढांचे को बनाने में खर्च करेंगे, जो वास्तविक है और अक्सर कम आंका जाता है।

Beta में मौजूदा constraints:

• Custom tools MCP servers के माध्यम से route करते हैं, in-process functions में नहीं। अगर आपका custom tooling आपके application के runtime से tightly coupled है, तो आपको इसे पहले MCP server में extract करना होगा।
• Session observability session log endpoint के माध्यम से है। कोई built-in dashboard नहीं है जो आप SDK के top पर build करेंगे।
• ant apply आंशिक विफलता शब्दार्थ के लिए मैनुअल समन्वय की आवश्यकता होती है। कोई स्वचालित रोलबैक नहीं है।
• क्रमबद्ध apply का अर्थ है कि पाइपलाइन थ्रूपुट apply अवधि से सीमित है।

तैनाती से पहले की जाँच सूची:

1. एजेंट परिभाषा की समीक्षा की गई और सिस्टम प्रॉम्प्ट अंतिम रूप दिया गया
2. MCP सर्वर पंजीकृत और एजेंट से जोड़ने से पहले स्वतंत्र रूप से परीक्षण किए गए
3. claude-lock.json प्रतिबद्ध और एक समीक्षित कलाकृति के रूप में माना गया
4. कोई भी उत्पादन apply करने से पहले ant apply --dry-run आउटपुट की किसी दूसरे व्यक्ति द्वारा समीक्षा की गई
5. सत्र अवधि निगरानी स्थित है (अप्रत्याशित रूप से लंबे सत्रों के लिए ध्यान दें)
6. आंशिक-विफलता पुनर्प्राप्ति प्रक्रिया आपकी टीम के लिए प्रलेखित है
7. उत्पादन को बढ़ावा देने से पहले मंचन वातावरण सत्यापित किया गया
8. बीटा मूल्य निर्धारण परिवर्तन हो सकता है इसे देखते हुए खाता स्तर पर बजट सतर्कता कॉन्फ़िगर की गई है

बनाएँ-बनाम-खरीदें प्रश्न पर एक अंतिम बात। Agent SDK आपको अधिक नियंत्रण देता है, हाँ। लेकिन नियंत्रण का अर्थ है स्वामित्व। जैसा कि ksred SDK के बारे में नोट करता है, जो पर्याप्त काम करने वाले एजेंटिक सत्र जल्दी ही महंगे हो सकते हैं, और विफलता पुनर्प्राप्ति पूरी तरह से SDK में आपके डिज़ाइन पर है। Managed Agents उस नियंत्रण का कुछ व्यापार करता है टिकाऊ सत्र और बुनियादी ढाँचे के लिए जो आप संचालित नहीं करते। दोनों ही गलत नहीं हैं। चुनाव इस बात पर निर्भर करता है कि आपकी टीम वास्तव में क्या बनाए रख सकती है।

कोई भी उत्पादन apply करने से पहले ant apply --dry-run आउटपुट की किसी दूसरे व्यक्ति द्वारा समीक्षा की गई

क्या Managed Agents किसी भी Claude मॉडल के साथ काम करता है, या यह विशिष्ट संस्करणों तक सीमित है?

आधिकारिक दस्तावेज़ लेखन के समय Managed Agents के भीतर विशिष्ट मॉडल प्रतिबंध सूचीबद्ध नहीं करता है। बीटा स्थिति को देखते हुए, मॉडल उपलब्धता बदल सकती है। किसी विशिष्ट मॉडल संस्करण को उत्पादन एजेंट परिभाषा में प्रतिबद्ध करने से पहले सीधे अवलोकन पृष्ठ जाँचें।

क्या मैं Managed Agents को तैनात करने से पहले परीक्षण के लिए SDK के साथ स्थानीय रूप से एक ही एजेंट परिभाषा चला सकता हूँ?

सीधे नहीं। SDK आपकी अपनी प्रक्रिया में लूप को आपके स्थानीय वातावरण के विरुद्ध चलाता है; Managed Agents इसे Anthropic की सैंडबॉक्स में चलाता है। आप SDK के साथ एजेंट व्यवहार का प्रोटोटाइप बना सकते हैं, लेकिन निष्पादन संदर्भ काफी भिन्न है कि आपको उत्पादन में बढ़ावा देने से पहले मंचन वातावरण में वास्तविक Managed Agents तैनाती का परीक्षण करना चाहिए।

Managed Agents उन MCP सर्वर के लिए प्रमाणीकरण को कैसे संभालता है जिन्हें क्रेडेंशियल की आवश्यकता है?

आधिकारिक दस्तावेज़ कस्टम टूल को MCP सर्वर के माध्यम से जोड़ने के रूप में वर्णित करता है, Claude टूल को ट्रिगर करता है और आपकी सेवा परिणाम लौटाती है। उन MCP सर्वर के लिए क्रेडेंशियल हैंडलिंग सर्वर स्तर पर आपकी जिम्मेदारी है। Managed Agents वर्तमान दस्तावेज़न के आधार पर आपकी ओर से MCP कॉल में क्रेडेंशियल को इंजेक्ट नहीं करता है।

क्या Managed Agents में SDK के max_budget_usd पैरामीटर की तरह प्रति सत्र खर्च को सीमित करने का कोई तरीका है?

SDK के max_budget_usd पैरामीटर पर query() एक SDK-स्तर का नियंत्रण है जो सीधे Managed Agents REST API में अनुवाद नहीं करता है। Managed Agents के भीतर बजट नियंत्रण वर्तमान बीटा में उसी सूक्ष्मता पर प्रलेखित नहीं हैं। खाता-स्तर के खर्च सतर्कता अभी सबसे सुरक्षित समर्थन है।

यदि क्षेत्र या सैंडबॉक्स में बाहरी गिरावट होती है तो चलने वाले सत्र का क्या होता है?

टिकाऊ सत्र लॉग Managed Agents की एक मुख्य डिज़ाइन विशेषता हैं, लेकिन बुनियादी ढाँचे की बाहरी गिरावट में सत्र पुनर्प्राप्ति की विशिष्टताएँ वर्तमान बीटा दस्तावेज़न में विस्तृत नहीं हैं। बीटा पदनाम को देखते हुए, Anthropic प्रकाशित करने तक टिकाऊपन गारंटी को सर्वोत्तम-प्रयास के रूप में मानें सेवा के लिए एक SLA।

ईमानदार सारांश: Managed Agents एक वास्तव में उपयोगी सेवा है जो बुनियादी ढाँचे के काम का एक बड़ा वर्ग समाप्त करता है। ant apply वर्कफ़्लो सीधा है एक बार जब आप dry-run सावधानियों और क्रमबद्धता आवश्यकता को समझ जाते हैं। लेकिन यह बीटा है, आंशिक-विफलता शब्दार्थ को देखभाल की आवश्यकता है, और यदि आपको स्थानीय फाइलसिस्टम पहुँच की आवश्यकता है या पहले से ही एजेंट बुनियादी ढाँचा है जिसके साथ आप खुश हैं तो यह सही उत्तर नहीं है। निर्णय तालिका के साथ शुरू करें, इस बात के आधार पर चुनें कि आपकी टीम वास्तव में क्या स्वामित्व लेना चाहती है, और लॉकफाइल को उसी तरह गंभीरता से मानें जैसे आप किसी अन्य स्टेट फाइल को मानते।