AI agents شروع سے سیکھنے کا 6 مرحلوں کا راستہ

چھ مراحل میں راستہ

AI agents کو ابتدا سے سیکھنے کے لیے چھ مراحل ترتیب سے مکمل کریں: تصورات، اپنا پہلا loop، tools، memory، loop design، اور safety۔ ہر مرحلے میں ایک چیز اپنے ہاتھ سے بنانی ہے۔ آگے کے مراحل پر جلدی جانے کی عام وجہ یہی ہوتی ہے کہ framework عین وہ حصہ چھپا دیتا ہے جسے آپ کو دیکھنا ضروری تھا۔

AI agent ایک language model کے گرد بنایا گیا loop ہے، جسے tools call کرنے کی اجازت ہوتی ہے۔ یہی پورا موضوع ہے۔ اس کے بعد کی ہر بات loop میں شامل اجزا، tools کے رسائی حاصل کرنے والے حصوں، اور خرابی کی صورت میں loop روکنے کے طریقے کی تفصیل ہے۔ اگر آپ یہ loop کسی دوسرے شخص کو سمجھا سکتے ہیں تو آپ نے بنیادی بات سیکھ لی ہے۔ اگر آپ صرف frameworks کے نام بتا سکتے ہیں تو آپ نے یہ چیز نہیں سیکھی۔

ذیل کا منصوبہ اس مفروضے پر مبنی ہے کہ آپ بنا کر سیکھتے ہیں۔ ایک مرحلہ پڑھیں، چھوٹی چیز بنائیں، جان بوجھ کر اس میں خرابی پیدا کریں، پھر اگلے مرحلے پر جائیں۔ جس مرحلے کو آپ نے صرف پڑھا ہے، اسے آپ نے مکمل نہیں کیا۔

مرحلہ 1 سے پہلے آپ کو حقیقتاً کیا درکار ہے

حقیقی پیشگی تقاضوں کی فہرست مختصر ہے، اور زیادہ تر کورس صفحات میں بتائی گئی فہرست سے بھی مختصر ہے۔

• آپ پچاس سطروں کی script کی سطح پر Python یا TypeScript پڑھ اور لکھ سکتے ہیں۔
• آپ Linux shell میں اطمینان سے کام کر سکتے ہیں: package install کرنا، file edit کرنا، اور log پڑھنا۔
• آپ کے پاس hosted model کے لیے API key ہے، یا ایسی machine ہے جو local model چلا سکتی ہے۔

بس یہی پوری فہرست ہے۔ آپ کو machine learning theory کی ضرورت نہیں، اور نہ ہی آپ کا کوئی model train کرنا ضروری ہے۔ Agent کے کام میں gradients یا training data شامل نہیں ہوتے۔ Graphics card صرف اس وقت اہم ہوتا ہے جب آپ model خود چلانے کا فیصلہ کریں۔ یہ ایک الگ skill ہے، جسے آپ بعد میں VPS پر Ollama کو host کرکے LLM کو self-host کرنا سے سیکھ سکتے ہیں۔

لوگ shell والے حصے کو کم اہم سمجھتے ہیں۔ Agents permissions، paths، environment variables، اور خاموشی سے بند ہونے والے processes کی وجہ سے fail ہوتے ہیں۔ اگر PATH کے بارے میں stack trace یا file mode دیکھ کر آپ terminal بند کر دیتے ہیں تو پہلے ایک weekend Linux کی بنیادی باتوں پر صرف کریں۔ یہ بعد میں آپ کا ایک ماہ بچا دے گا۔

مرحلہ 1: agent کیا ہے، اور کیا نہیں ہے

ایک API call سے آغاز کریں اور loop استعمال نہ کریں۔ ایک prompt بھیجیں، جواب print کریں، اور response میں token counts دیکھیں۔ اب آپ لاگت کی اکائی اور latency کی اکائی سمجھ چکے ہیں۔

پھر tool use سیکھیں؛ پورے شعبے میں یہی واحد واقعی نیا تصور ہے۔ آپ model کو ایک function کا نام، description، اور اس کے inputs کے لیے JSON (JavaScript object notation) schema فراہم کرتے ہیں۔ model خود کچھ نہیں چلاتا۔ وہ ایک structured request کے ساتھ جواب دیتا ہے: ان arguments کے ساتھ run_command کو call کریں۔ آپ کا code function چلاتا ہے، اس کا output ایک message کے طور پر واپس بھیجتا ہے، اور model سے دوبارہ پوچھتا ہے۔ model ایک planner ہے جو text پڑھتا اور text لکھتا ہے۔ آپ کا code وہ حصہ ہے جو کام انجام دیتا ہے۔

