Anthropic کا MHS: AI agents اب lab equipment ایک زبان میں چلائیں گے

Anthropic نے 27 اگست 2026 کو Model Hardware Standard، یا MHS، کا محدود research preview شروع کیا۔ Reuters کی 27 اگست کی رپورٹ کے مطابق یہ framework AI agents کو microscopes اور robotic arms جیسے programmable آلات باہم مربوط کر کے چلانے دیتا ہے، مگر ابتدائی version ابھی partners کے ساتھ safety evaluations کے لیے شیئر کیا جا رہا ہے۔

اس 27 اگست کے preview میں “ایک زبان” سے مراد ہر مشین کو براہ راست عام بول چال میں حکم دینا نہیں، بلکہ مختلف آلات کے لیے مشترک software interface ہے۔ رسائی درخواست کی بنیاد پر محدود ہے؛ MHS ابھی عام open-source release، certified industrial control system یا production-ready automation platform نہیں۔

MHS driver مشینوں کے فرق کو کیسے چھپاتا ہے

ہر laboratory instrument یا صنعتی مشین عموماً اپنی API، commands اور data format رکھتی ہے۔ MHS اس فرق کے اوپر standardized driver رکھتا ہے: یہ آلے کے vendor-specific interface کو مشترک read اور write operations میں بدلتا اور device کو قابل دریافت format میں پیش کرتا ہے۔

Anthropic کی MHS technical وضاحت کے مطابق driver میں قدرتی زبان کے tags کے ذریعے آلے کی قابل پیمائش حالتیں، adjustable controls، physical characteristics اور نافذ ہونے والی safety limits درج کی جا سکتی ہیں؛ انہی tags سے agent کے لیے reference file بنتی ہے۔ یہ architecture درج ذیل flow بناتا ہے:

1. Onboarding: programmable device کے موجودہ interface کے لیے MHS driver بنایا جاتا ہے۔
2. Description: driver measurements، controls، operating state اور متعلقہ جسمانی حدود مشترک format میں ظاہر کرتا ہے۔
3. Discovery: agent دستیاب devices اور ان کی مجاز operations شناخت کرتا ہے۔
4. Execution: agent read/write commands چلاتا ہے یا تیز اور طویل کارروائی کو deterministic code file میں جوڑتا ہے۔
5. Feedback: نئی sensor readings اور device state واپس آتی ہیں، جن کی بنیاد پر اگلی محدود کارروائی طے ہوتی ہے۔

اس کا فائدہ یہ ہے کہ orchestration layer کو ہر microscope، liquid handler یا robotic arm کی مکمل الگ vocabulary نہیں سیکھنی پڑتی۔ مگر MHS driver خود تیار کرنا، vendor API سے درست mapping بنانا اور مقامی limits درج کرنا بدستور engineering کام ہے؛ جس مشین کا programmable interface ہی نہ ہو اسے یہ standard خودکار طور پر قابل کنٹرول نہیں بناتا۔

MHS اور MCP کا تعلق کہاں بنتا ہے

MHS کو “hardware کے لیے MCP” کہنا بنیادی خیال سمجھنے میں مدد دیتا ہے، مگر دونوں ایک protocol نہیں۔ MHS آلے کی capabilities، state اور operations بیان کرنے والی hardware-facing layer ہے؛ Model Context Protocol ان راستوں میں سے ایک ہے جن سے agent اس layer تک رسائی حاصل کر سکتا ہے۔

MHS device control کے لیے MCP کے ساتھ command-line interface اور code files یا APIs بھی استعمال کر سکتا ہے۔ سادہ خاکہ یوں بنتا ہے: agent یا agent harness → MCP، CLI یا API → MHS driver → programmable physical device۔ اسی separation کی وجہ سے standard model-agnostic رہ سکتا ہے، البتہ مختلف models یا harnesses کی عملی safety اور reliability خود بخود یکساں ثابت نہیں ہوتیں۔

ابتدائی pilots صلاحیت دکھاتے ہیں، آزاد benchmark نہیں

Preview کے تجربات biotechnology، microscopy، quantum hardware اور manufacturing تک پھیلے ہیں۔ SiliconANGLE کی آزاد رپورٹنگ محدود partner access کی تصدیق کرتی ہے اور HHMI کے microscope-management agent، QuEra کے laser coordination، نیز AWS، Hugging Face اور industrial robotics suppliers کی جاری integration سرگرمیوں کا ذکر کرتی ہے۔

