زیرعامل‌ها

عامل‌های فرعی، اجراهای عامل در پس‌زمینه هستند که از یک اجرای عامل موجود ایجاد می‌شوند. آن‌ها در نشست خودشان (agent:<agentId>:subagent:<uuid>) اجرا می‌شوند و، پس از پایان، نتیجه‌شان را به کانال گفت‌وگوی درخواست‌کننده اعلام می‌کنند. هر اجرای عامل فرعی به‌عنوان یک وظیفه پس‌زمینه رهگیری می‌شود.

اهداف اصلی:

• موازی‌سازی کارهای «پژوهش / وظیفه طولانی / ابزار کند» بدون مسدود کردن اجرای اصلی.
• جدا نگه داشتن عامل‌های فرعی به‌صورت پیش‌فرض (جداسازی نشست + سندباکس اختیاری).
• سخت‌کردن سوءاستفاده از سطح ابزار: عامل‌های فرعی به‌صورت پیش‌فرض ابزارهای نشست را دریافت نمی‌کنند.
• پشتیبانی از عمق تودرتوی قابل پیکربندی برای الگوهای هماهنگ‌کننده.

فرمان اسلش

از /subagents برای بررسی اجراهای عامل فرعی در نشست فعلی استفاده کنید:

/subagents list/subagents log <id|#> [limit] [tools]/subagents info <id|#>

/subagents info فراداده اجرا را نشان می‌دهد (وضعیت، زمان‌مهرها، شناسه نشست، مسیر رونوشت، پاک‌سازی). برای نمای یادآوری محدود و فیلترشده از نظر ایمنی از sessions_history استفاده کنید؛ وقتی به رونوشت کامل خام نیاز دارید، مسیر رونوشت روی دیسک را بررسی کنید.

کنترل‌های اتصال رشته

این فرمان‌ها روی کانال‌هایی کار می‌کنند که از اتصال‌های رشته پایدار پشتیبانی می‌کنند. در ادامه کانال‌های پشتیبان رشته را ببینید.

/focus <subagent-label|session-key|session-id|session-label>/unfocus/agents/session idle <duration|off>/session max-age <duration|off>

رفتار ایجاد

عامل‌ها با sessions_spawn عامل‌های فرعی پس‌زمینه را شروع می‌کنند. تکمیل عامل فرعی به‌صورت رویدادهای داخلی نشست والد برمی‌گردد؛ عامل والد/درخواست‌کننده تصمیم می‌گیرد که آیا به‌روزرسانی قابل مشاهده برای کاربر لازم است یا نه.

حالت‌های زمینه

عامل‌های فرعی بومی جدا شروع می‌شوند، مگر اینکه فراخواننده صریحاً درخواست کند رونوشت فعلی fork شود.

از fork با احتیاط استفاده کنید. این برای واگذاری حساس به زمینه است، نه جایگزینی برای نوشتن اعلان وظیفه روشن.

ابزار: sessions_spawn

یک اجرای عامل فرعی را با deliver: false روی مسیر جهانی subagent شروع می‌کند، سپس یک مرحله اعلان اجرا می‌کند و پاسخ اعلان را به کانال گفت‌وگوی درخواست‌کننده ارسال می‌کند.

در دسترس بودن به سیاست ابزار مؤثر فراخواننده بستگی دارد. پروفایل‌های coding و full به‌صورت پیش‌فرض sessions_spawn را ارائه می‌کنند. پروفایل messaging این کار را نمی‌کند؛ برای عامل‌هایی که باید کار را واگذار کنند، tools.alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"] را اضافه کنید یا از tools.profile: "coding" استفاده کنید. سیاست‌های مجاز/غیرمجاز کانال/گروه، ارائه‌دهنده، سندباکس و هر عامل همچنان می‌توانند ابزار را پس از مرحله پروفایل حذف کنند. برای تأیید فهرست ابزار مؤثر، از همان نشست /tools را استفاده کنید.

پیش‌فرض‌ها:

