کارهای زمان‌بندی‌شده

Cron زمان‌بند داخلی Gateway است. کارها را پایدار می‌کند، عامل را در زمان درست بیدار می‌کند، و می‌تواند خروجی را به یک کانال چت یا نقطه پایانی Webhook برساند.

شروع سریع

openclaw cron create "2026-02-01T16:00:00Z" \  --name "Reminder" \  --session main \  --system-event "Reminder: check the cron docs draft" \  --wake now \  --delete-after-run

openclaw cron listopenclaw cron get <job-id>openclaw cron show <job-id>

openclaw cron runs --id <job-id>

نحوه کار Cron

• Cron داخل فرایند Gateway اجرا می‌شود (نه داخل مدل).
• تعریف‌های کار، وضعیت زمان اجرا، و تاریخچه اجرا در پایگاه داده وضعیت SQLite مشترک OpenClaw پایدار می‌مانند تا راه‌اندازی‌های مجدد باعث از دست رفتن زمان‌بندی‌ها نشوند.
• هنگام ارتقا، openclaw doctor --fix را اجرا کنید تا فایل‌های قدیمی ~/.openclaw/cron/jobs.json، jobs-state.json، و runs/*.jsonl به SQLite وارد شوند و با پسوند .migrated تغییر نام پیدا کنند. ردیف‌های بدشکل کار از زمان اجرا رد می‌شوند و برای تعمیر یا بررسی بعدی در jobs-quarantine.json کپی می‌شوند.
• cron.store همچنان کلید منطقی فروشگاه Cron و مسیر واردسازی doctor را نام‌گذاری می‌کند. پس از واردسازی، ویرایش آن فایل JSON دیگر کارهای فعال Cron را تغییر نمی‌دهد؛ به‌جای آن از openclaw cron add|edit|remove یا متدهای RPC مربوط به Cron در Gateway استفاده کنید.
• همه اجراهای Cron رکوردهای کار پس‌زمینه ایجاد می‌کنند.
• هنگام شروع Gateway، کارهای عقب‌افتاده گردش عامل ایزوله به‌جای بازپخش فوری، بیرون از پنجره اتصال کانال دوباره زمان‌بندی می‌شوند تا راه‌اندازی Discord/Telegram و تنظیم فرمان‌های بومی پس از راه‌اندازی مجدد پاسخ‌گو بمانند.
• کارهای یک‌باره (--at) به‌طور پیش‌فرض پس از موفقیت خودکار حذف می‌شوند.
• اجراهای ایزوله Cron پس از تکمیل اجرا، با بهترین تلاش زبانه‌ها/فرایندهای مرورگر ردیابی‌شده را برای نشست cron:<jobId> خود می‌بندند، تا خودکارسازی مرورگر جداشده فرایندهای بی‌صاحب باقی نگذارد.
• اجراهای ایزوله Cron که مجوز محدود خودپاک‌سازی Cron را دریافت می‌کنند همچنان می‌توانند وضعیت زمان‌بند، فهرست خودفیلترشده‌ای از کار فعلی خود، و تاریخچه اجرای همان کار را بخوانند، بنابراین بررسی‌های وضعیت/Heartbeat می‌توانند بدون دسترسی گسترده‌تر به تغییر Cron، زمان‌بندی خودشان را بررسی کنند.
• اجراهای ایزوله Cron همچنین در برابر پاسخ‌های تأیید قدیمی محافظت می‌کنند. اگر نتیجه نخست فقط یک به‌روزرسانی وضعیت موقت باشد (on it، pulling everything together، و نشانه‌های مشابه) و هیچ اجرای فرزند subagent همچنان مسئول پاسخ نهایی نباشد، OpenClaw پیش از تحویل یک بار دیگر برای نتیجه واقعی prompt می‌دهد.
• اجراهای ایزوله Cron از فراداده ساختاریافته رد اجرا از اجرای جاسازی‌شده استفاده می‌کنند، از جمله پوشش‌های node-host با UNAVAILABLE که پیام خطای تودرتویشان با SYSTEM_RUN_DENIED یا INVALID_REQUEST شروع می‌شود، تا یک فرمان مسدودشده به‌عنوان اجرای سبز گزارش نشود، در حالی که نثر عادی دستیار به‌عنوان رد اجرا تلقی نشود.
• اجراهای ایزوله Cron همچنین شکست‌های عامل در سطح اجرا را حتی وقتی هیچ payload پاسخی تولید نشده باشد خطای کار در نظر می‌گیرند، بنابراین شکست‌های مدل/ارائه‌دهنده شمارنده‌های خطا را افزایش می‌دهند و اعلان‌های شکست را فعال می‌کنند، به‌جای اینکه کار را موفق پاک کنند.
• وقتی یک کار گردش عامل ایزوله به timeoutSeconds می‌رسد، Cron اجرای عامل زیربنایی را لغو می‌کند و یک پنجره کوتاه پاک‌سازی به آن می‌دهد. اگر اجرا تخلیه نشود، پاک‌سازی تحت مالکیت Gateway پیش از اینکه Cron وقفه زمانی را ثبت کند، مالکیت نشست آن اجرا را به‌اجبار پاک می‌کند، تا کار چت صف‌شده پشت یک نشست پردازشی قدیمی جا نماند.
• اگر یک گردش عامل ایزوله پیش از شروع runner یا پیش از نخستین فراخوانی مدل متوقف شود، Cron یک وقفه زمانی مخصوص فاز مانند setup timed out before runner start یا stalled before first model call (last phase: context-engine) ثبت می‌کند. این watchdogها ارائه‌دهندگان جاسازی‌شده و ارائه‌دهندگان مبتنی بر CLI را پیش از اینکه فرایند CLI خارجی آن‌ها واقعاً شروع شود پوشش می‌دهند، و مستقل از مقادیر طولانی timeoutSeconds سقف‌گذاری می‌شوند تا شکست‌های cold-start/auth/context به‌جای انتظار برای کل بودجه کار، سریع آشکار شوند.
• اگر از system cron یا زمان‌بند خارجی دیگری برای اجرای openclaw agent استفاده می‌کنید، آن را با تشدید hard-kill بپیچید، حتی با اینکه CLI، SIGTERM/SIGINT را مدیریت می‌کند. اجراهای مبتنی بر Gateway از Gateway می‌خواهند اجراهای پذیرفته‌شده را لغو کند؛ اجراهای محلی و fallback جاسازی‌شده همان سیگنال لغو را دریافت می‌کنند. برای GNU timeout، timeout -k 60 600 openclaw agent ... را به timeout 600 ... ساده ترجیح دهید؛ مقدار -k پشتیبان supervisor است اگر فرایند نتواند تخلیه شود. برای واحدهای systemd، همین شکل را با استفاده از سیگنال توقف SIGTERM همراه با یک پنجره مهلت مانند TimeoutStopSec پیش از هر kill نهایی حفظ کنید. اگر یک تلاش مجدد از --run-id استفاده کند در حالی که اجرای اصلی Gateway هنوز فعال است، نسخه تکراری به‌جای شروع اجرای دوم، درحال‌اجرا گزارش می‌شود.

انواع زمان‌بندی

مهرهای زمانی بدون منطقه زمانی به‌عنوان UTC در نظر گرفته می‌شوند. برای زمان‌بندی بر اساس ساعت محلی، --tz America/New_York را اضافه کنید.

عبارت‌های تکرارشونده ابتدای ساعت به‌طور خودکار تا ۵ دقیقه پخش می‌شوند تا جهش‌های بار کاهش یابد. برای اجبار زمان‌بندی دقیق از --exact یا برای یک پنجره صریح از --stagger 30s استفاده کنید.

روز ماه و روز هفته از منطق OR استفاده می‌کنند

عبارت‌های Cron توسط croner تحلیل می‌شوند. وقتی هر دو فیلد روز ماه و روز هفته غیر wildcard باشند، croner زمانی تطبیق می‌دهد که هرکدام از فیلدها تطبیق داشته باشد، نه هر دو. این رفتار استاندارد Vixie cron است.

# Intended: "9 AM on the 15th, only if it's a Monday"# Actual:   "9 AM on every 15th, AND 9 AM on every Monday"0 9 15 * 1

این به‌جای ۰ تا ۱ بار در ماه، حدود ۵ تا ۶ بار در ماه اجرا می‌شود. OpenClaw در اینجا از رفتار پیش‌فرض OR در Croner استفاده می‌کند. برای الزام هر دو شرط، از modifier روز هفته + در Croner (0 9 15 * +1) استفاده کنید، یا زمان‌بندی را روی یک فیلد انجام دهید و فیلد دیگر را در prompt یا فرمان کار خود guard کنید.

سبک‌های اجرا

payloadهای فرمان

از payloadهای فرمان برای اسکریپت‌های قطعی استفاده کنید که باید داخل زمان‌بند Gateway بدون شروع یک گردش عامل ایزوله مبتنی بر مدل اجرا شوند. کارهای فرمان روی میزبان Gateway اجرا می‌شوند، stdout/stderr را capture می‌کنند، اجرا را در تاریخچه Cron ثبت می‌کنند، و همان حالت‌های تحویل announce، webhook، و none را مانند کارهای ایزوله دوباره استفاده می‌کنند.

openclaw cron create "*/15 * * * *" \  --name "Queue depth probe" \  --command "scripts/check-queue.sh" \  --command-cwd "/srv/app" \  --announce \  --channel telegram \  --to "-1001234567890"

