پروتکل جدید عامل‌های هوش مصنوعی؛ جایگزینی برای لیست‌های ابزار ایستا

تصور کنید یک برنامه‌نویس هستید که می‌خواهد دنیای بازی‌اش را به هوش مصنوعی بسپارد، اما هر حرکت یک شخصیت غیرقابل‌بازی (NPC) ثانیه‌ها طول می‌کشد تا پردازش شود. این دقیقاً همان دیواری است که منجر به خلق یک پروتکل جدید برای تعامل عامل‌ها با نرم‌افزار شد. این درک عمیق که «لیست‌های ایستای ابزارها مشکل اصلی هستند»، در تاریخ ۱۷ جولای ۲۰۲۶ به ذهن یک توسعه‌دهنده خطور کرد. او در آن زمان در تلاش برای ساخت یک بازی MMO مبتنی بر مدل‌های زبانی بزرگ (LLM) بود و متوجه شد که رویکردهای فعلی در مواجهه با سرعت و دقت شکست می‌خورند. او به این نتیجه رسید که برای رسیدن به تعاملات آنی و حذف شکاف‌های زمینه‌ای، باید یک پروتکل پویا و آگاه از وضعیت (State-aware) طراحی کرد تا تأخیرات ذاتی در چارچوب‌های فعلی عامل‌های هوشمند برطرف شود.

این پروژه از مفهومی به نام وایب کدینگ (Vibe Coding) بیرون آمد؛ روشی که در آن قصد کلی برنامه‌نویس و قدرت تولید مدل‌ها، موتور پیش‌برنده ساخت هستند. با توجه به ماهیت تقریبی این رویکرد، برخی کارشناسان هشدار داده‌اند که تولید نرم‌افزار بر اساس «حس» یا همان وایب کدینگ می‌تواند شکاف‌های امنیتی خطرناکی در محیط‌های عملیاتی ایجاد کند. مسیر رسیدن به این نقطه برای این توسعه‌دهنده ساده نبود. او تا ابتدای سال ۲۰۲۶ یک «متنفر از هوش مصنوعی» (AI hater) بود، اما ناگهان دچار یک چرخش ۱۸۰ درجه شد و به اصطلاح «AI-pilled» شد. این تغییر مسیر به معنای غوطه‌وری کامل در مدل‌های محلی، موتورهای استنتاج (Inference Engines) و harnessing عامل‌ها بود تا تمام پکیج فنی این فناوری را فرا بگیرد.

نقطه عطف این تغییر، عرضه مدل Opus 4.5 از سوی شرکت Anthropic بود. توسعه‌دهنده با اکراه اعتراف می‌کند که این مدل لحظه‌ای حیاتی بود که به او فهماند این ابزارها می‌توانند واقعاً برای مهندسی نرم‌افزار مفید باشند. با این حال، این پذیرش با یک کلنجار ذهنی همراه بود: مانند بسیاری از مهندسان، او نیز سخت بود که بپذیرد مهارت‌هایی که سال‌ها برای کسب آن‌ها سخت تلاش کرده بود، در حال تبدیل شدن به ابزارهایی تا حدودی بی‌استفاده هستند، حتی اگر همیشه این موضوع را به زبان نیاورده باشد. پیش از این مقطع، مفاهیمی مثل تکمیل خودکار کد (Tab Autocomplete) یا تولید کدهای سطح پایین، برای او اصلاً جذاب نبودند.

زمینه این تحول را باید در تلاطمات شخصی سال ۲۰۲۵ جست. در آن سال، این توسعه‌دهنده با ضربه‌ی «چکش بدنام اخراج‌ها» مواجه شد و تأثیر آن بسیار دردناک بود. این اتفاق منجر به دورانی از «برزخ بازار کار» شد؛ دورانی که با ارسال درخواست‌های بی‌هدف برای هر موقعیت شغلی موجود زیر هر خورشیدی، سرزنش کردن «سیستم» و به‌طور کلی احساس بدبختی شناخته می‌شد. پس از گذشت چند ماه، آن بخش از ذهن او که او به آن «میمون درون مغز» می‌گوید، تصمیم گرفت روی هدف متمرکز شود (Lock in). زمان آن رسیده بود که به آینده نگاه کند و ببیند با به حداکثر رساندن استفاده از این ابزار درخشان و جدید، چه دستاوردی ممکن است حاصل شود.

