خطة العمال السحابيين

الحالة

مقترح، المراجعة 3. غير مُنفَّذ. تم الاتفاق على التوجه في 2026-07؛ أدرجت المراجعة 2 نتائج المراجعة المضادة (بروتوكول مخصص للعامل، وآلات حالات للموضع والبيئة، ومزامنة واردة مدركة لـ git، وتسليم أحادي الاتجاه في الإصدار v1، وصياغة أمنية للخروج الشبكي المتحكم فيه). تحسم المراجعة 3 نموذج ملكية المزامنة (ينشئ العامل الالتزامات، ويتبناها Gateway وينشرها)، وتضيف وضع مزامنة عاديًا من دون git، وتصحح تنفيذ العامل إلى كامل الصلاحيات داخل الصندوق، وتنقل سياسة الإنترنت إلى وقت التوفير، وتعيد إرسال الوكيل إلى المرحلة الرئيسية 3.

المشكلة

تشغّل جلسات وكيل OpenClaw حلقتها وأدواتها والاستدلال داخل عملية Gateway على جهاز واحد. تكون القدرة الحاسوبية محدودة بقدرات ذلك الجهاز، وتشغله المهام الطويلة، ويتنافس العمل المتوازي على موارده. تحل المنتجات المستضافة (وكلاء Cursor السحابيون، وClaude Code على الويب، وCodex cloud) هذه المشكلة باستخدام بيئات سحابية مؤقتة لكل مهمة، لكنها تتطلب بنية تحتية تابعة للمورّد والثقة به.

لا توجد وسيلة تتيح للمشغّلين الذين يملكون بالفعل أجهزة احتياطية (أو يمكنهم استئجارها بتكلفة منخفضة) أن يقولوا: شغّل هذه الجلسة هناك، واعرضها في شريطي الجانبي مثل أي جلسة أخرى، ثم تخلّص من الجهاز بعد ذلك.

الأهداف

• تشغيل جلسة وكيل كاملة (الحلقة + الأدوات) على جهاز بعيد مؤقت («عامل سحابي»)، مع ظهور الجلسة وبثها في واجهة التحكم تمامًا مثل الجلسة المحلية.
• عدم وجود بيانات اعتماد دائمة على العامل (لا مصادقة لمزوّد، ولا رموز لمنصة استضافة الشيفرة) وعدم وجود خروج شبكي مباشر؛ لا يحتاج الصندوق إلا إلى خدمة sshd قابلة للوصول.
• التوفير والمزامنة والتشغيل والجمع والتدمير — بأتمتة كاملة، مع قابلية تبديل المزوّد (المزوّد الأول: واجهات CLI لاستئجار الموارد على نمط Crabbox).
• إرسال العمل الجاري من Gateway إلى عامل عند حدّ دورة من دون فقدان النص المنسوخ للجلسة أو هوية الجلسة أو تقارب ذاكرة التخزين المؤقت لدى المزوّد (عندما تظل بايتات الطلب متكافئة)؛ ثم سحب النتائج بأمان.
• تمكين كل من البشر (عبر الواجهة) والوكلاء (عبر الأداة) من إرسال العمل إلى عامل سحابي.
• دعم الجلسات الممتدة لأيام؛ مدة البقاء سياسة وليست حدًا ثابتًا مضمّنًا في الشيفرة.

غير مستهدف (v1)

• لا توجد أُطر برمجية خارجية للبرمجة (Claude Code وCodex CLI) على العمال. تشغّل جلسات العامل مشغّل OpenClaw المضمّن فقط. دعم الأُطر خيار اشتراك في v2 لأن الأُطر تنفّذ استدلالها الخاص باستخدام بيانات اعتمادها الخاصة.
• لا توجد محاولات متعددة لاختيار الأفضل من N، ولا توزيع متوازٍ للمحاولات.
• لا يوجد اعتماد على VPN أو شبكة tailnet. النقل عبر SSH فقط.
• لا توجد بيئة تشغيل جديدة للعزل. جهاز العامل هو حد العزل؛ ويمكن إضافة عزل نظام التشغيل داخل الصندوق لاحقًا.
• لا توجد هجرة حية متناظرة في v1: الإرسال من المحلي ← العامل؛ وتتطلب العودة من العامل ← المحلي جلسة متوقفة مع اكتمال تسوية مساحة العمل. سيُبنى التسليم الحي ثنائي الاتجاه لاحقًا على آلية الحواجز نفسها.
• لا توجد حالة جانبية بصيغة JSON على Gateway؛ تعيش حالات البيئة والموضع والمؤشر والمنح في SQLite.

الأعمال السابقة (ما ننسخه وما نعكسه)

• وكلاء Cursor السحابيون: تعمل حلقة الوكيل في سحابتهم؛ والآلة الافتراضية هدف لتنفيذ الأدوات؛ ومخزن محادثة للإلحاق فقط يُبث إلى جميع العملاء؛ وبدء سريع من لقطة بعد التثبيت؛ والعمال المستضافون ذاتيًا عمليات عمال للاتصال الصادر فقط. ننسخ نموذج «يبقى مصدر الحقيقة للمحادثة لدى المنسّق» ونموذج البث؛ ونعكس موضع الحلقة (راجع القرار أدناه).
• Codex cloud: تشغيل على مرحلتين — مرحلة إعداد متصلة بالشبكة، ثم مرحلة وكيل غير متصلة مع إزالة الأسرار؛ وذاكرة تخزين مؤقت لحالة الحاوية لتسريع المتابعات. ننسخ فصل المراحل بوصفه نهجنا للخروج الشبكي، وفكرة ذاكرة التخزين المؤقت للصور الدافئة في v2.
• Claude Code على الويب: آلة افتراضية لكل جلسة؛ ووسيط git يعزل بيانات الاعتماد (لا تدخل الرموز الحقيقية إلى البيئة المعزولة أبدًا، ويقتصر الدفع على فرع الجلسة)؛ ولقطة لنظام الملفات بعد الإعداد؛ وتسليم بالنقل الآني = فرع مدفوع + سجل معاد تشغيله. ننسخ عزل بيانات الاعتماد وتأطير التسليم، لكن المزامنة الصادرة تتم عبر rsync من Gateway لكي تعمل أشجار العمل غير النظيفة، ولا يوجد رمز لمنصة استضافة الشيفرة في أي مكان قريب من الصندوق.
• وكيل البرمجة Copilot: رفض افتراضي للخروج الشبكي مع قائمة سماح لسجلات الحزم. الوضع الافتراضي في الحالة المستقرة لدينا أقوى (لا خروج مباشر على الإطلاق) لأن الاستدلال والبحث على الويب يصلان عبر نفق SSH — لكن راجع قسم الأمان لمعرفة سبب تسمية ذلك «خروجًا شبكيًا متحكمًا فيه»، وليس «انعدام الخروج الشبكي».

القرار المعماري: الحلقة على العامل، والاستدلال عبر Gateway

تم النظر في ثلاثة مواضع:

1. تبقى الحلقة على Gateway وينفّذ العامل الأدوات (نموذج Cursor). هذا هو نطاق الفشل الأكثر أمانًا (يبقى النص المنسوخ، والاستدلال، والموافقات، والتعافي من إعادة التشغيل محليًا)، وكان المرحلة الرئيسية الأولى المفضلة لدى أحد المراجعين. رُفض بوصفه معمارية المنتج: أدوات OpenClaw غير التنفيذية هي عمليات نظام ملفات داخل العملية، ولذلك تصبح كل قراءة أو عملية تحرير أو grep للملفات رحلة شبكية ذهابًا وإيابًا، أو تتطلب إعادة هيكلة كبيرة لسطح الأدوات إلى استدعاءات RPC لمساحة العمل خشنة الحبيبات؛ وسلوك وقت التشغيل كثير التفاعل ومقيد بزمن الاستجابة. نعيد استخدام فكرته حيث تكون مبنية بالفعل (تفويض التنفيذ إلى Node)، لكننا لا نبني طبقة تشغيل الأدوات عن بُعد.
2. تعمل الحلقة والاستدلال كلاهما على العامل. هذا أبسط نطاق للفشل، لكن يجب إرسال بيانات اعتماد النموذج (بما في ذلك ملفات تعريف OAuth) إلى أجهزة مؤقتة، ويفقد Gateway التحكم في السياسة والتوجيه والتدقيق، وتغيّر الهجرة الهوية التي تستدعي المزوّد، مما يبطل ذاكرات التخزين المؤقت لدى المزوّد.
3. الحلقة + الأدوات على العامل، مع تمرير استدعاءات النموذج عبر Gateway. هذا هو الخيار المختار. رحلة واحدة ذهابًا وإيابًا لكل دورة نموذج بدلًا من كل استدعاء أداة؛ وتعمل الأدوات بجوار الشيفرة؛ ويبقى Gateway المالك الوحيد لملفات تعريف المصادقة وتوجيه المزوّد والسياسة؛ ولا يحتفظ العامل بأي أسرار.

تكلفة الخيار 3 هي الاعتماد المتزامن على Gateway أثناء كل دورة نموذج، ولذلك تُعد قواعد متانته جزءًا من القرار وليست فكرة لاحقة:

• يؤدي فقدان Gateway في منتصف الدورة إلى فشل استدعاء المزوّد النشط. تُعلَّم الدورة بأنها فاشلة وتُعاد محاولتها بوصفها دورة جديدة بعد إعادة الاتصال؛ ولا توجد إعادة تشغيل شفافة لتدفق مزوّد قيد التنفيذ (بسبب مخاطر الفوترة المزدوجة أو استدعاء الأدوات مرتين).
• تحمل كل عملية بين العامل وGateway هوية دائمة (راجع بروتوكول العامل)، لكي تستأنف عمليات إعادة الاتصال أو تجلب النتائج النهائية المخزنة مؤقتًا بدلًا من أن تظل معلّقة.
• يُدار Gateway وفقًا للسعة: حدود العمال المتزامنين، والتحكم في التدفق، وتخفيف الحمل ضمن نطاق v1 (راجع السعة).

لأن Gateway يخزّن النص المنسوخ ويُنشئ كل حركة المرور إلى المزوّد، تكون الجلسة مستقلة عن الموقع: لا يغيّر نقل الحلقة بين Gateway والعامل أي شيء من جهة المزوّد أو في مسار بيانات الواجهة. وهذا ما يجعل الإرسال والسحب مجددًا منخفضي التكلفة.

المكوّنات

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 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 ثابت معلَّم بأنه للتطوير فقط — يمكن لعامل على مضيف مشترك قراءة بيانات أخرى غير مرتبطة على المضيف، ولذلك تُستخدم المضيفات الثابتة لتطوير الميزة، لا بوصفها الوضع الافتراضي.

2. تمهيد العامل: تثبيت OpenClaw على الصندوق

لا توجد تحفة عامل مخصصة، ولا اعتماد على توفر npm:

• التثبيت المرجعي لجميع الأوضاع: حزمة عامل ذات تجزئة محتوى ينشئها Gateway (مخرجات بناء Gateway نفسه معبأة في ملف tar)، وتُدفع عبر SSH وتُثبّت على الصندوق. يغطي هذا إصدارات التطوير والالتزامات غير المنشورة بحكم التصميم.
• يُعد npm i -g openclaw@<exact gateway version> تحسينًا عندما يشغّل Gateway إصدارًا منشورًا؛ ولا يُستخدم latest أبدًا.
• التمهيد متكرر التنفيذ بأمان؛ يتخطى الاستئجار الدافئ ذو تجزئة الحزمة المطابقة التثبيت. قد تحتاج الأجهزة الخام إلى مرحلة مجموعة أدوات متصلة بالشبكة (بيئة تشغيل Node) — وهي جزء من مرحلة الإعداد، وتُغلق بعد ذلك.
• تتحقق المصافحة من تجزئة بناء العامل ومجموعة ميزات البروتوكول وتوافق بيئة التشغيل. فحوص الإصدار والبروتوكول الحالية في Gateway غير كافية لهذا الغرض (تُعفى عُقد Node المتصلة عبر نفق SSH من الرفض بسبب عدم تطابق الإصدار تمامًا)، ولذلك ينفّذ قبول العامل فحصه الخاص للتطابق الدقيق للبناء.

وضع العامل (openclaw worker) هو نقطة دخول وليس تفرعًا: معالجة الاتصال بالإضافة إلى مشغّل الوكيل المضمّن، مع دعم استمرارية الجلسة واستدعاءات النموذج عبر استدعاءات RPC إلى Gateway. يجب ألا يشغّل أسطح Gateway: لا قنوات، ولا بدء تلقائي لأي Plugin خارج مجموعة أدوات الجلسة، ودليل حالة مؤقت، ولا ملفات تعريف مصادقة محلية.

3. النقل: كل شيء عبر SSH

يمتلك Gateway الاتصال؛ ولا يحتاج العامل إلى شيء سوى sshd:

• يفتح Gateway اتصال SSH بالعامل (باستخدام بيانات الاعتماد من استئجار المزوّد، مع تثبيت مفتاح المضيف من مخرجات التوفير — لا استخدام لـ StrictHostKeyChecking=no) وينشئ نفقًا عكسيًا يعيد توجيه مقبس محلي للعامل إلى نقطة نهاية WS الخاصة بـ Gateway.
• تستخدم حركة التحكم/النموذج ونقل مساحة العمل اتصالات SSH منفصلة بمواد الثقة المثبّتة نفسها، لكي لا يتسبب rsync في حجب تدفقات الرموز في مقدمة الصف.
• تمتلك بيئة التشغيل الخاصة بالبيئة على Gateway دورة حياة النفق (إبقاء الاتصال حيًا، وإعادة الاتصال مع تراجع زمني). يكون الانقطاع العابر للنفق غير مرئي على مستوى الجلسة: تسمح حالة البروتوكول الدائمة (أدناه) للعامل بإعادة الإرفاق والاستئناف.

4. بروتوكول العامل (مخصص؛ وليس بروتوكول Node)

استبعدت المراجعة المضادة وفق منافذ Node الحالية إعادة الاستخدام المباشر: استدعاءات Node المعلّقة هي وعود محلية للعملية تموت مع الاتصال، وتُحلَّل مفاتيح تكرار التنفيذ الخاصة بـ Node من دون إزالة التكرار، والأهم أن Node متصلة يمكنها إصدار أحداث Node عادية (بما فيها طلبات تشغيل الوكيل)، ولذلك لا يشكل «نوع Node + سقف الإمكانات» حدًا أمنيًا للدخول. لذلك يحصل العمال على دور worker مصادق عليه، مع قائمة سماح مغلقة ومحددة الإصدارات لاستدعاءات RPC والأحداث؛ ولا يمكن لاتصالات العامل الوصول إلى أي معالج قديم لأحداث Node.

الهوية وبيانات الاعتماد: ينشئ التوفير بيانات اعتماد قصيرة الأجل للعامل مرتبطة بمعرّف البيئة، ومفتاح العامل، وتجزئة الحزمة، والجلسة الوحيدة المسموح بها، ومجموعة استدعاءات RPC المسموح بها، ووقت انتهاء الصلاحية. يظل الاقتران المتحقق منه عبر SSH ساريًا (فنحن من وفّر الصندوق ونحتفظ بالمفتاح)، لكن التخويل يأتي من بيانات الاعتماد المنشأة، لا من سطح Node المعلن.

دلالات العمليات الدائمة (الشكل مستعار من بيئة تشغيل ACP الحالية وسجل أحداثها — مقابض مستقرة، وتسلسل لكل جلسة، وإعادة تشغيل دائمة لـ (session, seq)):

• يقتصر نطاق كل عملية على (sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq).
• تعزل حقب الملكية العمال المتقادمين: يقدّم العامل البديل الحقبة؛ وتُرفض النتائج المتأخرة من الحقبة القديمة بصورة حتمية.
• تسليم مرة واحدة على الأقل مع مؤشرات ACK محفوظة ونتائج نهائية مخزنة مؤقتًا في SQLite؛ وتكون إزالة التكرار حتمية. لا توجد وعود بتنفيذ مرة واحدة بالضبط.
• إطارات صريحة للإلغاء والإغلاق والاستئناف والنتائج النهائية؛ وتحكم في التدفق قائم على الرصيد/النافذة في التدفقات.
• يكون تفاوض ميزات البروتوكول مستقلًا عن إصدار بروتوكول Node العام.

5. استدعاءات RPC للواجهة الخلفية للجلسة

عقدان منفصلان — تفصل قاعدة الشيفرة الحالية بين تعديلات سجل المحادثة الدائمة (التي يديرها مدير الجلسة، وهي شجرة JSONL ذات حالة أب/ورقة) والأحداث الحية المحلية للعملية (فروق التدفق، ودورة حياة الأدوات، والموافقات)، ويجب أن يحافظ بروتوكول العامل على هذا الفصل:

• عمليات إيداع سجل المحادثة الدائمة: يرسل العامل دفعات إلحاق دلالية مع runEpoch ومقارنة وتبديل للورقة الأساسية؛ وينشئ مدير جلسات Gateway معرّفات الإدخالات ومعرّفات الآباء. لا يمكن للعامل مطلقًا تقديم صفوف موثوقة لسجل المحادثة، أو معرّفات إدخالات، أو معرّفات آباء، أو معرّفات جلسات أجنبية.
• الأحداث الحية القابلة لإعادة التشغيل: اتحاد أحداث نمطي يتضمن أرقامًا تسلسلية للعامل، وإقرارات استلام من Gateway، واحتفاظًا محدودًا، وحجبًا للأحداث المتأخرة، ويغذي توزيع أحداث الوكيل الحالي كي تعمل طريقة عرض المحادثة وصفوف الأدوات ومنطق غير المقروء/الحالة بصورة مطابقة للجلسات المحلية.

وكيل الاستدلال: أعد استخدام مفردات أحداث عميل تدفق وكيل وقت التشغيل الحالي (src/agents/runtime/proxy.ts)، لكن انقل حد الثقة. يرسل العامل فقط هوية الجلسة/التشغيل، ومرجع نموذج معتمدًا، والسياق، وخيارات توليد مقيّدة؛ ويحل Gateway المزوّد ونقطة النهاية والمصادقة والترويسات والتوجيه وسياسة التكلفة من الكتالوج الخاص به. يُرفض كائن نموذج يقدمه العامل (مثل baseUrl يتحكم فيه مهاجم). تُطبّق حدود حجم الطلب، والإلغاء، والتدقيق، وإعادة تشغيل النتيجة النهائية. تُنفّذ الأدوات المقيمة في Gateway (البحث على الويب) على Gateway وتعيد النتائج عبر القناة نفسها.

6. مزامنة مساحة العمل

مرساة المزامنة هي مساحة عمل محلية في Gateway ذات ملكية حصرية للموضع: لمساحات عمل git، شجرة عمل مُدارة مخصصة (بيانات شجرة العمل المُدارة الحالية — الفرع، والأساس، وملكية اللقطة — هي الأساس)؛ ولمساحات العمل غير المستندة إلى git، دليل هدف مملوك لـ Gateway. ليست أبدًا نسخة العمل الحية للمستخدم. الملكية الحصرية أثناء وضع الجلسة عن بُعد هي ما يجعل المزامنة الواردة خالية من التعارضات بحكم التصميم.

فصل الملكية — الإيداع مقابل النشر:

• ينشئ الوكيل على جانب العامل عمليات الإيداع بالطريقة المعتادة في نسخته (git commit عملية محلية لا تتطلب بيانات اعتماد؛ وتُسقط هوية المؤلف من إعدادات Gateway). تظل عمليات الإيداع هذه كائنات خاملة حتى يتبناها Gateway.
• ينفّذ Gateway كل ما يتطلب الثقة: التحقق من أن عمليات الإيداع الواردة مبنية على الأساس المسجل، وتقديم شجرة العمل المحلية تقديمًا سريعًا، والدفع، وإنشاء PR، والتوقيع أو إعادة التوقيع اختياريًا — وكل ذلك باستخدام بيانات اعتماد محلية في Gateway. لا يحتفظ العامل مطلقًا ببيانات اعتماد git أو منصة الاستضافة، ولا يتعامل مطلقًا مع مستودع بعيد.

وضعا مزامنة، يُختار أحدهما بناءً على ما إذا كانت مساحة العمل مستودع git:

• وضع Git. الصادر: مزامنة شجرة العمل عبر rsync (بما في ذلك الملفات غير المودعة والملفات غير المتتبعة المؤهلة؛ تضمين/استبعاد بأسلوب crabbox، مع احترام .worktreeinclude) عبر هوية SSH الخاصة بالنفق، وتسجيلها كبيان أساس غير قابل للتغيير (تجزئات المحتوى + عملية الإيداع الأساسية). الوارد: تعود عمليات الإيداع الجديدة كحزمة git أو مرجع مؤقت مقابل الأساس المسجل؛ وتعود العناصر غير المتتبعة عبر بيان صريح يتضمن فحوصات الحجم/النوع/احتواء الروابط الرمزية. يتحقق التبني من تسلسل الأسلاف من الأساس ويتوقف عند التباعد — ولا يُستبدل أي جانب بصمت. تعالج قواعد البيان عمليات الحذف وإعادة التسمية والوحدات الفرعية وهروب الروابط الرمزية، لا استدلالات rsync.
• الوضع العادي (دون git — مثلًا عند إنشاء مشروع من الصفر على الصندوق). الصادر هو مزامنة rsync نفسها + بيان الأساس. الوارد هو نسخة مطابقة محسوبة بفروق البيان إلى دليل الهدف المملوك لـ Gateway، مع نشر عمليات الحذف. وهو آمن للسبب نفسه الذي يجعل وضع git آمنًا: تعني الملكية الحصرية عدم وجود تعديلات محلية متزامنة يمكن أن تتعارض؛ ويظل بيان الأساس يكتشف أي انحراف محلي غير متوقع ويتوقف بدل الاستبدال.