--command <shell> مقدار argv: ["sh", "-lc", <shell>] را ذخیره می‌کند. وقتی اجرای دقیق argv را بدون تحلیل shell می‌خواهید، از --command-argv '["node","scripts/report.mjs"]' استفاده کنید. فیلدهای اختیاری --command-env KEY=VALUE، --command-input، --timeout-seconds، --no-output-timeout-seconds، و --output-max-bytes محیط فرایند، stdin، و حدود خروجی را کنترل می‌کنند.

اگر stdout خالی نباشد، همان متن نتیجهٔ تحویل‌شده است. اگر stdout خالی باشد و stderr خالی نباشد، stderr تحویل داده می‌شود. اگر هر دو جریان وجود داشته باشند، Cron یک بلوک کوچک stdout: / stderr: تحویل می‌دهد. کد خروج صفر، اجرا را به‌صورت ok ثبت می‌کند؛ خروج غیرصفر، سیگنال، وقفهٔ زمانی، یا وقفهٔ زمانیِ بدون خروجی، error ثبت می‌کند و می‌تواند هشدارهای شکست را فعال کند. فرمانی که فقط NO_REPLY چاپ کند، از سرکوب عادی توکنِ بی‌صدای Cron استفاده می‌کند و چیزی به چت ارسال نمی‌کند.

