ایجنٹ ماڈل

ایجنٹ کیا ہے؟

ایجنٹ ایک نامزد فریق ہوتا ہے جس کی ایک شخصیت، مہارتوں کا ایک مجموعہ، اور چلانے کے لیے ایک اڈاپٹر ہوتا ہے۔ ایجنٹ اُسی معنی میں پرنسپل ہیں جس معنی میں انسان ہیں: وہ پیغامات لکھتے ہیں، ٹکٹوں کے مالک ہوتے ہیں، جائزے چھوڑتے ہیں اور اُسی روسٹر پر نظر آتے ہیں۔ کام دراصل وہی کرتے ہیں۔

ہر ایجنٹ کا تعلق ٹھیک ایک ورک اسپیس سے ہوتا ہے۔ یہ ایک سخت ناقابلِ تغیر اصول ہے — agent.workspaceId غیر null ہے، ایجنٹ کی اپنی ورک اسپیس ہی طے کرتی ہے کہ اس کے ریکارڈ کس ڈیٹا بیس فائل میں جائیں گے، اور ورک اسپیس کے بغیر ایجنٹ بنانے کی درخواست مسترد کر دی جاتی ہے۔

ایجنٹ ایک ڈائریکٹری بھی ہوتا ہے۔ اس کی تعریف ورک اسپیس کی ڈیٹا ڈائریکٹری کے اندر agents/<slug>/AGENTS.md پر رہتی ہے، اور اس کی مہارتیں agents/<slug>/.agents/skills میں سم لنک ہوتی ہیں۔ ڈیٹا بیس کا ریکارڈ اور فائل ایک ساتھ لکھے جاتے ہیں۔ سیڈنگ ایڈمپوٹنٹ ہے: اگر ایجنٹ کا ریکارڈ پہلے سے موجود ہو تو بھی ڈسک پر موجود فائلیں اور مہارت کے لنک دوبارہ لکھے جاتے ہیں۔ پروڈکشن میں اس کا بلانے والا ورک اسپیس کی تخلیق ہے، ہر سرور لانچ نہیں۔

ایجنٹ کے پاس کیا ہوتا ہے

خصوصیت	یہ کیا کرتی ہے
name	مختصر slug جیسا شناخت کنندہ (architect, qa)۔ ساتھ ہی وہ چیز جس کے خلاف @mentions حل ہوتے ہیں
title	انسان کے پڑھنے کے قابل عہدے کا عنوان
persona	آزاد متن میں شخصیت اور رویے کی ہدایات، جو پرامپٹ کے ایک حصے کے طور پر شامل کی جاتی ہیں
systemPrompt	اختیاری اضافی ہدایات، جو “ایجنٹ ہدایات” کے حصے کے طور پر شامل کی جاتی ہیں — یہ جوڑے گئے پرامپٹ کے باقی حصے کی جگہ نہیں لیتیں
skills	مہارتوں کے ناموں کا غیر حساسِ حروف مجموعہ، جو ڈسک پر مہارت کے لنکوں کی صورت میں جھلکتا ہے
adapterId	ایجنٹ کس رنر کو بھیجتا ہے۔ null ہونے پر بلٹ اِن لوپ پر واپس آ جاتا ہے
modelId	اُس اڈاپٹر کے اندر کون سا ماڈل
effort	استدلال کی سطح، جو منتخب ماڈل کی اپنی اصطلاحات سے لی جاتی ہے
contextSize	کانٹیکسٹ ونڈو کی اوور رائیڈ
silenceTimeoutMinutes	خاموشی واچ ڈاگ کے لیے فی ایجنٹ اوور رائیڈ (1–240)
reportsTo	والد ایجنٹ کی id — وہ رپورٹنگ زنجیر جو آرگ چارٹ بناتا ہے

یہ سب آپ ترتیبات → ورک اسپیس → ایجنٹس پر ترمیم کرتے ہیں۔ نیا ایجنٹ ایک بے نام ایجنٹ بناتا ہے جسے پھر آپ بھرتے ہیں۔

مہارتیں

مہارتیں ایجنٹ ہستی پر غیر حساسِ حروف نام ہوتی ہیں۔ اُن کے ساتھ دو الگ الگ چیزیں ہوتی ہیں:

• نام جوڑے گئے پرامپٹ میں “مہارتیں” کے عنوان کے نیچے درج ہوتے ہیں۔ ہستی کا مجموعہ خود سے بس یہی کرتا ہے — اس پر مبنی کوئی فی مہارت پرامپٹ لائبریری نہیں ہوتی۔
• ہر نامزد مہارت کی ڈائریکٹری (ورک اسپیس میں skills/<slug>/SKILL.md) ایجنٹ کے اپنے فولڈر میں لنک کی جاتی ہے۔ بلٹ اِن ہارنس پر، لنک شدہ مہارتوں کا frontmatter خودکار طور پر سسٹم پرامپٹ میں لوڈ ہو جاتا ہے اور ایجنٹ ضرورت پر کوئی باڈی پڑھتا ہے؛ گفتگو میں /skill:<name> ٹائپ کرنے سے وہ باڈی اُس باری کے لیے ایک ہدایت کے طور پر لوڈ ہو جاتی ہے۔

باہر سے لائی گئی مہارتیں لانے اور لکھنے کے درمیان ایک ناکامی پر بند ہو جانے والا سپلائی چین اسکین سے گزرتی ہیں — کسی فیصلے کے بغیر کوئی مہارت کا مواد نہ ڈسک تک پہنچتا ہے نہ پرامپٹ تک۔ “باہر” سے مراد وہ GitHub ریپوزٹریز ہیں جنہیں آپ خود مہارت کے ماخذ کے طور پر رجسٹر کرتے ہیں: کوئی منتخب اسٹور نہیں ہے، اس لیے ریپوزٹری کا اپنا میٹا ڈیٹا (اس کی تفصیل، اس کے اسٹارز، مہارت کا نام) ناقابلِ اعتماد ڈسپلے ڈیٹا ہے اور اسکین کا فیصلہ ہی واحد حفاظتی اشارہ ہے۔ کوئی بھی انسٹال مہارت کی پوری ڈائریکٹری لے آتا ہے، اسے skills-lock.json میں اُس کمیٹ پر پن کرتا ہے جہاں سے وہ آیا، اور بعد میں کوئی اپ ڈیٹ کچھ بھی بدلنے سے پہلے اُسی گیٹ سے دوبارہ گزرتا ہے۔ طریقہ کار مہارتیں انسٹال اور منظم کریں میں موجود ہے۔

ریپو کے دائرہ کار کی مہارتیں

کوئی ریپو اپنی مہارتیں روایتی مقامات میں سے کسی میں بھی بھیج سکتا ہے (.agents/skills/, .claude/skills/, .opencode/skills/)۔ ایک اسپیس ہر لنک شدہ ریپو کو repos/<name>/ کے نیچے ساتھ ساتھ چیک آؤٹ کرتی ہے، مگر ایجنٹ ایک وقت میں ایک ریپو میں کام کرتا ہے — اس لیے وہ صرف اُسی ریپو کی مہارتیں ساتھ رکھتا ہے، اور منتقل ہونے پر وہ بدل جاتی ہیں۔

کون سا ریپو فعال ہے یہ ایجنٹ کے چھونے والی فائلوں سے اخذ کیا جاتا ہے: repos/<name>/ کے نیچے فائل لکھنے سے وہی فعال ریپو بن جاتا ہے، جبکہ محض ریپوز کے پار پڑھنے سے ایسا نہیں ہوتا، اس لیے کسی ہم مرتبہ سروس میں کسی سمبل کا پیچھا کرنا کسی کام کے نیچے سے مجموعہ نہیں بدلتا۔ ایک ہی ریپو والی اسپیس پر یہ جواب پہلی باری سے پہلے ہی معلوم ہوتا ہے۔