• Genentech proof of concept: Claude اور MHS نے liquid handler، robotic arm اور plate reader کو BCA protein assay کے مراحل میں coordinate کیا۔ یہ ایک مخصوص workstation اور assay کی demonstration ہے، عمومی laboratory reliability test نہیں۔
• HHMI Janelia microscopy: مختلف vendors کے lasers، focusers اور cameras والے rig کو مشترک interface سے جوڑنے کا کام MHS کی بنیاد بنا۔ یہ heterogeneous instruments کے مسئلے کی حقیقی مثال ہے، کسی finished commercial microscopy product کا اعلان نہیں۔
• QuEra laser workflow: agent نے live instruments سے feedback لے کر laser recovery کا deterministic script بہتر کیا۔ رپورٹ شدہ نتیجہ اسی setup اور partner test سے متعلق ہے؛ اسے تمام quantum systems پر MHS کی کامیابی کی شرح نہیں سمجھا جا سکتا۔
• Vendor integrations: کچھ suppliers drivers بنا رہے ہیں، support شامل کر رہے ہیں یا early access tests کر چکے ہیں۔ ان مختلف status کو shipped، certified اور production-supported integration کے برابر رکھنا درست نہیں۔

اعلان میں integration speed، assay performance اور laser recovery کے جو نتائج شامل ہیں وہ Anthropic اور شریک اداروں کے اپنے experiments سے آئے ہیں۔ کوئی مشترک آزاد test suite، متعدد labs میں reproducibility study یا public failure-rate benchmark جاری نہیں ہوا، اس لیے pilots امکان دکھاتے ہیں، عمومی کارکردگی ثابت نہیں کرتے۔

Physical safety کی حد software interface سے آگے ہے

مشترک commands جسمانی خطرات ختم نہیں کرتیں۔ Model text، code اور images سے حاصل شدہ context پر کام کرتا ہے، اس لیے sample viscosity، foaming، mechanical clearance، vibration یا بدلتے ماحول کا اثر غلط سمجھ سکتا ہے۔ Genentech کے pilot میں ماہرین کو Claude کو یہ سمجھانے کی ضرورت پڑی کہ protein samples میں bubbles سے پیدا ہونے والی خرابی software bug نہیں بلکہ physical failure تھی۔

Production deployment کا دعویٰ کرنے سے پہلے کم از کم یہ controls MHS agent سے الگ اور قابل آزمائش ہونے چاہییں:

• driver version، supported device interface، مالک اور review status واضح ہوں؛
• force، speed، temperature، laser power اور travel range کی hard limits agent سے نچلی control layer پر نافذ ہوں؛
• خطرناک commands کے لیے انسانی منظوری، محدود permissions اور حقیقی emergency stop موجود ہو؛
• commands، sensor readings، manual interventions اور partial execution کا audit trail محفوظ ہو؛
• network loss، stale readings، conflicting states اور interrupted workflows کے لیے deterministic fail-safe طے ہو؛
• validation پہلے simulation، inert material یا محدود test cell میں ہو، نہ کہ حساس sample یا live production line پر۔

یہ MHS کی جاری کردہ certification scheme نہیں بلکہ preview کی معلوم حدود سے اخذ کردہ deployment checklist ہے۔ اصل safety boundary driver کی description نہیں، بلکہ وہ physical interlocks اور انسانی اختیار ہیں جو غلط command کو مشین تک پہنچنے یا جاری رہنے سے روک سکیں۔

Production-ready ہونے سے پہلے کیا غائب ہے

MHS کی موجودہ حیثیت application-based limited research preview ہے۔ صرف programmable interface رکھنے والا equipment شامل ہو سکتا ہے، expert oversight اب بھی ضروری ہے، اور standard کو safety evaluations اور operating practices پر partner work مکمل ہونے سے پہلے open source نہیں کیا گیا۔

Public release کی حتمی تاریخ، stable specification، driver compatibility certification، آزاد reliability data اور production support commitments ابھی دستیاب نہیں۔ اگلا فیصلہ کن مرحلہ صرف code کا کھلنا نہیں ہوگا؛ یہ بھی دیکھنا ہوگا کہ preview سے قابل جانچ safety guidance، failure data، driver-review rules اور physical deployment boundaries سامنے آتی ہیں یا نہیں۔

یہ بھی پڑھیں:

• ServiceNow کے تین flaws کا اسکور 10.0—کون سے instances خطرے میں ہیں؟