• مدل: عامل‌های فرعی بومی از فراخواننده ارث‌بری می‌کنند، مگر اینکه agents.defaults.subagents.model (یا agents.list[].subagents.model برای هر عامل) را تنظیم کنید. ایجادهای زمان اجرای ACP در صورت وجود از همان مدل پیکربندی‌شده عامل فرعی استفاده می‌کنند؛ وگرنه ACP harness پیش‌فرض خودش را نگه می‌دارد. sessions_spawn.model صریح همچنان برنده است.
• Thinking: عامل‌های فرعی بومی از فراخواننده ارث‌بری می‌کنند، مگر اینکه agents.defaults.subagents.thinking (یا agents.list[].subagents.thinking برای هر عامل) را تنظیم کنید. ایجادهای زمان اجرای ACP همچنین agents.defaults.models["provider/model"].params.thinking را برای مدل انتخاب‌شده اعمال می‌کنند. sessions_spawn.thinking صریح همچنان برنده است.
• مهلت اجرای اجرا: OpenClaw وقتی agents.defaults.subagents.runTimeoutSeconds تنظیم شده باشد از آن استفاده می‌کند؛ وگرنه به 0 (بدون مهلت) برمی‌گردد. sessions_spawn بازنویسی مهلت برای هر فراخوانی را نمی‌پذیرد.
• تحویل وظیفه: عامل‌های فرعی بومی وظیفه واگذارشده را در نخستین پیام قابل مشاهده [Subagent Task] خود دریافت می‌کنند. اعلان سیستم عامل فرعی قواعد زمان اجرا و زمینه مسیریابی را حمل می‌کند، نه یک نسخه پنهان تکراری از وظیفه.

ایجادهای پذیرفته‌شده عامل فرعی بومی، فراداده مدل فرزند حل‌شده را در نتیجه ابزار شامل می‌شوند: resolvedModel شامل مرجع مدل اعمال‌شده و resolvedProvider وقتی مرجع دارای پیشوند ارائه‌دهنده باشد شامل آن پیشوند است.

حالت اعلان واگذاری

agents.defaults.subagents.delegationMode فقط راهنمایی اعلان را کنترل می‌کند؛ سیاست ابزار را تغییر نمی‌دهد یا واگذاری را اجبار نمی‌کند.

• suggest (پیش‌فرض): تلنگر استاندارد اعلان برای استفاده از عامل‌های فرعی در کارهای بزرگ‌تر یا کندتر را نگه دارید.
• prefer: به عامل اصلی بگویید پاسخ‌گو بماند و هر چیزی پیچیده‌تر از پاسخ مستقیم را از طریق sessions_spawn واگذار کند.

بازنویسی‌های هر عامل از agents.list[].subagents.delegationMode استفاده می‌کنند.

{  agents: {    defaults: {      subagents: {        delegationMode: "prefer",        maxConcurrent: 4,      },    },    list: [      {        id: "coordinator",        subagents: { delegationMode: "prefer" },      },    ],  },}

پارامترهای ابزار

نام‌های وظیفه و هدف‌گیری

taskName یک شناسه رو به مدل برای هماهنگ‌سازی است، نه کلید نشست. وقتی یک هماهنگ‌کننده ممکن است بعدا نیاز داشته باشد آن فرزند را بررسی کند، از آن برای نام‌های پایدار فرزند مانند review_subagents، linux_validation، یا docs_update استفاده کنید.

حل هدف، تطابق‌های دقیق taskName و پیشوندهای بدون ابهام را می‌پذیرد. تطابق به همان پنجره هدف فعال/اخیر محدود است که اهداف شماره‌دار /subagents از آن استفاده می‌کنند، بنابراین یک فرزند تکمیل‌شده قدیمی باعث مبهم شدن شناسه استفاده‌مجددشده نمی‌شود. اگر دو فرزند فعال یا اخیر همان taskName را داشته باشند، هدف مبهم است؛ به‌جای آن از نمایه فهرست، کلید نشست، یا شناسه اجرا استفاده کنید.

اهداف رزروشده last و all مقدارهای معتبر taskName نیستند زیرا از پیش معنای کنترلی دارند.

ابزار: sessions_yield

نوبت فعلی مدل را پایان می‌دهد و منتظر می‌ماند رویدادهای زمان اجرا، در درجه نخست رویدادهای تکمیل زیرعامل، به‌عنوان پیام بعدی برسند. پس از ایجاد کار فرزند الزامی، وقتی درخواست‌کننده تا رسیدن آن تکمیل‌ها نمی‌تواند پاسخ نهایی تولید کند، از آن استفاده کنید.

sessions_yield سازوکار اولیه انتظار است. آن را صرفا برای تشخیص تکمیل فرزند با حلقه‌های نظرسنجی روی subagents، sessions_list، sessions_history، shell sleep، یا نظرسنجی فرایند جایگزین نکنید.

فقط وقتی از sessions_yield استفاده کنید که فهرست ابزار مؤثر نشست شامل آن باشد. برخی پروفایل‌های ابزار حداقلی یا سفارشی ممکن است sessions_spawn و subagents را بدون ارائه sessions_yield در معرض بگذارند؛ در آن صورت، صرفا برای انتظار تکمیل، حلقه نظرسنجی ابداع نکنید.

وقتی فرزندان فعال وجود دارند، OpenClaw یک بلوک اعلان فشرده و تولیدشده توسط زمان اجرا با نام Active Subagents را در نوبت‌های عادی تزریق می‌کند تا درخواست‌کننده بتواند نشست‌های فرزند فعلی، شناسه‌های اجرا، وضعیت‌ها، برچسب‌ها، وظیفه‌ها، و نام‌های مستعار taskName را بدون نظرسنجی ببیند. فیلدهای وظیفه و برچسب در آن بلوک به‌عنوان داده نقل‌قول می‌شوند، نه دستورالعمل، زیرا ممکن است از آرگومان‌های ایجاد ارائه‌شده توسط کاربر/مدل منشأ بگیرند.

ابزار: subagents

اجراهای زیرعامل ایجادشده و متعلق به نشست درخواست‌کننده را فهرست می‌کند. دامنه آن به درخواست‌کننده فعلی محدود است؛ یک فرزند فقط می‌تواند فرزندان تحت کنترل خودش را ببیند.

برای وضعیت درخواستی و اشکال‌زدایی از subagents استفاده کنید. برای انتظار رویدادهای تکمیل از sessions_yield استفاده کنید.

نشست‌های متصل به رشته

وقتی اتصال‌های رشته برای یک کانال فعال باشند، یک زیرعامل می‌تواند به یک رشته متصل بماند تا پیام‌های پیگیری کاربر در آن رشته همچنان به همان نشست زیرعامل مسیریابی شوند.

کانال‌های پشتیبان رشته

هر کانالی که آداپتور اتصال نشست داشته باشد می‌تواند نشست‌های پایدار زیرعامل متصل به رشته را پشتیبانی کند (sessions_spawn با thread: true). آداپتورهای همراه در حال حاضر شامل رشته‌های Discord، رشته‌های Matrix، موضوعات انجمن Telegram، و اتصال‌های مکالمه فعلی برای Feishu هستند. برای فعال‌سازی، زمان‌سنجی‌ها، و spawnSessions از کلیدهای پیکربندی threadBindings ویژه هر کانال استفاده کنید.

جریان سریع

کنترل‌های دستی

سوییچ‌های پیکربندی

• پیش‌فرض سراسری: session.threadBindings.enabled، session.threadBindings.idleHours، session.threadBindings.maxAgeHours.
• بازنویسی کانال و کلیدهای اتصال خودکار هنگام ایجاد ویژه آداپتور هستند. بخش کانال‌های پشتیبان رشته در بالا را ببینید.

برای جزئیات فعلی آداپتور، مرجع پیکربندی و فرمان‌های اسلش را ببینید.

فهرست مجاز

اگر نشست درخواست‌کننده sandboxed باشد، sessions_spawn هدف‌هایی را که بدون sandbox اجرا می‌شوند رد می‌کند.

کشف

برای دیدن اینکه کدام شناسه‌های عامل در حال حاضر برای sessions_spawn مجاز هستند، از agents_list استفاده کنید. پاسخ شامل مدل مؤثر هر عامل فهرست‌شده و فراداده زمان اجرای جاسازی‌شده است تا فراخوان‌ها بتوانند OpenClaw، سرور برنامه Codex، و سایر زمان‌های اجرای بومی پیکربندی‌شده را از هم تشخیص دهند.