تحمي نقاط التحقق الجلسات الممتدة لأيام من فقدان مدة التأجير: نقاط تحقق واردة دورية (عمليات إيداع لفرع الجلسة في وضع git، ولقطات بيان في الوضع العادي)؛ ويحدد ملف التعريف وتيرتها (الافتراضي قائم على الأدوار).

7. آلة حالات الموضع والجلسات وواجهة المستخدم

موضع وقت التشغيل هو آلة حالات مملوكة لـ SQLite ومرتبطة بالجلسة، وليس زوجًا من حقول صفوف منفصلة:

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

تحتفظ بمعرّف البيئة، وجيل الانتقال، وحقبة المالك النشط، وبيان أساس مساحة العمل، وتجزئة حزمة العامل، ومؤشرات آخر إقرار استلام. يطالب قبول الدور بالموضع ذريًا قبل أن تبدأ أي من الحلقتين دورًا، لذا لا يمكن لرسالة محلية قُبلت استنادًا إلى لقطة قديمة أن تتسابق مطلقًا مع دور عامل — حلقة واحدة فقط تملك الجلسة في أي وقت.

واجهة المستخدم:

• جلسة العامل هي صف جلسة عادي مع بيانات وصفية للموضع. توجد في المخزن المعتاد، وتظهر عبر sessions.list، وتتدفق عبر الاشتراكات الحالية — لا يحتاج الشريط الجانبي والمحادثة إلى مسار بيانات جديد، بل إلى عرض تقديمي فقط: شارة عامل وحالة الموضع/البيئة (provisioning / syncing / running / idle / reconciling / reclaimed).
• تجربة الإنشاء: يكتسب شريط هدف الجلسة (إعادة تصميم الشريط الجانبي للجلسات) وجهة عامل سحابي إلى جانب Gateway وNode. يتطلب ذلك ملف تعريف مزوّد مهيأ؛ وتكون الميزة غير مرئية حتى تهيئتها.
• إسناد الوكيل: تتيح أداة جلسة للوكيل تسليم العمل إلى عامل سحابي بالطريقة نفسها التي يفعل بها الإنسان (جلسة فرعية مدعومة بعامل، بأسلوب الوكيل الفرعي). تُطرح في المرحلة نفسها مع الإسناد البشري، وتخضع لإعدادات المزوّد الاختيارية نفسها. يُحد التكرار بنيويًا (لا يمكن لجلسات العامل نفسها إسناد عاملين في الإصدار الأول)؛ وضبط الإنفاق هو محاسبة/تدقيق لكل بيئة، وليس آلية حصص.

الإسناد والتسليم

الإصدار الأول غير متماثل عن قصد:

• محلي ← العامل (الإسناد): اجتز حاجز الترحيل أدناه، ووفّر عاملًا أو أعد استخدامه، وزامن، واقلب الموضع؛ يُنفّذ الدور التالي عن بُعد.
• العامل ← محلي (السحب إلى الخلف): أوقف الجلسة (صرّف العامل وفق الحاجز نفسه)، وأكمل التسوية الواردة، واقلب الموضع إلى محلي. هذا ليس ترحيلًا حيًا.
• التسليم الحي المتماثل (نقل جلسة تعمل بنشاط في كلا الاتجاهين من دون إيقافها) يعيد استخدام الحاجز وآليات التسوية نفسها، ويُطرح بعد أن تثبت اختبارات حقن الأعطال صحة الحاجز.

حاجز الترحيل («حد الدور» وحده غير كافٍ — إذ يمكن أن تمتد الموافقات والعمليات الخلفية وعمليات دمج سجل المحادثة بعد تحرير القفل عبره):

1. أوقف قبول أدوار جديدة (المطالبة بالموضع).
2. ألغِ عمليات التشغيل النشطة أو صرّفها.
3. ألغِ الموافقات المعلقة على التنفيذ ومنح التنفيذ.
4. صرّف الكتابات الجانبية لسجل المحادثة وإقرارات استلام الأحداث الحية.
5. أنهِ العمليات الفرعية للعامل.
6. احجب المالك القديم بتقديم حقبة المالك.
7. سوِّ مساحة العمل (وارد، مع مراعاة التعارضات).
8. فعّل المالك الجديد.