chatbot ایک جواب کے بعد رک جاتا ہے۔ agent اس تبادلے کو اس وقت تک دہراتا ہے جب تک model tools کے لیے مزید درخواستیں کرنا بند نہ کر دے۔ یہی دونوں کے درمیان بنیادی فرق ہے، اور اسی وجہ سے failure modes بھی مختلف ہوتے ہیں۔ chatbot ایک بار غلط جواب دیتا ہے۔ agent کے غلط جواب پر کسی کے نوٹس لینے سے پہلے وہ کئی بار عمل کر سکتا ہے۔

مرحلہ 2: لوپ خود ایک بار لکھیں

کسی framework سے آغاز نہ کریں۔ Python کی تقریباً تیس سطریں خود لکھیں تاکہ اس پروگرام کی ساخت آپ کی اپنی ہو۔

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/agent
source ~/agent/bin/activate
pip install anthropic
export ANTHROPIC_API_KEY=your-key-here

import subprocess
import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "run_command",
    "description": "Run a read only shell command and return its output.",
    "input_schema": {
        "type": "object",
        "properties": {"command": {"type": "string"}},
        "required": ["command"],
    },
}]

messages = [{"role": "user", "content": "How much disk space is free here?"}]

while True:
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=4096,
        tools=tools,
        messages=messages,
    )
    if response.stop_reason != "tool_use":
        break
    messages.append({"role": "assistant", "content": response.content})
    results = []
    for block in response.content:
        if block.type == "tool_use":
            done = subprocess.run(
                block.input["command"], shell=True,
                capture_output=True, text=True, timeout=10,
            )
            results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": done.stdout or done.stderr,
            })
    messages.append({"role": "user", "content": results})

print(next(b.text for b in response.content if b.type == "text"))

اسے python3 agent.py کے ساتھ چلائیں۔ کامیاب run ایک پیراگراف دکھاتا ہے جس میں آپ کے filesystems اور ان کی خالی جگہ بیان ہوتی ہے، کیونکہ model نے df -h طلب کیا، آپ کے code نے اسے چلایا، اور دوسرے pass نے اس table کو ایک جملے میں تبدیل کر دیا۔ اگر کچھ بھی ظاہر نہ ہو تو loop کسی text block کے آنے سے پہلے ختم ہو گیا۔ loop کے اندر print(response.stop_reason) شامل کریں اور values کو تبدیل ہوتے دیکھیں۔

اب جان بوجھ کر خرابی پیدا کریں۔ tool_use_id والی line حذف کریں اور error پڑھیں، کیونکہ matching id کے بغیر tool result کو API مسترد کر دیتی ہے، اور یہ beginners کی سب سے عام غلطی ہے۔ ایسا سوال پوچھیں جس کے لیے دو commands درکار ہوں اور دیکھیں کہ loop دو بار چلتا ہے۔ کوئی ناممکن سوال پوچھیں اور دیکھیں کہ یہ یا تو کوشش ترک کرتا ہے یا ہمیشہ چلتا رہتا ہے۔

اس مثال کے بارے میں ایک انتباہ ہے۔ یہ model output کو shell=True کے ذریعے براہِ راست shell میں بھیجتی ہے۔ ایسی مشین پر یہ قابل قبول ہے جسے آپ دوبارہ rebuild کر سکتے ہوں، لیکن دیگر تمام جگہوں پر یہ غلط ہے۔ مرحلہ 6 میں اسے درست کیا جائے گا۔ loop کے بنیادی تصورات اپنے VPS پر اپنا AI agent بنانا میں مزید تفصیل سے بیان کیے گئے ہیں۔

مرحلہ 3: وہ tools جو agent کے پاس پہلے سے موجود نہیں تھے

آپ کا run_command tool کام کرتا ہے، لیکن ایک حقیقی agent کو ایسے tools درکار ہوتے ہیں جو سرور سے باہر موجود systems تک رسائی دیں: ticket system، database اور repository۔ ہر service اور ہر agent کے لیے الگ bespoke wrapper لکھنا قابلِ توسیع طریقہ نہیں ہے۔

صنعت نے اس مسئلے کے لیے Model Context Protocol (MCP) اختیار کیا ہے۔ MCP server standard transport کے ذریعے tools کا ایک مجموعہ فراہم کرتا ہے، اور کوئی بھی MCP-aware agent اسے custom glue کے بغیر استعمال کر سکتا ہے۔ reference filesystem server کے لیے صرف ایک command درکار ہے:

