فاز 14 · درس 29

محیط‌های اجرای پروداکشن: صف، رویداد و کران‌جاب

نوع
مفهومی
زمان
حدود 60 دقیقه
زبان‌ها
Python (stdlib)
پیش‌نیاز
فاز 14 · درس 13 (LangGraph)، فاز 14 · درس 22 (صوت)
شش گره متصل به‌هم روی یک برد معماری شبکه که جریان داده‌ها را در مسیرهای صف، حلقه و محرک‌های زمانی نشان می‌دهند
فهرست مطالب
  1. اهداف یادگیری
  2. صورت مسئله
  3. مفاهیم کلیدی
  4. درخواست-پاسخ (Request-response)
  5. استریمینگ (Streaming)
  6. اجرای پایدار (Durable execution)
  7. مبتنی بر صف / پس‌زمینه (Queue-based / background)
  8. رویدادمحور (Event-driven)
  9. زمان‌بندی‌شده (Scheduled)
  10. الگوهای دیپلوی سال 2026
  11. سیستم رصدپذیری نقشی باربر دارد
  12. نقاط شکست محیط‌های اجرای پروداکشن
  13. پیاده‌سازی از صفر
  14. استفاده از ابزارهای واقعی
  15. خروجی این درس
  16. تمرین‌ها
  17. اصطلاحات کلیدی
  18. برای مطالعه‌ی بیشتر

پیاده‌سازی یک ایجنت هوش مصنوعی در محیط نوت‌بوک یا در قالب اسکریپت ساده، تفاوت بسیار زیادی با اجرای پایدار آن در محیط واقعی دارد. در محیط توسعه همه‌چیز سریع و بی‌نقص پیش می‌رود، اما در شرایط واقعی با خطاهایی مانند انقضای زمان شبکه (network timeout) در گام سی‌وهفتم، قطعی ناگهانی ارتباط کاربر یا کمبود حافظه در پردازش‌های پس‌زمینه روبه‌رو می‌شوید.

اگر ساختار محیط اجرا (runtime shape) اشتباه انتخاب شود، ایجنت یا پشت درخواست‌های همگام قفل می‌شود یا با هر خطای ساده کل مسیر طی‌شده را از دست می‌دهد. این درس شش الگوی اصلی معماری برای اجرای پروداکشن را بررسی می‌کند تا پیش از انتخاب فریم‌ورک، بستر اجرایی مناسب برای وظایف کوتاه، رویدادمحور یا چندمرحله‌ای را مشخص کنید.

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

ایجنت‌های پروداکشن روی شش ساختار محیط اجرا (runtime shapes) کار می‌کنند: درخواست-پاسخ (request-response)، استریمینگ (streaming)، اجرای پایدار (durable execution)، پس‌زمینه مبتنی بر صف (queue-based background)، رویدادمحور (event-driven) و زمان‌بندی‌شده (scheduled). پیش از انتخاب فریم‌ورک، ساختار محیط اجرای خود را مشخص کنید. سیستم رصدپذیری (observability) در تک‌تک این ساختارها نقشی حیاتی و باربر دارد.

اهداف یادگیری

  • نام بردن شش ساختار محیط اجرای پروداکشن و تطبیق هرکدام با یک فریم‌ورک یا الگوی محصولی.
  • توضیح چرایی اهمیت اجرای پایدار (LangGraph) برای کارهای با افق زمانی طولانی (long-horizon tasks).
  • شرح محیط اجرای رویدادمحور و بررسی موارد کاربرد Claude Managed Agents.
  • تشریح این ادعا که سیستم رصدپذیری نقشی حیاتی و باربر در ایجنت‌های چندمرحله‌ای ایفا می‌کند.

صورت مسئله

ایجنت‌های پروداکشن به روش‌هایی دچار خطا می‌شوند که هرگز در یک نوت‌بوک Jupyter رخ نمی‌دهد: انقضای زمان شبکه (network timeout) در مرحله‌ی 37، قطع تماس صوتی توسط کاربر در میانه‌ی مسیر، از کار افتادن کران‌جاب (cron job) هنگام ریبوت سرور، یا پر شدن حافظه‌ی رم ورکر پس‌زمینه. ساختار محیط اجرا تعیین می‌کند که کدام‌یک از این خرابی‌ها قابل بازیابی هستند.

مفاهیم کلیدی

درخواست-پاسخ (Request-response)

  • پروتکل HTTP همگام (Synchronous). کاربر تا پایان کار منتظر می‌ماند.
  • صرفاً برای کارهای کوتاه (کمتر از 30 ثانیه) مناسب است.
  • استک‌های رایج: Agno (ترکیب Python و FastAPI)، Mastra (ترکیب TypeScript با فریم‌ورک‌های Express/Hono/Fastify/Koa).
  • رصدپذیری: لاگ‌های دسترسی استاندارد HTTP به‌همراه اسپن‌های OTel.

استریمینگ (Streaming)

  • استفاده از SSE یا WebSocket برای ارائه‌ی تدریجی خروجی.
  • ابزار LiveKit این شیوه را با WebRTC برای صدا و تصویر توسعه می‌دهد (درس 22).
  • استک‌های رایج: هر فریم‌ورکی با پشتیبانی از استریمینگ به‌همراه فرانت‌اندی که از پس مدیریت SSE/WS بربیاید.
  • رصدپذیری: زمان‌بندی هر چانک (chunk)، تاخیر تا اولین توکن (first-token latency) و تاخیر دنباله (tail latency).

اجرای پایدار (Durable execution)

  • ذخیره‌ی وضعیت در قالب چک‌پوینت پس از هر مرحله؛ ادامه‌ی خودکار اجرای فرایند در صورت بروز خطا.
  • مدل اکتر (actor model) در AutoGen v0.4 خرابی‌ها را به یک ایجنت ایزوله و محدود می‌کند (درس 14).
  • وجه تمایز اصلی LangGraph (درس 13).
  • برای مواقعی که تعداد مراحل از پیش نامشخص است و هزینه‌ی بازیابی بسیار بالاست، حیاتی است.

مبتنی بر صف / پس‌زمینه (Queue-based / background)

  • تسک وارد یک صف می‌شود، ورکرها آن را برمی‌دارند و نتایج از طریق وب‌هوک (webhook) یا الگوهای pub/sub بازمی‌گردند.
  • برای ایجنت‌های با افق زمانی طولانی حیاتی است (طبق اعلام شرکت Anthropic برای ویژگی computer use، ده‌ها تا صدها مرحله در هر تسک اجرا می‌شود).
  • استک‌های رایج: Celery (در Python)، BullMQ (در Node)، ترکیب SQS و Lambda (در AWS) یا سیستم‌های سفارشی.
  • رصدپذیری: عمق صف (queue depth)، توزیع تاخیر هر تسک، و حجم صف پیام‌های پردازش‌نشده (Dead-letter queue یا DLQ).

رویدادمحور (Event-driven)

  • ایجنت‌ها گوش‌به‌زنگ محرک‌ها (triggers) می‌مانند: دریافت ایمیل جدید، باز شدن PR، یا اجرای یک کران‌جاب.
  • سرویس Claude Managed Agents این قابلیت را به‌صورت پیش‌فرض پوشش می‌دهد (درس 17).
  • فریم‌ورک CrewAI Flows (درس 15) به جریان‌های کاری قطعی و رویدادمحور ساختار می‌دهد.
  • رصدپذیری: منبع محرک، تاخیر بین رویداد تا شروع، و تاخیر ایجنت.

زمان‌بندی‌شده (Scheduled)

  • ایجنت‌هایی با ساختار شبیه کران که به‌صورت دوره‌ای اجرا می‌شوند.
  • ترکیب این مدل با اجرای پایدار باعث می‌شود اگر یک اجرای شبانه با خطا متوقف شد، در دور بعدی از همان‌جا ادامه پیدا کند.
  • استک‌های رایج: Kubernetes CronJob به‌همراه یک فریم‌ورک پایدار؛ سرویس‌های میزبانی‌شده (مانند Render cron یا Vercel cron).

الگوهای دیپلوی سال 2026

  • CrewAI Flows برای محیط‌های پروداکشن رویدادمحور.
  • محیط بی‌وضعیت Agno بر پایه‌ی FastAPI برای میکروسرویس‌های Python.
  • تطبیق‌دهنده‌های سرور Mastra (مانند Express، Hono، Fastify، Koa) برای تعبیه‌سازی (embedding).
  • سرویس‌های Pipecat Cloud / LiveKit Cloud برای پردازش صوت مدیریت‌شده (درس 22).
  • Claude Managed Agents برای وظایف ناهمگام و طولانی‌مدت میزبانی‌شده.

سیستم رصدپذیری نقشی باربر دارد

بدون اسپن‌های GenAI در OpenTelemetry (درس 23) به‌همراه بک‌اندی مثل Langfuse/Phoenix/Opik (درس 24)، رفع باگ ایجنتی چندمرحله‌ای که در گام چهلم متوقف شده ممکن نخواهد بود. این بخش در محیط پروداکشن اختیاری نیست؛ بلکه تفاوت میان «دیباگ سریع» و «شروع مجدد همه‌چیز از صفر با لاگ‌های بیشتر» را رقم می‌زند.

نقاط شکست محیط‌های اجرای پروداکشن

  • انتخاب نادرست ساختار محیط اجرا. انتخاب مدل درخواست-پاسخ برای تسکی 5 دقیقه‌ای. کاربران تماس را قطع می‌کنند؛ ورکرها روی هم تلنبار می‌شوند؛ و بازآزمایی‌ها (retries) بحران را تشدید می‌کنند.
  • نبود DLQ. استفاده از ورکرهای صف بدون صف پیام‌های پردازش‌نشده. در این حالت، کارهای ناموفق محو می‌شوند.
  • فرایندهای پس‌زمینه‌ی تاریک و مبهم. اجرای ایجنت پس‌زمینه بدون خروجی ردگیری محاسبات (trace export). خرابی‌ها تا زمانی که کاربر آن‌ها را گزارش نکند پنهان می‌مانند.
  • نادیده گرفتن وضعیت پایدار. هر اجرایی که بیش از 30 ثانیه طول می‌کشد و توان پرداخت هزینه‌ی اجرای مجدد آن از ابتدا را ندارید، نیازمند اجرای پایدار است.
الگوهای محیط اجراسه ورودی، یک ورکر
RUNTIME SHAPESQueue-based background work, event-driven triggers, and scheduled cron jobs are three of the six production runtime shapes. Each intake delivers work to the same agent loop, but the shape decides which failures are survivable: a queue can retry, an event can replay, a cron must assume the last run died.صفرویدادcronورکر ایجنتهمان حلقه در داخلاول الگوی ورودی را انتخاب کنید؛ حلقه‌ی داخلی تقریباً تغییر نمی‌کند
کارهای پس‌زمینه مبتنی بر صف، محرک‌های رویدادمحور و جاب‌های زمان‌بندی‌شده‌ی cron سه مورد از شش الگوی محیط اجرای پروداکشن هستند. هر ورودی کار را به همان حلقه‌ی ایجنت تحویل می‌دهد، اما این الگو است که مشخص می‌کند کدام خرابی‌ها قابل جبرانند: صف می‌تواند دوباره تلاش کند، رویداد می‌تواند بازپخش شود، و cron باید فرض کند اجرای قبلی متوقف شده است.

پیاده‌سازی از صفر

فایل code/main.py یک پروژه‌ی دمو از ساختارهای مختلف با استفاده از کتابخانه‌ی استاندارد پایتون (stdlib) است:

  • اندپوینت درخواست-پاسخ (تابع ساده).
  • هندلر استریمینگ (generator).
  • ورکر مبتنی بر صف به‌همراه DLQ.
  • رجیستری محرک‌های رویداد.
  • اسکژولر با ساختار کران.

اجرای آن:

python3 code/main.py

خروجی: پنج ردگیری محاسبات که رفتار هر ساختار را روی تسکی یکسان نشان می‌دهند. منطق ایجنت در همگی یکسان است، اما پوسته‌های بیرونی متفاوتی دارند. اجرای پایدار (ششمین ساختار) به‌طور ویژه در درس 13 همراه با چک‌پوینت‌گیری LangGraph بررسی خواهد شد.

استفاده از ابزارهای واقعی

  • درخواست-پاسخ برای تجربه‌ی کاربری شبیه چت.
  • استریمینگ برای ارائه‌ی پاسخ‌های تدریجی.
  • اجرای پایدار برای کارهای با افق زمانی طولانی.
  • صف برای کارهای دسته‌ای (batch)، ناهمگام و زمان‌بر.
  • رویداد برای رفتارهای واکنشی ایجنت.
  • کران برای خانه‌تکانی سیستم (یکپارچه‌سازی حافظه، ارزیابی‌ها، گزارش هزینه‌ها).

خروجی این درس

سند outputs/skill-runtime-shape.md یک ساختار محیط اجرا را برای یک تسک انتخاب کرده و الزامات رصدپذیری آن را تنظیم می‌کند.

تمرین‌ها

  1. حلقه‌ی ReAct درس 01 را به هر شش ساختار در استک نرم‌افزاری خود پورت کنید. کدام ساختار با کدام سطح محصول شما همخوانی دارد؟
  2. یک DLQ به دموی مبتنی بر صف اضافه کنید. 10٪ خرابی در تسک‌ها شبیه‌سازی کرده و حجم DLQ را نمایش دهید.
  3. یک ایجنت ارزیابی بنویسید که با کران شبانه فعال شود و روی 20 ردگیری محاسبات برتر روز اجرا شود.
  4. قابلیت استریمینگ را با مکانیزم پس‌زدگی (backpressure) پیاده‌سازی کنید: اگر کلاینت کند بود، فعالیت ایجنت موقتاً متوقف شود. این فرایند چه تعاملی با بودجه‌ی نوبت گفت‌وگو (turn budget) دارد؟
  5. مستندات Claude Managed Agents را مطالعه کنید. در چه شرایطی یک ایجنت با افق زمانی طولانیِ خودمیزبان (self-hosted) را به سرویس مدیریت‌شده منتقل می‌کنید؟

اصطلاحات کلیدی

اصطلاح در گفت‌وگوها چه می‌گویند در عمل واقعاً چیست
Request-response «همگام» کاربر منتظر می‌ماند؛ فقط مخصوص کارهای کوتاه
Streaming «SSE / WS» خروجی تدریجی؛ تجربه‌ی کاربری بهتر؛ تاخیر در سطح هر چانک قابل رصد است
Durable execution «ادامه‌ی اجرا بعد از خرابی» وضعیت چک‌پوینت‌شده؛ راه‌اندازی مجدد از آخرین گام
Queue-based «کارهای پس‌زمینه» صف تولیدکننده / استخر ورکرها / DLQ
Event-driven «مبتنی بر محرک» ایجنت به رویدادهای بیرونی واکنش نشان می‌دهد
DLQ «صف پیام‌های پردازش‌نشده» محل پارک کارهای ناموفق
Claude Managed Agents «بستر آزمایشی میزبانی‌شده» محیط اجرای ناهمگام و طولانی‌مدت تحت میزبانی Anthropic با قابلیت کش‌کردن و فشرده‌سازی

برای مطالعه‌ی بیشتر

خودآزمایی

به سؤال‌ها جواب بدهید تا ببینید چقدر از درس در ذهنتان مانده است.

  1. پیش از درسشش الگوی محیط اجرا که در درس فهرست شده‌اند کدامند؟
  2. پیش از درسچه زمانی الگوی درخواست-پاسخ انتخاب نامناسبی است؟
  3. حین درسویژگی اصلی اجرای پایا (durable execution) چیست؟
  4. حین درسکدام مشاهده‌ی Anthropic محیط‌های اجرای مبتنی بر صف را برای ایجنت‌های طولانی توجیه می‌کند؟
  5. حین درسمنظور درس از عبارت «مشاهده‌پذیری باربر است» چیست؟
  6. پس از درسچرا ورکرهای صف باید صف پیام‌های مرده (DLQ) داشته باشند؟
  7. پس از درسدرس توصیه می‌کند ایجنت‌های با الگوی cron با چه چیزی جفت شوند؟

سؤالات متداول

چه زمانی باید از اجرای پایدار (Durable execution) به جای درخواست-پاسخ معمولی استفاده کرد؟

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

نقش صف پیام‌های پردازش‌نشده (DLQ) در معماری ایجنت‌ها چیست؟

صف DLQ کارهای ناموفقی را که ورکرها نتوانسته‌اند پردازش کنند در محلی جداگانه ذخیره می‌کند تا تسک‌ها ناپدید نشوند و مهندسان بتوانند علت شکست را ریشه‌یابی کنند.

چرا رصدپذیری (Observability) در ایجنت‌های چندمرحله‌ای حیاتی است؟

بدون ثبت اسپن‌ها و داده‌های ردگیری (trace)، اگر ایجنتی در گام‌های میانی (مثلاً مرحله‌ی 40) متوقف شود، امکان بازتولید و شناسایی دقیق مشکل بدون صرف هزینه و اجرای دوباره از صفر وجود نخواهد داشت.

ما رو توی گوگل بیشتر ببین

با افزودن نکست ادمین به «منابع ترجیحی» گوگل، درس‌ها و مطالب ما را در بخش اخبار برتر جستجو بیشتر می‌بینید.