تصور کنید جهانی را در نظر بگیرید که در آن یک کاربر واحد میتواند با «صحبت کردن با کد»، ویژگیهای سفارشی بسازد که فقط به نیازهای او پاسخ میدهد و دیگر نیازی نیست منتظر بماند تا تیم محصول یک شرکت بزرگ، نیازهای خاص و حاشیهای او را در اولویتهای توسعه قرار دهد. این تغییر رویکرد به سمت نرمافزار برای یک نفر (Software for One)، نشاندهنده گذاری از اپلیکیشنهای وب ایستا به پلتفرمهای گسترشپذیر است؛ جایی که «دم بلند» (Long Tail) نیازهای کاربران در نهایت توسط کدنویسی به کمک مدلهای زبانی بزرگ (LLM) برطرف میشود.
بیشتر نرمافزارهای وب مدرن برای «کاربر متوسط» ساخته شدهاند. این امر باعث ایجاد شکاف بزرگی از نیازهای برآوردهنشده شده است، زیرا افزودن هر ویژگی ممکن، رابط کاربری را برای همه شلوغ و غیرقابلاستفاده میکند. توسعهدهندگان معمولاً روی نوک منحنی تقاضا تمرکز میکنند. با این حال، هر ویژگی اضافی که اضافه شود، محصول را برای تمام کاربران دیگر پیچیدهتر میکند. اگر بازار یک ویژگی کوچک باشد، افزودن آن میتواند فعالانه محصول را برای کسانی که به آن نیاز ندارند، بدتر کند. با تکیه بر پوشش قبلی ما درباره اینکه ابزارهایی مانند OmnisBench چگونه کارایی مسیریابی LLM را آشکار میکنند، مرز بعدی تنها این نیست که مدلها چگونه وظایف را مسیریابی میکنند، بلکه این است که چگونه به کاربران اجازه میدهند نرمافزاری را که با آن تعامل دارند، در لحظه بازنویسی کنند. در این مسیر، نقش تخصص کاربر در هدایت مدلها برای تولید کدهای دقیقتر هرچه پررنگتر میشود، موضوعی که در تحلیل ما درباره متغیرهای کیفیت خروجی مدلهای زبانی به تفصیل بررسی شده است.
به نقل از تحلیل مفصلی که در ۱۹ اوت ۲۰۲۶ توسط جرمی مورل منتشر شد، ظهور مدلهای زبانی بزرگ بهطور رادیکالی هزینه نویسندگی افزونهها را کاهش میدهد. وقتی این مدلها با ابزارهای مدرن ایزولاسیون (Sandbox Primitives) ترکیب شوند، به توسعهدهندگان اجازه میدهند یک هسته پایدار و پاسخگو بسازند و در عین حال به کاربران اجازه دهند قطعات گمشده را بهصورت امن پر کنند. مورل که در Cloudflare فعالیت میکند، اشاره میکند که این ماهیت «نرم و انعطافپذیر» (Squishy) نرمافزار، هر کسی را که نیازهایش در دم بلند تقاضاهای برآوردهنشده قرار داشت، توانمند میکند. او بخش زیادی از تفکرات خود را مدیون نوشتههای کنتون واردا میداند.
چشماندازی برای اپلیکیشنهای وب گسترشپذیر
یک اپلیکیشن «بعداً بخوان» را تصور کنید که فقط لینکها را ذخیره نمیکند، بلکه به او میگویید: «هر مقالهای که بیش از ۴۰۰۰ کلمه است را به کتابخوان الکترونیکی من بفرست». در این حالت، بهجای انتظار برای اینکه یک توسعهدهنده این ویژگی را بسازد، یک LLM کد لازم را استخراج کرده و آن را به یک نقطه اتصال (Extension Point) متصل میکند.
سایر مثالهای این رویکرد افزونههای بومی LLM عبارتند از:
- اتوماسیون پژوهشی: «هر هفته به دنبال مقالات جدید منتشر شده در arxiv در [تخصص من] بگرد، خلاصهای از نحوه ارتباط آن با کار من را در ابتدا اضافه کن و آن را با [برچسب] علامتگذاری کن».
- تجزیه دادههای سفارشی: ایجاد یک تجزیهکننده (Parser) سفارشی برای سایتی خاص که در آن الگوریتم پیشفرض، محتوا را بههمریخته نمایش میدهد.
- منطق رویداد-محور: «وقتی این برچسب را به یک رکورد میزنم، تابع من را اجرا کن» یا اجرای عملیاتها بر اساس یک زمانبندی روزانه (Cron).
این الگو در حال حاضر در نرمافزارهای «بومی LLM» مانند Pi ظاهر شده است که قلابهای (Hooks) پایداری برای ابزارها، دستورات، رویدادها و رابط کاربری (UI) فراهم میکند. Pi میتواند یک درخواست را به یک افزونه کوچک TypeScript تبدیل کرده و آن را در جای خود بارگذاری مجدد کند. این افزونهها میتوانند در بستههایی جمعآوری شده و به اشتراک گذاشته شوند، که به اکوسیستم اجازه میدهد دم بلند ایدهها را بدون حجیم کردن بدنه اصلی برنامه جذب کند. در حالی که بیشتر نرمافزارهای پلاگینمحور محلی بودهاند — مانند عاملهای هوش مصنوعی، IDEهای توسعهدهندگان، افزونههای Blender و گسترشهای CAD — اما وب موفقترین سیستم توزیع در جهان است و نباید از این تحول عقب بماند.
حوزههای با تأثیر بالا
مورل چندین حوزه را شناسایی میکند که در آنها این گسترشپذیری حیاتی است:
- عاملهای هوش مصنوعی (AI Agents): انتقال از اجرای محلی به شخصیسازی امن و متناسب با دامنه برای متخصصانی مانند پزشکان، حسابداران و وکلا. در حال حاضر، بسیاری از عاملها نیاز دارند که کاربران در اجرای نرمافزارهای سفارشی روی ماشینهای محلی راحت باشند. در محیطهای شرکتی، سازمانها در اجرای نرمافزاری که هیچکس آن را بررسی نکرده است، تردید دارند. افزونهها اگر ایزوله (Sandboxed) نشوند، اغلب با همان مجوزهای خودِ عامل اجرا میشوند. هدف این است که نرمافزار با نیازهای متخصص سازگار شود، نه اینکه متخصص مجبور شود به یک توسعهدهنده نرمافزار تبدیل شود.
- پلتفرمهای داخلی شرکتی: اجازه دادن به کارکنان برای «وایبکدینگ» (Vibe-coding) نماهای داده و اتوماسیونهای خودشان. شرکتها مقادیر عظیمی از دادهها دارند که کارکنان نیاز دارند آنها را استعلام کنند، مرتبط سازند یا برای یافتن مشتریانی که در شرف ترک شرکت (Churn) هستند، استفاده کنند. در حالی که برخی از PaaS برای این کار استفاده میکنند، این امر کابوسهای نگهداری و امنیتی ایجاد میکند. یک پلتفرم مناسب تضمین میکند که دسترسی به دادهها توسط یک تیم داخلی مدیریت شود تا از نشت توکنهای احراز هویت جلوگیری شده و انطباق با GDPR تضمین گردد. این مدل اساساً همان چیزی است که با Cloudflare OS در حال ساخت است.
- پلتفرمهای پشتیبانی: توانمندسازی مهندسان پشتیبانی برای ایجاد دکمهها یا سطوح داده سفارشی. برای مثال، یک مهندس میتواند افزونهای بسازد که دادههای خاص سیستم را برای کاربری که تیکت باز کرده است، مستقیماً در رابط پشتیبانی نمایش دهد، یا عاملهایی را برای انجام اولین دور بررسی قبل از رسیدگی انسان فعال کند. کارهای رایج، مانند «بازنشانی سهمیه خاص X»، میتواند به یک دکمه ساده تبدیل شود که در کل تیم پشتیبانی به اشتراک گذاشته شود.
- پلتفرمهای مشاهدهپذیری (Observability): جایگزینی نمودارهای آبشاری (Waterfall) ایستا با بصریسازیهای سفارشی. در حالی که نمودارهای آبشاری برای سیستمهای درخواست/پاسخ کار میکنند، اپلیکیشنهای مدرن از عاملهای غیرقطعی یا موتورهای گردش کار بادوام استفاده میکنند که در آنها یک اقدام واحد ممکن است ساعتها یا روزها طول بکشد. گسترشپذیری به کاربران اجازه میدهد:
- تبدیلهای دلخواه را برای دادهها در هنگام ورود (Ingestion) تزریق کنند.
- اسکریپتها یا عاملهای سفارشی را از طریق هشدارها (Alarms) فعال کنند.
- کدهای خاصی را در طول رویدادهای پرریسک مانند استقرار (Deploy) یا فعالسازی Feature Flag اجرا کنند.
- یک
MyResourceIDخاص در لاگها را به یک لینک مستقیم به پلتفرمی دیگر تبدیل کنند.
چالش امنیت
اجرای کدهای دلخواه کاربر در وب بهطور تاریخی خطرناک بوده است. ریسکها شامل حلقههای بینهایت است که باعث کرش سرویسها میشوند، استخراج دادهها از طریق کلیدهای API و حملات اجرای گمانهزنانه مانند Spectre. تهدیدات دیگر شامل استفاده کاربران از محاسبات رایگان برای استخراج ارز دیجیتال یا راهاندازی حملات منع سرویس (DoS) علیه میزبان یا شخص ثالث است.
در حالی که ابزارهایی مانند Obsidian گسترشپذیری عظیمی را فراهم میکنند — و به کاربران اجازه میدهند وظایف را در تابلوهای کانبان ردیابی کنند یا از پایگاههای داده برداری برای جستجوی معنایی استفاده کنند — اما آنها بر یک مدل مبتنی بر اعتماد تکیه دارند. Obsidian از بررسیهای دستی و خودکار برای تأیید نویسندگان استفاده میکند، اما این مدل برای نرمافزارهای سازمانی که تراکنشهای مالی یا پیامهای خصوصی را نگه میدارند، از هم میپاشد.
برای حل این مشکل، مورل به Salesforce اشاره میکند که از سال ۲۰۰۷ (اندکی پس از عرضه AWS S3 و EC2 در سال ۲۰۰۶) با موفقیت یک پلتفرم برنامهپذیر چندمستاجری را اجرا کرده است. Salesforce کاربران را مجبور به استفاده از یک زبان سفارشی شبیه به جاوا به نام Apex کرد و کامپایلر، محیط اجرا (Runtime) و دیباگر خود را ساخت. این کار به آنها اجازه داد تا بهطور امن منطق سفارشی را در پاسخ به رویدادهای برنامه در قالب تراکنشها اجرا کنند و ثابت کردند که پلتفرمهای برنامهپذیر میتوانند در مقیاس عظیم کار کنند. آنها یک اکوسیستم آموزشی کامل ساختند تا هزینه استخدام متخصصان برای پلتفرمشان را توجیه کنند.
الزامات فنی برای زیرساخت جدید
برای ساخت یک پلتفرم گسترشپذیر مدرن، محیط اجرای زیربنایی باید ۵ معیار سختگیرانه را برآورده کند:
۱. هزینه اقتصادی: هزینه در حالت بیکار باید تقریباً صفر باشد و هزینه هر اجرا کسری از یک سنت باشد. راهاندازی یک کانتینر سفارشی برای هر کاربر اصلاً پذیرفتنی نیست. سربار حافظه حیاتی است؛ در سال ۲۰۲۶، قیمتهای RAM تعیین میکند که چه تعداد کاربر را میتوان در یک ماشین جای داد. برای بهینهسازی این هزینهها، برخی مدلهای جدید پرداخت را تغییر دادهاند، مشابه آنچه در مدل پرداخت هر درخواست Oxlo.ai برای کاهش هزینههای خط لوله محتوا مشاهده میکنیم.
۲. راهاندازی سرد سریع (Fast Cold Starts): زمان شروع باید در حد تکرقمی میلیثانیه باشد تا از ایجاد لگ در تجربه کاربر جلوگیری شود، بهویژه زمانی که کد در مسیر بحرانی یک درخواست قرار دارد. اگر افزونه فقط به رویدادها یا زمانبندیها پاسخ میدهد، زمانهای شروع بالاتر ممکن است قابل قبول باشد.
۳. محدودیتهای سخت: سیستم باید سقفهای سختگیرانهای برای CPU، حافظه، اندازه درخواستهای شبکه، اندازه پاسخ و حجم لاگها اعمال کند. این کار از سناریوهایی مانند حلقه بینهایت «hello world» جلوگیری میکند — یک مثال واقعی در Heroku که در آن یک راهنمای محبوب باعث شد کاربران اپلیکیشنی با دستور while True: print("hello world!") مستقر کنند که میلیونها لاگ در ثانیه تولید میکرد.
۴. ایزولاسیون محکم: خطاهای کد یک کاربر هرگز نباید بر مستاجر (Tenant) دیگر تأثیر بگذارد. این شامل محافظت در برابر حملات اجرای گمانهزنانه و اطمینان از اینکه کد مخرب نمیتواند از محیط خود خارج شود یا مستاجران دیگر را بازرسی کند.
۵. قابلیتهای کنترلشده: بهجای دادن دسترسی خام شبکه به کد (که اجازه نشت دادهها را میدهد)، میزبان باید «قابلیتها» (Capabilities) — یعنی مراجع توابع خاص و پیشتأیید شده — را ارائه دهد.
مورل استدلال میکند که استفاده از یک پروکسی برای فیلتر کردن درخواستهای خام fetch بیش از حد پیچیده و شکننده است. یک پروکسی به منطق فیلترینگ پیچیدهای نیاز دارد تا تضمین کند کاربر فقط به یک ایمیل خاص دسترسی دارد و نه کل صندوق ورودی. راه بهتر، مدل «قابلیت شیء» (Object Capability) است. بهجای یک کلاینت کامل ایمیل، به کد یک تابع محدود مانند email.send_me_email() داده میشود. تولید این مدل برای LLMها بسیار بهینهتر از تولید تعاریف پیچیده JSON در OpenAPI است.
پشته فناوری (Tech Stack)
چندین فناوری میتوانند این ایزولاسیون را فراهم کنند، هرچند توازنهای (Trade-offs) متفاوتی دارند:
- V8 Isolates: مورد استفاده در Cloudflare Workers، اینها ایزولاسیون با عملکرد بالا و کمترین سربار را فراهم میکنند. سایر پیادهسازیها شامل
isolated-vmبرای Node وsecure-execتوسط Rivet است. Celld نیز بخشهایی از Dynamic Workers را پیاده کرده است. - MicroVMs: ابزارهایی مانند Firecracker، libkrun، AWS Lambda، smolvm یا Daytona سازگاری قویتری با POSIX و توانایی اجرای فایلهای باینری را ارائه میدهند، اما سربار آنها بیشتر از Isolates است. آنها اغلب برای مرحله نویسندگی و تست افزونهها مفید هستند.
- WASM + WASI: وباسمبلی یک صفحه سفید برای امنیت فراهم میکند. WASI یک رابط استاندارد برای قابلیتها تعریف میکند و به کاربران اجازه میدهد به هر زبانی که به WASM کامپایل میشود بنویسند، هرچند زنجیره ابزار (Toolchain) آن پیچیدهتر است.
- مفسرها: استفاده از مفسرهای قابل جاسازی مانند Lua یا QuickJS مسیری مناسب برای کسانی است که رویکرد زبان سفارشی را میپسندند.
مورل Dynamic Workers کلودفلر را به عنوان یک چارچوب آماده برای تولید (Production-ready) در این مدل برجسته میکند. این سیستم چندین جزء کلیدی را یکپارچه میکند که در غیر این صورت باید از صفر ساخته میشدند:
- مشاهدهپذیری: ردیابی OpenTelemetry داخلی در محیط اجرا، که توابع درجهیک برای کنترل تلهمتری فراهم میکند.
- ذخیرهساز چندمستاجری: ارائه پایگاههای داده SQLite اختصاصی به کاربران از طریق Durable Object facets یا باکتهای R2.
- اجرای بادوام (Durable Execution): گردش کارهای پویا (Dynamic Workflows) که اجازه میدهد اقدامات در بازه زمانی چند دقیقه یا چند روز با تلاش مجدد (Retry) و عقبنشینی (Backoff) خودکار انجام شوند.
- ابزارهای یکپارچه: کنترل نسخه داخلی و LLMهای میزبانی شده از طریق Workers AI، که به افزونهها اجازه میدهد وظایف هوش مصنوعی (مثلاً تحلیل اینکه آیا مقالهای درباره «بچه گربههای بامزه» است یا خیر) را در بودجههای توکن مدیریتشده اجرا کنند. در اینجا نکته کلیدی این است که بسیاری از این وظایف نیازی به مدلهای عظیم ندارند؛ همانطور که در بحث جایگزینی مدلهای 7B با مسائل طبقهبندی ساده اشاره شد، بهینهسازی مدل بر اساس نوع وظیفه میتواند هزینهها را به شدت کاهش دهد.
- ابزارهای JS: توانایی اجرای ابزارهای جاوااسکریپت (مانند Sucrase برای ترنسپایل) مستقیماً در محیط بدون نیاز به VMهای مجزا.
این تغییر به این معناست که نقش توسعهدهنده نرمافزار در حال تغییر است. آنها بهجای ساخت هر ویژگی، اکنون در حال ساخت «هارنس» (Harness) هستند — محیطی امن و با عملکرد بالا که کاربران میتوانند بهطور ایمن ابزارهای خود را در آن بسازند. همانطور که مورل نتیجه میگیرد، اگرچه طراحی و دیباگ پلتفرمها سخت است، اما این کار اجازه میدهد تا زمانی که کاربران چیزهایی میسازند که توسعهدهندگان اصلی هرگز تصور نمیکردند ممکن باشد، غافلگیریهای واقعی رخ دهد.
گام بعدی شما
- اگر توسعهدهنده هستید، مدل Object Capability را برای محدود کردن دسترسیهای API بررسی کنید.
- محیطهای V8 Isolates را برای کاهش هزینه استنتاج و اجرای کدهای کاربر مطالعه کنید.
- در طراحی محصول، بهجای افزودن ویژگیهای حاشیهای، روی ایجاد «نقاط اتصال» (Extension Points) برای کاربران متمرکز شوید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو