Neon Functions اکنون از اتصالات استریم با مدت‌زمان نامحدود پشتیبانی می‌کند و به عامل‌های هوش مصنوعی (AI agents) اجازه می‌دهد تا یک کانال زنده را برای ثانیه‌ها، دقیقه‌ها یا حتی طولانی‌تر باز نگه دارند، بدون اینکه با محدودیت‌های زمانی (timeout) که باعث قطع شدن اکثر بارهای کاری serverless می‌شود، مواجه شوند. این تغییر برای هر کسی که در حال ساخت دستیارهای سبک چت یا ربات‌های ابزار-محور است، بسیار حیاتی است؛ زیرا یک استریم قطع‌شده باعث متوقف شدن گفتگو و خراب شدن تجربه کاربری می‌شود.

چرا سرویس‌های serverless و عامل‌های هوش مصنوعی با هم در تضاد بوده‌اند

اکثر پلتفرم‌های serverless برای وظایف سریع و «اجرا و فراموش» (fire-and-forget) ساخته شده‌اند. آن‌ها برای پیش‌بینی‌پذیر نگه داشتن منابع، محدودیت‌های زمانی سخت‌گیرانه‌ای را اعمال می‌کنند—اغلب ۱۰ ثانیه در سطوح رایگان و ۶۰ ثانیه در طرح‌های پولی. اما یک عامل هوش مصنوعی، زمان خود را صرف تفکر، فراخوانی ابزارهای خارجی و تولید توکن‌ها در حین تولید می‌کند. آن مرحله «تفکر» اغلب به ده‌ها ثانیه کشیده می‌شود و جریان توکن‌ها می‌تواند تا زمانی که مدل در حال تولید خروجی است، ادامه یابد. وقتی تایمر پلتفرم تمام می‌شود، اتصال را می‌بندد و کلاینت با یک استریم قطع‌شده مواجه می‌شود.

پاسخ Neon: استریم طولانی‌مدت به‌صورت پیش‌فرض

Neon Functions بازی را عوض می‌کند. یک فراخوانی تابع می‌تواند تا بی‌نهایت باز بماند و داده‌ها را از طریق WebSockets یا Server-Sent Events (SSE) بدون هیچ پیکربندی خاصی تحویل دهد. این پلتفرم با یک استریم طولانی مانند یک درخواست معمولی برخورد می‌کند، بنابراین توسعه‌دهندگان منطق تولید استریم را می‌نویسند و اجازه می‌دهند Neon بقیه کارها را انجام دهد.

در یک آزمایش اخیر، دو endpoint این رفتار را نشان دادند:

  • Heartbeat endpoint – تابع هر ثانیه یک بار به مدت ۹۰ ثانیه یک «تیک» (tick) ارسال کرد. سطوح معمولی serverless درخواست را پس از ۱۰ یا ۶۰ ثانیه قطع می‌کردند؛ اما Neon اتصال را تا زمانی که تابع به خودی خود تمام شود، باز نگه داشت.
  • Token-relay endpoint – تابع توکن‌ها را از یک مدل هوش مصنوعی به محض تولید هر توکن، برای کلاینت استریم کرد. کاربران شاهد ظاهر شدن پاسخ کلمه به کلمه بودند، به جای اینکه منتظر کل بلوک متن بمانند.

هر دو مثال تنها به یک درخواست از سوی کلاینت نیاز داشتند؛ هیچ نیازی به تکنیک‌های polling یا keep-alive نبود.

چه کسانی سود می‌برند و چه کسانی باید محتاط باشند

تیم‌هایی که در حال ساخت دستیارهای گفتگو‌محور، عامل‌های ابزار-محور یا هر سرویسی هستند که نیاز به ارسال نتایج تدریجی دارد، یک برد فوری به دست می‌آورند: محدودیت زمانی (timeout) از بین می‌رود. نتیجه آن کد ساده‌تر، تأخیر (latency) کمتر و تجربه کاربری روان‌تر است.

ملاحظات زیر قابل توجه هستند:

  • مدل مبتنی بر درخواست (Request-only model) – Neon Functions استریم‌هایی را مدیریت می‌کند که به یک درخواست فعال متصل هستند. وظایف پس‌زمینه (Background jobs) که باید طولانی‌تر از درخواست باقی بمانند، همچنان به یک زمان‌بند مجزا مانند Inngest یا موتور گردش کار (workflow engine) مشابه نیاز دارند.
  • شروع‌های سرد (Cold starts) – توابعی که بیکار هستند می‌توانند تا سطح صفر مقیاس‌بندی شوند (scale to zero)، بنابراین درخواست بعدی ممکن است با تأخیر شروع سرد مواجه شود. یک استریم فعال از مقیاس‌بندی به پایین (scaling down) جلوگیری می‌کند، اما اولین درخواست پس از دوره عدم فعالیت، همچنان هزینه شروع کار را پرداخت می‌کند.

آنچه باید در آینده زیر نظر داشت

خلاصه کلام: Neon Functions سقف محدودیت زمانی را که مدت‌ها توسعه‌دهندگان هوش مصنوعی را مجبور به استفاده از راهکارهای جایگزین (workarounds) می‌کرد، از میان برمی‌دارد. با اجازه دادن به یک درخواست برای باز ماندن تا زمانی که عامل نیاز به فکر کردن و صحبت کردن دارد، Neon استقرار عامل‌های هوش مصنوعی استریمینگ را به سادگی هر تابع serverless دیگری می‌کند.