npx -y @modelcontextprotocol/server-filesystem /home/you/projects

اس کے لیے Node نصب ہونا چاہیے، اور directory argument ہی وہ واحد path ہے جسے server استعمال کرے گا۔ یہ security model کی مختصر مثال ہے: boundary کا فیصلہ model نہیں بلکہ server کرتا ہے۔ کسی client کو اس server کی طرف point کریں، اور آپ کے agent کو file reading اور writing کی وہ صلاحیت مل جاتی ہے جس کے لیے آپ نے خود code نہیں لکھا۔ ان servers کو service account کے تحت درست طریقے سے چلانے اور transport کے انتخاب کی وضاحت AI coding agents کے لیے VPS پر MCP servers چلانا میں کی گئی ہے۔

اس مرحلے کا سبق یہ ہے کہ اصل کام tool design ہے۔ مبہم description model کو اندازہ لگانے پر مجبور کرتی ہے۔ جو tool چالیس ہزار characters واپس کرے، وہ context window کو خراب کر دیتا ہے۔ جو tool چیزیں delete کر سکتا ہو، وہ آخرکار چیزیں delete کرے گا۔

مرحلہ 4: memory، جو زیادہ تر صرف files پر مشتمل ہے

Beginners یہاں vector database استعمال کرنے کی طرف جاتے ہیں۔ کم از کم ابھی ایسا نہ کریں۔

ایک agent calls کے درمیان memory برقرار نہیں رکھتا۔ آپ ہر بار پوری conversation دوبارہ بھیجتے ہیں، اسی لیے طویل session میں ہر turn کی لاگت مختصر session کے مقابلے میں زیادہ ہوتی ہے۔ اس لیے memory دو مسائل میں تقسیم ہو جاتی ہے۔ پہلا مسئلہ یہ ہے کہ اس وقت context window میں کیا سما سکتا ہے۔ آپ اسے summarising، پرانے tool output کو trim کرنے، اور اپنے prompt کے مستحکم prefix کو cache کرنے سے manage کرتے ہیں، تاکہ اس کے لیے قیمت کا صرف ایک حصہ ادا کریں۔ دوسرا مسئلہ یہ ہے کہ restart کے بعد کیا برقرار رہتا ہے۔ یہ storage ہے۔

دوسرے مسئلے کے لیے ایک سادہ markdown file، جسے agent پڑھ اور لکھ سکتا ہو، تقریباً ہر پہلے project کے لیے vector database سے بہتر ہے۔ اسے ایک file دیں، format بتائیں، اور کہیں کہ شروع کرنے سے پہلے یہ file پڑھے اور کچھ سیکھنے پر اسے update کرے۔ آپ کو زیادہ تر فائدہ حاصل ہو جاتا ہے، اور آپ file کھول کر دیکھ سکتے ہیں کہ آپ کا agent کیا سمجھتا ہے۔ جب notes context window میں سما نہ سکیں تو embeddings اور retrieval استعمال کریں، اس سے پہلے نہیں۔

مرحلہ 5: loop ہی product ہے

اب تک آپ ایسا agent بنا سکتے ہیں جو آپ کی نگرانی میں کام کرتا ہے۔ مرحلہ 5 میں اسے اس وقت کام کرنے کے قابل بنانا ہے جب آپ موجود نہ ہوں۔

چار سوالات طے کرتے ہیں کہ unattended agent کو اکیلا چھوڑنا محفوظ ہے یا نہیں۔ اسے کیا trigger کرتا ہے، تاکہ یہ بے وجہ نہ چلے۔ یہ کس boundary کے اندر کام کرتا ہے، تاکہ غلطی محدود رہے۔ نتیجے کی verification کیسے ہوتی ہے، کیونکہ جو agent اپنا homework خود grade کرتا ہے وہ ہمیشہ پاس ہو جاتا ہے۔ اسے روکنے کے لیے کون سا budget مقرر ہے، خواہ tokens میں یا wall clock time میں۔ ان چاروں چیزوں کو جان بوجھ کر design کرنا ہی وہ discipline ہے جسے loop engineering اور اس تعریف میں شامل دائرۂ کار میں بیان کیا گیا ہے۔

مشق: اپنے stage 2 agent کو لیں، اسے ایسا task دیں جس کے لیے چار یا پانچ steps درکار ہوں، اور ایک hard iteration cap شامل کریں۔ پھر cap ہٹا کر دیکھیں کہ unbounded loop آپ کے token bill کے ساتھ کیا کرتا ہے۔ یہ کام پہلے ایک چھوٹے budget پر کریں، تاکہ بڑے budget پر غلطی سے ایسا نہ ہو۔

مرحلہ 6: حفاظت، رازدارانہ معلومات، اور لاگت

یہ مرحلہ اختیاری نہیں ہے۔ یہ صرف اس لیے آخری ہے کہ خطرے کا اندازہ اس وقت تک نہیں ہوتا جب تک آپ کوئی کام کرنے والی چیز تیار نہ کر لیں۔

Agent کو اپنے الگ unprivileged user کے طور پر چلائیں۔ اسے کبھی root یا اپنے ذاتی account کے طور پر نہ چلائیں۔ اس طرح ممکنہ نقصان ایک machine کے بجائے ایک directory تک محدود رہتا ہے۔ Credentials کو model کی رسائی سے باہر رکھیں، کیونکہ context window میں موجود کسی بھی چیز کو tool call کے ذریعے دوبارہ ظاہر کیا جا سکتا ہے۔ اس کا حل یہ ہے کہ اپنے AI agents سے secrets باہر رکھیں میں بیان کردہ helper کے ذریعے محدود اور مختصر مدت کے tokens استعمال کیے جائیں۔ خرچ کی ایک سخت حد مقرر کریں، کیونکہ بغیر نگرانی چلنے والا loop ہر iteration کا بل بناتا ہے۔ اسے قابو میں رکھنے کے لیے caps اور batching کی تفصیل ہمیشہ چلنے والے VPS پر AI agent کی لاگت کا کنٹرول میں موجود ہے۔

لاگت کے لیے ایک واضح عدد دیکھیں۔ July 2026 تک، Claude Opus 5 ہر million input tokens کے لیے $5 اور ہر million output tokens کے لیے $25 وصول کرتا ہے۔ بڑھتی ہوئی conversation کو بار بار بھیجنے والا chatty agent ایک ہی task کے دوران چند hundred thousand tokens استعمال کر سکتا ہے۔ Prompt caching اور معمول کے steps کے لیے چھوٹا model استعمال کرنے سے یہ حساب کسی بھی prompt tweak کے مقابلے میں کہیں زیادہ بدل جاتا ہے۔

Prompt injection بھی اسی مرحلے میں شامل ہے۔ اگر آپ کا agent کسی web page، issue tracker یا inbox کو پڑھتا ہے تو وہ متن لکھنے والا شخص آپ کے agent کے لیے instructions بھی لکھ رہا ہوتا ہے۔ دفاع کسی زیادہ clever system prompt میں نہیں ہے۔ اصل دفاع boundary ہے، کیونکہ جو agent کسی repository کو delete نہیں کر سکتا، اسے repository delete کرنے پر آمادہ نہیں کیا جا سکتا۔

آپ کو کون سا نقشہ اختیار کرنا چاہیے؟

ایک ہی نصاب منتخب کریں اور اسے مکمل کریں؛ چھ نصابوں سے تھوڑا تھوڑا نہ پڑھیں۔ Microsoft ai-agents-for-beginners repository سب سے مکمل مفت ذریعہ ہے۔ یہ 18 اسباق پر مشتمل course ہے اور July 2026 تک اسے 70,000 سے زیادہ stars مل چکے ہیں۔ یہ اوپر بیان کیے گئے مراحل سے واضح طور پر مطابقت رکھتا ہے۔ مقبول agent repositories کی فہرستیں یہ دیکھنے کے لیے مفید ہیں کہ کیا کچھ دستیاب ہے، لیکن نصاب کے طور پر ان کی افادیت بہت کم ہے، کیونکہ stars کے لحاظ سے ترتیب دی گئی فہرست popularity کے مطابق ہوتی ہے، تدریسی ترتیب کے مطابق نہیں۔

جب آپ مشق کے لیے کسی حقیقی project کا انتخاب کرنا چاہیں تو coding agent بہترین ابتدائی ہدف ہے: feedback فوری ملتا ہے، tools واضح ہوتے ہیں، اور غلطیوں کو واپس درست کرنا آسان ہوتا ہے۔ VPS پر coding AI agent چلانا میں ایک agent کو ابتدا سے آخر تک چلانے کا طریقہ بتایا گیا ہے۔ اگر آپ صفر سے بنانے کے بجائے چلتے ہوئے systems کا مطالعہ کرنا چاہیں تو بہترین self-hosted AI agents میں موجود موازنہ دکھاتا ہے کہ کئی projects ایک ہی loop کو مختلف طریقوں سے کیسے حل کرتے ہیں۔

اس میں کتنا وقت لگتا ہے؟