او که از کودکی شخصیت یک «نرد» (Nerd) را داشت — و اشاره می‌کند که پیش از آنکه نرد بودن مد شود، نرد بود و حتی مطمئن نیست الان واقعاً باحال باشد یا نه — از نبود بازی‌های MMO جدید و باکیفیت احساس درماندگی می‌کرد. او عاشق پیش‌فرض و ایده‌ی این بازی‌ها بود، اما نبود عناوین نسل جدید همیشه مانع از بازی کردن او می‌شد. او به شوخی اشاره می‌کند که شاید این کمبود گزینه‌ها برای صلاحش بوده، زیرا احتمالاً در صورت وجود، دچار اعتیاد شدید به این بازی‌ها می‌شد. با این اشتیاق برای یادگیری و خلق، او شروع به کار روی پروژه‌ای به نام «SAO: Slop Art Online» کرد. اگرچه نام پروژه عجیب به نظر می‌رسد، اما نویسنده تأکید می‌کند که هنگام ایده‌پردازی، این نام «خنده‌دارترین چیز ممکن» بود و از خوانندگان می‌خواهد که درباره آن قضاوت نکنند.

برای ساخت این اولین بازی «واقعی»، توسعه‌دهنده عمداً انتخاب‌های غیربهینه‌ای برای پشته فنی (Tech Stack) خود داشت. او از ترکیب Rust، Bevy و SpacetimeDB استفاده کرد. در حالی که این‌ها ابزارهایی قدرتمند هستند، او اشاره می‌کند که لزوماً آن‌ها را به کسی که تازه وارد دنیای توسعه بازی شده پیشنهاد نمی‌دهد. این انتخاب یک استراتژی عمدی بود تا اصطکاک بین توسعه‌دهنده و درک سطح پایین از آنچه در حال ساخت بود، به حداکثر برسد. او به شوخی به هم‌هم‌سراهای Rust-کار خود می‌گوید که تنها عیب بزرگ شروع با Rust این است که اگر از ابتدا از آن استفاده کنید، دیگر لذت بازنویسی پروژه با Rust در مراحل بعدی را نخواهید داشت.

مأموریت اصلی، خلق یک MMO بود که در آن شخصیت‌های غیرقابل‌بازی (NPC) دقیقاً مانند بازیکنان مدل‌سازی شوند. تنها تفاوت این است که NPCها به جای انسان‌ها، توسط LLMها کنترل می‌شوند. این مدل برای تمام موجودات هوشمند بازی اعمال شد: از بازرگانان و نگهبانان گرفته تا سیاستمداران و انواع هیولاها و حیوانات.

در اجرای اولیه، او از یک رویکرد ساده‌انگارانه (Naive Implementation) استفاده می‌کرد:
اول، یک snapshot از جهان قابل مشاهده در محدوده بازیکن را به LLM ارسال می‌کرد.
دوم، لیستی از ابزارهای قابل اجرا (Actionable Tools) را ضمیمه می‌کرد.
سوم، منتظر می‌ماند تا LLM با یک اکشن پاسخ دهد.
اگرچه این روش در تئوری کار می‌کند، اما در بازی با مکانیک‌های بلادرنگ (Real-time) مانند مبارزات، مقیاس‌پذیر نیست. دلیل اصلی، تأخیر یا همان لتنسی (Latency) بسیار بالا بود که تجربه بازی را تخریب می‌کرد.

برای حل این مشکل، او ابتدا گزینه‌ی تنظیم دقیق (Fine-tuning) یک مدل کوچک روی داده‌های بازی (Gameplay Traces) را بررسی کرد. اما این ایده به دو دلیل رد شد: اول اینکه احساس می‌کرد دور از دسترس و بسیار گران است و دوم اینکه مکانیک‌های بازی هنوز قطعی نشده بودند و یک مدل ثابت، سیستم را بیش از حد صلب و غیرمنعطف می‌کرد. او به این نتیجه رسید که هر چقدر هم استنتاج (Inference) بهینه شود، هرگز حس یک تجربه بلادرنگ واقعی را نخواهد داد. بنابراین، یک رویکرد متفاوت نیاز بود.

