عوامل پیش زمینه طولانی مدت: اعدام پایدار
while Trueهر تماس LLM تبدیل به یک فعالیت با نقطه چک، دوباره تلاش، و بازی. ادغام OpenAI Agents SDK Temporal به مارس 2026 انجام شد. کلود کد روتینز (انتروپک) بدون یک فرآیند محلی مداوم کالود کد برنامه ریزی شده را اجرا می کند. جلسات توقف در ورودی انسانی، نجات از انتشار و ادامه از آخرین نقطه چک کلید توسطthread_id. پشت ارگونومیک جدید یک الگوی قدیمی قرار دارد ارقای کاری با یک ورودی جدید: LLM به عنوان فعالیت های غیر تعیین کننده ای که باید به طور تعیین کننده در بازیابی تکرار شود، می خواند.Type: Learn
Languages: Python (stdlib, minimal durable-execution state machine)
Prerequisites: Phase 15 · 10 (Permission modes), Phase 15 · 01 (Long-horizon agents)
Time: ~60 minutes
مشکل
به یک نماینده که چهار ساعت کار می کند فکر کنید. سه ابزار را می خواند، دو بار کاربر را به او می گوید و چهل تماس LLM می کند. در نیمه راه، میزبان را در حال راه اندازی مجدد است. چه اتفاقی می افتد؟
- در یک ساده
while Trueلوپ: همه چیز از دست رفته است. اجرا از نو شروع می شود. سه تماس ابزار (با اثرات جانبی واقعی) دوباره اجرا می شود. کاربر دوباره برای چیزهایی که قبلاً تأیید کرده اند خواسته می شود. چهل تماس LLM دوباره صورت می گیرد. - با اجرای پایدار: اجرا از آخرین نقطه بازرسی ادامه می یابد. فعالیت های تکمیل شده دوباره اجرا نمی شوند؛ نتایج آنها از دفترچه دوام دوباره پخش می شود. کاربر چیزهایی را که قبلاً تأیید کرده است دوباره تأیید نمی کند. تماس های LLM که قبلاً انجام شده است دوباره صورت حساب نمی شود.
این همان الگوی است که موتورهای جریان کار برای یک دهه (تمپورال، کادنس، چریمی اوبر) منتشر کرده اند. آنچه جدید است این است که تماس های LLM اکنون نوعی فعالیت هستند غیر تعیین کننده، گران قیمت، با عوارض جانبی و آنها به طور تمیز با این الگوی مطابقت دارند.
موضوع راه اندازی درس: کاهش قابلیت اطمینان افق طولانی (METR "هلاک شدن 35 دقیقه ای" را مشاهده می کند) نرخ موفقیت تقریباً به صورت مربع با افق کاهش می یابد. اجرای پایدار باعث می شود که دوره های طولانی تر از پروفایل قابلیت اطمینان پشتیبانی شود، که راهی جدید برای شکست ایمن است اگر طراحی درست باشد و غیر امن اگر طراحی اشتباه باشد.
مفهوم
فعالیت ها، جریان های کار و بازخورد
- Workflow: کد ارق بندی تعیین کننده. ترتیب فعالیت ها، شاخه ها، انتظارات را تعریف می کند. باید تعیین کننده باشد تا بتواند از دفترچه رویداد بدون انحراف شگفت انگیزی باز شود.
- Activity: یک واحد کار غیر تعیین کننده و بالقوه شکست خورده. LLM تماس، ابزار تماس، فایل نوشتن، HTTP درخواست. هر فعالیت با ورودی خود را ثبت و (یک بار کامل) خروجی خود را.
- Event log: فروشگاه پشتیبان پایدار. هر فعالیت شروع، تکمیل، شکست، دوباره تلاش و هر تصمیم جریان کار ثبت می شود.
- Replay: در بازیابی، کد جریان کار از ابتدا دوباره اجرا می شود؛ هر فعالیت که قبلاً انجام شده است، نتیجه ثبت شده خود را بدون اجرای مجدد به ارمغان می آورد. تنها فعالیت هایی که هنوز انجام نشده اند در واقع اجرا می شوند.
این شکل مشابه React است که در برابر یک DOM مجازی، یا Git که در یک درخت کار از commits بازسازی می شود. تعیین کننده در orkestrator چیزی است که دوام را ارزان تر می کند.
چرا تماس های LLM با الگوی مناسب است
تماس های LLM اینه:
- غیر تعیین کننده (طمره > 0؛ حتی درجه حرارت 0 در انواع مدل ها تغییر می کند).
- گران قیمت (مال و تاخیر)
- احتمال شکست (حدود نرخ، زمان بندی)
- اثرات جانبی (اگر ابزار را استفاده کنند)
این دقیقاً پروفایل فعالیت است. بسته کردن هر تماس LLM به عنوان یک فعالیت به شما اجازه می دهد که با بازپرداخت نمایی، چکپوائنت کردن در سراسر بازپرداخت، و یک ردیابی قابل بازی برای دیبگینگ دوباره تلاش کنید.
نقاط بازرسی که توسط thread_id
LangGraph، Microsoft Agent Framework، Cloudflare Durable Objects و Claude Code روتین ها همه بر روی شکل API یکسان جمع شده اند:thread_id(یا معادل) جلسه را شناسایی می کند؛ هر انتقال حالت به یک پس زمینه باقی می ماند (پستگرسکول پیش فرض، SQLite برای dev، Redis برای کیش) ؛ ادامه خواندن آخرین نقطه چک.
انتخاب پس از پایان مهم است:
- PostgreSQL: دوامدار، قابل جستجو، از زمان استفاده زنده می ماند.
- SQLite: فقط از طریق محلی؛ داده ها را در میان میزبان ها از دست می دهد.
- Redis: سریع اما کوتاه مدت مگر اینکه AOF/سرموده پیکربندی شده باشد.
- Cloudflare Durable Objects: به صورت شفاف توزیع شده؛ با یک کلید منحصر به فرد به اندازه گیری شده؛ ساعت ها تا هفته ها زنده می ماند.
ورود انسان به عنوان یک کشور درجه اول
پیشنهاد پس از تعهد (درسی 15) نیاز به یک وضعیت پایدار "انتظار انسان" دارد. جریان کار توقف می کند، صف خارجی درخواست منتظر را نگه می دارد و تأیید دقیقا از آن نقطه شروع می شود. بدون دوام این بهترین تلاش است؛ با آن، یک تایید یک شبه می رسد و جریان کار در صبح شروع می شود.
35 دقیقه تخریب
METR مشاهده کرد که هر کلاس عامل اندازه گیری شده نشان می دهد قابلیت اطمینان از 35 دقیقه کار مداوم فراتر می رود. دو برابر کردن مدت زمان کار تقریباً چهار برابر کردن میزان شکست است. اجرای پایدار این مشکل را حل نمی کند؛ این به شما اجازه می دهد تا بیشتر از مشخصات قابلیت اطمینان پشتیبانی کنید. الگوی امن این است که دوام با نقاط بازرسی که در ورود مجدد HITL تازه را نیاز دارند و با سوئیچ های بکوژ بودجه (درسی 13) که بدون توجه به زمان ساعت دیوار، محاسبه کل را محدود می کنند، ترکیب شود.
وقتی اجرای طولانی مدت جواب اشتباه است
- بدون کمک انسانی کمتر از چند دقیقه طول می کشد.
- فقط اطلاعات قابل خواندن
- وظایف که در آن درستی نیاز به پایان به پایان در یک پنجره زمینه (بعضی از وظایف استدلال؛ برخی از نسل یک شات) دارد.
ازش استفاده کن
code/main.pyیک موتور اجرا با دوام حداقل را در stdlib Python پیاده سازی می کند. پشتیبانی از:
@activityدکوراتور که ورودی و خروجی را به یک دفترچه رویداد JSON ثبت می کند.- یک تابع جریان کار که فعالیت ها را ترتیب می دهد.
- A
run_or_replay(workflow, event_log)عملکردی که فعالیت های انجام شده را بدون اجرای مجدد تکرار می کند.
راننده یک جریان کار سه فعالیت را شبیه سازی می کند، در نیمه راه تصادف می کند و نشان می دهد (الف) یک تلاش ساده برای انجام مجدد همه چیز در مقابل (ب) یک بازی مجدد که فقط فعالیت گمشده را اجرا می کند.
-باده
outputs/skill-durable-execution-review.mdبررسی یک اجنتی طولانی مدت پیشنهادی برای شکل صحیح اجرای پایدار: فعالیت ها، تعیین گرایی، پس زمینه نقطه بازرسی، وضعیت ورودی انسانی و سیاست HITL در ادامه.
تمرینات
- فرار کن
code/main.py. تفاوت تعداد فعالیت ها و اجرای آنها را بین تکرار و تکرار ساده مشاهده کنید. نقطه تصادف را تغییر دهید و تعداد تکرار را به طور متناسب نشان دهید.
- موتور اسباب بازی رو برای استفاده تبدیل کن
thread_idبه طور صریح. دو جلسه همزمان با موتور را شبیه سازی کنید و تایید کنید که ثبت رویداد آنها در هم نمی افتد.
- یک فعالیت در موتور اسباب بازی را بگیرید. یک غیر تعیین کننده را معرفی کنید (مختر زمانی دیوار در داخل یک تصمیم جریان کار). تفاوت را در تکرار نشان دهید. توضیح دهید که موتورهای واقعی چگونه این کار را انجام می دهند (رجستریشن عوارض جانبی،
Workflow.now()API ها
- پست " زمان اجرا پشت عوامل عمیق تولید" لانگ چین را بخوانید. فهرست هر حالت که زمان اجرا ادامه دارد و نام اینکه هر حالت شکست را پوشش می دهد.
- یک سیاست چک پوند برای یک کار کد گذاری مستقل 6 ساعته طراحی کنید. شما چک پوند را کجا می سازید؟ ادامه کار در تصادف چگونه به نظر می رسد؟ چه چیزی نیاز به HITL تازه دارد؟
اصطلاحات کلیدی
| Term | What people say | What it actually means |
|---|---|---|
| Workflow | "Agent's script" | Deterministic orchestration code; replayable from event log |
| Activity | "A step" | Non-deterministic unit (LLM call, tool call); logged before and after |
| Event log | "The backing store" | Durable record of every state transition |
| Replay | "Resume" | Re-run workflow; completed activities return logged results without re-execution |
| Checkpoint | "Save point" | Persisted state keyed by thread_id; latest-wins on resume |
| thread_id | "Session key" | Identifier that scopes durable state |
| 35-minute degradation | "Reliability decay" | METR: success rate drops ~quadratically with horizon |
| Non-determinism | "Drift on replay" | Wall clock, random, LLM output; must be registered as side effect |
خواندن بیشتر
- Anthropic — Claude Code Agent SDK: agent loop بودجه، نوبت و بازخورد معنوی
- Microsoft — Agent Framework: human-in-the-loop and checkpointing شکل درخواست اطلاعات
- LangChain — The Runtime Behind Production Deep Agents الزامات عملیاتی مشخص
- OpenAI Agents SDK + Temporal integration (Trigger.dev announcement) شکل فعالیت برای تماس های LLM
- Anthropic — Measuring agent autonomy in practice ۳۵ دقیقه ای استناد تخریب
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.