طرح کارگرهای ابری

وضعیت

پیشنهاد، بازبینی 3. پیاده‌سازی نشده است. جهت‌گیری در 2026-07 مورد توافق قرار گرفت؛ بازبینی 2 یافته‌های بازبینی خصمانه را در خود گنجاند (پروتکل اختصاصی worker، ماشین‌های حالت استقرار/محیط، همگام‌سازی ورودی آگاه از git، واگذاری یک‌طرفه v1، نگارش امنیتی خروجی کنترل‌شده). بازبینی 3 مدل مالکیت همگام‌سازی را نهایی می‌کند (worker کامیت‌ها را ایجاد می‌کند، gateway آن‌ها را می‌پذیرد و منتشر می‌کند)، یک حالت همگام‌سازی ساده بدون git می‌افزاید، اجرای worker را در حالت کامل درون ماشین اصلاح می‌کند، سیاست اینترنت را به زمان تأمین منتقل می‌کند و ارسال agent را به نقطه عطف 3 بازمی‌گرداند.

مشکل

نشست‌های agent در OpenClaw حلقه، ابزارها و استنتاج خود را درون فرایند gateway روی یک ماشین اجرا می‌کنند. توان محاسباتی به ظرفیت همان ماشین محدود است، وظایف طولانی آن را اشغال می‌کنند و کارهای موازی برای استفاده از آن رقابت می‌کنند. محصولات میزبانی‌شده (agentهای ابری Cursor، Claude Code در وب، Codex cloud) این مشکل را با sandboxهای ابری موقتی برای هر وظیفه حل می‌کنند، اما به زیرساخت و اعتماد به فروشنده نیاز دارند.

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

اهداف

• اجرای یک نشست کامل agent (حلقه + ابزارها) روی یک ماشین راه‌دور موقتی («worker ابری»)، در حالی که نشست دقیقاً مانند یک نشست محلی در Control UI ظاهر و پخش می‌شود.
• نبود اعتبارنامه‌های دائمی روی worker (بدون احراز هویت ارائه‌دهنده و بدون توکن‌های forge) و نبود خروجی مستقیم شبکه؛ ماشین فقط به یک sshd قابل‌دسترسی نیاز دارد.
• تأمین، همگام‌سازی، اجرا، جمع‌آوری، نابودسازی — کاملاً خودکار و قابل‌اتصال به ارائه‌دهنده‌های مختلف (اولین ارائه‌دهنده: CLIهای اجاره به سبک Crabbox).
• ارسال کار در حال اجرا از gateway به یک worker در مرز نوبت، بدون از دست دادن رونوشت، هویت نشست یا (هنگامی که بایت‌های درخواست هم‌ارز باقی بمانند) پیوستگی کش ارائه‌دهنده؛ بازگرداندن امن نتایج.
• هم انسان‌ها (UI) و هم agentها (ابزار) می‌توانند کار را به یک worker ابری ارسال کنند.
• پشتیبانی از نشست‌های چندروزه؛ طول عمر تابع سیاست است، نه یک سقف کدنویسی‌شده.

خارج از اهداف (v1)

• بدون چارچوب‌های کدنویسی خارجی (Claude Code، Codex CLI) روی workerها. نشست‌های worker فقط اجراکننده تعبیه‌شده OpenClaw را اجرا می‌کنند. پشتیبانی از چارچوب‌ها در v2 به‌صورت انتخابی خواهد بود، زیرا چارچوب‌ها استنتاج خود را با اعتبارنامه‌های خودشان انجام می‌دهند.
• بدون انتخاب بهترین از میان N تلاش / انشعاب تلاش‌های موازی.
• بدون وابستگی به VPN/tailnet. انتقال فقط از طریق SSH است.
• بدون runtime جدید sandbox. ماشین worker مرز جداسازی است؛ sandboxing سیستم‌عامل درون ماشین می‌تواند بعداً به‌صورت لایه‌ای افزوده شود.
• بدون مهاجرت زنده متقارن در v1: ارسال به‌صورت local → worker است؛ worker → local به یک نشست متوقف‌شده به‌همراه تکمیل تطبیق workspace نیاز دارد. واگذاری زنده دوطرفه بعداً بر همان سازوکارهای مانع بنا می‌شود.
• بدون وضعیت جانبی JSON روی gateway؛ وضعیت محیط، استقرار، مکان‌نما و مجوز در SQLite نگهداری می‌شود.

نمونه‌های پیشین (چه چیزی را کپی و چه چیزی را معکوس می‌کنیم)

