मुख्य कंटेंट तक स्किप करें

प्रबंधित एजेंट

उन्नत
What you'll learn
  • समझें कि एक प्रबंधित (Anthropic-होस्टेड) एजेंट लूप आपके लिए क्या संभालता है
  • दो मूल ऑब्जेक्ट को अलग करें: एक वर्ज़न्ड Agent बनाम एक प्रति-रन Session
  • Vaults के साथ सीक्रेट्स को सुरक्षित रूप से इंजेक्ट करें — मॉडल को कभी देखे बिना
  • Scheduled Deployments के साथ एक एजेंट को cron शेड्यूल पर रखें — कोई शेड्यूलर होस्ट किए बिना
  • जानें कि कब प्रबंधित एक कस्टम लूप से बेहतर है, और कौन से गार्डरेल अब भी लागू होते हैं

अगर अपना खुद का एजेंट लूप बनाना उससे ज़्यादा इन्फ्रास्ट्रक्चर है जितना आप संभालना चाहते हैं, तो एक प्रबंधित (Anthropic-होस्टेड) एजेंट आपके लिए लूप चलाता है — ताकि आप एजेंट के काम पर ध्यान दें, न कि session की प्लंबिंग, रीट्राई, स्टेट, और शेड्यूलिंग पर।

दो ऑब्जेक्ट: Agent बनाम Session​

यह वह मानसिक मॉडल है जिस पर बाकी सब कुछ टिका है। ये जानबूझकर अलग हैं।

  • एक Agent एक पर्सिस्टेड, वर्ज़न्ड कॉन्फ़िगरेशन है — मॉडल, सिस्टम प्रॉम्प्ट, टूल, MCP सर्वर, और skills। आप इसे एक बार बनाते हैं। हर अपडेट एक नया अपरिवर्तनीय वर्ज़न बनाता है।
  • एक Session एक रनटाइम इंस्टेंस है — एक एक्ज़ीक्यूशन जो ID द्वारा किसी एजेंट की ओर इंगित करता है। कॉन्फ़िगरेशन एजेंट पर रहता है, session पर कभी नहीं।
Pro tip

Sessions उस agent वर्ज़न पर पिन होते हैं जिसके साथ वे बनाए गए थे: चल रहे sessions अपना वर्ज़न रखते हैं, नए sessions को नवीनतम मिलता है। यही तरीका है जिससे आप चल रहे काम को तोड़े बिना कॉन्फ़िगरेशन बदलाव शिप करते हैं।

"प्रबंधित" आपको क्या देता है​

लूप को हाथ से बनाने और होस्ट करने के बजाय, आपको होस्टेड बिल्डिंग ब्लॉक मिलते हैं:

  • Sessions — पर्सिस्टेंट रन जिन्हें आप प्रति एक्ज़ीक्यूशन बनाते और रिज़्यूम करते हैं; SSE पर इवेंट स्ट्रीम करते हैं।
  • Environments — कंटेनर इन्फ्रास्ट्रक्चर, या तो cloud (Anthropic-होस्टेड) या self_hosted (टूल आपके अपने VPC में एक्ज़ीक्यूट होते हैं)। प्रति session एक कंटेनर एजेंट का वर्कस्पेस होता है।
  • Memory stores — sessions के बीच पर्सिस्टेंट स्टेट, वर्ज़निंग और रिडैक्शन के साथ, बिना आपके किसी डेटाबेस को वायर किए।
  • Vaults — MCP ऑथ और अन्य सेवाओं के लिए सीक्रेट्स।
  • Scheduled deployments — एजेंट जो cron शेड्यूल पर चलते हैं, बिना निगरानी के।

एक एजेंट बनाएं (वर्ज़न्ड कॉन्फ़िग), फिर उसके विरुद्ध एक session चलाएं

# 1. Create the agent once
POST /v1/agents        -> returns $AGENT_ID
# 2. Each execution is a session pinned to that agent
POST /v1/sessions      { "agent": "$AGENT_ID" }

Vaults: सीक्रेट्स जो मॉडल कभी नहीं देखता​

एक स्वायत्त एजेंट को अक्सर एक API key की ज़रूरत होती है — लेकिन मॉडल को इसे कभी नहीं पढ़ना चाहिए। Vault क्रेडेंशियल (mcp_oauth, static_bearer, environment_variable) एग्रेस पर प्रतिस्थापित किए जाते हैं: एक environment_variable क्रेडेंशियल एक्ज़ीक्यूशन समय पर सैंडबॉक्स में इंजेक्ट किया जाता है और मॉडल को कभी दिखाई नहीं देता।

Watch out

किसी एजेंट को शक्तिशाली एक्सेस देने के लिए यह सुरक्षित पैटर्न है। keys को सिस्टम प्रॉम्प्ट या किसी मैसेज में पेस्ट न करें — वे उस कॉन्टेक्स्ट का हिस्सा बन जाती हैं जिसे मॉडल (और आपके लॉग) देख सकते हैं। उन्हें एक vault में रखें।

Scheduled deployments: cron पर एक एजेंट​

एक deployment एक cron शेड्यूल को किसी एजेंट से जोड़ता है। जब शेड्यूल फायर होता है, यह एक नया session शुरू करता है और अपना कार्य पूरा करता है — आपके लिए बनाने या होस्ट करने हेतु कोई शेड्यूलर नहीं। रात्रि डेटा सिंक, साप्ताहिक अनुपालन स्कैन, या दैनिक डाइजेस्ट के लिए अच्छा।

Guided walkthrough1 of 4
  1. POST /v1/deployments को agent, environment_id, initial_events (जिसमें एक user.message होना चाहिए), और एक schedule के साथ: एक POSIX cron एक्सप्रेशन साथ ही एक IANA टाइमज़ोन।

एक साप्ताहिक अनुपालन स्कैन, शुक्रवार को 20:00 न्यूयॉर्क समय पर

POST /v1/deployments
{
"name": "Weekly compliance scan",
"agent": "$AGENT_ID",
"environment_id": "$ENVIRONMENT_ID",
"initial_events": [
  {"type": "user.message", "content": [{"type": "text", "text": "Run the compliance scan and summarize findings."}]}
],
"schedule": {"type": "cron", "expression": "0 20 * * 5", "timezone": "America/New_York"}
}
Pro tip

Cron है minute hour day-of-month month day-of-week, मिनट-स्तरीय बारीकी। DST वॉल-क्लॉक सेमांटिक्स का उपयोग करता है: एक समय जो स्प्रिंग-फॉरवर्ड पर मौजूद नहीं होता वह छोड़ दिया जाता है; एक समय जो फ़ॉल-बैक पर दो बार आता है वह दो बार फायर होता है। किसी भी संवेदनशील चीज़ के लिए एक ऐसा टाइमज़ोन और घंटा चुनें जो उन किनारों से बचे।

कब प्रबंधित बनाम कस्टम चुनें​

प्रबंधित चुनें जब…एक कस्टम लूप / SDK चुनें जब…
आप चाहते हैं कि होस्टिंग, स्टेट, शेड्यूलिंग, और सीक्रेट्स संभाले जाएंआपको लूप और टूल पर पूर्ण नियंत्रण चाहिए
आप तेज़ी से प्रोटोटाइप बना रहे हैंआपकी सख्त कस्टम इन्फ्रा/अनुपालन आवश्यकताएं हैं
नियंत्रण से ज़्यादा ऑप्स सरलता मायने रखती हैआप अपने खुद के स्टैक में गहराई से एम्बेड कर रहे हैं

यह एक स्पेक्ट्रम है — सिंगल कॉल → वर्कफ़्लो → कस्टम एजेंट (SDK) → प्रबंधित। जितना सरल कार्य अनुमति दे उतने सरल से शुरू करें; तभी ऊपर जाएं जब आपको ज़रूरत हो।

वही गार्डरेल लागू होते हैं​

होस्टेड हो या न हो, एक स्वायत्त एजेंट फिर भी कार्रवाइयां करता है। न्यूनतम विशेषाधिकार, सीमित लागत/इटरेशन, और जोखिमपूर्ण चरणों के लिए मानवीय अनुमोदन बनाए रखें — देखें एजेंट सुरक्षित करना और स्वायत्त रन को कठोर बनाना।

Key takeaways
  • प्रबंधित एजेंट लूप, sessions, environments, मेमोरी, vaults, और शेड्यूलिंग को संभाल लेते हैं ताकि आप काम पर ध्यान दें
  • एक Agent वर्ज़न्ड कॉन्फ़िग है; एक Session एक रन है जो किसी वर्ज़न पर पिन होता है — कॉन्फ़िग एजेंट पर रहता है, session पर नहीं
  • Vault environment_variable क्रेडेंशियल एक्ज़ीक्यूशन पर इंजेक्ट होते हैं और मॉडल को कभी दिखाई नहीं देते — एजेंट को सीक्रेट्स देने का सुरक्षित तरीका
  • एक scheduled deployment एक cron एक्सप्रेशन + IANA टाइमज़ोन है; हर फायर एक रन बनाता है, और unpause छूटे हुए ट्रिगर को बैकफिल नहीं करता
  • प्रबंधित सिंगल कॉल -> वर्कफ़्लो -> कस्टम -> प्रबंधित के होस्टेड छोर पर बैठता है; स्वायत्तता गार्डरेल अब भी लागू होते हैं

खुद को जांचें​

खुद को जांचें

0/3
  1. एक Agent और एक Session के बीच क्या अंतर है?
  2. एक प्रबंधित एजेंट को उसकी ज़रूरत की API key आपको कैसे देनी चाहिए?
  3. एक scheduled deployment दो दिन के लिए paused किया गया और फिर unpaused किया गया। उन ट्रिगर का क्या होता है जो paused रहते हुए फायर हुए होते?

आगे​