«ماشین‌های لینوکس اختصاصی»؛ راهکار Trigger.dev برای حفظ حافظهٔ عامل‌ها

تصور کنید یک برنامه‌نویس است که می‌خواهد عاملی بسازد که ساعت‌ها روی یک تحلیل داده‌ای سنگین فکر کند، اما هر بار بعد از ۳۰ ثانیه با خطای Timeout مواجه می‌شود. این بن‌بست فنی اکنون با رویکردی رادیکال در زیرساخت‌های محاسباتی شکسته شد.

شرکت Trigger.dev در ۱۰ اوت ۲۰۲۶ قابلیتی به نام chat.agent را معرفی کرد که هر گفتگوی هوش مصنوعی را به یک ماشین لینوکس اختصاصی متصل می‌کند. این یعنی انتقال از چرخه‌های «درخواست-پاسخ» (Request-Response) که حافظه‌ای ندارند، به محاسبات پایدار و دارای وضعیت (Stateful).

بیشتر توسعه‌دهندگان فعلاً بک‌اندهای چت را با مسیرهای استاندارد API می‌سازند. این مسیرها بدون وضعیت (Stateless) هستند؛ یعنی مثل پیشخدمتی که هر بار شما را می‌بیند فراموش می‌کند چه سفارش داده‌اید و باید همه چیز را از اول توضیح دهید. اگر مدل زبانی بیش از حد به فکر برود یا ابزاری دیر اجرا شود، اتصال قطع می‌شود. برای حل این مشکل، مهندسان معمولاً مجبورند وضعیت را به‌صورت دستی در Redis یا یک دیتابیس مدیریت کنند و برای کارهای کند، ورکر‌های پس‌زمینه (Background Workers) را هماهنگ کنند. این موضوع باعث ایجاد یک جدال دائمی می‌شود؛ به‌خصوص زمانی که مدل بیش از زمانی که تابع اجازه اجرا دارد به پاسخ نیاز دارد، یا زمانی که توسعه‌دهنده بخواهد یک عامل فرعی (Sub-agent) ایجاد کند که تفکر مستقل خود را داشته باشد. این رویکرد در تضاد با مدل‌های سنتی است و شباهت زیادی به معماری متمرکز بر تکلیف xAgent دارد که رابط‌های چت را به محیط‌های عملیاتی تبدیل کرد.

Trigger.dev این مشکل را با اختصاص یک ماشین واقعی لینوکس به هر نشست حل کرده است. این ماشین با اولین پیام بیدار شده و وقتی کاربر تایپ نمی‌کند، به خواب می‌رود. چون ماشین پایدار است، متغیرها، حافظه پنهان (Cache) و عامل‌های فرعی در حافظه باقی می‌مانند. این یعنی شما مجبور نیستید هر بار که کاربر پیامی می‌فرستد، داده‌های گران‌قیمت را دوباره فراخوانی کنید. ماشین دقیقاً از همان جایی که متوقف شده بود، بیدار می‌شود بدون اینکه توسعه‌دهنده نیاز به مدیریت دستی وضعیت داشته باشد.

زمینه و پیاده‌سازی

ساخت یک عامل چت شامل نوشتن هر نوبت گفتگو به عنوان یک تسک Trigger.dev است که پیام‌ها را می‌گیرد و یک جریان (Stream) را برمی‌گرداند. توسعه‌دهندگان سپس useChat مربوط به AI SDK را مستقیماً به آن متصل می‌کنند و نیاز به یک مسیر API در این میان کاملاً حذف می‌شود.

برای مثال، یک پیاده‌سازی پایه از کتابخانه‌های @trigger.dev/sdk/ai و @ai-sdk/anthropic استفاده می‌کند. عامل با یک شناسه (ID) منحصر‌به‌فرد و یک تابع اجرا تعریف می‌شود که از streamText بهره می‌برد. برای جلوگیری از حلقه‌های بی‌نهایت یا هزینه‌های نجومی، توسعه‌دهندگان می‌توانند از دستور stopWhen: stepCountIs(15) استفاده کنند تا تعداد گام‌های هر نوبت را محدود نمایند.

