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

स्थानीय AI एजेंट बनाना

उन्नत

एक स्थानीय AI एजेंट एक स्वायत्त लूप है जो पूरी तरह आपके अपने हार्डवेयर पर चलता है: एक ओपन-वेट मॉडल (Ollama या LM Studio द्वारा सर्व किया गया) तय करता है कि क्या करना है, आपके दिए टूल कॉल करता है, परिणाम पढ़ता है, और तब तक चलता रहता है जब तक कार्य पूरा न हो — आपकी मशीन से कुछ भी बाहर जाए बिना। कोई क्लाउड API नहीं, कोई प्रति-कॉल बिल नहीं, कोई इंटरनेट ज़रूरी नहीं। पेच: लैपटॉप पर चलने लायक छोटा मॉडल कठिन तर्क और लंबी-अवधि की योजना में एक फ्रंटियर मॉडल से कमज़ोर है, और आप इसकी विश्वसनीयता और सुरक्षा के मालिक हैं। यह पेज स्थानीय एजेंटों का ईमानदार मामला, न्यूनतम आर्किटेक्चर, वास्तव में स्थानीय रूप से क्या चलता है, और आपके पहले एजेंट का यथार्थवादी रास्ता कवर करता है।

What you'll learn
  • जानें कि आप एजेंट को स्थानीय रूप से क्यों चलाएँगे — और क्लाउड-API एजेंट बनाम इसके ईमानदार समझौते
  • न्यूनतम आर्किटेक्चर समझें: स्थानीय मॉडल + tool-calling लूप + टूल + एक guardrail/stop condition
  • एक स्थानीय मॉडल चुनें जो वास्तव में tool use / एजेंटिक काम कर सके
  • जानें कि कौन-से एजेंट फ्रेमवर्क एक स्थानीय endpoint की ओर इंगित करके स्थानीय रूप से चलते हैं (LangGraph, CrewAI, OpenAI Agents SDK)
  • एक one-shot tool कॉल से एक guarded लूप तक 'सरल से शुरू करें' रास्ते का अनुसरण करें
  • एजेंट को sandbox और budget-cap करें ताकि एक स्वायत्त लूप असली नुकसान न कर सके

एक स्थानीय एजेंट क्यों बनाएँ (और कब नहीं)

एक साधारण tool-use एजेंट एक क्लाउड मॉडल कॉल करता है। एक स्थानीय एजेंट उस क्लाउड कॉल को आपकी अपनी मशीन पर चल रहे मॉडल से बदल देता है। आप कुछ क्षमता छोड़ते हैं और कुछ संचालन बोझ विरासत में पाते हैं; बदले में आपको चार चीज़ें मिलती हैं जिन्हें किसी और तरीके से पाना कठिन है:

  • गोपनीयता — प्रॉम्प्ट, टूल इनपुट, और टूल आउटपुट कभी मशीन से बाहर नहीं जाते। यही पूरा कारण है कि विनियमित, संवेदनशील, या एयर-गैप्ड सेटिंग्स में टीमें स्थानीय एजेंट बनाती हैं: डेटा भौतिक रूप से किसी तीसरे पक्ष तक नहीं जा सकता।
  • ऑफ़लाइन — कोई इंटरनेट नहीं, कोई API निर्भरता नहीं, कोई प्रोवाइडर आउटेज नहीं। एजेंट आपकी डिस्क पर फ़ाइलें हैं; यह हवाई जहाज़ में या फ़ायरवॉल के पीछे चलता है।
  • कोई प्रति-कॉल लागत नहीं — एक एजेंट लूप प्रति कार्य दर्जनों मॉडल कॉल फ़ायर कर सकता है। स्थानीय रूप से वे कॉल "मुफ़्त" हैं (आप बिजली और हार्डवेयर में भुगतान करते हैं, टोकन में नहीं), तो आप इसे मीटर देखे बिना दोहराने दे सकते हैं।
  • पूर्ण नियंत्रण — एक सटीक मॉडल वर्शन पिन करें, व्यवहार अनुकूलित करें, और रेट लिमिट या सेवा-शर्त आश्चर्यों के बिना चलाएँ।