یہ دائرہ بندی کانٹیکسٹ بجٹ کا فیصلہ ہے۔ مہارت کا انڈیکس ہر باری پر پرامپٹ میں رہتا ہے جبکہ باڈیز نہیں، اس لیے ہر ریپو کی مہارتیں ایک ساتھ درج کرنا مسلسل ٹوکن خرچ کرتا ہے — اور ایک سروس کی testing مہارت فعال طور پر گمراہ کرتی ہے جب کام کسی دوسری جگہ ہو۔ یہی استدلال بتاتا ہے کہ ایجنٹ کے انڈیکس میں ایک ریپو کیوں ہوتا ہے مگر کمپوزر کا دائرہ اُس طرح بند نہیں: مہارت کا نام خود دینا ایک واضح عمل ہے، اس لیے /skill:<repo>:<name> اسپیس کے کسی بھی ریپو تک پہنچ جاتا ہے۔

ریپو کی مہارتیں ہر اڈاپٹر کے لیے لوڈ ہوتی ہیں، صرف بلٹ اِن ہارنس کے لیے نہیں۔ فعال ریپو کی مہارتیں ایجنٹ کی ورکنگ ڈائریکٹری میں تیار کر دی جاتی ہیں، جو وہی راستہ ہے جسے Claude Code پہلے ہی اسکین کرتا ہے؛ وہی انڈیکس AGENTS.md میں تشکیل دیا جاتا ہے جسے بلٹ اِن ہارنس پڑھتا ہے۔ ریپو کی مہارتیں یہ سب ہونے سے پہلے وہی ناکامی پر بند ہو جانے والا اسکین پاس کرتی ہیں جو ایک انسٹال شدہ مہارت کرتی ہے — چیک آؤٹ کیا گیا ریپو کلون شدہ مواد ہے، اور اس کا frontmatter ایک پرامپٹ تک پہنچتا ہے۔

اجازتیں

ایجنٹ کوئی اجازتی فلیگ نہیں رکھتا۔ وہ کمیٹ بنا سکتا ہے، پش کر سکتا ہے، pull request کھول سکتا ہے، کسی ٹریکر پر لکھ سکتا ہے یا نیٹ ورک تک پہنچ سکتا ہے یا نہیں، یہ ایکشن گارڈریلز طے کرتے ہیں — اجازت دیں، پہلے پوچھیں یا منع کریں، ورک اسپیس، ایجنٹ یا اسپیس کے دائرے میں — اور یہی قواعد لاگو ہوتے ہیں چاہے اسے کوئی بھی اڈاپٹر چلائے۔

کسی رن کو جو کچھ دیا جاتا ہے وہ ان قواعد کے ساتھ نہیں بدلتا۔ GitHub worktree میں چلنے والے رن کو ہمیشہ صرف پڑھنے والا GitHub ٹوکن ملتا ہے، اور پش کے بارے میں اُسی لمحے پوچھا جاتا ہے جب وہ ہوتا ہے: ایجنٹ کی git کنفیگریشن GitHub پر ہر پش کو Control Center کے ذریعے بھیجتی ہے، جو اسے آگے بڑھانے سے پہلے ریموٹ پر پش کریں قاعدہ لاگو کرتا ہے۔

یہ کیسے کام کرتا ہے، بشمول یہ کہ فائل سسٹم کی سطح پر کیا نافذ ہوتا ہے اور کیا نہیں، سینڈ باکس اور سیکیورٹی میں دیکھیں۔

اڈاپٹر طے کرتا ہے کہ کیا نافذ ہو سکتا ہے

ایجنٹ پر سب سے زیادہ اثر رکھنے والا واحد فیلڈ اس کا اڈاپٹر ہے، کیونکہ اڈاپٹر کا ٹرانسپورٹ طے کرتا ہے کہ Control Center کی پالیسی کا کتنا حصہ واقعی نافذ ہو سکتا ہے۔

ٹرانسپورٹ	اڈاپٹرز	Control Center کیا نافذ کرتا ہے
بلٹ اِن ہارنس	Control Center (built-in)	سب کچھ۔ ٹول کی سطح موڈ سے بنائی جاتی ہے، اس لیے نامنظور ٹول صرف مسترد نہیں ہوتا بلکہ نظر ہی نہیں آتا؛ ہر کال منظوری کے گیٹ اور ایکشن گارڈریلز سے گزرتی ہے؛ مکمل ہونے کا معاہدہ ایسے رن کو جو اپنی مطلوبہ تیاری کے بغیر ختم ہو، پہلے اکسا کر پھر ناکام کر سکتا ہے
Claude CLI	Claude Code	وہ mcp__* ٹولز جو اسے دیے جاتے ہیں، اور اس کی Bash کمانڈز، جنہیں ایک ہک چلنے سے پہلے ایکشن پالیسی کو بھیجتا ہے۔ Claude کے اپنے read، write اور edit ٹولز اس کے پراسیس میں رہتے ہیں اور نظر آئے بغیر چلتے ہیں — اور اسے --dangerously-skip-permissions کے ساتھ لانچ کیا جاتا ہے، کیونکہ غیر متعامل claude -p ورنہ اپنے ہی پرامپٹ پر ہمیشہ کے لیے رکا رہے گا

حقیقتاً، صرف بلٹ اِن ہارنس سب ایجنٹس، رن کے دوران اسٹیرنگ، توقف اور دوبارہ آغاز (اور اسی لیے ٹیک اوور) اور ساختی موڈ نفاذ کی حمایت کرتا ہے۔ Claude Code کو ان میں سے کچھ بھی نہیں ملتا۔

OS سینڈ باکس ایک فلور ہے، موڈ نافذ کرنے والا نہیں، اور ہر ہوسٹ پر موجود نہیں

اوپر کا میٹرکس اسی بارے میں ہے کہ Control Center کیا دیکھ اور گیٹ کر سکتا ہے۔ اس کے نیچے، cc_server جہاں موجود ہو وہاں Claude Code CLI کو ہوسٹ کے OS سینڈ باکس میں لپیٹ دیتا ہے — macOS پر Seatbelt، Linux اور WSL2 پر bubblewrap — چنانچہ کوئی نظر نہ آنے والا rm یا نظر نہ آنے والی write بھی OS کی طرف سے محدود رہتی ہے۔ Windows پر کوئی بیک اینڈ بالکل نہیں اور Linux یا WSL2 پر bwrap اور socat کے بغیر جانچ کچھ نہیں بتاتی، اس لیے وہاں ایسے رنز ماحول کی صفائی، بروکر شدہ اسناد، اُن کالوں پر گارڈریلز جنہیں Control Center دیکھ سکتا ہے، اور گفتگو کے اپنے worktree (جہاں rift موجود ہو وہاں copy-on-write؛ Windows پر git worktree) پر واپس چلے جاتے ہیں۔

سینڈ باکس جو چیز نہیں ہے وہ ایک گیٹ ہے۔ یہ محدود کرتا ہے کہ کوئی پراسیس کہاں پڑھ، لکھ اور جڑ سکتا ہے — صرف پڑھنے کا موڈ اس تک پہنچتا ہے، بطور صرف پڑھنے کے بائنڈ ماؤنٹس — مگر یہ کسی کال کو روک نہیں سکتا، منظوری نہیں مانگ سکتا، اور بعد میں نہیں بتا سکتا کہ CLI نے کیا کرنے کی کوشش کی۔ یہی چیز، اور اوپر بتائی گئی چار قابلیتیں، وہ ہیں جو بلٹ اِن ہارنس کے پاس ہیں اور باقیوں کے پاس نہیں۔ سینڈ باکس اور سیکیورٹی دیکھیں۔