این معماری در مقیاس واقعی آزمایش شده است. شرکت Arena حالت «Agent Mode» خود را بر پایه chat.agent ساخته و آن را در محیط عملیاتی اجرا می‌کند. گراهام ترمپر از Arena می‌گوید: «اختصاص یک ماشین واقعی به هر گفتگو، ساخت عامل‌های پایدار را برای ما بسیار ساده‌تر کرد. ردیابی (Tracing) و قابلیت مشاهده (Observability) پیش‌فرض، مشاهده و عیب‌یابی نشست‌های عامل‌محور را به شدت آسان کرده است.»

قابلیت chat.agent از ۲ ژوئیه در دسترس عموم قرار گرفته و از ژوئن در محیط عملیاتی فعال بوده است. طبق گزارش Trigger.dev، این سیستم تاکنون میلیون‌ها نشست و بیش از ۸۴ سال زمان محاسباتی را مدیریت کرده است.

محاسبات پایدار و حافظه

تغییر بنیادین این است که هر نوبت گفتگو دیگر «زمان محدود» یا Timeout ندارد. چه عامل در حال اجرای زنجیره‌ای طولانی از ابزارها باشد و چه یک عامل فرعی در حال استدلال عمیق، فرآیند تا پایان کار ادامه می‌یابد. دیگر نیازی نیست کارهای سنگین را به تکه‌های کوچک تقسیم کنید تا با محدودیت‌ها سازگار شوند و نیازی به صف‌های جداگانه برای بخش‌های کند نیست. در محیط عملیاتی، Trigger.dev گزارش می‌دهد که یک مورد از هر بیست اجرای عامل، بیش از ۳۶ دقیقه طول می‌کشد؛ زمانی که تقریباً هر API استاندارد را کرش می‌دهد.

حافظه در طول این چرخه‌های خواب و بیداری باقی می‌ماند. اگر مقداری را در نوبت سوم در یک متغیر ذخیره کنید، در نوبت بیستم و در روز بعد همچنان در دسترس است. برای مثال، یک Map که برای بردار‌های معنایی (Embeddings) استفاده شده است، می‌تواند نتایج را در طول نوبت‌ها کش کند و تضمین کند که یک جست‌وجوی گران‌قیمت که یک بار انجام شده، برای تمام طول عمر گفتگو ذخیره بماند.

البته سیستم با حافظه (Heap) مانند یک سرور استاندارد برخورد می‌کند؛ اگر ماشین کرش کند، تاریخچه گفتگو چون روی دیسک نوشته شده بازیابی می‌شود، اما متغیرهای داخل حافظه (مانند Map مذکور) پاک می‌شوند. به همین دلیل توصیه می‌شود داده‌های حیاتی در دیتابیس و داده‌های سریع در حافظه ذخیره شوند.

جریان‌های داده (Streams) نیز پایدار هستند. یک گفتگو در واقع نشستی است که طولانی‌تر از فرآیند سرویس‌دهنده آن است. اگر کاربر در میانه پاسخ صفحه را رفرش کند، جریان از همان جایی که مرورگر خواندن را متوقف کرده بود دوباره پخش می‌شود، بدون اینکه مدل دوباره اجرا شود. اگر یک اجرا کشته شود یا حافظه تمام شود، پیام بعدی صرفاً یک ماشین جدید را بوت می‌کند و گفتگو بازیابی می‌شود. استقرار نسخه‌های جدید کد (Deploy) باعث قطع اجرای فعال‌ها نمی‌شود؛ هر اجرا روی همان نسخه‌ای می‌ماند که با آن شروع شده است، مگر اینکه توسعه‌دهنده صراحتاً chat.requestUpgrade() را برای انتقال گفتگو به کد جدید فراخوانی کند.

مزیت محیط اجرای لینوکس

برخلاف محیط‌های محدود Serverless، این سیستم یک محیط کامل لینوکس فراهم می‌کند. این یعنی عامل‌ها می‌توانند:

• نصب نرم‌افزارهای دلخواه: اجرای هر ابزار CLI که به سیستم فایل واقعی و درخت فرآیند (Process Tree) نیاز دارد.
• اجرای باینری‌های پیچیده: استفاده از node:child_process برای فراخوانی ابزارهایی مثل ffmpeg جهت تبدیل فرمت ویدیو.
• اتوماسیون وب: هدایت مرورگرهای بدون رابط گرافیکی (Headless) برای استخراج داده‌های پیچیده یا تعامل با وب‌سایت‌ها.
• ابزارهای سفارشی: تعریف ابزارهایی با استفاده از طرح‌های Zod که دستورات شل (Shell) را مستقیماً روی ماشین اجرا می‌کنند.