گزینه‌های بار برای کارهای ایزوله

--model از مدل مجاز انتخاب‌شده به‌عنوان مدل اصلی همان کار استفاده می‌کند. این با بازنویسی /model در نشست چت یکسان نیست: زنجیره‌های پشتیبان پیکربندی‌شده همچنان وقتی مدل اصلی کار شکست بخورد اعمال می‌شوند. اگر مدل درخواست‌شده مجاز نباشد یا قابل حل نباشد، Cron به‌جای بازگشت بی‌صدای مدل انتخابی عامل/پیش‌فرضِ کار، اجرا را با خطای اعتبارسنجی صریح شکست می‌دهد.

کارهای Cron همچنین می‌توانند fallbacks در سطح بار داشته باشند. وقتی وجود داشته باشد، آن فهرست زنجیرهٔ پشتیبان پیکربندی‌شده برای کار را جایگزین می‌کند. وقتی اجرای Cron سخت‌گیرانه‌ای می‌خواهید که فقط مدل انتخاب‌شده را امتحان کند، در بار کار/API از fallbacks: [] استفاده کنید. اگر کاری --model داشته باشد اما نه پشتیبانِ بار و نه پشتیبانِ پیکربندی‌شده، OpenClaw یک بازنویسی پشتیبانِ خالیِ صریح پاس می‌دهد تا مدل اصلی عامل به‌عنوان هدف تلاش مجددِ اضافی و پنهان افزوده نشود.

بررسی‌های پیش‌پرواز ارائه‌دهندهٔ محلی پیش از علامت‌گذاری اجرای Cron به‌صورت skipped، پشتیبان‌های پیکربندی‌شده را پیمایش می‌کنند؛ fallbacks: [] آن مسیر پیش‌پرواز را سخت‌گیرانه نگه می‌دارد.

تقدم انتخاب مدل برای کارهای ایزوله چنین است:

