بسیاری از پایپ‌لاین‌های اولیه برای اجرای ایجنتهای هوشمند در حلقه‌های باز و شکننده اجرا میشوند. در چنین طراحی‌هایی، اگر سرور در میانه‌ی یک وظیفه‌ی 4 ساعته خاموش شود یا ارتباط شبکه قطع گردد، تمام محاسبات، فراخوانیهای گران‌قیمت مدل و اثرات جانبی ابزارها از بین می‌روند و کل فرایند باید از ابتدا تکرار شود.
الگوی اجرای پایدار (Durable Execution) با تفکیک منطق ارکستراسیون از فعالیتهای دارای اثر جانبی، قابلیت بازپخش رویدادها را فراهم میکند. با استفاده از لاگ رویدادها و چک‌پوینت‌های مبتنی بر شناسه نشست، در صورت بروز هرگونه قطعی یا ریاستارت، برنامه دقیقاً از آخرین گام متوقف‌شده ادامه می‌یابد و از مصرف مجدد بودجه یا تاییدهای تکراری جلوگیری میکند.
این شیوه برای سناریوهایی که نیازمند حضور انسان در چرخه هستند یا به دلیل طولانی‌شدن فرایند با افت پایداری ذاتی مواجه میشوند، یک ضرورت در محیط‌های عملیاتی به شمار می‌آید.
ایجنتهای افق‌بلند (long-horizon) در محیط عملیاتی (پروداکشن) درون یک حلقه‌ی
while Trueاجرا نمی‌شوند. در این سیستم‌ها، هر فراخوانی مدل زبانی بزرگ (LLM call) به یک فعالیت (activity) مجهز به چک‌پوینت، تلاش مجدد (retry) و بازپخش (replay) تبدیل میشود. یکپارچه‌سازی Temporal با OpenAI Agents SDK در مارس 2026 به پایداری کامل (GA) رسید. قابلیت Claude Code Routines از شرکت Anthropic، فراخوانیهای زمان‌بندی‌شده‌ی Claude Code را بدون نیاز به یک فرایند محلیِ همیشه روشن اجرا میکند. نشست‌ها هنگام نیاز به ورودی انسان متوقف میشوند، در برابر دیپلوی‌های جدید دوام می‌آورند و از آخرین چک‌پوینت که باthread_idمشخص شده ادامه می‌یابند. پشت این تجربه کاربری مدرن، یک الگوی قدیمی نشسته است: ارکستراسیون جریان کاری (workflow orchestration)؛ اما این بار با یک ورودیِ تازه: فراخوانیهای LLM به‌عنوان فعالیتهای غیرقطعی (non-deterministic) که هنگام بازیابی باید بتوان آن‌ها را به‌صورت قطعی بازپخش کرد.
صورت مسئله
ایجنت فرضی را در نظر بگیرید که قرار است 4 ساعت کار کند. این ایجنت 3 ابزار را فراخوانی میکند، 2 بار از کاربر ورودی می‌خواهد و 40 بار مدل زبانی را صدا می‌زند. در میانه‌ی کار، سروری که برنامه روی آن اجرا میشود ناگهان ری‌بوت میشود. چه اتفاقی می‌افتد؟
- در یک حلقه‌ی ساده‌لوحانه‌ی
while True: همه‌چیز از دست میرود. فرایند از صفر شروع میشود. آن 3 فراخوانی ابزار (با اثرات جانبی واقعی) دوباره اجرا میشوند. از کاربر دوباره درباره‌ی چیزهایی که قبلاً تایید کرده سوال میشود. هزینهی 40 فراخوانی مدل زبانی دوباره در صورت‌حساب شما ثبت میشود. - با اجرای پایدار (durable execution): فرایند از جدیدترین چک‌پوینت از سر گرفته میشود. فعالیت‌هایی که پیش‌تر کامل شده‌اند، دوباره اجرا نمی‌شوند؛ بلکه نتیجه‌ی آن‌ها از لاگِ پایدار بازپخش میشود. کاربر مجبور نیست مواردی را که قبلاً تایید کرده دوباره تایید کند. بابت فراخوانیهای LLM که قبلاً انجام شده‌اند، هزینهی مجددی پرداخت نمی‌کنید.
این دقیقاً همان الگویی است که موتورهای جریان کاری یک دهه‌ی گذشته ارائه کرده‌اند (Temporal، Cadence و Cherami در اوبر). تفاوت ماجرا اینجاست که اکنون فراخوانیهای LLM خود نوعی فعالیت هستند؛ غیرقطعی، گران‌قیمت و همراه با اثرات جانبی، و دقیقاً در همین الگو می‌گنجند.
موضوع اصلی این درس این است: قابلیت اطمینان در کارهای افق‌بلند با گذشت زمان افت میکند (موسسه‌ی METR متوجه یک «افت 35 دقیقهای» شده است؛ یعنی نرخ موفقیت با افزایش طول زمان کار، تقریباً به‌صورت درجهدو کاهش می‌یابد). اجرای پایدار این امکان را به شما می‌دهد که فرایندها را فراتر از سقف پایداری ذاتی‌شان اجرا کنید. اگر طراحی درست باشد، این کار راهی امن برای مدیریت شکست‌ها در اختیارتان می‌گذارد؛ و اگر طراحی غلط باشد، به شکلی ناامن شکست خواهد خورد.
مفاهیم کلیدی
فعالیت‌ها، جریان‌های کاری و بازپخش
- جریان کاری (Workflow): کد ارکستراسیونِ قطعی. توالی فعالیت‌ها، انشعاب‌ها و توقف‌ها را مشخص میکند. این کد حتماً باید قطعی باشد تا بتوان آن را از روی لاگ رویدادها بازپخش کرد، بدون اینکه انحراف غیرمنتظره‌ای رخ دهد.
- فعالیت (Activity): یک واحد کاری غیرقطعی که پتانسیل شکست دارد؛ مثل فراخوانی LLM، فراخوانی ابزار، نوشتن روی فایل یا ارسال درخواست HTTP. هر فعالیت همراه با ورودی‌ها و (پس از پایان) خروجی‌هایش لاگ میشود.
- لاگ رویدادها (Event log): ذخیره‌ساز پایدار داده‌ها. شروع هر فعالیت، پایان آن، شکست‌ها، تلاش‌های مجدد و تمام تصمیم‌های جریان کاری در این بخش ثبت میشوند.
- بازپخش (Replay): هنگام بازیابی پس از خرابی، کد جریان کاری دوباره از ابتدا اجرا میشود؛ هر فعالیتی که قبلاً کامل شده بود، نتیجه‌ی لاگ‌شده‌ی خود را برمی‌گرداند و دوباره اجرا نمی‌شود. فقط فعالیت‌هایی واقعاً اجرا میشوند که به پایان نرسیده بودند.
این سازوکار درست شبیه رندر مجدد در React در مقایسه با Virtual DOM، یا بازسازی درخت کاری در Git از روی commitهاست. همین قطعی بودنِ هماهنگ‌کننده است که پایدارسازی را کم‌هزینه میکند.
چرا فراخوانیهای LLM با این الگو همخوانی دارند؟
فراخوانیهای مدل‌های زبانی:
- غیرقطعی هستند (با دمای بالاتر از 0؛ حتی با دمای 0 هم خروجی در نسخه‌های مختلف مدل تغییر میکند).
- هزینه‌بر هستند (هم از نظر مالی و هم تاخیر).
- مستعد خطا هستند (محدودیت نرخ درخواست، خطای مهلت زمانی یا تایم‌اوت).
- اثر جانبی دارند (اگر ابزاری را فراخوانی کنند).
این ویژگی‌ها دقیقاً همان پروفایل یک فعالیت است. کپسوله‌کردن هر فراخوانی LLM درون یک فعالیت، مواردی مثل تلاش مجدد با عقب‌گرد نمایی (exponential backoff)، چک‌پوینت‌گیری در طول ری‌استارت‌ها و یک ردگیری محاسبات (trace) قابل بازپخش برای اشکال‌زدایی را به شما می‌دهد.
چک‌پوینت‌های مبتنی بر thread_id
ابزارهای LangGraph، Microsoft Agent Framework، Cloudflare Durable Objects و Claude Code Routines همگی به ساختار API یکسانی رسیده‌اند: یک شناسه مثل thread_id (یا معادل آن) نشست را مشخص میکند؛ هر تغییر وضعیتی روی یک پایگاه داده پایدار میشود (PostgreSQL به عنوان پیش‌فرض، SQLite برای محیط توسعه و Redis برای کش)؛ و ادامه‌ی فرایند، جدیدترین چک‌پوینت را می‌خواند.
انتخاب پایگاه داده اهمیت زیادی دارد:
- PostgreSQL: پایدار، با قابلیت کوئری‌زدن، و مقاوم در برابر دیپلوی‌ها. گزینه‌ی پیش‌فرض برای LangGraph.
- SQLite: فقط مناسب توسعه‌ی محلی؛ با تغییر هاست اطلاعات آن از دست میرود.
- Redis: سریع، اما ناپایدار؛ مگر اینکه AOF یا snapshot روی آن فعال شده باشد.
- Cloudflare Durable Objects: توزیع‌شده به‌صورت شفاف؛ محدود به دامنه‌ی یک کلید یکتا؛ با ماندگاری از چند ساعت تا چند هفته.
ورودی انسان به‌عنوان وضعیتی رسمی در سیستم
الگوی «پیشنهاد و سپس ثبت قطعی» (درس 15) نیازمند یک وضعیت پایدار تحت عنوان «در انتظار تایید انسان» است. جریان کاری متوقف میشود، یک صف خارجی درخواست بلاتکلیف را نگه می‌دارد و به محض تایید، جریان کاری دقیقاً از همان نقطه ادامه می‌یابد. بدون اجرای پایدار، این فرایند فقط در حد بهترین تلاش ممکن (best-effort) است؛ اما با وجود آن، اگر تاییدیه‌ای شبانه صادر شود، جریان کاری صبح روز بعد ادامه‌ی کار را پی می‌گیرد.
افت 35 دقیقهای
بررسی‌های METR نشان می‌دهد هر کلاسی از ایجنتها که بررسی شده، بعد از حدود 35 دقیقه کار مداوم با افت قابلیت اطمینان مواجه میشود. دو برابر شدن مدت‌زمان وظیفه، نرخ شکست را تقریباً چهار برابر میکند. اجرای پایدار این مشکل را حل نمی‌کند؛ بلکه اجازه می‌دهد وظایفی طولانی‌تر از سقف قابلیت اطمینان مدل اجرا شوند. الگوی امن این است که پایداری را با چک‌پوینت‌هایی ترکیب کنید که در ورود مجدد، تایید دوباره‌ی انسان در چرخه (HITL) را الزامی کنند، و همچنین کلیدهای قطع اضطراری بودجه (درس 13) را به کار بگیرید تا کل توان پردازشی فارغ از زمان سپری‌شده محدود شود.
چه زمان‌هایی نباید از اجرای پایدار استفاده کرد؟
- اجراهایی که کمتر از چند دقیقه طول می‌کشند و به ورودی انسان نیاز ندارند. در این حالت، بار محاسباتی اضافه از مزایای آن بیشتر است.
- سناریوهایی که صرفاً بازیابی اطلاعات فقط‌خواندنی هستند.
- وظایفی که درستی آن‌ها وابسته به اجرای سرتاسری درون یک پنجره‌ی بافتار واحد است (برخی کارهای استدلالی؛ بعضی تولیدهای تک‌نوبته).
پیاده‌سازی عملی
فایل code/main.py یک موتور اجرای پایدار حداقلی را فقط با کتابخانه‌ی استاندارد Python پیاده‌سازی میکند. این ابزار از موارد زیر پشتیبانی میکند:
- دکوراتور
@activityکه ورودی‌ها و خروجی‌ها را در یک لاگ رویداد JSON ذخیره میکند. - تابع جریان کاری که توالی اجرای فعالیت‌ها را مشخص میکند.
- تابع
run_or_replay(workflow, event_log)که فعالیتهای تکمیل‌شده را بدون اجرای مجدد بازپخش میکند.
کد اجراکننده، جریان کاری با سه فعالیت را شبیه‌سازی میکند، در میانه‌ی کار کرش میکند و تفاوت این دو حالت را نشان می‌دهد: (الف) تلاش مجدد ساده‌لوحانه که همه‌چیز را از ابتدا اجرا میکند در برابر (ب) بازپخش که فقط فعالیت باقی‌مانده را انجام می‌دهد.
تحویل نهایی
فایل outputs/skill-durable-execution-review.md دیپلوی پیشنهادی یک ایجنت طولانی‌مدت را بررسی میکند تا ساختار اجرای پایدار آن از جنبه‌های مختلف سنجیده شود: فعالیت‌ها، قطعی بودن ارکستراسیون، بک‌اند چک‌پوینت، وضعیت در انتظار انسان، و سیاست‌های ورود دوباره‌ی انسان در چرخه پس از بازیابی.
تمرین‌ها
-
فایل
code/main.pyرا اجرا کنید. تفاوت تعداد دفعات اجرای فعالیت‌ها را بین تلاش مجدد ساده‌لوحانه و بازپخش مقایسه کنید. نقطه‌ی کرش را تغییر دهید و بررسی کنید که شمارنده‌ی بازپخش چگونه متناسب با آن تغییر میکند. -
این موتور کوچک را طوری تغییر دهید که مستقیماً از
thread_idاستفاده کند. دو نشست هم‌روند را روی این موتور شبیه‌سازی کنید و مطمئن شوید که لاگ رویدادهای آن‌ها با یکدیگر تداخل پیدا نمی‌کند. -
در یکی از فعالیتهای این موتور ساده، یک عامل غیرقطعی وارد کنید (مثلاً خواندن ساعت سیستم در شرط‌های تصمیم‌گیری جریان کاری). انحراف در بازپخش را عملاً نشان دهید. توضیح دهید که موتورهای واقعی چگونه این مشکل را حل می‌کنند (ثبت اثر جانبی، APIهای
Workflow.now()). -
مقاله‌ی LangChain با عنوان «Runtime behind production deep agents» را بخوانید. تمام وضعیت‌هایی را که این محیط اجرا پایدار میکند فهرست کرده و مشخص کنید هر کدام جلوی چه نوع نقصی را می‌گیرند.
-
یک سیاست چک‌پوینت برای وظیفه‌ی کدنویسی خودکار که 6 ساعت طول می‌کشد طراحی کنید. در چه مراحلی چک‌پوینت ایجاد می‌کنید؟ بازیابی سیستم پس از کرش به چه شکل است؟ در چه مراحلی تایید مجدد انسان در چرخه الزامی است؟
اصطلاحات کلیدی
| اصطلاح | در گفت‌وگوهای روزمره | معنای دقیق فنی |
|---|---|---|
| جریان کاری (Workflow) | «اسکریپت ایجنت» | کد ارکستراسیونِ قطعی؛ قابل بازپخش از روی لاگ رویدادها |
| فعالیت (Activity) | «یک مرحله» | واحد کاری غیرقطعی (فراخوانی LLM، فراخوانی ابزار) که قبل و بعد از اجرا ثبت میشود |
| لاگ رویدادها (Event log) | «محل ذخیره‌سازی داده» | سابقه‌ی پایدار تمام تغییرات وضعیت در سیستم |
| بازپخش (Replay) | «ادامه‌ی اجرا» | اجرای دوباره‌ی جریان کاری؛ فعالیتهای قبلی خروجی لاگ‌شده را برمیگردانند و دوباره اجرا نمی‌شوند |
| چک‌پوینت (Checkpoint) | «نقطه‌ی ذخیره» | وضعیت پایدارشده بر اساس thread_id؛ در ادامه‌ی کار، آخرین مقدار معتبر است |
| thread_id | «کلید نشست» | شناسه‌ای که دامنه‌ی وضعیت پایدار را مشخص میکند |
| افت 35 دقیقهای (35-minute degradation) | «کاهش قابلیت اطمینان» | گزارش METR: افت تقریباً درجهدو در نرخ موفقیت با افزایش زمان کار |
| غیرقطعی بودن (Non-determinism) | «انحراف در بازپخش» | ساعت سیستم، مقادیر تصادفی، خروجی LLM؛ مواردی که حتماً باید به‌صورت اثر جانبی ثبت شوند |
برای مطالعه‌ی بیشتر
- Anthropic — Claude Code Agent SDK: agent loop — بودجه، نوبت‌های گفت‌وگو و مفاهیم ادامه‌ی اجرا.
- Microsoft — Agent Framework: human-in-the-loop and checkpointing — ساختار RequestInfoEvent.
- LangChain — The Runtime Behind Production Deep Agents — نیازمندی‌های واقعی محیط اجرا.
- OpenAI Agents SDK + Temporal integration (Trigger.dev announcement) — ساختار فعالیت‌ها برای فراخوانیهای LLM.
- Anthropic — Measuring agent autonomy in practice — مرجع ارزیابی افت عملکرد پس از 35 دقیقه.