تقارب ذاكرة التخزين المؤقت: نظرًا إلى أن طلبات المزوّد تنشأ من Gateway في كلا الموضعين، يُحافظ على تقارب ذاكرة التخزين المؤقت عندما يظل طلب المزوّد المتسلسل متكافئًا — ترتيب الأدوات نفسه، وتعليمات النظام نفسها، وأغلفة المزوّد نفسها، وبيانات ذاكرة التخزين المؤقت الوصفية نفسها (التي تظل على جانب Gateway). هذه خاصية قابلة للاختبار وليست افتراضًا: تُعد اختبارات تكافؤ البايتات عبر الموضع المحلي/موضع العامل لكل نقل مزوّد مدعوم جزءًا من المرحلة التي تقدم حلقة العامل.

نموذج الأمان

بصياغة دقيقة: لا يملك العامل خروجًا مباشرًا إلى الشبكة ولا بيانات اعتماد دائمة للمزوّد/منصة الاستضافة. هذا ليس «انعدام خروج» — فالاستدلال والأدوات التي ينفذها Gateway قنوات خروج مضبوطة (ولا يزال بإمكان عامل خضع لحقن الموجّه وضع بايتات مساحة العمل في سياق النموذج أو استعلامات البحث على الويب). وبناءً على ذلك:

• محاسبة الخروج المضبوط: تدقيق لكل بيئة ومحاسبة مرئية للمشغّل على وكيل الاستدلال وأدوات Gateway. توجد حدود المعدل/البايتات باعتبارها تحكمًا في تدفق البروتوكول (السعة)، لا بوصفها آلية حصص إنفاق.
• الدخول من العامل إلى Gateway هو قائمة السماح المغلقة لبروتوكول العامل؛ وكتابات سجل المحادثة مقيّدة بنيويًا (معرّفات ينشئها Gateway، وجلسة مرتبطة واحدة).
• يتمتع تنفيذ العامل بأذونات كاملة داخل الصندوق. الصندوق قابل للتخلص منه وخالٍ من بيانات الاعتماد، لذا تضيف الموافقة لكل أمر احتكاكًا من دون حماية أي شيء؛ والحد المحمي هو التسوية الواردة والتدقيق. لا يعبر التنفيذ مطلقًا مسار موافقة Node في Gateway.
• سياسة الإنترنت قرار للمزوّد وقت التوفير: يقرر ملف تعريف البيئة عند إنشاء الصندوق (جدار حماية/مجموعة أمان/شبكة بلا خروج)، مع مرحلة إعداد متصلة بالشبكة اختياريًا يغلقها المزوّد قبل مرحلة الوكيل. لا تنفذ النواة مفتاح تبديل للشبكة في وقت التشغيل.
• نظافة الصندوق وقت التوفير: حجب نقطة نهاية بيانات السحابة الوصفية أو التحقق من غيابها، وعدم وجود ملف تعريف للمثيل، أو وكيل SSH موروث، أو مقبس Docker، مع بيئة/دليل رئيسي نظيفين. تُثبّت مفاتيح مضيف SSH من مخرجات التوفير.
• تظل الموافقات والسياسة لأي شيء على جانب Gateway (الدفع، وPR، واستدعاءات المزوّد) تعمل على Gateway.

نطاق تأثير اختراق جلسة عامل: نسخة مساحة العمل المتزامنة، إضافة إلى ما تسمح به قنوات الوكيل المدققة — لا بيانات اعتماد، ولا شبكة مباشرة، ولا سطح في Gateway يتجاوز قائمة السماح.

السعة

يرحّل Gateway كل موجّه وتدفق رموز لـ N من العاملين، لذا يحدد الإصدار الأول نموذج سعة بدل اكتشافه في الإنتاج: حدود العاملين المتزامنين لكل Gateway، ونوافذ أرصدة لكل تدفق (صف تدفق الأحداث الحالي غير محدود، والحد الأقصى للمخزن المؤقت لمقبس Node يغلق المستهلكين البطيئين قسرًا — وكلاهما غير مناسب دون تعديل)، وتخزين مؤقت محدود على القرص للطفرات، وتخفيف الحمل مع حالات ضغط عكسي مرئية في واجهة المستخدم. يظل نقل مساحة العمل على قناة SSH مستقلة.

دورة الحياة