1. بازنویسی مدل هوک Gmail، وقتی اجرا از Gmail آمده باشد و آن بازنویسی مجاز باشد
2. model در بار مخصوص کار
3. بازنویسی مدل نشست Cron ذخیره‌شدهٔ انتخاب‌شده توسط کاربر
4. انتخاب مدل عامل/پیش‌فرض

حالت سریع نیز از انتخاب زندهٔ حل‌شده پیروی می‌کند. اگر پیکربندی مدل انتخاب‌شده params.fastMode داشته باشد، Cron ایزوله به‌صورت پیش‌فرض از آن استفاده می‌کند. بازنویسی fastMode نشست ذخیره‌شده همچنان در هر دو جهت بر پیکربندی مقدم است. حالت خودکار، وقتی موجود باشد، از آستانهٔ params.fastAutoOnSeconds مدل انتخاب‌شده استفاده می‌کند و پیش‌فرض آن ۶۰ ثانیه است.

اگر اجرای ایزوله به واگذاریِ تغییر مدل زنده برسد، Cron با ارائه‌دهنده/مدل تغییریافته دوباره تلاش می‌کند و پیش از تلاش مجدد، آن انتخاب زنده را برای اجرای فعال پایدار می‌کند. وقتی تغییر، پروفایل احراز هویت جدیدی هم داشته باشد، Cron بازنویسی آن پروفایل احراز هویت را نیز برای اجرای فعال پایدار می‌کند. تلاش‌های مجدد محدود هستند: پس از تلاش اولیه به‌علاوهٔ ۲ تلاش مجدد تغییر، Cron به‌جای حلقهٔ بی‌پایان متوقف می‌شود.

پیش از آنکه اجرای Cron ایزوله وارد اجراکنندهٔ عامل شود، OpenClaw نقاط پایانی قابل دسترس ارائه‌دهندهٔ محلی را برای ارائه‌دهنده‌های پیکربندی‌شدهٔ api: "ollama" و api: "openai-completions" بررسی می‌کند که baseUrl آن‌ها loopback، شبکهٔ خصوصی، یا .local باشد. اگر آن نقطهٔ پایانی خاموش باشد، اجرا به‌جای شروع فراخوانی مدل، به‌صورت skipped همراه با خطای روشنِ ارائه‌دهنده/مدل ثبت می‌شود. نتیجهٔ نقطهٔ پایانی برای ۵ دقیقه کش می‌شود، بنابراین کارهای موعددارِ زیادی که از همان سرور محلیِ خاموشِ Ollama، vLLM، SGLang، یا LM Studio استفاده می‌کنند، به‌جای ایجاد طوفان درخواست، یک کاوش کوچک مشترک دارند. اجراهای ردشدهٔ پیش‌پرواز ارائه‌دهنده، پس‌روی خطای اجرا را افزایش نمی‌دهند؛ وقتی اعلان‌های ردشدن تکراری می‌خواهید، failureAlert.includeSkipped را فعال کنید.

تحویل و خروجی

برای تحویل کانال، از --announce --channel telegram --to "-1001234567890" استفاده کنید. برای موضوع‌های انجمن Telegram، از -1001234567890:topic:123 استفاده کنید؛ OpenClaw همچنین کوتاه‌نویسی متعلق به Telegram یعنی -1001234567890:123 را می‌پذیرد. فراخواننده‌های مستقیم RPC/پیکربندی می‌توانند delivery.threadId را به‌صورت رشته یا عدد پاس دهند. مقصدهای Slack/Discord/Mattermost باید از پیشوندهای صریح استفاده کنند (channel:<id>، user:<id>). شناسه‌های اتاق Matrix به بزرگی و کوچکی حروف حساس‌اند؛ از شناسهٔ دقیق اتاق یا قالب room:!room:server از Matrix استفاده کنید.