کاربران می‌توانند از پیش‌فرض‌های مختلف ماشین، از نمونه‌های میکرو با ۰.۲۵ vCPU شروع کنند که دارای CPU، حافظه و دیسک اختصاصی هستند. این تنظیمات را می‌توان برای هر عامل تعیین کرد یا برای گفتگوهای خاص تغییر داد.

حل شکاف تأخیر با Head Start

برای اینکه ماهیت «پایدار» ماشین باعث کند شدن تجربه کاربر نشود، قابلیت Head Start معرفی شده است. این ویژگی اولین فراخوانی مدل (LLM) را روی یک سرور گرم (Warm Server) اجرا می‌کند، در حالی که ماشین اختصاصی عامل به‌طور موازی در حال بوت شدن است.

این مکانیزم در میانه نوبت، هنگام فراخوانی ابزارها، کنترل را به ماشین اختصاصی می‌سپارد. کاربر یک پاسخ پیوسته می‌بیند و متوجه این جابه‌جایی نمی‌شود. طبق تست‌های Trigger.dev، این روش زمان رسیدن به اولین توکن و طول کل نوبت را تقریباً نصف کرده است.

قابلیت Head Start یک هندلر Web Fetch ساده برمی‌گرداند که آن را با Next.js، Hono، SvelteKit، Remix و TanStack Start بدون نیاز به آداپتور سازگار می‌کند. اگر نوبت اول فقط متن باشد و ابزاری فراخوانی نشود، ماشین بوت شده و خارج می‌شود بدون اینکه مدل فراخوانی شود و کاربر فقط هزینه آنچه واقعاً نیاز داشته را می‌پردازد. همچنین چون حافظه به‌صورت اسنپ‌شات ذخیره می‌شود و نه بازپخش (Replay)، هیچ محدودیتی برای دترمینیسم وجود ندارد؛ توسعه‌دهندگان می‌توانند از Date.now()، Math.random() یا fetch در میانه یک حلقه استفاده کنند بدون اینکه به لاگ بازپخش نیاز داشته باشند.

انتظار کم‌هزینه و نظارت

یکی از کاربردی‌ترین تغییرات، مفهوم «انتظار با هزینه صفر» است. با تعریف ابزاری بدون تابع execute (اجرا)، عامل می‌تواند اجرای خود را متوقف کرده و منتظر تایید انسان بماند.

• تعلیق: نوبت به پایان می‌رسد و عامل به حالت تعلیق می‌رود.
• حضور انسان: یک شخص می‌تواند ساعت‌ها یا روزها برای تایید یک اقدام غیرقابل بازگشت زمان بگذارد.
• هزینه صفر: چون ماشین در حالت تعلیق است، هزینه‌ای برای زمان انتظار دریافت نمی‌شود.

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

سیستم نظارت (Observability) نیز به‌طور مستقیم یکپارچه شده است. هر نوبت به عنوان یک بازه (Span) در داشبورد ثبت می‌شود تا تأخیر ابزارها و پاسخ‌ها ردیابی شود. داشبورد معیارهای هوش مصنوعی جزئیات زیر را ارائه می‌دهد:

• هزینه و توکن‌ها: مجموع هزینه‌ها، تعداد کل فراخوانی‌ها و هزینه تفکیک شده بر اساس تسک و ارائه‌دهنده.
• عملکرد: میانگین زمان تا نخستین توکن، میانگین توکن در ثانیه و صدک‌های تأخیر بر اساس مدل.
• تحلیل: دلایل پایان یافتن اجرا (Finish Reasons) و شناسایی گران‌ترین نشست‌ها.

هر مدل ردیف مخصوص خود را برای ردیابی هزینه‌ها و صرفه‌جویی‌های حاصل از حافظه پنهان پرامپت (Prompt Caching) دارد. این داده‌ها از طریق TRQL در دسترس هستند و امکان ساخت داشبوردهای سفارشی را فراهم می‌کنند. علاوه بر این، sessions.list فهرستی از تمام گفتگوها را ارائه می‌دهد که برای ساخت یک اینباکس کامل از گفتگوها کافی است.

یکپارچگی و مقیاس‌پذیری