جس ایجنٹ کے پاس کوئی اڈاپٹر نہ ہو وہ Control Center (بلٹ اِن) پر واپس چلا جاتا ہے — سرور کے اندر کا لوپ، اس لیے انسٹال کرنے کے لیے کوئی CLI نہیں — اور اس کا رن لاگ cc-harness درج کرتا ہے۔ ہر سیڈ کیا گیا ایجنٹ بغیر اڈاپٹر اور بغیر ماڈل بنایا جاتا ہے، اس لیے ایک نئی ورک اسپیس کے پانچ ایجنٹ سب وہیں چلتے ہیں، Anthropic کے ڈیفالٹ ماڈل پر، جب تک آپ فی ایجنٹ اڈاپٹر اور ماڈل مقرر نہیں کرتے۔ آن بورڈنگ میں “ڈیفالٹ اڈاپٹر” کا انتخاب ایک کلائنٹ طرفہ ترجیح ہے جسے سرور کبھی نہیں پڑھتا اور یہ پہلے سے بنے ایجنٹس پر بعد ازاں لاگو نہیں ہوتی۔

ایجنٹ کہاں سے آتے ہیں

• ورک اسپیس کے ساتھ سیڈ ہوتے ہیں۔ ہر ورک اسپیس — صرف پہلی ہی نہیں — کو ایک CEO اور اس کے تحت چار ماہرین (qa, architect, engineer, librarian) ملتے ہیں، جو ورک اسپیس بنتے وقت پس منظر میں ایڈمپوٹنٹ طور پر بنائے جاتے ہیں۔ ورک اسپیسز اور تنہائی دیکھیں۔
• ہاتھ سے شامل کیے جاتے ہیں ترتیبات → ورک اسپیس → ایجنٹس پر۔ کسی ایجنٹ سے ساتھی بھرتی کرنے کو کہنے سے کوئی ریکارڈ نہیں بنتا؛ وہی اسکرین استعمال کریں۔

لائیو حالت

ایجنٹ کا کوئی محفوظ اسٹیٹس کالم نہیں ہوتا۔ اس کی لائیو حالت ہر بار پڑھے جانے پر اس کے تازہ ترین رن لاگز سے اخذ کی جاتی ہے:

حالت	مطلب
neverRun	کوئی رن لاگ موجود نہیں
running	کم از کم ایک رن اس وقت جاری ہے
failed	تازہ ترین رن میں خرابی آئی، یا اس کی فعالیت ناکام یا مردہ ہے
blocked	تازہ ترین رن کی فعالیت بلاک، رکی ہوئی یا لوپ میں ہے
idle	باقی سب کچھ — ایجنٹ پہلے چل چکا ہے اور اس وقت کچھ بھی پرواز میں نہیں

دو مزید حالتیں، queued اور succeeded، گفتگو کے رن ٹری میں انفرادی رنز کے لیے موجود ہیں؛ روسٹر انہیں کبھی پیدا نہیں کرتا، کیونکہ مکمل شدہ رن کا سبز ہونا رن کے بارے میں ایک حقیقت ہے، ایجنٹ کے بارے میں نہیں۔

موجودگی کا روسٹر سرور کی طرف سے لائیو رن ایونٹس — سوچ رہا ہے، چل رہا ہے، منظوری پر بلاک، مکمل — سے ترکیب کردہ ایک متوازی، موٹی تصویر دکھاتا ہے، اور اسی وجہ سے ایجنٹ انسانوں کے ساتھ نظر آتے ہیں۔ ملٹی پلیئر دیکھیں۔

متعلقہ تصورات

• ایجنٹ ڈسپیچ لائف سائیکل: جب ایجنٹ واقعی چلایا جاتا ہے تو کیا ہوتا ہے
• موڈز: فی گفتگو وہ ترتیب جو ایجنٹ کے ٹول کی سطح کو تشکیل دیتی ہے
• ملٹی پلیئر: ایجنٹ بحیثیت پرنسپل، موجودگی اور خود مختاری کا ڈائل
• سینڈ باکس اور سیکیورٹی: آج کسی رن کو کیا محدود کرتا ہے
• ایجنٹ کنفیگریشن حوالہ: مکمل فیلڈ فہرست