راهکار نهایی، یک معماری ترکیبی (Hybrid AI Architecture) بود. سیستم ابتدا با یک «درخت رفتار» (Behavior Tree) پیش‌فرض بر اساس نوع موجود شروع می‌کند تا اجرای آنی و قطعی (Deterministic) تضمین شود. سپس مدل زبانی (LLM) برای بازسازی و به‌روزرسانی آن درخت رفتار، هم‌زمان با «تجربیات» NPC در دنیای بازی، به کار گرفته می‌شود.

این مدل، بهترین ویژگی‌های هر دو جهان را ترکیب می‌کند: اجرای آنی رفتارهای قطعی و سازگاری موقعیتی LLMهای کند و غیرقطعی. به لطف معماری مبتنی بر Push در SpacetimeDB، پل ارتباطی همیشه یک وضعیت تازه از بازی برای هر فراخوانی LLM در اختیار دارد. این وضعیت شامل جهان قابل مشاهده و اقدامات موجود است؛ همه چیز زمینه‌مند (Contextualized) شده و اکشن‌ها از نظر معنایی به وضعیت متصل هستند.

این موفقیت منجر به یک درک کلیدی شد: استانداردهای فعلی مانند پروتکل زمینه مدل (Model Context Protocol یا MCP) و پارادایم‌های «استفاده از کامپیوتر» (Computer Use) شکست می‌خورند چون یا لیست‌های تختی از ابزارها را ارائه می‌دهند یا از رابط‌های بصری استفاده می‌کنند که برای انسان‌ها طراحی شده است. توسعه‌دهنده این سوال را مطرح کرد که چرا عامل‌ها از برون‌فکنی‌های وضعیت مبتنی بر Push با اکشن‌های زمینه‌مند استفاده نمی‌کنند و یک رابط واقعاً «عامل-محور» (Agent-first) باید چگونه باشد؟

تحت تأثیر یک موج ناگهانی از وسواس فکری (OCD)، او احساس کرد باید درستی این شهود را امتحان کند. این منجر به طراحی پروتکلی شد که نحوه تعامل عامل‌ها با اپلیکیشن‌ها را استاندارد کند. مبانی این پروتکل بر چهار تغییر ساختاری استوار است:

۱. برون‌فکنی‌های درخت وضعیت (State Tree Projections): به جای ارسال داده‌های خام یا لیست‌های تخت، اپلیکیشن یک برون‌فکنی متنی ساختاریافته از داده‌های خود ایجاد می‌کند. این دقیقاً مشابه کاری است که رابط‌های گرافیکی (UI) برای انسان‌ها انجام می‌دهند، با این تفاوت که جلوه‌های بصری جای خود را به متن ساختاریافته برای LLM می‌دهند. برای مثال، ساختاری مانند این:

• [root] My Todos
• [collection] Todos (count=2)
• [todo] Write the SLOP article | completed: false
• [todo] Publish the article | completed: false

۲. آیینه‌سازی وضعیت برنامه (Application State Mirroring): فراخوانی ابزارها می‌تواند کند، گران و مسدودکننده (Blocking) باشد، به‌خصوص اگر نتوان آن‌ها را دسته‌ای (Batch) کرد. خواندن وضعیت فعلی برنامه نمونه‌ای بارز از این مشکل است؛ شما نمی‌توانید کاری را شروع کنید بدون اینکه محیط فعلی را بشناسید. با ارسال یک برون‌فکنی از وضعیت فعلی هم‌زمان با درخواست کاربر، عامل می‌تواند مرحله «خواندن وضعیت» را حذف کند. این تضمین می‌کند که تعاملات کاربر بلافاصله در نوبت بعدی عامل در دسترس باشد.

