پیادهسازی یک ایجنت هوش مصنوعی در محیط نوتبوک یا در قالب اسکریپت ساده، تفاوت بسیار زیادی با اجرای پایدار آن در محیط واقعی دارد. در محیط توسعه همهچیز سریع و بینقص پیش میرود، اما در شرایط واقعی با خطاهایی مانند انقضای زمان شبکه (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 ثانیه طول میکشد و توان پرداخت هزینهی اجرای مجدد آن از ابتدا را ندارید، نیازمند اجرای پایدار است.
پیادهسازی از صفر
فایل code/main.py یک پروژهی دمو از ساختارهای مختلف با استفاده از کتابخانهی استاندارد پایتون (stdlib) است:
- اندپوینت درخواست-پاسخ (تابع ساده).
- هندلر استریمینگ (generator).
- ورکر مبتنی بر صف بههمراه DLQ.
- رجیستری محرکهای رویداد.
- اسکژولر با ساختار کران.
اجرای آن:
python3 code/main.py
خروجی: پنج ردگیری محاسبات که رفتار هر ساختار را روی تسکی یکسان نشان میدهند. منطق ایجنت در همگی یکسان است، اما پوستههای بیرونی متفاوتی دارند. اجرای پایدار (ششمین ساختار) بهطور ویژه در درس 13 همراه با چکپوینتگیری LangGraph بررسی خواهد شد.
استفاده از ابزارهای واقعی
- درخواست-پاسخ برای تجربهی کاربری شبیه چت.
- استریمینگ برای ارائهی پاسخهای تدریجی.
- اجرای پایدار برای کارهای با افق زمانی طولانی.
- صف برای کارهای دستهای (batch)، ناهمگام و زمانبر.
- رویداد برای رفتارهای واکنشی ایجنت.
- کران برای خانهتکانی سیستم (یکپارچهسازی حافظه، ارزیابیها، گزارش هزینهها).
خروجی این درس
سند outputs/skill-runtime-shape.md یک ساختار محیط اجرا را برای یک تسک انتخاب کرده و الزامات رصدپذیری آن را تنظیم میکند.
تمرینها
- حلقهی ReAct درس 01 را به هر شش ساختار در استک نرمافزاری خود پورت کنید. کدام ساختار با کدام سطح محصول شما همخوانی دارد؟
- یک DLQ به دموی مبتنی بر صف اضافه کنید. 10٪ خرابی در تسکها شبیهسازی کرده و حجم DLQ را نمایش دهید.
- یک ایجنت ارزیابی بنویسید که با کران شبانه فعال شود و روی 20 ردگیری محاسبات برتر روز اجرا شود.
- قابلیت استریمینگ را با مکانیزم پسزدگی (backpressure) پیادهسازی کنید: اگر کلاینت کند بود، فعالیت ایجنت موقتاً متوقف شود. این فرایند چه تعاملی با بودجهی نوبت گفتوگو (turn budget) دارد؟
- مستندات Claude Managed Agents را مطالعه کنید. در چه شرایطی یک ایجنت با افق زمانی طولانیِ خودمیزبان (self-hosted) را به سرویس مدیریتشده منتقل میکنید؟
اصطلاحات کلیدی
| اصطلاح | در گفتوگوها چه میگویند | در عمل واقعاً چیست |
|---|---|---|
| Request-response | «همگام» | کاربر منتظر میماند؛ فقط مخصوص کارهای کوتاه |
| Streaming | «SSE / WS» | خروجی تدریجی؛ تجربهی کاربری بهتر؛ تاخیر در سطح هر چانک قابل رصد است |
| Durable execution | «ادامهی اجرا بعد از خرابی» | وضعیت چکپوینتشده؛ راهاندازی مجدد از آخرین گام |
| Queue-based | «کارهای پسزمینه» | صف تولیدکننده / استخر ورکرها / DLQ |
| Event-driven | «مبتنی بر محرک» | ایجنت به رویدادهای بیرونی واکنش نشان میدهد |
| DLQ | «صف پیامهای پردازشنشده» | محل پارک کارهای ناموفق |
| Claude Managed Agents | «بستر آزمایشی میزبانیشده» | محیط اجرای ناهمگام و طولانیمدت تحت میزبانی Anthropic با قابلیت کشکردن و فشردهسازی |
برای مطالعهی بیشتر
- مروری بر LangGraph — جزئیات اجرای پایدار
- مروری بر Claude Managed Agents — اجرای ناهمگام و طولانیمدت میزبانیشده
- معرفی قابلیت computer use توسط Anthropic — «دهها تا صدها مرحله در هر تسک»
- تحقیقات مایکروسافت روی AutoGen v0.4 — ایزولهسازی خطا با مدل اکتر