جو شخص پہلے سے programming کرتا ہو، اس کے لیے stages 1 اور 2 ایک شام کا کام ہیں۔ stage 3 میں ایک ہفتہ وار تعطیل لگتی ہے، جس کا زیادہ تر وقت protocol کے بجائے tools کی وضاحتوں پر صرف ہوتا ہے۔ stages 4 اور 5 کے لیے حقیقی استعمال کے چند ہفتے درکار ہوتے ہیں، کیونکہ آپ صرف اسی وقت سیکھتے ہیں کہ آپ کا agent کیا بھولتا ہے جب آپ اسے بھولتے ہوئے monitor کرتے ہیں۔ stage 6 کبھی مکمل طور پر ختم نہیں ہوتا، کیونکہ ہر نئی capability جس کی آپ اجازت دیتے ہیں، اسے دوبارہ کھول دیتی ہے۔

مسلسل دو ماہ کی شامیں زیادہ تر لوگوں کو ایک working، bounded اور useful agent تک پہنچا دیتی ہیں۔ جو لوگ ایک سال لگاتے ہیں، عموماً وہی ہوتے ہیں جو build کرنے کے بجائے پڑھتے رہتے ہیں۔

FAQ

کیا AI agent بنانے کے لیے machine learning جاننا ضروری ہے؟

نہیں۔ Agent بنانے کا مطلب API کے ذریعے model کو call کرنا اور اس کی tool requests کو حقیقی functions سے جوڑنا ہے، جو عام application programming ہے۔ آپ کو training، gradients یا datasets سے براہ راست واسطہ نہیں پڑتا۔ آپ کے agent کے کام کرنے یا نہ کرنے کا فیصلہ tools کے لیے schema design، error handling اور Linux permissions جیسی مہارتیں کرتی ہیں۔ Machine learning theory صرف اس وقت متعلقہ بنتی ہے جب آپ model کو fine tune کرنے کی طرف جائیں، جو مختلف prerequisites کے ساتھ ایک الگ کام ہے۔

کیا مجھے LangChain یا CrewAI جیسے framework سے آغاز کرنا چاہیے؟

پہلے ایک raw loop خود لکھیں، پھر framework اپنائیں۔ Framework، stage 2 کی تیس lines کو ایک configuration object سے بدل دیتا ہے۔ یہ اس وقت سہولت دیتا ہے جب آپ جانتے ہوں کہ اس نے کیا بدلا ہے، لیکن اس سے پہلے الجھن پیدا کرتا ہے۔ جب agent غلط برتاؤ کرے تو آپ کو message list اور tool results کو براہ راست سمجھنا پڑتا ہے۔ اگر آپ نے انہیں پہلے کبھی نہ دیکھا ہو تو یہ کام بہت مشکل ہو جاتا ہے۔ اپنا ایک loop لکھنے کے بعد framework mechanism چھپانے کے بجائے آپ کا وقت بچاتا ہے۔

AI agents سیکھنے میں کتنی لاگت آتی ہے؟

اگر آپ حد مقرر رکھیں تو توقع سے کم۔ ایک hosted API key اور چھوٹا VPS ان چھ stages کے لیے کافی ہیں۔ اصل خطرہ فی گھنٹہ لاگت نہیں، بلکہ وہ بے قابو loop ہے جو آپ کے سوتے وقت ہر iteration کا bill بناتا رہے۔ پہلے دن ہی اپنے API account پر hard spend limit مقرر کریں، اپنے ہر loop میں iteration cap شامل کریں، اور معمول کے steps کے لیے کم لاگت والا model استعمال کریں۔ Model کو مقامی طور پر چلانے سے token bill ختم ہو جاتا ہے، لیکن اس کے بدلے hardware درکار ہوتا ہے۔

AI agent اور chatbot میں کیا فرق ہے؟

Chatbot ایک بار جواب دیتا ہے۔ Agent ایک cycle دہراتا ہے: model کسی tool کی درخواست کرتا ہے، آپ کا code اسے چلاتا ہے، result واپس جاتا ہے، اور model طے کرتا ہے کہ اگلا قدم کیا ہونا چاہیے۔ یہی تکرار agent کو کئی steps پر مشتمل task مکمل کرنے دیتی ہے۔ اسی وجہ سے agents کو ایسی boundaries درکار ہوتی ہیں جو chatbots کے لیے ضروری نہیں ہوتیں۔ Chatbot کا غلط جواب ایک خراب paragraph ہوتا ہے۔ Agent کا غلط جواب ایک خراب paragraph کے ساتھ وہ action بھی ہوتا ہے جو اس نے اس کے بارے میں انجام دیا ہو۔