ईमानदार समझौते — प्रतिबद्ध होने से पहले इनके बारे में स्पष्ट रहें:

  • क्षमता अंतर। एक एजेंट का सबसे कठिन हिस्सा तर्क है: बहु-चरणीय काम की योजना बनाना, किसी विफल टूल कॉल से उबरना, यह जानना कि कब रुकना है। लैपटॉप पर चलने लायक मॉडल (मोटे तौर पर 1B–14B पैरामीटर) यहाँ एक फ्रंटियर मॉडल से स्पष्ट रूप से कमज़ोर है। सरल, अच्छी तरह सीमित लूप स्थानीय रूप से अच्छे काम करते हैं; लंबी-अवधि, खुले-अंत वाले कार्य वे हैं जहाँ स्थानीय एजेंट सबसे अधिक बार पटरी से उतरते हैं।
  • विश्वसनीयता और सुरक्षा के मालिक आप हैं। कोई प्रोवाइडर आपके लिए फ़िल्टर, निगरानी, या guard-rail नहीं कर रहा। अगर एजेंट हमेशा के लिए लूप करता है, गलत टूल कॉल करता है, या कोई विनाशकारी कार्रवाई करता है, तो वह आपके डिज़ाइन पर है। (नीचे चेतावनी देखें — यही वह हिस्सा है जिसे लोग कम आँकते हैं।)
  • हार्डवेयर सीमाएँ। बड़े, अधिक स्मार्ट मॉडलों को अधिकांश मशीनों की तुलना में अधिक RAM/VRAM चाहिए। आप आमतौर पर अपने हार्डवेयर पर चलने लायक सबसे बड़ा सक्षम मॉडल चुन रहे होते हैं, न कि मौजूद सर्वश्रेष्ठ मॉडल।

एक टिकाऊ अंगूठे का नियम: स्थानीय से शुरू करें, कार्य की माँग होने पर बढ़ाएँ। निजी/ऑफ़लाइन/स्केल-पर-सस्ते काम और अच्छी तरह सीमित लूप के लिए एक स्थानीय एजेंट इस्तेमाल करें; जब कार्य को सचमुच अतिरिक्त तर्क चाहिए तो एक फ्रंटियर-API एजेंट की ओर बढ़ें। नीचे का आर्किटेक्चर दोनों तरह समान है — केवल endpoint बदलता है — तो आप स्थानीय रूप से प्रोटोटाइप कर सकते हैं और बाद में मॉडल स्वैप कर सकते हैं।

न्यूनतम आर्किटेक्चर

एक एजेंट को उसके मूल तक छाँटें और चार भाग हैं। बाकी सब इनके ऊपर सुविधा है।

┌─────────────────────────────────────────────┐
│ │
│ 1. LOCAL MODEL ──► decides next action │
│ (Ollama / LM Studio, tool-capable) │
│ │ │
│ ▼ │
│ 2. TOOL-CALLING LOOP │
│ parse the model's tool request, │
│ run it, feed the result back │
│ │ │
│ ▼ │
│ 3. TOOLS ──► search / read file / │
│ run code / call an API (your code) │
│ │ │
│ ▼ │
│ 4. GUARDRAIL / STOP CONDITION │
│ max steps, budget, approval gate, │
│ "done" check ──► exit the loop │
│ │
└─────────────────────────────────────────────┘
  1. एक स्थानीय मॉडल जो tool calling समर्थित करता है। मॉडल को किसी टूल को कॉल करने का एक संरचित अनुरोध (उर्फ़ function calling) जारी करने में सक्षम होना चाहिए, केवल चैट नहीं। Ollama इसे अपने API के ज़रिए और http://localhost:11434/v1 पर एक OpenAI-संगत endpoint के ज़रिए उजागर करता है, तो कोई भी फ्रेमवर्क जो OpenAI फ़ॉर्मेट बोलता है वह एक स्थानीय मॉडल चला सकता है।
  2. tool-calling लूप। एजेंट का हृदय: बातचीत को मॉडल को भेजें, देखें कि क्या उसने किसी टूल को कॉल करने को कहा, उस टूल को चलाएँ, परिणाम जोड़ें, और दोहराएँ। जब मॉडल बिना किसी टूल का अनुरोध किए जवाब देता है, तो लूप समाप्त हो जाता है।
  3. टूल। सादे फ़ंक्शन जिन्हें आप मॉडल को उजागर करते हैं — वेब सर्च करें, एक फ़ाइल पढ़ें, एक shell कमांड चलाएँ, एक डेटाबेस क्वेरी करें, एक API हिट करें। प्रत्येक टूल का एक नाम, एक विवरण, और एक टाइप किया हुआ इनपुट schema होता है ताकि मॉडल जाने कि इसे कब और कैसे इस्तेमाल करना है।
  4. एक guardrail / stop condition। स्वायत्तता के लिए गैर-समझौता योग्य। कम से कम एक max-step cap ताकि लूप हमेशा के लिए न चले, प्लस — जो कुछ भी लिखता, हटाता, खर्च करता, या भेजता है उसके लिए — एक approval gate या एक sandbox। इसके बिना आपके पास एजेंट नहीं है, आपके पास फ़ाइल पहुँच वाला एक अनंत लूप है।

चरण 2 का लूप सचमुच छोटा है। यहाँ यह एक स्थानीय Ollama endpoint के विरुद्ध Python छद्म-कोड में है:

एक न्यूनतम स्थानीय एजेंट लूप (Python छद्म-कोड, स्थानीय Ollama की ओर इंगित करता है)

from openai import OpenAI

# Point the OpenAI client at your LOCAL Ollama endpoint — nothing leaves the machine
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

tools = [{
  "type": "function",
  "function": {
      "name": "read_file",
      "description": "Read a UTF-8 text file and return its contents",
      "parameters": {
          "type": "object",
          "properties": {"path": {"type": "string"}},
          "required": ["path"],
      },
  },
}]

def run_tool(name, args):
  if name == "read_file":
      # GUARDRAIL: only allow reads inside a sandboxed directory
      return safe_read(args["path"])
  raise ValueError(f"unknown tool: {name}")

messages = [{"role": "user", "content": "Summarize ./notes/today.md"}]

for step in range(8):                       # GUARDRAIL: hard step cap
  resp = client.chat.completions.create(
      model="llama3.1", messages=messages, tools=tools,
  )
  msg = resp.choices[0].message
  messages.append(msg)

  if not msg.tool_calls:                  # STOP: model answered, we're done
      print(msg.content)
      break

  for call in msg.tool_calls:
      result = run_tool(call.function.name, json.loads(call.function.arguments))
      messages.append({
          "role": "tool", "tool_call_id": call.id, "content": str(result),
      })
else:
  print("Stopped: hit the step cap without finishing.")

यही पूरा पैटर्न है। फ्रेमवर्क इस लूप के ऊपर memory, retries, बहु-एजेंट ऑर्केस्ट्रेशन, tracing, और संरचित state जोड़ते हैं — पर उनमें से हर एक इसी लूप का एक अधिक मज़बूत संस्करण है।

कौन-से स्थानीय मॉडल एजेंटिक / tool-use काम के अनुकूल हैं

हर ओपन-वेट मॉडल एक एजेंट नहीं चला सकता। मानदंड है भरोसेमंद tool calling: मॉडल को लगातार सुगठित टूल अनुरोध जारी करने होंगे, सही टूल चुनना होगा, और आर्ग्युमेंट्स hallucinate नहीं करने होंगे। चुनते समय दो फ़िल्टर:

  • यह एक tool-सक्षम मॉडल होना चाहिए। Ollama इन्हें टैग करता है — मान लेने के बजाय वर्तमान सूची के लिए Tools श्रेणी ब्राउज़ करें। ठोस स्थानीय tool use के लिए आमतौर पर उद्धृत मॉडलों में Qwen और Llama निर्देश-ट्यून्ड परिवार शामिल हैं; सटीक सर्वश्रेष्ठ पिक तिमाही-दर-तिमाही बदलता है।
  • यह आपके हार्डवेयर में context के लिए जगह के साथ फ़िट होना चाहिए। एजेंट लूप लंबे message इतिहास जमा करते हैं (हर टूल परिणाम जोड़ा जाता है), तो आपको weights और memory में एक उदार context window दोनों चाहिए। एक छोटा मॉडल जो आराम से फ़िट होकर तेज़ चलता है अक्सर एक बड़े मॉडल को हरा देता है जो डिस्क पर swap करता है और लूप के बीच में अटक जाता है।

निर्णायक कदम बेंचमार्क पढ़ना नहीं है — यह आपके कार्य का एक छोटा eval दो या तीन उम्मीदवार मॉडलों के विरुद्ध चलाना है। एक मॉडल जो किसी लीडरबोर्ड में शीर्ष पर है वह उन विशिष्ट टूलों पर अभी भी अविश्वसनीय हो सकता है जिनकी आपके एजेंट को ज़रूरत है। अपने खुद के लूप पर मापें।

फ्रेमवर्क जो स्थानीय रूप से चलते हैं

आप ऊपर के लूप को हाथ से बना सकते हैं, और पहले एजेंट के लिए यह सीखने का एक बढ़िया तरीका है। किसी भी असली चीज़ के लिए, एक फ्रेमवर्क आपको retries, memory, बहु-एजेंट समन्वय, और tracing देता है। मुख्य तथ्य: लोकप्रिय एजेंट फ्रेमवर्क मॉडल-अज्ञेय हैं — उन्हें परवाह नहीं कि मॉडल क्लाउड में है या localhost पर, जब तक आप उन्हें सही endpoint की ओर इंगित करते हैं।

  • LangGraph — stateful एजेंटों के लिए एक निम्न-स्तरीय ऑर्केस्ट्रेशन फ्रेमवर्क (टिकाऊ निष्पादन, persistence, human-in-the-loop)। मॉडल-अज्ञेय; इसे LangChain Ollama एकीकरण के ज़रिए बिना किसी जुगाड़ के एक स्थानीय मॉडल से जोड़ें। तब अच्छा जब आपको एजेंट के state graph पर स्पष्ट नियंत्रण चाहिए।
  • CrewAI — एक या अधिक भूमिका-आधारित एजेंटों ("crews") को ऑर्केस्ट्रेट करने के लिए एक उच्च-स्तरीय फ्रेमवर्क। LiteLLM के ज़रिए मॉडल-अज्ञेय; एक एजेंट को LLM(model="ollama/llama3.1", base_url="http://localhost:11434") के साथ स्थानीय मॉडल की ओर इंगित करें। तब अच्छा जब आप कई सहयोगी एजेंटों को जल्दी रचना करना चाहें।
  • OpenAI Agents SDK — एक हल्का बहु-एजेंट फ्रेमवर्क। नाम के बावजूद यह प्रोवाइडर-अज्ञेय है: अपने LiteLLM एकीकरण के ज़रिए आप इसे एक OpenAI मॉडल के बजाय एक स्थानीय Ollama मॉडल की ओर इंगित कर सकते हैं। तब अच्छा जब आप एक स्थानीय backend पर OpenAI के एजेंट ergonomics चाहें।