این سیستم برای جایگزینی در استک‌های موجود طراحی شده است. با استفاده از AI SDK (به‌ویژه streamText و useChat)، مسیر API بین کلاینت و سرور کاملاً حذف می‌شود. با استفاده از useTriggerChatTransport تنها پیام‌های جدید منتقل می‌شوند و تاریخچه روی سرور انباشته می‌شود. این نوع یکپارچگی در مقیاس وسیع، مشابه راهکارهای مقیاس‌پذیری برای SMBهاست که از چات‌بات‌های یکپارچه برای مدیریت پشتیبانی بدون افزایش نیروی انسانی استفاده می‌کنند.

برای کاهش هزینه‌ها و افزایش عملکرد در بلندمدت، ویژگی‌های پیشرفته‌ای اضافه شده است:

• فشرده‌سازی (Compaction): وقتی تاریخچه به حد پنجره متنی (مثلاً بیش از ۸۰ هزار توکن) نزدیک می‌شود، به‌طور خودکار خلاصه می‌شود. توسعه‌دهندگان می‌توانند منطق shouldCompact و تابع summarize (مثلاً با استفاده از مدل Haiku) را تعریف کنند.
• حافظه پنهان پرامپت: بخش‌های ثابت هر درخواست را ارزان نگه می‌دارد.
• پرامپت‌های نسخه‌بندی شده: پرامپت‌ها در کد قرار دارند و با هر استقرار نسخه‌بندی می‌شوند. متن یا مدل‌ها را می‌توان از داشبورد بدون نیاز به استقرار مجدد تغییر داد.
• پشتیبانی از چند کلاینت: قابلیت AgentChat اجازه می‌دهد تسک‌ها، اسکریپت‌ها یا سایر عامل‌ها گفتگوها را هدایت کنند. یک سرور MCP تعامل با عامل‌ها را از طریق Claude Code یا Cursor ممکن می‌سازد.

در صورت بروز خطا، سیستم بازیابی قدرتمندی دارد. اگر نوبتی به‌دلیل خطای کمبود حافظه (OOM) کشته شود، روی ماشینی بزرگ‌تر مجدداً اجرا می‌شود بدون اینکه پیام کاربر از دست برود. بوت بازیابی (Recovery boot) تمام زمینه (Context) را پس از یک کرش یا لغو عملیات بازمی‌گرداند.

تست و اکوسیستم

توسعه‌دهندگان اکنون می‌توانند این عامل‌ها را از طریق تست‌های واحد (Unit Tests) آزمایش کنند که نوبت‌های واقعی را بدون نیاز به شبیه‌سازی (Mocking) محیط یا نیاز به شبکه اجرا می‌کنند. چون عامل‌ها به عنوان تسک‌های Trigger.dev ساخته می‌شوند، از تمام قابلیت‌های پلتفرم بهره می‌برند:

• ارکستراسیون: فعال کردن تسک‌های دیگر از طریق یک ابزار و انتظار برای اتمام آن‌ها.
• کنترل ترافیک: قرار دادن چت پشت یک صف با محدودیت‌های همزمانی (Concurrency) مشخص.
• زمان‌بندی: دسته‌بندی کارها یا زمان‌بندی اقدامات عامل.
• ارزیابی (Evals): ساخت تسک‌های ارزیابی برای اجرای عامل روی مجموعه‌های داده (Fixture sets) در هر استقرار.

پروژه Trigger.dev تحت لایسنس Apache 2.0 متن‌باز است و به توسعه‌دهندگان اجازه می‌دهد کد را بخوانند یا کل سیستم را خودشان اجرا کنند. صورت‌حساب بر اساس زمان واقعی اجرای ماشین است و گفتگوهای معلق رایگان هستند.

برای شروع، توسعه‌دهندگان می‌توانند از راهنمای مهاجرت برای انتقال اپلیکیشن‌های چت موجود به مدل Stateful استفاده کنند، یا یک عامل جدید را در سه گام با استفاده از مستندات chat.agent پیاده‌سازی نمایند.

گام بعدی شما

• اگر اپلیکیشن چتی دارید که با تایم‌اوت‌های API دست‌وپنجه نرم می‌کند، راهنمای مهاجرت به مدل Stateful را مطالعه کنید.
• ابزارهای CLI لینوکسی را که پیش از این در محیط Serverless غیرممکن بود، به عامل‌های خود اضافه کنید.
• برای کاهش هزینه‌ها، منطق shouldCompact را برای خلاصه کردن تاریخچه‌های طولانی پیاده‌سازی کنید.

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