وقتی تحویل اعلام از channel: "last" استفاده می‌کند یا channel را حذف می‌کند، مقصدی با پیشوند ارائه‌دهنده مانند telegram:123 می‌تواند پیش از بازگشت Cron به تاریخچهٔ نشست یا یک کانال پیکربندی‌شده، کانال را انتخاب کند. فقط پیشوندهایی که Plugin بارگذاری‌شده اعلام کرده است انتخابگر ارائه‌دهنده هستند. اگر delivery.channel صریح باشد، پیشوند مقصد باید همان ارائه‌دهنده را نام ببرد؛ برای نمونه، channel: "whatsapp" همراه با to: "telegram:123" رد می‌شود، نه اینکه به WhatsApp اجازه داده شود شناسهٔ Telegram را به‌عنوان شماره تلفن تفسیر کند. پیشوندهای نوع مقصد و سرویس مانند channel:<id>، user:<id>، imessage:<handle>، و sms:<number> همچنان نحو مقصد متعلق به کانال هستند، نه انتخابگر ارائه‌دهنده.

برای کارهای ایزوله، تحویل چت مشترک است. اگر مسیر چت در دسترس باشد، عامل می‌تواند حتی وقتی کار از --no-deliver استفاده می‌کند، از ابزار message استفاده کند. اگر عامل به مقصد پیکربندی‌شده/فعلی ارسال کند، OpenClaw اعلام پشتیبان را رد می‌کند. در غیر این صورت announce، webhook، و none فقط کنترل می‌کنند اجراکننده پس از نوبت عامل با پاسخ نهایی چه کند.

وقتی عاملی از یک چت فعال یادآور ایزوله ایجاد می‌کند، OpenClaw مقصد تحویل زندهٔ حفظ‌شده را برای مسیر اعلام پشتیبان ذخیره می‌کند. کلیدهای نشست داخلی ممکن است حروف کوچک باشند؛ وقتی زمینهٔ چت فعلی در دسترس است، مقصدهای تحویل ارائه‌دهنده از آن کلیدها بازسازی نمی‌شوند.

تحویل اعلام ضمنی از فهرست‌های مجاز کانال پیکربندی‌شده برای اعتبارسنجی و مسیردهی دوبارهٔ مقصدهای کهنه استفاده می‌کند. تأییدهای انبار جفت‌سازی پیام مستقیم، گیرندگان اتوماسیون پشتیبان نیستند؛ وقتی یک کار زمان‌بندی‌شده باید فعالانه به یک پیام مستقیم ارسال کند، delivery.to را تنظیم کنید یا ورودی allowFrom کانال را پیکربندی کنید.

زبان خروجی

کارهای Cron زبان پاسخ را از کانال، محل، یا پیام‌های قبلی استنباط نمی‌کنند. قانون زبان را در پیام زمان‌بندی‌شده یا الگو بگذارید:

openclaw cron edit <jobId> \  --message "Summarize the updates. Respond in Chinese; keep URLs, code, and product names unchanged."

برای فایل‌های الگو، دستور زبان را در اعلان رندرشده نگه دارید و پیش از اجرای کار بررسی کنید جای‌نگهدارهایی مانند {{language}} پر شده باشند. اگر خروجی زبان‌ها را ترکیب می‌کند، قانون را صریح کنید، برای نمونه: "Use Chinese for narrative text and keep technical terms in English."

اعلان‌های شکست از مسیر مقصد جداگانه‌ای پیروی می‌کنند:

• cron.failureDestination یک پیش‌فرض جهانی برای اعلان‌های شکست تنظیم می‌کند.
• job.delivery.failureDestination آن را برای هر کار بازنویسی می‌کند.
• اگر هیچ‌کدام تنظیم نشده باشد و کار از پیش از طریق announce تحویل بدهد، اعلان‌های شکست اکنون به همان مقصد اعلام اصلی بازمی‌گردند.
• delivery.failureDestination فقط روی کارهای sessionTarget="isolated" پشتیبانی می‌شود، مگر اینکه حالت تحویل اصلی webhook باشد.
• failureAlert.includeSkipped: true یک کار یا سیاست هشدار Cron جهانی را وارد هشدارهای تکراریِ اجرای ردشده می‌کند. اجراهای ردشده شمارندهٔ ردشدن متوالی جداگانه‌ای دارند، بنابراین بر پس‌روی خطای اجرا اثر نمی‌گذارند.

نمونه‌های CLI

openclaw cron add \  --name "Calendar check" \  --at "20m" \  --session main \  --system-event "Next heartbeat: check calendar." \  --wake now

openclaw cron create "0 7 * * *" \  "Summarize overnight updates." \  --name "Morning brief" \  --tz "America/Los_Angeles" \  --session isolated \  --announce \  --channel slack \  --to "channel:C1234567890"

openclaw cron add \  --name "Deep analysis" \  --cron "0 6 * * 1" \  --tz "America/Los_Angeles" \  --session isolated \  --message "Weekly deep analysis of project progress." \  --model "opus" \  --thinking high \  --announce

openclaw cron create "0 18 * * 1-5" \  "Summarize today's deploys as JSON." \  --name "Deploy digest" \  --webhook "https://example.invalid/openclaw/cron"

openclaw cron create "*/15 * * * *" \  --name "Queue depth probe" \  --command "scripts/check-queue.sh" \  --command-cwd "/srv/app" \  --announce \  --channel telegram \  --to "-1001234567890"

Webhookها

Gateway می‌تواند نقاط پایانی HTTP Webhook را برای محرک‌های خارجی در معرض بگذارد. در پیکربندی فعال کنید:

{  hooks: {    enabled: true,    token: "shared-secret",    path: "/hooks",  },}

احراز هویت

هر درخواست باید توکن هوک را از طریق سرآیند شامل کند:

• Authorization: Bearer <token>؛ توصیه‌شده
• x-openclaw-token: <token>

توکن‌های رشتهٔ پرس‌وجو رد می‌شوند.

curl -X POST http://127.0.0.1:18789/hooks/wake \  -H 'Authorization: Bearer SECRET' \  -H 'Content-Type: application/json' \  -d '{"text":"New email received","mode":"now"}'

curl -X POST http://127.0.0.1:18789/hooks/agent \  -H 'Authorization: Bearer SECRET' \  -H 'Content-Type: application/json' \  -d '{"message":"Summarize inbox","name":"Email","model":"openai/gpt-5.4"}'

یکپارچه‌سازی Gmail PubSub

محرک‌های صندوق ورودی Gmail را از طریق Google PubSub به OpenClaw وصل کنید.

راه‌اندازی جادوگر (توصیه‌شده)

openclaw webhooks gmail setup --account openclaw@gmail.com

این پیکربندی hooks.gmail را می‌نویسد، پیش‌تنظیم Gmail را فعال می‌کند، و از Tailscale Funnel برای نقطه پایانی push استفاده می‌کند.

شروع خودکار Gateway

وقتی hooks.enabled=true باشد و hooks.gmail.account تنظیم شده باشد، Gateway هنگام راه‌اندازی gog gmail watch serve را شروع می‌کند و ناظر را به‌طور خودکار تمدید می‌کند. برای انصراف، OPENCLAW_SKIP_GMAIL_WATCHER=1 را تنظیم کنید.

راه‌اندازی دستی یک‌باره

gcloud auth logingcloud config set project <project-id>gcloud services enable gmail.googleapis.com pubsub.googleapis.com

gcloud pubsub topics create gog-gmail-watchgcloud pubsub topics add-iam-policy-binding gog-gmail-watch \  --member=serviceAccount:gmail-api-push@system.gserviceaccount.com \  --role=roles/pubsub.publisher

gog gmail watch start \  --account openclaw@gmail.com \  --label INBOX \  --topic projects/<project-id>/topics/gog-gmail-watch

بازنویسی مدل Gmail

{  hooks: {    gmail: {      model: "openrouter/meta-llama/llama-3.3-70b-instruct:free",      thinking: "off",    },  },}

مدیریت کارها

# List all jobsopenclaw cron list # Get one stored job as JSONopenclaw cron get <jobId> # Show one job, including resolved delivery routeopenclaw cron show <jobId> # Edit a jobopenclaw cron edit <jobId> --message "Updated prompt" --model "opus" # Force run a job nowopenclaw cron run <jobId> # Force run a job now and wait for its terminal statusopenclaw cron run <jobId> --wait --wait-timeout 10m --poll-interval 2s # Run only if dueopenclaw cron run <jobId> --due # View run historyopenclaw cron runs --id <jobId> --limit 50 # View one exact runopenclaw cron runs --id <jobId> --run-id <runId> # Delete a jobopenclaw cron remove <jobId> # Agent selection (multi-agent setups)openclaw cron create "0 6 * * *" "Check ops queue" --name "Ops sweep" --session isolated --agent opsopenclaw cron edit <jobId> --clear-agent