• الإيقاف التلقائي عند الخمول وTTL هما سياسة لملف تعريف المزوّد، وليسا ثوابت ثابتة. الإعدادات الافتراضية سخية مع إبقاء الاتصال صراحةً؛ والعمل الممتد لأيام حالة أساسية (يوفر المزوّد renew للخلفيات القائمة على التأجير)؛ ولا تُسترد مطلقًا جلسة لها دور قيد التنفيذ أو نشاط حديث.
• عند موت العامل أو استرداده: ينتقل الموضع إلى reclaimed، ويبقى صف الجلسة، وتؤدي الرسالة التالية إلى توفير عامل جديد وإعادة المزامنة من آخر نقطة تحقق. لا تُفقد المحادثة مطلقًا (المخزن على جانب Gateway)؛ وتُفقد تغييرات مساحة العمل منذ آخر نقطة تحقق، وتوضح واجهة المستخدم ذلك.
• إعادة استخدام مدة التأجير الدافئة منذ اليوم الأول (للمزوّدين الذين يدعمونها)؛ ولقطة الصورة بعد التمهيد هي مسار البدء السريع للإصدار الثاني.

سطح الإعداد

محدود واختياري: كتلة ملف تعريف للمزوّد (معرّف المزوّد، وبيانات الاعتماد/مرجع CLI، وقواعد المزامنة، وسياسة العمر، والميزانيات، ومرحلة إعداد اختيارية) بالإضافة إلى اختيار الموضع لكل جلسة. لا متغيرات بيئة جديدة. لا ترى عمليات التثبيت غير المهيأة أي شيء.

المراحل

يصل التنفيذ في صورة PRs صغيرة قابلة للدمج بصورة مستقلة؛ كل مرحلة أدناه سلسلة PRs، وليست تغييرًا واحدًا.

1. الأسس: آلة حالات البيئة + عقد المزوّد + مزوّد بهيئة crabbox (static-SSH كبيئة تطوير تجريبية)، وتمهيد حزمة العامل + مصافحة القبول، ونفق SSH + تثبيت مفتاح المضيف، ولقطة شجرة العمل المُدارة + المزامنة الصادرة (وضعي git والعادي). تنظيف العناصر اليتيمة + التبني بعد إعادة التشغيل.
2. بروتوكول العامل + حلقة العامل: دور عامل موثّق، وعمليات دائمة/حِقب/مؤشرات إقرار الاستلام، وعقود إيداع سجل المحادثة + الأحداث الحية، ووكيل استدلال بنماذج يحلها Gateway، والتحكم في التدفق. مزوّد واحد، وإسناد بشري للجلسات الجديدة فقط، بلا تسليم. تشترط اختبارات حقن الأعطال (انقسام النفق، وإعادة تشغيل Gateway، وموت العامل) الخروج من المرحلة.
3. الإسناد + السحب إلى الخلف + إسناد الوكيل: حاجز الترحيل، وربط آلة حالات الموضع بشريط الهدف في واجهة المستخدم، والتسوية الواردة + نقاط التحقق، والتدقيق لكل بيئة، وحدود السعة، وأداة إسناد الوكيل (لا يمكن لجلسات العامل التكرار). اختبارات تكافؤ بايتات ذاكرة التخزين المؤقت للموجّهات.
4. التسليم الحي المتماثل، بعد إثبات حقن الأعطال في المرحلة الثالثة.

لاحقًا: بيئات ACP التجريبية على العاملين بوصفها خيار اشتراك لتزويد بيانات الاعتماد لكل بيئة؛ وبدء سريع عبر اللقطات/الصور الدافئة؛ والتوزيع المتشعب (N من مدد التأجير، والموجّه نفسه)؛ وعزل نظام التشغيل داخل الصندوق؛ والتقاط أثرى للعناصر عبر مخطط العناصر.

أسئلة مفتوحة

• توافر الـ Plugin/Skills على العمال: تتم مزامنة Skills المضمّنة في المستودع مع مساحة العمل تلقائيًا؛ أما Skills/Plugins الخاصة بالوكيل والمهيأة عبر Gateway فتتطلب قرارًا صريحًا بالمزامنة أو الاستبعاد (ويكون بيان الأداة/Plugin جزءًا من مصافحة القبول في كلتا الحالتين).
• الوتيرة الافتراضية لنقاط التحقق: حسب الأدوار أم حسب الوقت للجلسات كثيرة المحادثات.
• كيفية تفاعل ملفات تعريف البيئة مع توجيه الوكلاء المتعددين (ملفات تعريف افتراضية لكل وكيل مقابل الاختيار لكل جلسة فقط).