تصور کنید یک مشتری چت پشتیبانی شما را برای ۶ ساعت رها میکند و سپس بازمیگردد؛ در حالت عادی، سرور شما برای این انتظار هزینه پرداخته است، اما حالا این هزینه دقیقاً صفر ثانیه است. شرکت Trigger.dev در ۱۳ اوت ۲۰۲۶ با معرفی chat.agent، ابزاری را عرضه کرد که اجازه میدهد گفتگوهای هوش مصنوعی برای روزها در حالت بیکار بمانند بدون اینکه حتی یک سنت هزینهٔ زمانِ فعال بودن سرور (Uptime) ثبت شود.
بسیاری از عاملهای هوش مصنوعی فعلی، صرفاً پوششی روی صفهای کاری (Job Queues) هستند که برای باز نگه داشتن یک Worker از کاربر هزینه میگیرند. این موضوع یک تضاد اقتصادی میان «پاسخدهی سریع» و «هزینه سرور» ایجاد میکند. برای توسعهدهندگان، ساخت یک چت واقعاً قابلبازگشت معمولاً نیازمند ترکیبی شکننده از Postgres برای تاریخچه، Redis برای استریم و پروتکلهای اتصال مجدد است تا توکنها هنگام رفرش صفحه گم نشوند. اگر شما یک تب ChatGPT را در میانه پاسخ بستید، استریم قطع میشود؛ باز کردن مجدد آن تنها به این دلیل کار میکند که یک سرور در پسزمینه همچنان با مدل در حال گفتگو بود. پیادهسازی دستی این سازوکار نیازمند ساخت یک صف کاری، یک لایه pub/sub و یک پروتکل اتصال مجدد از صفر است، و همچنین نیاز به مکانی برای ذخیره این وضعیت که «دستیار عبارت X را گفت اما پردازش پیش از ثبت آن متوقف شد».
همانطور که در تحلیلهای پیشین ما دربارهی زیرساختهای عاملمحور اشاره کردیم، مدیریت وضعیت (State) بزرگترین چالش در مقیاس تولید است. Trigger.dev این مشکل را با تبدیل هر جلسه چت به یک «ماشین وضعیت» (State Machine) بهجای یک اتصال مداوم حل کرده است. این رویکرد در واقع تکامل یافتهی استفاده از ماشینهای لینوکس اختصاصی برای حفظ حافظهٔ عاملهاست که پیشتر توسط این شرکت بررسی شده بود. طبق مستندات معماری این شرکت، سیستم بر پایه S2 است؛ یک سرویس لاگ بادوام append-only که شبیه به موضوعات Kafka برای هر جلسه عمل میکند. یک جلسه چت از سه بخش تشکیل شده است: یک کانال ورودی (.in) برای پیامهای کاربر، یک کانال خروجی (.out) برای تکههای پاسخ دستیار و یک تسک طولانیمدت که اولی را میخواند و در دومی مینویسد.
این سازوکار تضمین میکند که وقتی مرورگر با یک Last-Event-ID دوباره متصل میشود، سرور فقط تکههای از دست رفته را بازپخش میکند و نیازی به اجرای مجدد فراخوانی مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — نیست. رکوردها دارای شمارههای توالی افزایشی (monotonically increasing) هستند و خوانندهها از یک نشانگر (Cursor) ادامه میدهند. این یعنی اگر لپتاپ کاربر وسط پاسخ مدل به خواب برود، توسعهدهنده مجبور نیست هزینه مدل را دوبار پرداخت کند.
مکانیسم توقف بدون هزینه
این پلتفرم چرخه حیات عامل را در چهار وضعیت متمایز مدیریت میکند:
- استریمینگ (Streaming): عامل فعال است، تابع
streamText()را اجرا میکند و تکهها را به کانال خروجی میفرستد. - بیکار (Idle): نوبت پاسخ تمام شده و تسک منتظر پیام بعدی است اما هیچ پردازشی انجام نمیدهد.
- تعلیق (Suspended): پس از یک زمان تعیینشده (پیشفرض ۳۰ ثانیه)، موتور تمام وضعیت پردازش — شامل متغیرها، حافظههای موقت (in-memory caches) و هر زیر-عاملی که در میانه گفتگو ایجاد شده است — را در یک نقطه بازرسی (Checkpoint) ذخیره کرده و منابع محاسباتی را کاملاً آزاد میکند. در این حالت ردیف جلسه (session row) فعال میماند و استریم .out قابل خواندن است، اما هیچ ماشینی به آن اختصاص داده نشده است.
- بازگشت (Resuming): پیام بعدی، اجرا را دقیقاً از همان نقطه بازرسی بازیابی میکند و از اجرای مجدد مراحل اولیه یا راهاندازی سرد (Cold Boot) جلوگیری میکند.
اگر یک اجرا بهطور کامل بسته شود — به دلیل رسیدن به سقف نوبتها، فراخوانی endRun()، کرش کردن یا لغو توسط کاربر — پلتفرم یک اجرای کاملاً جدید آغاز میکند. در این حالت، وضعیت گفتگو از یک Snapshot در S3 بازیابی شده و هر پیامی که پس از آن اسنپشات رسیده باشد، بازپخش میشود. اگر اجرای قبلی وسط استریم با یک پاسخ ناقص در .out متوقف شده باشد، فریمورک آن پاسخ ناقص و پیام محرک را در بستر (Context) اجرای جدید ادغام میکند تا انسجام گفتگو حفظ شود.
این سیستم نقطه بازرسی اختراع جدیدی برای این شرکت نیست؛ Trigger.dev از سال ۲۰۲۳ از این مکانیسم برای تمام تسکهای طولانی استفاده میکرد. به نقل از گزارشهای شرکت، این ویژگی تا زمان عرضه عمومی در ۱۳ اوت ۲۰۲۶، بیش از «۸۴ سال محاسبات» را پردازش کرده و از ژوئن ۲۰۲۶ میلیونها جلسه را در محیط عملیاتی پشتیبانی کرده است. این ابزار اکنون به عنوان یک Primitive ارکستراسیون در پلتفرمی که توسط سرمایهگذاران بزرگی چون Sequoia حمایت میشود، عرضه شده و طبق تغییرات ثبتشده (Changelog)، از ۲ ژوئیه ۲۰۲۶ بهصورت عمومی در دسترس است.
عملکرد و تجربه توسعهدهنده
برای حل تأخیر «راهاندازی سرد» که در اجراهای بادوام رایج است، Trigger.dev مسیری به نام Head Start ایجاد کرده است. در این مسیر، اولین فراخوانی مدل در یک پردازش گرم (مانند Next.js، Hono یا SvelteKit) اجرا میشود، در حالی که عامل بادوام بهطور موازی بوت میشود. مالکیت استریم تنها زمانی به بخش بادوام منتقل میشود که مدل بخواهد یک ابزار (Tool) را فراخوانی کند.
بنچمارکهای مربوط به مدل Claude-Sonnet-4.6 تغییر چشمگیری در پاسخدهی را نشان میدهند:
- زمان تا نخستین توکن (Time-to-first-token) از ۲۸۰۱ میلیثانیه به ۱۲۱۸ میلیثانیه رسید (کاهش ۵۷٪).
- زمان کل نوبت از ۴۱۸۰ میلیثانیه به ۲۳۴۵ میلیثانیه کاهش یافت (کاهش ۴۴٪).
از نظر تجربه توسعهدهنده (DX)، این بکاند به هیچ Route API نیاز ندارد. توسعهدهندگان یک تسک مینویسند که پیامها را میگیرد و یک استریم برمیگرداند، سپس هوک useChat از Vercel AI SDK را به یک ترنسپورت سفارشی متصل میکنند.
مثال پیادهسازی:
`import { chat } from "@trigger.dev/sdk/ai";
import { streamText, stepCountIs } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
export const myChat = chat.agent({
id: "my-chat",
run: async ({ messages, signal }) => streamText({
model: anthropic("claude-sonnet-4-5"),
messages,
abortSignal: signal,
stopWhen: stepCountIs(15),
}),
});`
این رویکرد نیاز به طرح پایگاهداده برای پیامها، Redis برای استریمهای بادوام یا پردازشهای Worker مجزا را از بین میبرد. همچنین همگامسازی چند-تب (Multi-tab) از طریق BroadcastChannel مدیریت میشود؛ تبی که پیام میفرستد، مالک ID چت میشود و سایر تبها به حالت Read-only میروند. یک Heartbeat ۱۰ ثانیهای در صورت کرش کردن تب، مالکیت را آزاد میکند تا از ارسالهای تکراری و رابط کاربری قدیمی جلوگیری شود.
انسان در حلقه و ابزارها
یکی از کاربردیترین قابلیتها، پرچم needsApproval: true برای فراخوانی ابزارها است. این ویژگی اجازه میدهد یک عامل اجرا را بهطور نامحدود متوقف کند — مثلاً برای تایید انسانی یک عملیات بازگشت وجه (refundOrder) — بدون اینکه منابع محاسباتی مصرف کند. عامل تمام وضعیت حافظه را حفظ میکند و هنگام تایید انسان، بستر گفتگو را گم نمیکند. این مدل از تعامل، شباهت زیادی به معماری متمرکز بر تکلیف xAgent دارد که در آن محیط عملیاتی بهجای چت ساده، بر روی پیشبرد هدف متمرکز است.
محصول Arena (یک عامل کدنویسی) پیش از این از این زیرساخت برای «حالت عامل» خود استفاده کرده است. گراهام ترمپر، مهندس این پروژه، اشاره کرد که اختصاص یک ماشین واقعی به هر گفتگو، ساخت عاملهای بادوام را بهطور قابلتوجهی سادهتر کرده است.
سایر قابلیتهای پیشرفته عبارتند از:
- تاریخچه رایگان چند-نوبتی: هر نوبت یک گام در همان تسک بادوام است؛ سرور تاریخچه را جمع میکند و کلاینت فقط پیام جدید را میفرستد.
- ردیابی داخلی (Tracing): هر نوبت در داشبورد Trigger.dev یک Span است که با متریکهای اختصاصی برای هزینه، توکن و تأخیر ثبت میشود.
- زیر-عاملها: الگوی AgentChat اجازه میدهد یک چت والد، زیر-عاملهایی را به عنوان جلسات بادوام مجزا ایجاد کند و خروجی آنها را از طریق کارت ابزار والد استریم کند.
- بقا در استقرار (Deployment Survival): گفتگویی که هنگام آپدیت کد در جریان است، روی همان نسخهای که شروع شده ادامه مییابد. شما میتوانید صراحتاً از طریق جریان ارتقای نسخه، آن را به کد جدید منتقل کنید، بهجای اینکه در میانه نوبت قطع شود.
موارد استفاده دقیق
به دلیل نحوه مدیریت وضعیت و هزینه در chat.agent، چندین الگوی کاربردی ممکن میشود که پیش از این گران یا پیچیده بودند:
- عاملهای پشتیبانی با دسترسی بالا: عاملهایی که اجازه بازگشت وجه یا لغو سفارش دارند میتوانند از جریان HITL (انسان در حلقه) استفاده کنند تا تایید انسانی بدون از دست دادن بستر گفتگو رخ دهد.
- تحقیق و کدنویسی طولانیمدت: برای عاملهایی که یک نوبت پاسخشان ممکن است دقایق زمان ببرد، کاربر میتواند لپتاپ را ببندد و بعداً برگردد. این کار محدودیتهای زمانی سختگیرانه محیطهای Serverless مانند Vercel (۸۰۰ ثانیه) یا AWS Lambda (۹۰۰ ثانیه) را دور میزند. این قابلیت میتواند زیربنای بسیاری از گردشکارهای اتوماسیون AI برای جایگزینی وظایف تکراری باشد که نیاز به پردازشهای طولانیمدت دارند.
- تفویض به متخصص: یک دستیار والد میتواند کار را به یک زیر-عامل متخصص بسپارد و خروجی را در یک کارت ابزار نمایش دهد، در حالی که زیر-عامل به عنوان یک جلسه بادوام مجزا اجرا میشود.
- جایگزین استریمهای بازگشتپذیر: هر محصولی که در حال حاضر از ترکیب Redis pub/sub و Postgres برای دستیابی به استریمهای قابلبازگشت استفاده میکند، میتواند این سرویس را به عنوان جایگزین مستقیم به کار ببرد.
موازنه و نقاط ضعف
استفاده از chat.agent وابستگی شدید به فروشنده (Vendor Lock-in) ایجاد میکند. مدل جلسات بر پایه استریمهای اختصاصی S2 و اسنپشاتهای S3 شرکت Trigger.dev است و هیچ آداپتوری برای انتقال این جلسات به رقبایی مثل Inngest یا Temporal وجود ندارد. اگرچه پلتفرم تحت لایسنس Apache-2.0 است، اما میزبانی شخصی (Self-hosting) استریمهای S2 پیچیدگی عملیاتی بیشتری نسبت به یک Runner بدون وضعیت دارد و مستندات عمومی در حال حاضر درباره جزئیات S2 در حالت Self-hosted ناقص است.
چالشهای فنی ثبتشده نیز وجود دارد:
- React Strict Mode: یک باگ شناختهشده باعث میشود اثر بازگشت در
useChatدوبار اجرا شود و خطای TypeError در کنسول توسعهدهندگان نمایش دهد (که مربوط به AI SDK است). - کنترل تولید: تابع
stop()درuseChatپس از بازگشت استریم بهدرستی کار نمیکند و توسعهدهندگان باید از متد مجزایstopGenerationاستفاده کنند. - مدیریت حافظه: در نسخههای اولیه ابزارهای MCP (که اجازه میدهد عاملهای IDE مثل Claude Code یا Cursor تسکها را هدایت کنند)، سیاست حذف دادهها (Eviction Policy) برای نقشه جلسات فعال وجود نداشت. یک بازبین اشاره کرد که این موضوع باعث رشد نامحدود حافظه میشود که در نهایت با افزودن سقف LRU و یک پاککننده (Sweeper) برای جلسات بیکار حل شد.
محدودیتهای همزمانی نیز به عنوان یک سقف عمل میکنند. سطح رایگان به ۲۰ اجرای همزمان، سطح Hobby به ۵۰ و سطح Pro از ۲۰۰ اجرا شروع میشود و برای موارد بیشتر هزینه متری شده دریافت میشود. در حالی که چتهای تعلیقشده جایگاهی اشغال نمیکنند، چتهای فعال یا بیکار این سهمیه را مصرف میکنند.
جایگاه بازار و اقتصاد
در مقایسه با سایر پلتفرمهای اجرای بادوام، رویکرد Trigger.dev بسیار متمرکز و خاص (Opinionated) است. Inngest بر اساس هر گام اجرا هزینه میگیرد که برای عاملهای پرحرف و چند-نوبتی (مثلاً یک عامل ۲۰ نوبتی که ممکن است ۴۰+ اجرای صورتحساب شده داشته باشد) گران میشود. Temporal قدرت بیشتری برای ارکستراسیونهای حساس به ماموریت دارد اما یادگیری آن بسیار سختتر است و نیاز به کلاستر اختصاصی یا اشتراک Cloud دارد. Restate ردپای سبکتری با اشیاء مجازی (Virtual Objects) دارد اما پروتکل چت پیشساخته ندارد.
Trigger.dev با ارائه یک پروتکل چت پیشساخته، لایهای از یکپارچهسازی را حذف میکند که اکثر تیمها بهصورت دستی میسازند. مدل هزینه بر اساس اندازه ماشین است، نه تعداد اجرا:
- Micro (۰.۲۵ vCPU): ۰.۰۰۰۰۱۶۹ دلار در ثانیه
- Large 2x (۸ vCPU): ۰.۰۰۰۶۸ دلار در ثانیه
- هزینه فراخوانی: مبلغ ثابت ۰.۰۰۰۰۲۵ دلار برای هر اجرا
این تغییر، صنعت را از «تاریخچه مبتنی بر پایگاهداده» به سمت «وضعیت مبتنی بر پردازش» میبرد و اجازه میدهد عاملهای طولانیمدت (مانند دستیاران تحقیق یا کدنویسی) بدون ترس از Timeout محیطهای Serverless مانند Vercel (۸۰۰ ثانیه) یا AWS Lambda (۹۰۰ ثانیه) اجرا شوند.
ارزیابی نهایی
مهندسی این سیستم بسیار دقیق است. تفکیک بین نقاط بازرسی موتور (برای بقا در وقفههای بیکاری)، اسنپشاتهای چت (برای بقا در خروج کامل) و نشانگرهای LastEventId کلاینت (برای بقا در رفرش تب)، سه حالت شکست مجزا را پوشش میدهد که پیادهسازیهای داخلی معمولاً آنها را با هم ترکیب کرده و دچار خطا میشوند.
توسعهدهندگان باید بسنجند که آیا به کنترل یک استک دستی Redis+Postgres نیاز دارند یا سرعت یک Primitive مدیریتشده، ریسک وابستگی به زیرساخت را توجیه میکند. اگر در حال حاضر با Workerهایی میجنگید که مدام با Timeoutهای Serverless مواجه میشوند، باید بپرسید چقدر از آن استک را برای کنترل ساختهاید و چقدر را صرفاً چون ابزاری مثل این وجود نداشت.
گام بعدی شما
- اگر از Vercel AI SDK استفاده میکنید، مستندات
chat.agentرا برای حذف لایههای Redis و Postgres بررسی کنید. - برای عاملهایی که نیاز به تایید انسانی دارند، قابلیت
needsApprovalرا جایگزین سیستمهای انتظار سنتی کنید. - هزینههای استنتاج خود را با مدل ماشینهای Micro در مقابل مدلهای پرداخت به ازای گام مقایسه کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو