برنامهٔ کارگرهای ابری

وضعیت

پیشنهاد، بازبینی ۳. پیاده‌سازی نشده است. جهت‌گیری در ۲۰۲۶-۰۷ مورد توافق قرار گرفت؛ بازبینی ۲ یافته‌های بررسی خصمانه را دربر گرفت (پروتکل اختصاصی worker، ماشین‌های حالت استقرار/محیط، همگام‌سازی ورودی آگاه از git، واگذاری یک‌طرفه در نسخه ۱، و عبارت‌بندی امنیتی خروجی کنترل‌شده). بازبینی ۳ مدل مالکیت همگام‌سازی را نهایی می‌کند (worker کامیت‌ها را ایجاد می‌کند، Gateway آن‌ها را می‌پذیرد و منتشر می‌کند)، حالت همگام‌سازی ساده بدون git را می‌افزاید، اجرای worker را در سطح دسترسی کامل درون ماشین اصلاح می‌کند، سیاست اینترنت را به زمان آماده‌سازی منتقل می‌کند و اعزام عامل را به نقطه عطف ۳ بازمی‌گرداند.

مشکل

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

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

اهداف

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

خارج از اهداف (نسخه ۱)

• هیچ چارچوب کدنویسی خارجی (Claude Code، Codex CLI) روی workerها وجود ندارد. نشست‌های worker فقط اجراکننده تعبیه‌شده OpenClaw را اجرا می‌کنند. پشتیبانی از چارچوب‌ها قابلیتی انتخابی برای نسخه ۲ است، زیرا این چارچوب‌ها استنتاج خود را با اعتبارنامه‌های خودشان انجام می‌دهند.
• بدون انشعاب چند تلاش موازی / انتخاب بهترین از میان N تلاش.
• بدون وابستگی به VPN یا شبکه خصوصی. انتقال فقط از طریق SSH انجام می‌شود.
• بدون محیط اجرای ایزوله جدید. خود ماشین worker مرز جداسازی است؛ ایزوله‌سازی سیستم‌عامل درون ماشین را می‌توان بعداً به آن افزود.
• بدون مهاجرت زنده متقارن در نسخه ۱: اعزام از محلی به worker انجام می‌شود؛ بازگشت از worker به محلی به نشست متوقف‌شده و تکمیل تطبیق فضای کاری نیاز دارد. واگذاری زنده دوطرفه بعداً بر همان سازوکارهای مانع بنا خواهد شد.
• بدون حالت جانبی JSON در Gateway؛ وضعیت محیط، استقرار، مکان‌نما و مجوز در SQLite نگهداری می‌شود.

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

• عامل‌های ابری Cursor: حلقه عامل در ابر آن‌ها اجرا می‌شود؛ ماشین مجازی هدف اجرای ابزار است؛ مخزن مکالمه فقط‌افزودنی به همه کارخواه‌ها جریان داده می‌شود؛ تصویر لحظه‌ای پس از نصب برای شروع گرم؛ workerهای خودمیزبان فرایندهایی هستند که فقط اتصال خروجی دارند. مدل «منبع حقیقت مکالمه روی هماهنگ‌کننده باقی می‌ماند» و مدل جریان‌دهی را اقتباس می‌کنیم؛ محل اجرای حلقه را معکوس می‌کنیم (تصمیم زیر را ببینید).
• Codex cloud: محیط اجرای دومرحله‌ای — مرحله راه‌اندازی متصل به شبکه، سپس مرحله آفلاین عامل با حذف اسرار؛ کش وضعیت کانتینر برای ادامه‌های سریع. جداسازی مراحل را به‌عنوان رویکرد خروجی شبکه و ایده کش را برای تصاویر گرم نسخه ۲ اقتباس می‌کنیم.
• نسخه وب Claude Code: ماشین مجازی جداگانه برای هر نشست؛ پراکسی git جداکننده اعتبارنامه‌ها (توکن‌های واقعی هرگز وارد محیط ایزوله نمی‌شوند و push به شاخه نشست محدود است)؛ تصویر لحظه‌ای سامانه فایل پس از راه‌اندازی؛ واگذاری انتقالی = شاخه push‌شده + تاریخچه بازپخش‌شده. جداسازی اعتبارنامه و چارچوب واگذاری را اقتباس می‌کنیم، اما همگام‌سازی خروجی با rsync از Gateway انجام می‌شود تا درخت‌های کاری دارای تغییر نیز کار کنند و هیچ توکن سامانه میزبانی کدی در نزدیکی ماشین وجود نداشته باشد.
• عامل کدنویسی Copilot: خروجی شبکه به‌صورت پیش‌فرض ممنوع و دارای فهرست مجاز مخازن بسته‌ها است. پیش‌فرض حالت پایدار ما قوی‌تر است (هیچ خروجی مستقیمی وجود ندارد)، زیرا استنتاج و جست‌وجوی وب از طریق تونل SSH می‌رسند — اما برای دلیل استفاده از اصطلاح «خروجی کنترل‌شده» به‌جای «خروجی صفر»، بخش امنیت را ببینید.

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

سه محل استقرار بررسی شد:

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

هزینه گزینه ۳، وابستگی همگام به Gateway در طول هر نوبت مدل است؛ بنابراین قواعد دوام آن بخشی از تصمیم هستند، نه ملاحظه‌ای پسینی:

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

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

مؤلفه‌ها

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

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

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

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

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

type WorkerProvider = {  id: string;  provision(profile: WorkerProfile, opId: string): Promise&lt;WorkerLease&gt;; // → ssh host/port/user/key material  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise&lt;LeaseStatus&gt;; // adopt/health/orphan sweep  renew?(leaseId: string): Promise<void>; // long-lived sessions vs provider TTLs  destroy(lease: { leaseId: string; profile: WorkerProfile }): Promise<void>; // idempotent, returns only on proof of teardown};

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

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

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

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

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

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

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

• Gateway با استفاده از اعتبارنامه‌های اجاره ارائه‌دهنده به worker متصل می‌شود، کلید میزبان را از خروجی آماده‌سازی پین می‌کند — بدون StrictHostKeyChecking=no — و یک تونل معکوس برقرار می‌کند که سوکت محلی worker را به نقطه پایانی WS در Gateway هدایت می‌کند.
• ترافیک کنترل/مدل و انتقال فضای کاری از اتصال‌های SSH جداگانه با همان داده اعتماد پین‌شده استفاده می‌کنند تا rsync نتواند جریان توکن‌ها را با انسداد ابتدای صف متوقف کند.
• چرخه عمر تونل (زنده‌نگه‌داشتن و اتصال مجدد با پس‌نشینی) تحت مالکیت محیط اجرای محیط در Gateway است. اختلال تونل در سطح نشست نامرئی است: وضعیت پایدار پروتکل (در ادامه) به worker اجازه می‌دهد دوباره متصل شود و ادامه دهد.

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

بررسی خصمانه در برابر مرزهای فعلی Node، استفاده مجدد ساده را رد کرد: فراخوانی‌های معلق Node وعده‌های درون‌فرایندی هستند که با اتصال از بین می‌روند، کلیدهای هم‌توانی Node تجزیه می‌شوند اما تکراری‌ها حذف نمی‌شوند و — مهم‌تر از همه — یک Node متصل می‌تواند رویدادهای عادی Node (از جمله درخواست‌های اجرای عامل) را منتشر کند؛ بنابراین «نوع Node + سقف قابلیت» مرز امنیتی ورودی نیست. در نتیجه، workerها نقشی احرازهویت‌شده با نام worker و فهرست مجاز بسته و نسخه‌بندی‌شده‌ای از RPCها/رویدادها دریافت می‌کنند؛ اتصال‌های worker نمی‌توانند به هیچ مدیریت‌کننده رویداد قدیمی Node دسترسی پیدا کنند.

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

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

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

۵. RPCهای پشتیبان نشست

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

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

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

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

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

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

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

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

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

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

۷. ماشین حالت جای‌گذاری، نشست‌ها و رابط کاربری

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

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

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

رابط کاربری:

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

اعزام و تحویل

نسخهٔ ۱ عمداً نامتقارن است:

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

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

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

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

مدل امنیتی

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

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

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

ظرفیت

Gateway هر prompt و جریان token را برای N کارگر رله می‌کند؛ بنابراین نسخهٔ ۱ به‌جای کشف ظرفیت در محیط عملیاتی، یک مدل ظرفیت تعریف می‌کند: محدودیت کارگر هم‌زمان به‌ازای هر Gateway، پنجره‌های اعتبار به‌ازای هر جریان (صف جریان رویداد کنونی نامحدود است و سقف بافر سوکت Node مصرف‌کنندگان کند را به‌اجبار قطع می‌کند — هیچ‌یک بدون تغییر مناسب نیستند)، spool دیسک محدود برای جهش‌های بار و کاهش بار با وضعیت‌های فشار برگشتی قابل مشاهده در رابط کاربری. انتقال فضای کاری روی کانال SSH اختصاصی خودش باقی می‌ماند.

چرخهٔ عمر

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

سطح پیکربندی

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

نقاط عطف

پیاده‌سازی در قالب PRهای کوچک و قابل ادغام مستقل انجام می‌شود؛ هر نقطهٔ عطف زیر یک مجموعه PR است، نه یک تغییر واحد.

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

بعداً: ابزارهای ACP روی کارگرها به‌صورت فعال‌سازی اختیاری تزریق اعتبارنامه به‌ازای هر محیط؛ شروع سریع با snapshot/تصویر گرم؛ fan-out (N lease، prompt یکسان)؛ sandbox سیستم‌عامل درون جعبه؛ ثبت غنی‌تر مصنوعات از طریق schema مصنوعات.

پرسش‌های باز

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