ورودی‌های allowAgents باید به شناسه‌های عامل پیکربندی‌شده در agents.list[] اشاره کنند. ["*"] یعنی هر عامل هدف پیکربندی‌شده به‌علاوه درخواست‌کننده. اگر پیکربندی یک عامل حذف شود اما شناسه آن در allowAgents باقی بماند، sessions_spawn آن شناسه را رد می‌کند و agents_list آن را حذف می‌کند. برای پاک‌سازی ورودی‌های قدیمی فهرست مجاز، openclaw doctor --fix را اجرا کنید، یا وقتی هدف باید در حالی که پیش‌فرض‌ها را به ارث می‌برد همچنان قابل ایجاد باشد، یک ورودی حداقلی agents.list[] اضافه کنید.

بایگانی خودکار

• نشست‌های زیرعامل پس از agents.defaults.subagents.archiveAfterMinutes به‌طور خودکار بایگانی می‌شوند (پیش‌فرض 60).
• بایگانی از sessions.delete استفاده می‌کند و رونوشت را به *.deleted.<timestamp> تغییر نام می‌دهد (همان پوشه).
• cleanup: "delete" بلافاصله پس از اعلام، بایگانی می‌کند (همچنان رونوشت را از طریق تغییر نام نگه می‌دارد).
• بایگانی خودکار بر پایه بهترین تلاش است؛ اگر gateway دوباره راه‌اندازی شود، زمان‌سنج‌های معلق از دست می‌روند.
• زمان‌سنجی‌های اجرای پیکربندی‌شده به‌طور خودکار بایگانی نمی‌کنند؛ فقط اجرا را متوقف می‌کنند. نشست تا بایگانی خودکار باقی می‌ماند.
• بایگانی خودکار به‌طور یکسان برای نشست‌های عمق ۱ و عمق ۲ اعمال می‌شود.
• پاک‌سازی مرورگر از پاک‌سازی بایگانی جداست: زبانه‌ها/فرایندهای مرورگر ردیابی‌شده وقتی اجرا تمام می‌شود بر پایه بهترین تلاش بسته می‌شوند، حتی اگر رونوشت/رکورد نشست نگه داشته شود.

زیرعامل‌های تودرتو

به‌طور پیش‌فرض، زیرعامل‌ها نمی‌توانند زیرعامل‌های خودشان را ایجاد کنند (maxSpawnDepth: 1). برای فعال‌سازی یک سطح تودرتویی، maxSpawnDepth: 2 را تنظیم کنید که همان الگوی هماهنگ‌کننده است: عامل اصلی → زیرعامل هماهنگ‌کننده → زیر-زیرعامل‌های کارگر.

