Automation
وظایف پسزمینه
تسکهای پسزمینه کارهایی را رهگیری میکنند که خارج از نشست گفتوگوی اصلی شما اجرا میشوند: اجراهای ACP، ایجاد subagent، اجرای jobهای cron ایزوله، و عملیات آغازشده از CLI.
تسکها جایگزین نشستها، jobهای cron یا heartbeatها نمیشوند - آنها دفتر ثبت فعالیت هستند که ثبت میکند چه کار جداشدهای انجام شده، چه زمانی، و آیا موفق بوده است یا نه.
خلاصه سریع
- تسکها رکورد هستند، نه زمانبند - cron و heartbeat تعیین میکنند کار چه زمانی اجرا شود، تسکها رهگیری میکنند چه اتفاقی افتاده است.
- ACP، subagentها، همه jobهای cron، و عملیات CLI تسک ایجاد میکنند. نوبتهای Heartbeat این کار را نمیکنند.
- هر تسک از مسیر
queued → running → terminalعبور میکند (succeeded، failed، timed_out، cancelled، یا lost). - تسکهای cron تا زمانی زنده میمانند که runtime مربوط به cron هنوز مالک job باشد؛ اگر وضعیت runtime درونحافظهای از بین رفته باشد، نگهداری تسک پیش از علامتگذاری آن بهعنوان lost ابتدا تاریخچه پایدار اجرای cron را بررسی میکند.
- تکمیل بهصورت push-driven انجام میشود: کار جداشده میتواند مستقیما اطلاع دهد یا نشست/heartbeat درخواستکننده را هنگام پایان کار بیدار کند، بنابراین حلقههای polling وضعیت معمولا شکل درستی ندارند.
- اجراهای cron ایزوله و تکمیلهای subagent بهصورت best-effort تبها/فرایندهای مرورگر رهگیریشده را برای نشست فرزندشان پیش از حسابداری پاکسازی نهایی، پاکسازی میکنند.
- تحویل cron ایزوله پاسخهای موقت کهنه والد را تا زمانی که کار subagent فرزند هنوز در حال تخلیه است سرکوب میکند، و وقتی خروجی نهایی فرزند پیش از تحویل برسد، آن را ترجیح میدهد.
- اعلانهای تکمیل مستقیما به یک کانال تحویل داده میشوند یا برای heartbeat بعدی صف میشوند.
openclaw tasks listهمه تسکها را نشان میدهد؛openclaw tasks auditمشکلات را نمایش میدهد.- رکوردهای terminal بهمدت ۷ روز نگه داشته میشوند و سپس خودکار پاک میشوند.
شروع سریع
فهرست و فیلتر
# List all tasks (newest first)openclaw tasks list # Filter by runtime or statusopenclaw tasks list --runtime acpopenclaw tasks list --status runningبازرسی
# Show details for a specific task (by ID, run ID, or session key)openclaw tasks show <lookup>لغو و اعلان
# Cancel a running task (kills the child session)openclaw tasks cancel <lookup> # Change notification policy for a taskopenclaw tasks notify <lookup> state_changesممیزی و نگهداری
# Run a health auditopenclaw tasks audit # Preview or apply maintenanceopenclaw tasks maintenanceopenclaw tasks maintenance --applyجریان تسک
# Inspect TaskFlow stateopenclaw tasks flow listopenclaw tasks flow show <lookup>openclaw tasks flow cancel <lookup>چه چیزی یک تسک ایجاد میکند
| منبع | نوع runtime | زمانی که رکورد تسک ایجاد میشود | سیاست اعلان پیشفرض |
|---|---|---|---|
| اجراهای پسزمینه ACP | acp |
ایجاد یک نشست فرزند ACP | done_only |
| هماهنگسازی subagent | subagent |
ایجاد یک subagent از طریق sessions_spawn |
done_only |
| jobهای cron (همه انواع) | cron |
هر اجرای cron (نشست اصلی و ایزوله) | silent |
| عملیات CLI | cli |
فرمانهای openclaw agent که از طریق Gateway اجرا میشوند |
silent |
| jobهای رسانه عامل | cli |
اجراهای مبتنی بر نشست music_generate/video_generate |
silent |
پیشفرضهای اعلان برای cron و رسانه
تسکهای cron نشست اصلی بهصورت پیشفرض از سیاست اعلان silent استفاده میکنند - آنها برای رهگیری رکورد ایجاد میکنند اما اعلان تولید نمیکنند. تسکهای cron ایزوله نیز بهصورت پیشفرض silent هستند، اما چون در نشست خودشان اجرا میشوند، نمایانترند.
اجراهای مبتنی بر نشست music_generate و video_generate نیز از سیاست اعلان silent استفاده میکنند. آنها همچنان رکوردهای تسک ایجاد میکنند، اما تکمیل بهصورت یک بیدارسازی داخلی به نشست عامل اصلی برگردانده میشود تا عامل بتواند پیام پیگیری را بنویسد و رسانه تکمیلشده را خودش پیوست کند. تکمیلهای گروه/کانال از سیاست عادی پاسخ قابلمشاهده پیروی میکنند، بنابراین عامل وقتی تحویل منبع به آن نیاز داشته باشد، از ابزار پیام استفاده میکند. اگر عامل تکمیل نتواند در یک مسیر tool-only شواهد تحویل با ابزار پیام تولید کند، OpenClaw بهجای خصوصی گذاشتن رسانه، fallback تکمیل را مستقیما به کانال اصلی میفرستد.
حفاظت در برابر video_generate همزمان
تا زمانی که یک تسک مبتنی بر نشست video_generate هنوز فعال است، این ابزار همچنین نقش محافظ را دارد: فراخوانیهای تکراری video_generate در همان نشست، بهجای شروع تولید همزمان دوم، وضعیت تسک فعال را برمیگردانند. وقتی از سمت عامل به بررسی صریح پیشرفت/وضعیت نیاز دارید، از action: "status" استفاده کنید.
چه چیزهایی تسک ایجاد نمیکنند
- نوبتهای Heartbeat - نشست اصلی؛ Heartbeat را ببینید
- نوبتهای چت تعاملی عادی
- پاسخهای مستقیم
/command
چرخه عمر تسک
stateDiagram-v2
[*] --> queued
queued --> running : agent starts
running --> succeeded : completes ok
running --> failed : error
running --> timed_out : timeout exceeded
running --> cancelled : operator cancels
queued --> lost : session gone > 5 min
running --> lost : session gone > 5 min| وضعیت | معنی آن |
|---|---|
queued |
ایجاد شده و منتظر شروع عامل است |
running |
نوبت عامل بهطور فعال در حال اجراست |
succeeded |
با موفقیت تکمیل شده است |
failed |
با خطا تکمیل شده است |
timed_out |
از timeout پیکربندیشده فراتر رفته است |
cancelled |
توسط اپراتور از طریق openclaw tasks cancel متوقف شده است |
lost |
runtime پس از دوره مهلت ۵ دقیقهای، وضعیت پشتیبان مقتدر را از دست داده است |
انتقالها خودکار رخ میدهند - وقتی اجرای عامل مرتبط پایان مییابد، وضعیت تسک برای مطابقت با آن بهروزرسانی میشود.
تکمیل اجرای عامل برای رکوردهای تسک فعال مرجع معتبر است. یک اجرای جداشده موفق بهصورت succeeded نهایی میشود، خطاهای عادی اجرا بهصورت failed نهایی میشوند، و پیامدهای timeout یا abort بهصورت timed_out نهایی میشوند. اگر اپراتور قبلا تسک را لغو کرده باشد، یا runtime از قبل وضعیت terminal قویتری مانند failed، timed_out، یا lost ثبت کرده باشد، سیگنال موفقیت بعدی آن وضعیت terminal را تنزل نمیدهد.
lost نسبت به runtime آگاه است:
- تسکهای ACP: فراداده نشست فرزند ACP پشتیبان ناپدید شده است.
- تسکهای subagent: نشست فرزند پشتیبان از store عامل هدف ناپدید شده است.
- تسکهای cron: runtime مربوط به cron دیگر job را بهعنوان فعال رهگیری نمیکند و تاریخچه پایدار اجرای cron نتیجه terminal برای آن اجرا نشان نمیدهد. ممیزی CLI آفلاین وضعیت خالی runtime مربوط به cron درونفرایندی خودش را مرجع معتبر در نظر نمیگیرد.
- تسکهای CLI: تسکهایی که run id/source id دارند از زمینه اجرای زنده استفاده میکنند، بنابراین
ردیفهای باقیمانده نشست فرزند یا نشست چت پس از ناپدید شدن اجرای متعلق به Gateway آنها را زنده نگه نمیدارند. تسکهای CLI قدیمی بدون هویت اجرا همچنان به نشست فرزند fallback میکنند. اجراهای
openclaw agentمبتنی بر Gateway نیز از نتیجه اجرای خودشان نهایی میشوند، بنابراین اجراهای تکمیلشده تا زمانی که sweeper آنها راlostعلامتگذاری کند فعال نمیمانند.
تحویل و اعلانها
وقتی یک تسک به وضعیت terminal میرسد، OpenClaw به شما اطلاع میدهد. دو مسیر تحویل وجود دارد:
تحویل مستقیم - اگر تسک هدف کانال داشته باشد (requesterOrigin)، پیام تکمیل مستقیما به همان کانال میرود (Telegram، Discord، Slack، و غیره). تکمیلهای تسک گروه و کانال در عوض از طریق نشست درخواستکننده مسیریابی میشوند تا عامل والد بتواند پاسخ قابلمشاهده را بنویسد. برای تکمیلهای subagent، OpenClaw همچنین در صورت موجود بودن مسیریابی thread/topic متصل را حفظ میکند و پیش از منصرف شدن از تحویل مستقیم، میتواند to / account گمشده را از مسیر ذخیرهشده نشست درخواستکننده (lastChannel / lastTo / lastAccountId) پر کند.
تحویل صفشده در نشست - اگر تحویل مستقیم شکست بخورد یا هیچ origin تنظیم نشده باشد، بهروزرسانی بهعنوان یک رویداد سیستمی در نشست درخواستکننده صف میشود و در heartbeat بعدی ظاهر میشود.
یعنی workflow معمول push-based است: کار جداشده را یک بار شروع کنید، سپس بگذارید runtime هنگام تکمیل شما را بیدار کند یا اطلاع دهد. وضعیت تسک را فقط زمانی poll کنید که به اشکالزدایی، مداخله، یا ممیزی صریح نیاز دارید.
سیاستهای اعلان
کنترل کنید درباره هر تسک چقدر میشنوید:
| سیاست | آنچه تحویل داده میشود |
|---|---|
done_only (پیشفرض) |
فقط وضعیت terminal (succeeded، failed، و غیره) - این پیشفرض است |
state_changes |
هر انتقال وضعیت و بهروزرسانی پیشرفت |
silent |
هیچ چیز |
سیاست را هنگام اجرای تسک تغییر دهید:
openclaw tasks notify <lookup> state_changesمرجع CLI
tasks list
openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]ستونهای خروجی: شناسه تسک، نوع، وضعیت، تحویل، شناسه اجرا، نشست فرزند، خلاصه.
tasks show
openclaw tasks show <lookup>توکن lookup یک شناسه تسک، شناسه اجرا، یا کلید نشست را میپذیرد. رکورد کامل شامل زمانبندی، وضعیت تحویل، خطا، و خلاصه terminal را نشان میدهد.
tasks cancel
openclaw tasks cancel <lookup>برای تسکهای ACP و subagent، این کار نشست فرزند را میکشد. برای تسکهای رهگیریشده توسط CLI، لغو در رجیستری تسک ثبت میشود (هیچ هندل runtime فرزند جداگانهای وجود ندارد). وضعیت به cancelled منتقل میشود و در صورت کاربرد، اعلان تحویل فرستاده میشود.
tasks notify
openclaw tasks notify <lookup> <done_only|state_changes|silent>tasks audit
openclaw tasks audit [--json]مشکلات عملیاتی را نمایش میدهد. وقتی مشکل شناسایی شود، یافتهها در openclaw status نیز ظاهر میشوند.
| یافته | شدت | محرک |
|---|---|---|
stale_queued |
هشدار | بیش از ۱۰ دقیقه در صف مانده است |
stale_running |
خطا | بیش از ۳۰ دقیقه در حال اجرا بوده است |
lost |
هشدار/خطا | مالکیت وظیفه متکی بر runtime ناپدید شده است؛ وظایف گمشده نگهداریشده تا cleanupAfter هشدار میدهند، سپس به خطا تبدیل میشوند |
delivery_failed |
هشدار | تحویل ناموفق بود و سیاست اعلان silent نیست |
missing_cleanup |
هشدار | وظیفه پایانی بدون زمانمهر پاکسازی |
inconsistent_timestamps |
هشدار | نقض خط زمانی (برای مثال، پیش از شروع پایان یافته است) |
نگهداری وظایف
openclaw tasks maintenance [--json]openclaw tasks maintenance --apply [--json]از این برای پیشنمایش یا اعمال همگامسازی، ثبت زمانمهر پاکسازی، و هرس کردن وظایف، وضعیت Task Flow، و ردیفهای قدیمی رجیستری نشست اجرای cron استفاده کنید.
همگامسازی نسبت به runtime آگاه است:
- وظایف ACP/subagent نشست فرزند پشتیبان خود را بررسی میکنند.
- وظایف subagent که نشست فرزندشان یک سنگقبر بازیابی پس از راهاندازی مجدد دارد، بهجای اینکه نشستهای پشتیبان قابلبازیابی تلقی شوند، گمشده علامتگذاری میشوند.
- وظایف Cron بررسی میکنند که آیا runtime کرون هنوز مالک job است یا نه، سپس پیش از fallback به
lost، وضعیت پایانی را از لاگهای اجرای کرون/وضعیت job پایدارشده بازیابی میکنند. فقط فرایند Gateway برای مجموعه active-job درونحافظهای کرون مرجع معتبر است؛ ممیزی آفلاین CLI از تاریخچه پایدار استفاده میکند، اما یک وظیفه کرون را صرفا بهدلیل خالی بودن آن Set محلی، گمشده علامتگذاری نمیکند. - وظایف CLI دارای هویت اجرا، کانتکست اجرای زنده مالک را بررسی میکنند، نه فقط ردیفهای child-session یا chat-session را.
پاکسازی تکمیل نیز نسبت به runtime آگاه است:
- تکمیل subagent پیش از ادامه پاکسازی اعلان، بهصورت best-effort تبهای مرورگر/فرایندهای رهگیریشده برای نشست فرزند را میبندد.
- تکمیل cron ایزوله پیش از اینکه اجرا کاملا از بین برود، بهصورت best-effort تبهای مرورگر/فرایندهای رهگیریشده برای نشست کرون را میبندد.
- تحویل cron ایزوله در صورت نیاز منتظر پیگیری subagent نواده میماند و بهجای اعلام متن تأیید والد قدیمی، آن را سرکوب میکند.
- تحویل تکمیل subagent آخرین متن قابلمشاهده دستیار را ترجیح میدهد؛ اگر خالی باشد، به آخرین متن پاکسازیشده tool/toolResult fallback میکند، و اجراهای tool-call فقط مبتنی بر timeout میتوانند به یک خلاصه کوتاه از پیشرفت جزئی فشرده شوند. اجراهای پایانی ناموفق بدون بازپخش متن پاسخ ضبطشده، وضعیت شکست را اعلام میکنند.
- شکستهای پاکسازی نتیجه واقعی وظیفه را پنهان نمیکنند.
هنگام اعمال نگهداری، OpenClaw همچنین ردیفهای قدیمی رجیستری نشست cron:<jobId>:run:<uuid> را که قدیمیتر از ۷ روز هستند حذف میکند، در حالی که ردیفهای مربوط به jobهای cron در حال اجرا را حفظ میکند و ردیفهای نشست غیرکرون را دستنخورده باقی میگذارد.
فهرست | نمایش | لغو جریان وظایف
openclaw tasks flow list [--status <status>] [--json]openclaw tasks flow show <lookup> [--json]openclaw tasks flow cancel <lookup>زمانی از اینها استفاده کنید که Task Flow هماهنگکننده برای شما مهم است، نه یک رکورد منفرد از وظیفه پسزمینه.
تابلوی وظایف چت (/tasks)
در هر نشست چت از /tasks استفاده کنید تا وظایف پسزمینه مرتبط با آن نشست را ببینید. تابلو وظایف فعال و اخیرا تکمیلشده را همراه با runtime، وضعیت، زمانبندی، و جزئیات پیشرفت یا خطا نشان میدهد.
وقتی نشست فعلی هیچ وظیفه مرتبط قابلمشاهدهای نداشته باشد، /tasks به شمارش وظایف محلی agent برمیگردد تا همچنان بدون افشای جزئیات نشستهای دیگر یک نمای کلی دریافت کنید.
برای دفترکل کامل اپراتور، از CLI استفاده کنید: openclaw tasks list.
یکپارچهسازی وضعیت (فشار وظیفه)
openclaw status یک خلاصه سریع از وظایف را شامل میشود:
Tasks: 3 queued · 2 running · 1 issuesخلاصه گزارش میدهد:
- فعال - تعداد
queued+running - شکستها - تعداد
failed+timed_out+lost - بر اساس runtime - تفکیک بر اساس
acp،subagent،cron،cli
هم /status و هم ابزار session_status از snapshot وظایف آگاه به پاکسازی استفاده میکنند: وظایف فعال ترجیح داده میشوند، ردیفهای تکمیلشده قدیمی پنهان میشوند، و شکستهای اخیر فقط زمانی نمایش داده میشوند که هیچ کار فعالی باقی نمانده باشد. این کار کارت وضعیت را روی آنچه همین حالا مهم است متمرکز نگه میدارد.
ذخیرهسازی و نگهداری
محل نگهداری وظایف
رکوردهای وظیفه در SQLite در این مسیر پایدار میشوند:
$OPENCLAW_STATE_DIR/tasks/runs.sqliteرجیستری هنگام شروع gateway در حافظه بارگذاری میشود و برای دوام در برابر راهاندازیهای مجدد، نوشتنها را با SQLite همگام میکند.
Gateway لاگ write-ahead مربوط به SQLite را با استفاده از آستانه autocheckpoint پیشفرض SQLite
بههمراه checkpointهای دورهای و هنگام خاموشی از نوع TRUNCATE محدود نگه میدارد.
نگهداری خودکار
یک sweeper هر ۶۰ ثانیه اجرا میشود و چهار کار را انجام میدهد:
همگامسازی
بررسی میکند که آیا وظایف فعال هنوز پشتیبان معتبر runtime دارند یا نه. وظایف ACP/subagent از وضعیت child-session استفاده میکنند، وظایف cron از مالکیت active-job استفاده میکنند، و وظایف CLI دارای هویت اجرا از کانتکست اجرای مالک استفاده میکنند. اگر آن وضعیت پشتیبان بیش از ۵ دقیقه از بین رفته باشد، وظیفه lost علامتگذاری میشود.
ترمیم نشست ACP
نشستهای ACP یکباره پایانی یا یتیم و متعلق به والد را میبندد، و نشستهای ACP پایدار پایانی یا یتیم و قدیمی را فقط زمانی میبندد که هیچ binding مکالمه فعالی باقی نمانده باشد.
ثبت زمانمهر پاکسازی
روی وظایف پایانی یک زمانمهر cleanupAfter تنظیم میکند (endedAt + ۷ روز). در طول دوره نگهداری، وظایف گمشده همچنان در ممیزی بهصورت هشدار ظاهر میشوند؛ پس از انقضای cleanupAfter یا وقتی metadata پاکسازی وجود نداشته باشد، خطا هستند.
هرس کردن
رکوردهایی را که از تاریخ cleanupAfter خود گذشتهاند حذف میکند.
ارتباط وظایف با سیستمهای دیگر
وظایف و Task Flow
Task Flow لایه هماهنگسازی جریان بالای وظایف پسزمینه است. یک flow منفرد میتواند در طول عمر خود با استفاده از حالتهای همگامسازی مدیریتشده یا آینهای، چند وظیفه را هماهنگ کند. برای بررسی رکوردهای وظیفه منفرد از openclaw tasks و برای بررسی flow هماهنگکننده از openclaw tasks flow استفاده کنید.
برای جزئیات، Task Flow را ببینید.
وظایف و cron
یک تعریف job کرون در ~/.openclaw/cron/jobs.json قرار دارد؛ وضعیت اجرای runtime در کنار آن در ~/.openclaw/cron/jobs-state.json قرار دارد. هر اجرای cron یک رکورد وظیفه ایجاد میکند، چه main-session باشد و چه ایزوله. وظایف cron در main-session بهطور پیشفرض از سیاست اعلان silent استفاده میکنند تا بدون ایجاد اعلان رهگیری شوند.
Cron Jobs را ببینید.
وظایف و heartbeat
اجراهای Heartbeat نوبتهای main-session هستند؛ آنها رکورد وظیفه ایجاد نمیکنند. وقتی یک وظیفه تکمیل میشود، میتواند یک بیدارباش heartbeat را تحریک کند تا نتیجه را سریع ببینید.
Heartbeat را ببینید.
وظایف و نشستها
یک وظیفه ممکن است به یک childSessionKey (جایی که کار اجرا میشود) و یک requesterSessionKey (کسی که آن را شروع کرده است) ارجاع دهد. نشستها کانتکست مکالمه هستند؛ وظایف رهگیری فعالیت روی آن هستند.
وظایف و اجراهای agent
runId یک وظیفه به اجرای agent که کار را انجام میدهد پیوند میخورد. رویدادهای چرخه عمر agent (شروع، پایان، خطا) بهطور خودکار وضعیت وظیفه را بهروزرسانی میکنند؛ لازم نیست چرخه عمر را دستی مدیریت کنید.
مرتبط
- اتوماسیون - همه سازوکارهای اتوماسیون در یک نگاه
- CLI: وظایف - مرجع فرمان CLI
- Heartbeat - نوبتهای دورهای main-session
- وظایف زمانبندیشده - زمانبندی کار پسزمینه
- Task Flow - هماهنگسازی flow بالای وظایف