एक कार्यशील AI एजेंट बनाएं: एक व्यावहारिक शब्दावली

एक AI एजेंट एक प्रोग्राम है जो एक लक्ष्य लेता है, क्रियाओं का एक क्रम तय करता है, और उन क्रियाओं को tools का उपयोग करके तब तक निष्पादित करता है जब तक लक्ष्य पूरा नहीं हो जाता या यह हार नहीं मान लेता। यह चैटबॉट से अलग है, जो केवल संदेशों का जवाब देता है। एक एजेंट योजना बनाता है, functions को कॉल करता है, परिणामों की जांच करता है, और समायोजन करता है। अगर आपने केवल ब्राउज़र के माध्यम से ChatGPT का उपयोग किया है, तो अपना पहला एजेंट बनाना वह जगह है जहां मॉडल एक टेक्स्ट जनरेटर होना बंद कर देता है और एक बड़ी प्रणाली में एक घटक बन जाता है।

मुख्य लूप

हर एजेंट, चाहे इसे कैसे भी मार्केट किया जाए, एक ही लूप का कोई संस्करण चलाता है: observe, think, act, repeat। व्यावहारिक रूप से:

1. एजेंट को एक कार्य मिलता है ("अगले महीने लिस्बन के लिए सबसे सस्ती उड़ान खोजें और एक ईमेल सारांश तैयार करें")।
2. यह उपलब्ध tools के विवरण के साथ कार्य को लेकर LLM को कॉल करता है।
3. मॉडल या तो एक अंतिम उत्तर या एक tool call देता है, जैसे search_flights(destination="Lisbon", month="2025-06")।
4. आपका कोड उस function को निष्पादित करता है, एक वास्तविक परिणाम प्राप्त करता है, और इसे मॉडल के context में वापस डालता है।
5. मॉडल यह तय करता है कि आगे क्या करना है: एक अन्य tool को कॉल करना, स्पष्टीकरण मांगना, या समाप्त करना।

इस पैटर्न को अक्सर ReAct लूप (reason plus act) कहा जाता है, और यह LangChain के agent executors, LlamaIndex agents, और OpenAI के function-calling API जैसे frameworks की रीढ़ है। आप इसे Python में सिर्फ एक LLM API और एक while लूप के साथ 100 लाइनों से भी कम में स्वयं लागू कर सकते हैं — frameworks सुविधा जोड़ते हैं, जादू नहीं।

Tools ही इसे एजेंट बनाते हैं

बिना tools के एक मॉडल केवल बात कर सकता है। इसे functions दें और यह कार्य कर सकता है। Tools आमतौर पर सादे Python functions होते हैं जिन्हें एक schema के साथ लपेटा जाता है जो उनके नाम, parameters, और उद्देश्य का वर्णन करता है, ताकि मॉडल जानता है कि उन्हें कब और कैसे कॉल करना है। उदाहरण:

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

OpenAI के function-calling के साथ, आप इस function के साथ एक JSON schema पास करते हैं, और मॉडल एक संरचित कॉल जैसे {"name": "get_weather", "arguments": {"city": "Lisbon"}} आउटपुट देता है बजाय freeform text के। आपका कोड इसे parse करता है, वास्तविक function को चलाता है, और परिणाम को संवाद में एक नए संदेश के रूप में लौटाता है। तब तक दोहराते हैं जब तक मॉडल के पास उत्तर देने के लिए पर्याप्त जानकारी नहीं है।

Memory और state

एक एकल API कॉल के पास अपने context window से परे कोई memory नहीं है। Agents को explicit state की जरूरत है: संदेशों की एक चलती सूची (conversation history), और अक्सर लंबे समय तक के तथ्यों के लिए एक अलग store। छोटे कार्यों के लिए, संवाद का प्रतिनिधित्व करने वाली dicts की एक Python सूची पर्याप्त है। Agents के लिए जिन्हें sessions के आर-पार चीजों को याद रखने की जरूरत है, आप एक vector database (Chroma, Pinecone, Qdrant) का उपयोग करेंगे embeddings के माध्यम से प्रासंगिक पिछली जानकारी को store और retrieve करने के लिए।

इसे जल्दी over-engineer न करें। एक आश्चर्यजनक संख्या में "agent" projects विफल होते हैं क्योंकि LLM कमजोर है नहीं बल्कि क्योंकि state management अव्यवस्थित है: duplicate messages, unbounded context growth, या यह ट्रैक खोना कि कौन सा tool call किस result से संबंधित है।

एक न्यूनतम कार्यशील उदाहरण

यहां OpenAI के API का उपयोग करके एक bare-bones agent का आकार है, कोई framework नहीं:

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

यह एक वास्तविक, कार्यशील agent है। बाकी सब कुछ — planning strategies, multi-agent coordination, retrieval pipelines — इस लूप पर निर्मित है।

यह कहां टूटता है

Agents predictable तरीकों से विफल होते हैं: infinite tool-call loops जब मॉडल को नहीं पता कि यह सफल हुआ है, hallucinated function arguments, और महंगे tools को फिर से कॉल करने से बेलगाम लागत। loops के विरुद्ध एक कठोर iteration cap (कहते हैं, 10 steps) के साथ और विकास के दौरान हर tool call को log करके रक्षा करें। किसी भी चीज को निष्पादित करने से पहले arguments को validate करें जो एक वास्तविक प्रणाली को छूती है — एक agent जो emails भेज सकता है या shell commands चला सकता है को उसी input sanitation की जरूरत है जो आप user-facing code पर लागू करेंगे, क्योंकि LLM, प्रभावी रूप से, एक untrusted user है जो उस input को generate कर रहा है।

आगे कहां जाएं

जब लूप काम करता है, तो दिलचस्प समस्याएं शुरू होती हैं: single-agent और multi-agent designs के बीच चुनना, कितनी autonomy देनी है यह तय करना, और agents को reliably test करना जब उनका output deterministic नहीं है। Korra Studio के AI और Python tracks में retrieval-augmented generation, prompt design, और tool-calling patterns अधिक गहराई में cover हैं अगर आप यहां से आगे बनाना चाहते हैं।