۳. متن‌بنیاد کردن معنایی (Semantic Contextualization): اکشن‌ها به‌صورت زمینه‌مند روی داده‌های خاصی که از آن‌ها استفاده می‌کنند تعریف می‌شوند. این کار نیاز مدل به نگاشت منطقی یک لیست تخت از ابزارها بر اساس نام و رابط را از بین می‌برد. به عنوان مثال در نگاشت معنایی:

• [root] My Todos $\rightarrow$ actions: add_todo(title: string)
• [todo] Write the SLOP article | completed: true $\rightarrow$ actions: mark_incomplete, delete
• [todo] Publish the article | completed: false $\rightarrow$ actions: complete, delete

۴. بارگذاری پویا (Dynamic Loading): اکشن‌ها بر اساس وضعیت برنامه به‌صورت پویا در زمینه (Context) عامل بارگذاری می‌شوند. اگر یک اکشن در وضعیت فعلی قابل اجرا نباشد، تأمین‌کننده می‌تواند تصمیم بگیرد که یا اصلاً آن اکشن را بارگذاری نکند یا اطلاعات اضافی ارائه دهد تا عامل بداند چگونه پیش برود تا آن اکشن در دسترس شود.

در این معماری، تفکیکی کامل بین منطق اپلیکیشن و مدیریت snapshotهای LLM از طریق یک تقسیم‌بندی مشخص وجود دارد:

• تأمین‌کننده (Provider): این موجودیت منطق اپلیکیشن را مدیریت کرده و وضعیت محدودشده برنامه را به مصرف‌کننده ارائه می‌دهد.
• مصرف‌کننده (Consumer): این موجودیت به‌روزرسانی‌های snapshot را مدیریت کرده و تعیین می‌کند که وضعیت چگونه برای LLM نمایش داده شود.
  تنها چیزی که این دو موجودیت باید بر سر آن توافق کنند، روش ارتباطی است: یعنی خودِ پروتکل.

پس از اعتبارسنجی این ایده مرکزی، توسعه‌دهنده زمان زیادی را صرف مشخص کردن جزئیات دقیق‌تر، SDKها، نمونه‌ها و بنچمارک‌ها کرد. با وجود ترس از اینکه پروژه در «دریای SLOP» عصر هوش مصنوعی رها شود و کسی از آن استفاده نکند، او خواست تا پروژه را به سرانجام برساند و به‌صورت عمومی منتشر کند.

متأسفانه، این به معنای آن بود که بازی اصلی دچار بیماری «پروژه جانبی» شد؛ یعنی در حال حاضر در قبرستان گیت‌هاب پروژه‌های نیمه‌تمام می‌پوسد. با این حال، از آنجایی که نسخه اول پروتکل اکنون منتشر، پایدار و توسط یک Runtime اختصاصی برای عامل‌ها تأیید شده است، نویسنده احتمالاً برای قابل‌بازی کردن دوباره‌ی بازی بازخواهد گشت.

خالق پروژه در نهایت نتیجه می‌گیرد که اگرچه کدنویسی دستی هنوز جایگاه خود را دارد، اما این کار بیشتر در حال تبدیل شدن به یک «هنر» است تا یک «نیاز عملکردی». در این عصر جدید، پیاده‌سازی واقعی (Implementation) اهمیت چندانی ندارد؛ بلکه شهود (Intuition) و زیرساخت‌های استوار همچنان پادشاهی می‌کنند. همان‌طور که او پیشنهاد می‌دهد: زمان آن رسیده که «اقیانوس را بجوشانیم» (Boil the ocean)، زیرا بالاخره ابزارهای لازم برای انجام این کار عظیم را در اختیار داریم.

گام بعدی شما

• اگر از MCP برای اتصال عامل‌های خود به ابزارها استفاده می‌کنید، بررسی کنید که آیا ارسال وضعیت (State) به جای فراخوانی ابزار (Tool Call) سرعت استنتاج شما را بالا می‌برد یا خیر.
• معماری‌های ترکیبی (Behavior Tree + LLM) را برای کاهش هزینه و تأخیر در سیستم‌های بلادرنگ آزمایش کنید.
• مستندات نسخه‌ی اولیه این پروتکل را برای پیاده‌سازی برون‌فکنی‌های متنی در اپلیکیشن‌های خود بررسی نمایید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.