• agentهای ابری Cursor: حلقه agent در ابر آن‌ها اجرا می‌شود؛ VM هدف اجرای ابزار است؛ مخزن مکالمه فقط‌افزودنی به همه کلاینت‌ها پخش می‌شود؛ شروع گرم با snapshot پس از نصب؛ workerهای خودمیزبان فقط فرایندهای worker با ارتباط خروجی هستند. مدل «منبع حقیقت مکالمه روی هماهنگ‌کننده باقی می‌ماند» و پخش را کپی می‌کنیم؛ محل اجرای حلقه را معکوس می‌کنیم (تصمیم زیر را ببینید).
• Codex cloud: runtime دومرحله‌ای — مرحله راه‌اندازی متصل به شبکه، سپس مرحله آفلاین agent با حذف اسرار؛ کش وضعیت کانتینر برای ادامه‌های سریع. تفکیک مراحل را به‌عنوان رویکرد خروجی شبکه و ایده کش را برای imageهای گرم v2 کپی می‌کنیم.
• Claude Code در وب: VM برای هر نشست؛ proxy مربوط به git با جداسازی اعتبارنامه‌ها (توکن‌های واقعی هرگز وارد sandbox نمی‌شوند و push به شاخه نشست محدود است)؛ snapshot سیستم فایل پس از راه‌اندازی؛ واگذاری teleport = شاخه pushشده + تاریخچه بازپخش‌شده. جداسازی اعتبارنامه‌ها و چارچوب واگذاری را کپی می‌کنیم، اما همگام‌سازی خروجی با rsync از gateway انجام می‌شود تا working treeهای کثیف کار کنند و هیچ توکن forge در نزدیکی ماشین وجود نداشته باشد.
• agent کدنویسی Copilot: خروجی شبکه با پیش‌فرض منع و allowlist رجیستری بسته‌ها. پیش‌فرض حالت پایدار ما سخت‌گیرانه‌تر است (اصلاً خروجی مستقیم وجود ندارد)، زیرا استنتاج و جست‌وجوی وب از طریق تونل SSH می‌رسند — اما برای علت اینکه این «خروجی کنترل‌شده» است، نه «خروجی صفر»، بخش امنیت را ببینید.

تصمیم معماری: حلقه روی worker، استنتاج از طریق gateway

سه محل اجرا در نظر گرفته شد:

1. حلقه روی gateway باقی می‌ماند و worker ابزارها را اجرا می‌کند (مدل Cursor). امن‌ترین دامنه خرابی (رونوشت، استنتاج، تأییدها و بازیابی پس از راه‌اندازی مجدد همگی محلی می‌مانند) و نقطه عطف اول ترجیحی بازبین. به‌عنوان معماری محصول رد شد: ابزارهای غیر exec در OpenClaw عملیات درون‌فرایندی سیستم فایل هستند، بنابراین هر خواندن/ویرایش/grep فایل به یک رفت‌وبرگشت شبکه یا بازسازی گسترده سطح ابزار به RPCهای درشت‌دانه workspace تبدیل می‌شود؛ رفتار runtime پرتعامل و محدود به تأخیر است. در جایی که روح این مدل از قبل ساخته شده است (واگذاری exec به nodeها) از آن استفاده می‌کنیم، اما لایه راه‌دورکردن ابزارها را نمی‌سازیم.
2. حلقه و استنتاج هر دو روی worker. ساده‌ترین دامنه خرابی، اما اعتبارنامه‌های مدل (از جمله پروفایل‌های OAuth) باید به ماشین‌های یک‌بارمصرف منتقل شوند، gateway کنترل سیاست/مسیریابی/ممیزی را از دست می‌دهد و مهاجرت هویت فراخوان ارائه‌دهنده را عوض می‌کند و کش‌های ارائه‌دهنده را نامعتبر می‌سازد.
3. حلقه + ابزارها روی worker، فراخوانی‌های مدل از طریق gateway به‌صورت proxy. انتخاب‌شده. یک رفت‌وبرگشت برای هر نوبت مدل به‌جای هر فراخوانی ابزار؛ ابزارها در کنار کد اجرا می‌شوند؛ gateway مالک یگانه پروفایل‌های احراز هویت، مسیریابی ارائه‌دهنده و سیاست باقی می‌ماند؛ worker هیچ رازی نگه نمی‌دارد.

هزینه گزینه 3 وابستگی همگام به gateway در طول هر نوبت مدل است، بنابراین قواعد دوام آن بخشی از تصمیم هستند، نه موضوعی که بعداً در نظر گرفته شود:

• از دست رفتن gateway در میانه نوبت باعث شکست فراخوانی فعال ارائه‌دهنده می‌شود. نوبت شکست‌خورده علامت‌گذاری می‌شود و پس از اتصال مجدد به‌عنوان یک نوبت جدید دوباره اجرا می‌شود؛ هیچ بازپخش شفافی از stream در حال اجرای ارائه‌دهنده وجود ندارد (خطر صورتحساب دوگانه/فراخوانی دوگانه ابزار).
• هر عملیات worker↔gateway هویت ماندگار را حمل می‌کند (به پروتکل worker مراجعه کنید) تا اتصال‌های مجدد به‌جای معلق ماندن، نتایج نهایی کش‌شده را از سر بگیرند یا دریافت کنند.
• gateway یک مؤلفه با ظرفیت مدیریت‌شده است: محدودیت workerهای هم‌زمان، کنترل جریان و کاهش بار در محدوده v1 هستند (به ظرفیت مراجعه کنید).

از آنجا که gateway هم رونوشت را ذخیره می‌کند و هم همه ترافیک ارائه‌دهنده را آغاز می‌کند، نشست مستقل از مکان است: جابه‌جایی حلقه میان gateway و worker هیچ‌چیز را در سمت ارائه‌دهنده و مسیر داده UI تغییر نمی‌دهد. همین موضوع ارسال و بازگرداندن را کم‌هزینه می‌کند.

مؤلفه‌ها

1. ماشین حالت محیط + قرارداد ارائه‌دهنده

environments.* در پروتکل gateway در حال حاضر فقط یک نمای وضعیت است. هسته ماندگار، رکورد محیط و ماشین حالتی تحت مالکیت SQLite است که پیش از شکل‌های RPC طراحی می‌شود:

requested → provisioning → bootstrapping → ready → (attached|idle) → draining → destroying → destroyed | failed | orphaned

• تأمین در برابر خرابی ایمن است: ردیف قصد پیش از فراخوانی ارائه‌دهنده و با یک شناسه عملیات قطعی ذخیره می‌شود تا راه‌اندازی مجدد gateway بتواند یک اجاره در حال انجام را بپذیرد، به‌جای اینکه دو بار تأمین کند یا یک ماشین پولی را رها کند.
• تطبیق پس از راه‌اندازی مجدد و پاک‌ساز منابع یتیم (ارائه‌دهنده inspect در برابر رکوردهای محلی) از الزامات v1 هستند، نه مقاوم‌سازی‌های اختیاری.

قرارداد ارائه‌دهنده (پیاده‌سازی‌شده توسط plugin؛ بدون نام ارائه‌دهنده یا سیاست در هسته):