openclaw cron run <jobId> پس از صف‌کردن اجرای دستی برمی‌گردد. برای قلاب‌های خاموش‌سازی، اسکریپت‌های نگهداری، یا خودکارسازی دیگری که باید تا پایان اجرای صف‌شده مسدود بماند، از --wait استفاده کنید. حالت انتظار دقیقاً همان runId بازگشتی را نظرسنجی می‌کند؛ برای وضعیت ok با 0 خارج می‌شود و برای error، skipped، یا پایان مهلت انتظار با مقدار غیرصفر.

ابزار عامل cron خلاصه‌های فشرده کار (id، name، enabled، nextRunAtMs، scheduleKind، lastRunStatus) را از cron(action: "list") برمی‌گرداند؛ برای تعریف کامل یک کار از cron(action: "get", jobId: "...") استفاده کنید. فراخواننده‌های مستقیم Gateway می‌توانند compact: true را به cron.list بدهند؛ حذف آن پاسخ کامل موجود را با پیش‌نمایش‌های تحویل حفظ می‌کند.

openclaw cron create نام مستعار openclaw cron add است، و کارهای جدید می‌توانند از یک زمان‌بندی مکانی ("0 9 * * 1"، "every 1h"، "20m"، یا یک timestamp با ISO) و پس از آن یک پیام عامل مکانی استفاده کنند. روی cron add|create یا cron edit از --webhook <url> استفاده کنید تا محموله اجرای پایان‌یافته به یک نقطه پایانی HTTP با POST ارسال شود. تحویل Webhook را نمی‌توان با پرچم‌های تحویل چت مانند --announce، --channel، --to، --thread-id، یا --account ترکیب کرد. در cron edit، --clear-channel، --clear-to، --clear-thread-id، و --clear-account آن فیلدهای مسیریابی را به‌صورت جداگانه unset می‌کنند (هرکدام همراه با پرچم تنظیم متناظر خود رد می‌شود)، که با غیرفعال‌کردن تحویل fallback اجراکننده توسط --no-deliver تفاوت دارد.

پیکربندی

{  cron: {    enabled: true,    store: "~/.openclaw/cron/jobs.json",    maxConcurrentRuns: 8,    retry: {      maxAttempts: 3,      backoffMs: [60000, 120000, 300000],      retryOn: ["rate_limit", "overloaded", "network", "server_error"],    },    webhookToken: "replace-with-dedicated-webhook-token",    sessionRetention: "24h",    runLog: { maxBytes: "2mb", keepLines: 2000 },  },}

maxConcurrentRuns هم ارسال Cron زمان‌بندی‌شده و هم اجرای نوبت عامل ایزوله را محدود می‌کند، و مقدار پیش‌فرض آن 8 است. نوبت‌های عامل Cron ایزوله به‌صورت داخلی از مسیر اجرای اختصاصی cron-nested صف استفاده می‌کنند، بنابراین افزایش این مقدار باعث می‌شود اجراهای مستقل LLM در Cron به‌جای اینکه فقط wrapperهای بیرونی Cron خود را شروع کنند، به‌صورت موازی پیش بروند. مسیر مشترک غیر-Cron nested با این تنظیم گسترش داده نمی‌شود.

cron.store یک کلید ذخیره منطقی و مسیر ورود doctor قدیمی است. برای واردکردن storeهای JSON موجود به SQLite و بایگانی آن‌ها، openclaw doctor --fix را اجرا کنید؛ تغییرات آینده Cron باید از طریق CLI یا API Gateway انجام شوند.

غیرفعال‌کردن Cron: cron.enabled: false یا OPENCLAW_SKIP_CRON=1.

عیب‌یابی

نردبان فرمان‌ها

openclaw statusopenclaw gateway statusopenclaw cron statusopenclaw cron listopenclaw cron runs --id <jobId> --limit 20openclaw system heartbeat lastopenclaw logs --followopenclaw doctor

مرتبط

• خودکارسازی — همه سازوکارهای خودکارسازی در یک نگاه
• کارهای پس‌زمینه — دفتر کارها برای اجراهای Cron
• Heartbeat — نوبت‌های دوره‌ای نشست اصلی
• Timezone — پیکربندی timezone