तीनों को नमूना लेने के बजाय एक फ्रेमवर्क चुनें और उसे अच्छी तरह सीखें। अवधारणाएँ (एजेंट, टूल, लूप, state) ट्रांसफर होती हैं; API विवरण हैं।

अपना पहला स्थानीय एजेंट बनाएँ

एक यथार्थवादी रास्ता "कोई लूप बिल्कुल नहीं" से "guarded स्वायत्त लूप" तक जानबूझकर चरणों में जाता है। चरण 4 पर मत कूदें — स्थानीय एजेंटों के साथ लोग जो अधिकांश विफलताएँ झेलते हैं वे एक कमज़ोर मॉडल को बहुत जल्दी बहुत ढील देने से आती हैं।

Guided walkthrough1 of 5
  1. Ollama इंस्टॉल करें (Run models locally देखें), फिर टूल के लिए टैग किया गया एक मॉडल pull करें, जैसे ollama pull llama3.1। पुष्टि करें कि यह http://localhost:11434 पर सर्व करता है और ollama list इसे दिखाता है। अभी कोई एजेंट नहीं — बस एक मॉडल जिसे आप कॉल कर सकते हैं।
Watch out
  • टूल वाला एक स्थानीय एजेंट फिर भी असली कार्रवाइयाँ कर सकता है — इसे sandbox करें, विनाशकारी चरणों के लिए approval की माँग करें, और इसके लूप/budget को cap करें।

खुद को जाँचें

खुद को जाँचें

0/4
  1. टीमें एक क्लाउड API के बजाय स्थानीय रूप से चलने वाले एजेंट क्यों बनाती हैं — इसका एकमात्र सबसे महत्वपूर्ण कारण क्या है?
  2. कौन-से चार भाग न्यूनतम स्थानीय-एजेंट आर्किटेक्चर बनाते हैं?
  3. LangGraph, CrewAI, और OpenAI Agents SDK के स्थानीय उपयोग के लिए 'मॉडल-अज्ञेय' होने का क्या मतलब है?
  4. आप अपना पहला स्थानीय एजेंट बना रहे हैं। किसी भी ऐसे टूल को जोड़ने से पहले जो फ़ाइलें लिखता या कमांड चलाता है, आपको क्या करना चाहिए?
कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 6
Key takeaways
  • एक स्थानीय एजेंट मानक tool-use लूप है जिसमें क्लाउड मॉडल को आपकी मशीन पर एक ओपन-वेट मॉडल से बदल दिया गया है — निजी, ऑफ़लाइन, और दोहराने में मुफ़्त।
  • न्यूनतम आर्किटेक्चर = स्थानीय tool-सक्षम मॉडल + tool-calling लूप + टूल + एक guardrail/stop condition। लूप खुद छोटा है।
  • Ollama का OpenAI-संगत endpoint (/v1) tool calling समर्थित करता है, तो कोई भी OpenAI-फ़ॉर्मेट फ्रेमवर्क एक स्थानीय मॉडल चला सकता है।
  • LangGraph, CrewAI, और OpenAI Agents SDK मॉडल-अज्ञेय हैं — उन्हें क्लाउड के बजाय एक स्थानीय endpoint की ओर इंगित करें।
  • एक tool-सक्षम मॉडल चुनें जो आपके हार्डवेयर में फ़िट हो, फिर एक लीडरबोर्ड नहीं, अपने खुद के कार्य के एक छोटे eval से तय करें।
  • क्षमता अंतर के बारे में ईमानदार रहें और सुरक्षा के मालिक बनें: लूप और budget cap करें, टूल sandbox करें, और किसी भी विनाशकारी चीज़ के लिए approval की माँग करें।
  • सरल से शुरू करें: एक साफ़ टूल कॉल → सीमित read-only लूप → guarded विनाशकारी टूल → (वैकल्पिक रूप से) एक फ्रेमवर्क।

स्रोत और आगे पढ़ें