type WorkerProvider = {  id: string;  provision(profile: WorkerProfile, opId: string): Promise&lt;WorkerLease&gt;; // → میزبان/درگاه/کاربر SSH/مواد کلید  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise&lt;LeaseStatus&gt;; // پذیرش/سلامت/پاک‌سازی یتیم‌ها  renew?(leaseId: string): Promise<void>; // نشست‌های طولانی‌مدت در برابر TTLهای ارائه‌دهنده  destroy(lease: { leaseId: string; profile: WorkerProfile }): Promise<void>; // ایدمپوتنت؛ فقط پس از اثبات برچیدن بازمی‌گردد};

RPCها: environments.create، environments.destroy، environments.list/status توسعه‌یافته (ارائه‌دهنده، شناسه اجاره، وضعیت، عمر، زمان بیکاری، نشست‌های متصل). نخستین ارائه‌دهنده‌ها: یک wrapper برای CLI اجاره با شکل Crabbox (مسیر محصول) و یک ارائه‌دهنده میزبان SSH ثابت با برچسب فقط برای توسعه — یک worker روی میزبان اشتراکی می‌تواند داده‌های نامرتبط میزبان را بخواند، بنابراین میزبان‌های ثابت برای توسعه قابلیت هستند، نه وضعیت پیش‌فرض.

2. راه‌اندازی اولیه worker: نصب OpenClaw روی ماشین

بدون artifact اختصاصی worker و بدون وابستگی به دردسترس‌بودن npm:

• نصب مرجع برای همه حالت‌ها: یک bundle worker با hash محتوایی که gateway تولید می‌کند (خروجی build خود gateway که به‌شکل tarball بسته‌بندی شده است)، از طریق SSH ارسال و روی ماشین نصب می‌شود. این روش ذاتاً buildهای توسعه و کامیت‌های منتشرنشده را پوشش می‌دهد.
• npm i -g openclaw@<exact gateway version> هنگامی که gateway یک نسخه منتشرشده را اجرا می‌کند یک بهینه‌سازی است؛ هرگز latest.
• راه‌اندازی اولیه ایدمپوتنت است؛ یک اجاره گرم با hash منطبق bundle از نصب صرف‌نظر می‌کند. ماشین‌های خام ممکن است به یک مرحله زنجیره ابزار متصل به شبکه (runtime مربوط به Node) نیاز داشته باشند — بخشی از مرحله راه‌اندازی که پس از آن بسته می‌شود.
• دست‌دهی، hash مربوط به build worker، مجموعه قابلیت‌های پروتکل و سازگاری runtime را بررسی می‌کند. بررسی‌های نسخه/پروتکل موجود gateway برای این کار کافی نیستند (nodeهای تونل‌شده با SSH از رد نسخه دقیق مستثنا هستند)، بنابراین پذیرش worker بررسی دقیق build خودش را انجام می‌دهد.

حالت worker (openclaw worker) یک نقطه ورود است، نه یک fork: مدیریت اتصال به‌همراه اجراکننده تعبیه‌شده agent، با ماندگاری نشست و فراخوانی‌های مدل که RPCهای gateway از آن‌ها پشتیبانی می‌کنند. این حالت نباید سطوح gateway را راه‌اندازی کند: بدون channel، بدون شروع خودکار plugin فراتر از مجموعه ابزار نشست، دایرکتوری وضعیت یک‌بارمصرف و بدون پروفایل‌های احراز هویت محلی.

3. انتقال: همه‌چیز از طریق SSH

gateway مالک اتصال است؛ worker جز sshd به چیزی نیاز ندارد:

• gateway اتصال SSH را به worker باز می‌کند (اعتبارنامه‌ها از اجاره ارائه‌دهنده، کلید میزبان pinشده از خروجی تأمین — بدون StrictHostKeyChecking=no) و یک تونل معکوس برقرار می‌کند که یک socket محلی worker را به endpoint مربوط به WS در gateway هدایت می‌کند.
• ترافیک کنترل/مدل و انتقال workspace از اتصال‌های SSH جداگانه با مواد اعتماد pinشده یکسان استفاده می‌کنند تا rsync نتواند streamهای توکن را با انسداد ابتدای صف متوقف کند.
• چرخه عمر تونل (keepalive، اتصال مجدد با backoff) تحت مالکیت runtime محیط روی gateway است. یک اختلال تونل در سطح نشست نامرئی است: وضعیت ماندگار پروتکل (در ادامه) به worker اجازه می‌دهد دوباره متصل شود و ادامه دهد.

4. پروتکل worker (اختصاصی؛ نه پروتکل node)

بازبینی خصمانه در برابر seamهای فعلی node، استفاده مجدد ساده را رد کرد: invokeهای معلق node، Promiseهای محلی فرایند هستند که با اتصال از بین می‌روند، کلیدهای idempotency مربوط به node تجزیه می‌شوند اما deduplicate نمی‌شوند و — عامل تعیین‌کننده — یک node متصل می‌تواند رویدادهای عادی node (از جمله درخواست‌های اجرای agent) را منتشر کند؛ بنابراین «نوع node + سقف قابلیت» یک مرز امنیتی ورودی نیست. در نتیجه workerها یک نقش احرازهویت‌شده worker با allowlist بسته و نسخه‌بندی‌شده RPC/رویداد دریافت می‌کنند؛ اتصال‌های worker نمی‌توانند به هیچ مدیریت‌کننده قدیمی رویداد node دسترسی داشته باشند.

هویت و اعتبارنامه‌ها: تأمین یک اعتبارنامه کوتاه‌عمر worker صادر می‌کند که به شناسه محیط، کلید worker، hash مربوط به bundle، تنها نشست مجاز، مجموعه RPC مجاز و یک زمان انقضا مقید است. جفت‌سازی تأییدشده با SSH همچنان اعمال می‌شود (ما ماشین را تأمین کرده‌ایم و کلید را در اختیار داریم)، اما مجوز از اعتبارنامه صادرشده می‌آید، نه از سطح node اعلام‌شده.

معناشناسی عملیات ماندگار (شکل آن از runtime موجود ACP و دفتر رویداد آن گرفته شده است — handleهای پایدار، سری‌سازی برای هر نشست، بازپخش ماندگار (session, seq)):

• دامنهٔ هر عملیات به (sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq) محدود است.
• دوره‌های مالکیت، workerهای منقضی را محصور می‌کنند: یک worker جایگزین دوره را جلو می‌برد؛ نتایج دیرهنگام دورهٔ قدیمی به‌صورت قطعی رد می‌شوند.
• تحویل حداقل یک‌باره با مکان‌نماهای ACK پایدارشده و نتایج نهایی ذخیره‌شده در حافظهٔ نهان SQLite؛ حذف موارد تکراری قطعی است. هیچ تضمینی برای تحویل دقیقاً یک‌باره وجود ندارد.
• فریم‌های صریح برای لغو، بستن، ازسرگیری و نتایج نهایی؛ کنترل جریان مبتنی بر اعتبار/پنجره در جریان‌ها.
• مذاکرهٔ قابلیت‌های پروتکل مستقل از نسخهٔ عمومی پروتکل Node است.

5. RPCهای بک‌اند نشست

دو قرارداد متمایز — کدبیس فعلی تغییرات پایدار رونوشت (تحت مالکیت مدیر نشست، درخت JSONL با وضعیت والد/برگ) را از رویدادهای زندهٔ محلی فرایند (دلتاهای جریانی، چرخهٔ عمر ابزار، تأییدها) جدا می‌کند و پروتکل worker باید این جداسازی را حفظ کند:

• ثبت‌های پایدار رونوشت: worker دسته‌های الحاق معنایی را همراه با runEpoch و عملیات مقایسه‌و‌تعویض برگ پایه ارسال می‌کند؛ مدیر نشست Gateway شناسه‌های ورودی و شناسه‌های والد را تولید می‌کند. worker هرگز نمی‌تواند ردیف‌های قابل‌اعتماد رونوشت، شناسه‌های ورودی، شناسه‌های والد یا شناسه‌های نشست خارجی را ارائه کند.
• رویدادهای زندهٔ قابل‌بازپخش: یک اجتماع نوع‌دار رویداد با شماره‌های توالی worker، ACKهای Gateway، نگه‌داری محدود و محصورسازی رویدادهای دیرهنگام که خروجی آن به توزیع موجود رویدادهای عامل وارد می‌شود تا نمای چت، ردیف‌های ابزار و منطق خوانده‌نشده/وضعیت، رفتاری یکسان با نشست‌های محلی داشته باشند.

پراکسی استنتاج: واژگان رویداد کلاینت جریان پراکسی زمان‌اجرای موجود (src/agents/runtime/proxy.ts) دوباره استفاده شود، اما مرز اعتماد جابه‌جا گردد. worker فقط هویت نشست/اجرا، یک ارجاع مدل تأییدشده، زمینه و گزینه‌های محدود تولید را ارسال می‌کند؛ Gateway ارائه‌دهنده، نقطهٔ پایانی، احراز هویت، سرآیندها، مسیریابی و سیاست هزینه را از کاتالوگ خودش حل می‌کند. شیء مدل ارائه‌شده توسط worker (برای مثال baseUrl تحت کنترل مهاجم) رد می‌شود. محدودیت‌های اندازهٔ درخواست، لغو، ممیزی و بازپخش نتیجهٔ نهایی اعمال می‌شوند. ابزارهای مستقر در Gateway (websearch) روی Gateway اجرا می‌شوند و نتایج را از همان کانال بازمی‌گردانند.

6. همگام‌سازی فضای کاری

لنگر همگام‌سازی، یک فضای کاری محلی Gateway با مالکیت انحصاری جای‌گذاری است: برای فضاهای کاری git، یک worktree مدیریت‌شدهٔ اختصاصی (فرادادهٔ موجود worktree مدیریت‌شده — شاخه، پایه، مالکیت snapshot — زیربنا است)؛ برای فضاهای کاری بدون git، یک پوشهٔ مقصد تحت مالکیت Gateway. هرگز checkout زندهٔ کاربر نیست. مالکیت انحصاری در زمانی که نشست از راه دور جای‌گذاری شده، باعث می‌شود همگام‌سازی ورودی ذاتاً بدون تعارض باشد.

تفکیک مالکیت — commit در برابر انتشار:

• عامل سمت worker به‌طور معمول در کپی خودش commit ایجاد می‌کند (git commit عملیاتی محلی و بدون اعتبارنامه است؛ هویت نویسنده از پیکربندی Gateway نگاشت می‌شود). این commitها تا زمانی که Gateway آن‌ها را نپذیرد، اشیایی بی‌اثر هستند.
• Gateway هر کاری را که به اعتماد نیاز دارد انجام می‌دهد: تأیید اینکه commitهای ورودی بر پایهٔ ثبت‌شده بنا شده‌اند، fast-forward کردن worktree محلی، push، ایجاد PR و امضای اختیاری/امضای مجدد — همگی با اعتبارنامه‌های محلی Gateway. worker هرگز اعتبارنامهٔ git یا forge را در اختیار ندارد و هرگز به remote دست نمی‌زند.

دو حالت همگام‌سازی که بر اساس git بودن مخزن فضای کاری انتخاب می‌شوند:

• حالت Git. خروجی: worktree با rsync (شامل فایل‌های commitنشده و فایل‌های untracked واجد شرایط؛ include/exclude به سبک crabbox، با رعایت .worktreeinclude) از طریق هویت SSH تونل منتقل و به‌عنوان یک مانیفست پایهٔ تغییرناپذیر (هش‌های محتوا + commit پایه) ثبت می‌شود. ورودی: commitهای جدید به‌شکل git bundle یا ref موقت نسبت به پایهٔ ثبت‌شده بازمی‌گردند؛ مصنوعات untracked از طریق مانیفستی صریح با بررسی اندازه/نوع/محصورسازی symlink بازمی‌گردند. پذیرش، تبار پایه را تأیید می‌کند و در صورت واگرایی متوقف می‌شود — هیچ‌چیز بی‌سروصدا هیچ‌یک از طرفین را بازنویسی نمی‌کند. حذف‌ها، تغییرنام‌ها، submoduleها و گریزهای symlink با قواعد مانیفست مدیریت می‌شوند، نه با روش‌های اکتشافی rsync.
• حالت ساده (بدون git — برای مثال ساخت یک پروژه از ابتدا روی box). خروجی همان rsync + مانیفست پایه است. ورودی یک آینهٔ مبتنی بر تفاوت مانیفست به پوشهٔ مقصد تحت مالکیت Gateway است که حذف‌ها را نیز منتقل می‌کند. به همان دلیل حالت git ایمن است: مالکیت انحصاری یعنی هیچ ویرایش محلی هم‌زمانی برای ایجاد تعارض وجود ندارد؛ مانیفست پایه همچنان تغییر محلی غیرمنتظره را تشخیص می‌دهد و به‌جای بازنویسی متوقف می‌شود.

checkpoint کردن، نشست‌های چندروزه را در برابر از دست رفتن lease محافظت می‌کند: checkpointهای ورودی دوره‌ای (commitهای شاخهٔ نشست در حالت git، snapshotهای مانیفست در حالت ساده)؛ تناوب، سیاست پروفایل است (پیش‌فرض مبتنی بر نوبت).

7. ماشین حالت جای‌گذاری، نشست‌ها و UI

جای‌گذاری زمان‌اجرا یک ماشین حالت تحت مالکیت SQLite و کلیدخورده بر اساس نشست است، نه یک جفت فیلد ردیف مستقل:

local → requested → provisioning → syncing → starting → active(worker) → draining → reconciling → local | reclaimed | failed

این ماشین، شناسهٔ محیط، نسل انتقال، دورهٔ مالک فعال، مانیفست پایهٔ فضای کاری، هش بستهٔ worker و آخرین مکان‌نماهای ACK را پایدار می‌کند. پذیرش نوبت، پیش از آنکه هر یک از حلقه‌ها نوبتی را آغاز کند، جای‌گذاری را به‌صورت اتمی مطالبه می‌کند؛ بنابراین پیام محلی پذیرفته‌شده بر اساس snapshot منقضی هرگز نمی‌تواند با نوبت worker وارد رقابت شود — در هر لحظه دقیقاً یک حلقه مالک نشست است.

UI:

• نشست worker یک ردیف نشست عادی به‌همراه فرادادهٔ جای‌گذاری است. در مخزن عادی قرار می‌گیرد، از طریق sessions.list فهرست می‌شود و از طریق اشتراک‌های موجود جریان می‌یابد — نوار کناری و چت به مسیر دادهٔ جدیدی نیاز ندارند، فقط به نمایش: نشان worker و وضعیت جای‌گذاری/محیط (provisioning / syncing / running / idle / reconciling / reclaimed).
• تجربهٔ ایجاد: نوار مقصد نشست (بازطراحی نوار کناری نشست‌ها) در کنار Gateway و Node یک مقصد worker ابری دریافت می‌کند. به پروفایل ارائه‌دهندهٔ پیکربندی‌شده نیاز دارد؛ این قابلیت تا زمان پیکربندی نامرئی است.
• اعزام عامل: یک ابزار نشست به عامل اجازه می‌دهد کار را همان‌گونه که انسان انجام می‌دهد به یک worker ابری بسپارد (زیرنشست مبتنی بر worker، به سبک subagent). در همان milestone اعزام انسانی عرضه می‌شود و با همان پیکربندی اختیاری ارائه‌دهنده محدود می‌گردد. بازگشت به‌صورت ساختاری محدود است (نشست‌های worker در v1 خودشان نمی‌توانند worker اعزام کنند)؛ کنترل هزینه، حسابداری/ممیزی به‌ازای هر محیط است، نه سازوکار سهمیه.

اعزام و تحویل

v1 عمداً نامتقارن است:

• محلی ← worker (اعزام): از مانع مهاجرت زیر عبور کنید، یک worker فراهم یا دوباره استفاده کنید، همگام‌سازی کنید، جای‌گذاری را تغییر دهید؛ نوبت بعدی از راه دور اجرا می‌شود.
• worker ← محلی (بازکشیدن): نشست را متوقف کنید (worker را با همان مانع تخلیه کنید)، تطبیق ورودی را کامل کنید و جای‌گذاری را به محلی تغییر دهید. این مهاجرت زنده نیست.
• تحویل زندهٔ متقارن (جابه‌جایی نشست فعال در هر دو جهت بدون توقف) از همان مانع و سازوکار تطبیق استفاده می‌کند و پس از آن عرضه می‌شود که آزمون‌های تزریق خطا مانع را اثبات کنند.

مانع مهاجرت («مرز نوبت» به‌تنهایی کافی نیست — تأییدها، فرایندهای پس‌زمینه و ادغام رونوشت پس از آزادسازی قفل می‌توانند از آن عبور کنند):

1. پذیرش نوبت جدید را متوقف کنید (مطالبهٔ جای‌گذاری).
2. اجراهای فعال را لغو یا تخلیه کنید.
3. تأییدهای معلق exec و مجوزهای اجرا را لغو کنید.
4. نوشتن‌های جانبی رونوشت و ACKهای رویداد زنده را تخلیه کنید.
5. فرایندهای فرزند worker را خاتمه دهید.
6. با جلو بردن دورهٔ مالک، مالک قدیمی را محصور کنید.
7. فضای کاری را تطبیق دهید (ورودی، با آگاهی از تعارض).
8. مالک جدید را فعال کنید.

هم‌بستگی حافظهٔ نهان: چون درخواست‌های ارائه‌دهنده در هر دو جای‌گذاری از Gateway سرچشمه می‌گیرند، هنگامی که درخواست سریال‌شدهٔ ارائه‌دهنده معادل باقی بماند، هم‌بستگی حافظهٔ نهان حفظ می‌شود — همان ترتیب ابزارها، دستورالعمل‌های سیستم، wrapperهای ارائه‌دهنده و فرادادهٔ حافظهٔ نهان (که سمت Gateway باقی می‌مانند). این ویژگی قابل‌آزمون است، نه یک فرض: آزمون‌های هم‌ارزی بایتی بین جای‌گذاری محلی/worker برای هر انتقال پشتیبانی‌شدهٔ ارائه‌دهنده، بخشی از milestone معرفی‌کنندهٔ حلقهٔ worker هستند.

مدل امنیتی

بیان دقیق: worker خروجی مستقیم شبکه و اعتبارنامهٔ دائمی ارائه‌دهنده/forge ندارد. این وضعیت «خروجی صفر» نیست — استنتاج و ابزارهای اجراشده توسط Gateway کانال‌های خروجی کنترل‌شده هستند (worker تحت تزریق پرامپت همچنان می‌تواند بایت‌های فضای کاری را در زمینهٔ مدل یا پرس‌وجوهای websearch قرار دهد). بنابراین:

• حسابداری خروجی کنترل‌شده: ممیزی به‌ازای هر محیط و حسابداری قابل‌مشاهده برای اپراتور در پراکسی استنتاج و ابزارهای Gateway. محدودیت نرخ/بایت به‌عنوان کنترل جریان پروتکل (ظرفیت) وجود دارد، نه به‌عنوان سازوکار سهمیهٔ هزینه.
• ورودی worker به Gateway همان فهرست مجاز بستهٔ پروتکل worker است؛ نوشتن‌های رونوشت به‌صورت ساختاری محدودند (شناسه‌های تولیدشده توسط Gateway، یک نشست مقید).
• exec در worker درون box دسترسی کامل دارد. box یک‌بارمصرف و بدون اعتبارنامه است، بنابراین تأیید به‌ازای هر فرمان بدون محافظت از چیزی اصطکاک ایجاد می‌کند؛ مرز محافظت‌شده، تطبیق ورودی و ممیزی است. exec هرگز از مسیر تأیید Node در Gateway عبور نمی‌کند.
• سیاست اینترنت تصمیمی از سوی ارائه‌دهنده در زمان فراهم‌سازی است: پروفایل محیط هنگام ایجاد box تصمیم می‌گیرد (فایروال/گروه امنیتی/شبکهٔ بدون خروجی)، در صورت نیاز همراه با مرحلهٔ راه‌اندازی شبکه‌دار که ارائه‌دهنده پیش از مرحلهٔ عامل آن را می‌بندد. هسته یک toggle شبکه در زمان‌اجرا پیاده‌سازی نمی‌کند.
• بهداشت box در زمان فراهم‌سازی: نقطهٔ پایانی فرادادهٔ ابری مسدود یا نبودنش تأیید شده، بدون پروفایل instance، بدون عامل SSH ارث‌رسیده، بدون socket مربوط به Docker، با env/home پاک. کلیدهای میزبان SSH از خروجی فراهم‌سازی pin می‌شوند.
• تأییدها و سیاست هر چیزی در سمت Gateway (push، PR، فراخوانی‌های ارائه‌دهنده) همچنان روی Gateway اجرا می‌شوند.

دامنهٔ آسیب نشست worker به‌خطر‌افتاده: کپی همگام‌شدهٔ فضای کاری به‌علاوهٔ آنچه کانال‌های پراکسی ممیزی‌شده اجازه می‌دهند — بدون اعتبارنامه، بدون شبکهٔ مستقیم و بدون هیچ سطح Gateway فراتر از فهرست مجاز.

ظرفیت

Gateway هر پرامپت و جریان توکن را برای N worker رله می‌کند، بنابراین v1 به‌جای کشف مدل ظرفیت در محیط تولید، آن را مشخص می‌کند: محدودیت workerهای هم‌زمان به‌ازای هر Gateway، پنجره‌های اعتبار به‌ازای هر جریان (صف جریان رویداد فعلی نامحدود است و سقف بافر socket مربوط به Node مصرف‌کنندگان کند را به‌اجبار قطع می‌کند — هیچ‌کدام بدون تغییر مناسب نیستند)، ذخیره‌سازی موقت محدود روی دیسک برای جهش‌ها و کاهش بار همراه با وضعیت‌های فشار برگشتی قابل‌مشاهده در UI. انتقال فضای کاری در کانال SSH جداگانهٔ خود باقی می‌ماند.

چرخهٔ عمر

• توقف خودکار در حالت بیکار و TTL سیاست پروفایل ارائه‌دهنده‌اند، نه ثابت‌های ازپیش‌تعیین‌شده. پیش‌فرض‌ها همراه با keep-alive صریح سخاوتمندانه‌اند؛ کار چندروزه شهروند درجه‌یک است (renew ارائه‌دهنده برای بک‌اندهای مبتنی بر lease وجود دارد)؛ نشستی با نوبت در حال اجرا یا فعالیت اخیر هرگز بازیابی نمی‌شود.
• هنگام مرگ یا بازیابی worker: جای‌گذاری به reclaimed منتقل می‌شود، ردیف نشست باقی می‌ماند و پیام بعدی یک worker تازه فراهم می‌کند و از آخرین checkpoint دوباره همگام می‌شود. مکالمه هرگز از دست نمی‌رود (مخزن سمت Gateway)؛ تغییرات فضای کاری پس از آخرین checkpoint از دست می‌روند و UI این موضوع را اعلام می‌کند.
• استفادهٔ مجدد از lease گرم از روز نخست (برای ارائه‌دهندگانی که از آن پشتیبانی می‌کنند)؛ snapshot تصویر پس از bootstrap مسیر شروع سریع v2 است.

سطح پیکربندی

حداقلی و اختیاری: یک بلوک پروفایل ارائه‌دهنده (شناسهٔ ارائه‌دهنده، ارجاع اعتبارنامه/CLI، قواعد همگام‌سازی، سیاست طول عمر، بودجه‌ها، مرحلهٔ راه‌اندازی اختیاری) به‌علاوهٔ انتخاب جای‌گذاری برای هر نشست. هیچ متغیر محیطی جدیدی وجود ندارد. نصب‌های پیکربندی‌نشده چیزی نمی‌بینند.

milestoneها

پیاده‌سازی در قالب PRهای کوچک و مستقلِ قابل‌ادغام ارائه می‌شود؛ هر milestone زیر یک مجموعه PR است، نه یک تغییر.

1. مبانی: ماشین حالت محیط + قرارداد ارائه‌دهنده + ارائه‌دهنده با ساختار crabbox ‏(SSH ایستا به‌عنوان بستر توسعه)، راه‌اندازی اولیه بسته worker + دست‌دهی پذیرش، تونل SSH + تثبیت کلید میزبان، snapshot از worktree مدیریت‌شده + همگام‌سازی خروجی (حالت‌های git + ساده). پاک‌سازی موارد یتیم + پذیرش مجدد پس از راه‌اندازی.
2. پروتکل worker + حلقه worker: نقش worker احراز هویت‌شده، عملیات/دوره‌ها/مکان‌نماهای ACK پایدار، ثبت نهایی رونوشت + قراردادهای رویداد زنده، پراکسی استنتاج با مدل‌های حل‌شده توسط Gateway، کنترل جریان. یک ارائه‌دهنده، اعزام دستی فقط برای نشست‌های جدید، بدون تحویل. آزمون‌های تزریق خطا (قطع تونل، راه‌اندازی مجدد Gateway، ازکارافتادن worker) شرط خروج هستند.
3. اعزام + بازکشیدن + اعزام عامل: مانع مهاجرت، ماشین حالت جای‌دهی متصل به نوار مقصد رابط کاربری، تطبیق ورودی + نقاط وارسی، ممیزی به‌ازای هر محیط، محدودیت‌های ظرفیت، ابزار اعزام عامل (نشست‌های worker نمی‌توانند بازگشتی عمل کنند). آزمون‌های هم‌ارزی بایت‌به‌بایت کش پرامپت.
4. تحویل زنده متقارن، پس از اثبات تزریق خطای milestone-3.

بعداً: بسترهای ACP روی workerها به‌صورت انتخاب اختیاری آب‌رسانی اعتبارنامه به‌ازای هر محیط؛ شروع سریع با snapshot/تصویر گرم؛ انشعاب (N اجاره، پرامپت یکسان)؛ سندباکس‌کردن سیستم‌عامل درون جعبه؛ ثبت غنی‌تر مصنوعات از طریق شِمای مصنوعات.

پرسش‌های باز

• دردسترس‌بودن Plugin/skill روی workerها: Skills همراه مخزن بدون هزینه همراه با فضای کاری همگام می‌شوند؛ Skills/Pluginهای عاملِ پیکربندی‌شده در Gateway به تصمیمی صریح برای همگام‌سازی یا کنارگذاری نیاز دارند (در هر صورت، مانیفست ابزار/Plugin بخشی از دست‌دهی پذیرش است).
• پیش‌فرض تناوب نقاط وارسی: مبتنی بر نوبت در برابر مبتنی بر زمان برای نشست‌های بسیار پرگفت‌وگو.
• نحوه تعامل پروفایل‌های محیط با مسیریابی چندعاملی (پروفایل‌های پیش‌فرض به‌ازای هر عامل در برابر انتخاب صرفاً به‌ازای هر نشست).