{  agents: {    defaults: {      subagents: {        maxSpawnDepth: 2, // allow sub-agents to spawn children (default: 1)        maxChildrenPerAgent: 5, // max active children per agent session (default: 5)        maxConcurrent: 8, // global concurrency lane cap (default: 8)        runTimeoutSeconds: 900, // default timeout for sessions_spawn (0 = no timeout)        announceTimeoutMs: 120000, // per-call gateway announce timeout      },    },  },}

سطوح عمق

زنجیره اعلام

نتایج در زنجیره به بالا برمی‌گردند:

1. کارگر عمق ۲ تمام می‌شود → به والد خود (هماهنگ‌کننده عمق ۱) اعلام می‌کند.
2. هماهنگ‌کننده عمق ۱ اعلان را دریافت می‌کند، نتایج را ترکیب می‌کند، تمام می‌شود → به اصلی اعلام می‌کند.
3. عامل اصلی اعلان را دریافت می‌کند و به کاربر تحویل می‌دهد.

هر سطح فقط اعلان‌های فرزندان مستقیم خود را می‌بیند.

سیاست ابزار بر اساس عمق

• نقش و دامنه کنترل هنگام ایجاد، در فراداده نشست نوشته می‌شوند. این باعث می‌شود کلیدهای نشست تخت یا بازیابی‌شده به‌طور تصادفی دوباره امتیازهای هماهنگ‌کننده را به دست نیاورند.
• عمق ۱ (هماهنگ‌کننده، وقتی maxSpawnDepth >= 2): sessions_spawn، subagents، sessions_list، sessions_history را دریافت می‌کند تا بتواند فرزند ایجاد کند و وضعیت آن‌ها را بررسی کند. ابزارهای دیگر نشست/سیستم همچنان رد می‌مانند.
• عمق ۱ (برگ، وقتی maxSpawnDepth == 1): بدون ابزار نشست (رفتار پیش‌فرض فعلی).
• عمق ۲ (کارگر برگ): بدون ابزار نشست — sessions_spawn همیشه در عمق ۲ رد می‌شود. نمی‌تواند فرزندان بیشتری ایجاد کند.

محدودیت ایجاد برای هر عامل

هر نشست عامل (در هر عمقی) می‌تواند هم‌زمان حداکثر maxChildrenPerAgent (پیش‌فرض 5) فرزند فعال داشته باشد. این از گسترش بی‌مهار از یک هماهنگ‌کننده واحد جلوگیری می‌کند.

توقف آبشاری

توقف یک هماهنگ‌کننده عمق ۱ به‌طور خودکار همه فرزندان عمق ۲ آن را متوقف می‌کند:

• /stop در گفت‌وگوی اصلی همه عامل‌های عمق ۱ را متوقف می‌کند و به فرزندان عمق ۲ آن‌ها آبشار می‌شود.

احراز هویت

احراز هویت زیرعامل بر اساس شناسه عامل حل می‌شود، نه بر اساس نوع نشست:

• کلید نشست زیرعامل agent:<agentId>:subagent:<uuid> است.
• ذخیره‌گاه احراز هویت از agentDir همان عامل بارگذاری می‌شود.
• پروفایل‌های احراز هویت عامل اصلی به‌عنوان جایگزین ادغام می‌شوند؛ پروفایل‌های عامل در تعارض‌ها پروفایل‌های اصلی را بازنویسی می‌کنند.

ادغام افزایشی است، بنابراین پروفایل‌های اصلی همیشه به‌عنوان جایگزین در دسترس هستند. احراز هویت کاملا ایزوله برای هر عامل هنوز پشتیبانی نمی‌شود.

اعلان

زیرعامل‌ها از طریق یک گام اعلان گزارش می‌دهند:

• گام اعلان داخل نشست زیرعامل اجرا می‌شود (نه نشست درخواست‌کننده).
• اگر زیرعامل دقیقا ANNOUNCE_SKIP پاسخ دهد، چیزی ارسال نمی‌شود.
• اگر آخرین متن دستیار همان توکن خاموش دقیق NO_REPLY / no_reply باشد، خروجی اعلان سرکوب می‌شود، حتی اگر پیشرفت قابل مشاهده قبلی وجود داشته باشد.

تحویل به عمق درخواست‌کننده بستگی دارد:

• نشست‌های درخواست‌کننده سطح بالا از یک فراخوانی پیگیری agent با تحویل خارجی (deliver=true) استفاده می‌کنند.
• نشست‌های زیرعاملِ درخواست‌کننده تودرتو یک تزریق پیگیری داخلی (deliver=false) دریافت می‌کنند تا هماهنگ‌کننده بتواند نتایج فرزند را درون نشست ترکیب کند.
• اگر نشست زیرعاملِ درخواست‌کننده تودرتو از بین رفته باشد، OpenClaw در صورت امکان به درخواست‌کننده همان نشست برمی‌گردد.

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

تجمیع تکمیل فرزند هنگام ساخت یافته‌های تکمیل تودرتو به اجرای درخواست‌کننده فعلی محدود می‌شود و مانع نشت خروجی‌های فرزند اجرای قبلی به اعلان فعلی می‌شود. پاسخ‌های اعلان، در صورت در دسترس بودن روی آداپتورهای کانال، مسیریابی رشته/موضوع را حفظ می‌کنند.

زمینه اعلان

زمینه اعلان به یک بلوک رویداد داخلی پایدار نرمال‌سازی می‌شود:

اجراهای ناموفق پایانی بدون بازپخش متن پاسخ ضبط‌شده، وضعیت شکست را گزارش می‌کنند. خروجی ابزار/نتیجه‌ابزار به متن نتیجه فرزند ارتقا داده نمی‌شود.

خط آمار

محموله‌های اعلان در پایان شامل یک خط آمار هستند (حتی وقتی بسته‌بندی شده باشند):

• زمان اجرا (برای نمونه runtime 5m12s).
• مصرف توکن (ورودی/خروجی/کل).
• هزینه تخمینی وقتی قیمت‌گذاری مدل پیکربندی شده باشد (models.providers.*.models[].cost).
• sessionKey، sessionId، و مسیر رونوشت تا عامل اصلی بتواند تاریخچه را از طریق sessions_history واکشی کند یا فایل روی دیسک را بررسی کند.

فراداده داخلی فقط برای هماهنگ‌سازی است؛ پاسخ‌های کاربرمحور باید با صدای عادی دستیار بازنویسی شوند.

چرا sessions_history را ترجیح دهیم

sessions_history مسیر هماهنگ‌سازی امن‌تری است:

• یادآوری دستیار ابتدا نرمال‌سازی می‌شود: برچسب‌های فکر کردن حذف می‌شوند؛ داربست <relevant-memories> / <relevant_memories> حذف می‌شود؛ بلوک‌های محموله XML فراخوانی ابزار به‌صورت متن ساده (<tool_call>، <function_call>، <tool_calls>، <function_calls>) حذف می‌شوند، از جمله محموله‌های کوتاه‌شده‌ای که هرگز تمیز بسته نمی‌شوند؛ داربست تنزل‌یافته فراخوانی/نتیجه ابزار و نشانگرهای زمینه تاریخی حذف می‌شوند؛ توکن‌های کنترل مدل نشت‌کرده (<|assistant|>، دیگر <|...|>های ASCII، <｜...｜> تمام‌عرض) حذف می‌شوند؛ XML فراخوانی ابزار MiniMax ناقص حذف می‌شود.
• متن‌های شبیه اعتبارنامه/توکن پوشانده می‌شوند.
• بلوک‌های طولانی می‌توانند کوتاه شوند.
• تاریخچه‌های بسیار بزرگ می‌توانند ردیف‌های قدیمی‌تر را حذف کنند یا یک ردیف بیش‌ازحد بزرگ را با [sessions_history omitted: message too large] جایگزین کنند.
• وقتی nextOffset وجود دارد، از آن برای صفحه‌بندی رو به عقب در پنجره‌های قدیمی‌تر رونوشت استفاده کنید.
• بررسی رونوشت خام روی دیسک جایگزین است وقتی به رونوشت کامل بایت‌به‌بایت نیاز دارید.

سیاست ابزار

زیرعامل‌ها ابتدا از همان خط لوله پروفایل و سیاست ابزارِ والد یا عامل هدف استفاده می‌کنند. پس از آن، OpenClaw لایه محدودیت زیرعامل را اعمال می‌کند.

بدون tools.profile محدودکننده، زیرعامل‌ها همه ابزارها به‌جز ابزار پیام، ابزارهای نشست، و ابزارهای سیستم را دریافت می‌کنند:

• sessions_list
• sessions_history
• sessions_send
• sessions_spawn
• message

sessions_history اینجا هم یک نمای یادآوری محدود و پاک‌سازی‌شده باقی می‌ماند — ریزش خام رونوشت نیست.

وقتی maxSpawnDepth >= 2 باشد، زیرعامل‌های هماهنگ‌کننده عمق ۱ افزون بر این sessions_spawn، subagents، sessions_list، و sessions_history را دریافت می‌کنند تا بتوانند فرزندان خود را مدیریت کنند.

بازنویسی از طریق پیکربندی

{  agents: {    defaults: {      subagents: {        maxConcurrent: 1,      },    },  },  tools: {    subagents: {      tools: {        // deny wins        deny: ["gateway", "cron"],        // if allow is set, it becomes allow-only (deny still wins)        // allow: ["read", "exec", "process"]      },    },  },}

tools.subagents.tools.allow یک فیلتر نهایی فقط-مجاز است. می‌تواند مجموعه ابزارِ از پیش حل‌شده را محدودتر کند، اما نمی‌تواند ابزاری را که توسط tools.profile حذف شده دوباره اضافه کند. برای نمونه، tools.profile: "coding" شامل web_search/web_fetch است اما ابزار browser را شامل نمی‌شود. برای اینکه زیرعامل‌های پروفایل کدنویسی بتوانند از خودکارسازی مرورگر استفاده کنند، browser را در مرحله پروفایل اضافه کنید:

{  tools: {    profile: "coding",    alsoAllow: ["browser"],  },}

وقتی فقط یک عامل باید خودکارسازی مرورگر بگیرد، از agents.list[].tools.alsoAllow: ["browser"] برای هر عامل استفاده کنید.

هم‌روندی

زیرعامل‌ها از یک مسیر صف اختصاصی درون‌فرایندی استفاده می‌کنند:

• نام مسیر: subagent
• هم‌روندی: agents.defaults.subagents.maxConcurrent (پیش‌فرض 8)

زنده‌بودن و بازیابی

OpenClaw نبود endedAt را اثبات دائمی زنده بودن یک زیرعامل در نظر نمی‌گیرد. اجراهای پایان‌نیافته قدیمی‌تر از پنجره اجرای کهنه، دیگر در /subagents list، خلاصه‌های وضعیت، گیت تکمیل نوادگان، و بررسی‌های هم‌روندی برای هر نشست به‌عنوان فعال/در انتظار شمرده نمی‌شوند.

پس از راه‌اندازی مجدد Gateway، اجراهای بازیابی‌شده کهنه و پایان‌نیافته هرس می‌شوند، مگر اینکه نشست فرزند آن‌ها با abortedLastRun: true علامت‌گذاری شده باشد. آن نشست‌های فرزندِ قطع‌شده در راه‌اندازی مجدد از طریق جریان بازیابی یتیم زیرعامل قابل بازیابی می‌مانند؛ این جریان پیش از پاک کردن نشانگر قطع‌شده، یک پیام ازسرگیری مصنوعی می‌فرستد.

بازیابی خودکار راه‌اندازی مجدد برای هر نشست فرزند محدود است. اگر همان فرزند زیرعامل درون پنجره گیرکردن دوباره سریع، مکررا برای بازیابی یتیم پذیرفته شود، OpenClaw یک سنگ‌قبر بازیابی روی آن نشست پایدار می‌کند و در راه‌اندازی‌های مجدد بعدی ازسرگیری خودکار آن را متوقف می‌کند. برای همسوسازی رکورد وظیفه، openclaw tasks maintenance --apply را اجرا کنید، یا برای پاک کردن پرچم‌های بازیابی قطع‌شده کهنه روی نشست‌های سنگ‌قبرشده، openclaw doctor --fix را اجرا کنید.

توقف

• ارسال /stop در گفت‌وگوی درخواست‌کننده، نشست درخواست‌کننده را قطع می‌کند و هر اجرای زیرعامل فعال ایجادشده از آن را متوقف می‌کند و به فرزندان تودرتو آبشار می‌شود.

محدودیت‌ها

• اعلان زیرعامل در حد بهترین تلاش است. اگر gateway دوباره راه‌اندازی شود، کارهای در انتظار «اعلان به عقب» از دست می‌روند.
• زیرعامل‌ها همچنان منابع همان فرایند gateway را شریک هستند؛ maxConcurrent را به‌عنوان شیر اطمینان در نظر بگیرید.
• sessions_spawn همیشه غیربلوک‌کننده است: بلافاصله { status: "accepted", runId, childSessionKey } را برمی‌گرداند.
• زمینه زیرعامل فقط AGENTS.md و TOOLS.md را تزریق می‌کند (بدون SOUL.md، IDENTITY.md، USER.md، MEMORY.md، HEARTBEAT.md، یا BOOTSTRAP.md). زیرعامل‌های بومی Codex همان مرز را دنبال می‌کنند: TOOLS.md در دستورالعمل‌های رشته Codex به‌ارث‌رسیده باقی می‌ماند، در حالی که فایل‌های شخصیت، هویت، و کاربرِ فقط-والد به‌عنوان دستورالعمل‌های همکاری محدود به نوبت تزریق می‌شوند تا فرزندان آن‌ها را کپی نکنند.
• بیشینه عمق تودرتوسازی 5 است (بازه maxSpawnDepth: 1–5). عمق 2 برای بیشتر موارد استفاده توصیه می‌شود.
• maxChildrenPerAgent فرزندان فعال برای هر نشست را سقف‌گذاری می‌کند (پیش‌فرض 5، بازه 1–20).

مرتبط

• عامل‌های ACP
• ارسال عامل
• وظایف پس‌زمینه
• ابزارهای جعبه شنی چندعاملی