بناء مساحات عمل مشتركة للأشخاص والوكلاء

أطلقنا مؤخرًا ميزة المشاريع، حيث يعمل الأشخاص والوكلاء معًا على مهام طويلة الأمد في Perplexity Computer. ويقوم كل مشروع على مساحة عمل مشتركة بنظام ملفات يراكم السياق عبر الجلسات والوكلاء والمستخدمين. ويتطلب التعاون متعدد المستخدمين الذي يمتد لأشهر توفر الاستمرارية والتزامن وإمكانية التتبع:

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

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

تكبير

البنية المعمارية

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

تشغّل بنيتنا العملية بأكملها على السحابة، وتدعم جميع أشكال العمل المعرفي إلى ما هو أبعد من البرمجة. وكل مشروع في Computer مدعوم بمستودع Git تخدمه 5 مكونات:

• واجهة CLI تدير نسخ العمل المحلية، وتزامن التحديثات، وترسل تغييرات الوكيل داخل كل بيئة Sandbox.
• مستوى التحكم يحدد موقع مستودع المشروع ويمنح بيانات اعتماد قصيرة الأجل للوصول إليه.
• خدمة Git ترسل بيانات المستودع إلى بيئات Sandbox، وتتلقى عمليات الإرسال منها، وتقرر أي عملية إرسال تصبح أحدث إيداع مقبول.
• التخزين المدعوم بـ AWS S3 يحفظ بيانات المستودع بشكل دائم.
• المعالجة اللاحقة تستخرج النص وغيره من المعلومات المفيدة من المستندات المحفوظة، وتتيحها عندما يحمّل الوكلاء المشروع أو يحدّثونه.

لكل وكيل بيئة Sandbox معزولة خاصة به. وداخل هذه البيئة، يعمل على نسخة محلية من المستودع تديرها واجهة CLI صغيرة. تطلب واجهة CLI من مستوى التحكم تحديد موقع المستودع، ثم تجلب التغييرات وترسلها عبر خدمة Git. ويتحقق الخادم الوسيط للوكلاء (agent proxy) من صلاحيات الوصول لطلبات بيئة Sandbox قبل وصولها إلى خدمة Git. وتقرأ خدمة Git المستودعات وتكتبها على نظام ملفات مشترك، وتقرر ما إذا كانت كل عملية إرسال ستصبح أحدث إيداع مقبول. ويوفر نظامَ الملفات هذا AWS S3Files، الذي يجعل التخزين المدعوم بـ S3 متاحًا كملفات ومجلدات عادية. وينقسم التخزين إلى خلايا معزولة، لكل منها نظام ملفات ونسخ متماثلة خاصة من خدمة Git. وبعد قبول الإيداع، يستخرج عمّال الخلفية النص وغيره من المعلومات المفيدة من المستندات المتغيرة، ويخزّنون النتائج بمعزل عن سجل المستودع، ويتيحونها عندما يحمّل الوكلاء المشروع أو يحدّثونه.

فيما يلي، نستعرض المكونات واحدًا تلو الآخر.

تكبير

واجهة CLI: العمل مع الملفات المحلية في بيئات Sandbox

يعمل الوكلاء في SPACE، منصة Sandbox الداخلية لدينا. وتحتوي كل بيئة Sandbox على واجهة CLI صغيرة تنشئ المستودع محليًا وتحافظ على مزامنته. ولكل وحدة عمل ذات معنى يُنجزها الوكيل، ترسل الواجهة التغييرات على شكل إيداع.

لا يتعامل الوكلاء عادةً إلا مع جزء صغير من ملفات المشروع، لذا ليس من الضروري إنشاء المستودع بأكمله محليًا مسبقًا. ولذلك تنشئ واجهة CLI الملفات محليًا عند الحاجة فقط: فالملفات الكبيرة والثنائية المخزنة عبر Git Large File Storage (LFS) تصل كملفات مؤشرات صغيرة تحفظ الحجم الفعلي للكائن، بحيث يستطيع الوكيل الاستعانة بالاسم والحجم ليقرر ما إذا كان التنزيل يستحق العناء. وبالنسبة إلى المستندات مثل ملفات PDF، يقرأ الوكيل النص المحلَّل أولًا، ولا ينزّل الملفات المصدر إلا عند الضرورة.

ومن الخيارات البديهية الأخرى استخدام نظام ملفات افتراضي. اختبرنا تطبيقًا قائمًا على FUSE، لكنه كان أبطأ بنحو 400 مرة من الملفات المحلية في أحمال العمل التي تعتمد بكثافة على نظام الملفات، لأن كل طلب يتطلب رحلة ذهاب وإياب عبر الشبكة. كما أنه يتطلب عادةً صلاحيات مميزة من المضيف، ما يعني أن كل وكيل سيحتاج إلى العمل داخل بيئة Sandbox ذات صلاحيات مميزة.

تكبير

مستوى التحكم: تحديد مواقع المستودعات ومنح صلاحيات الوصول

يحدد مستوى التحكم مكان تخزين كل مستودع ويمنح صلاحية الوصول إليه. فعند إنشاء مستودع، يخصصه مستوى التحكم لخلية تخزين، وهي وحدة تخزين معزولة لها نسخها المتماثلة الخاصة من خدمة Git. وعندما يبدأ وكيل العمل على مشروع، تسأل واجهة CLI مستوى التحكم عن مكان تخزين المستودع، فيُعيد مستوى التحكم الموقع وبيانات اعتماد مؤقتة لخدمة Git. ولا يقرأ مستوى التحكم بيانات المستودع ولا يكتبها أبدًا، أما خدمة Git فهي التي تقرر ما يدخل إلى المستودع.

خدمة Git: نقل البيانات وتنسيق التحديثات

تنفّذ خدمة Git عمليات Git وتنقل محتويات المستودع وسجل الإصدارات بين بيئات Sandbox والتخزين. وهي غلاف رفيع حول أوامر الخدمة الخاصة بـ Git نفسه. وتدعم اكتشاف المراجع (ref discovery) لإخبار العميل بمكان رأس المستودع، وupload-pack للاستنساخ والجلب، وreceive-pack لتلقي الكائنات الجديدة وطلب تحريك رأس المستودع إلى الأمام. كما تخدم واجهة Git LFS API: فبالنسبة إلى الملفات الكبيرة والثنائية، تُصدر روابط قصيرة الأجل حتى تتمكن بيئات Sandbox من رفع هذه الملفات وتنزيلها مباشرة من S3.

بدأنا بخادم جاهز لاستضافة Git، حتى نتمكن من إنشاء نماذج أولية لواجهات الوكلاء والمستخدمين بالتوازي مع بناء منصة استضافة Git خفيفة خاصة بنا، تركز فقط على عمليات Git التي نحتاجها.

تتكون الخدمة من أسطول من النسخ المتماثلة، كل منها نسخة قيد التشغيل من الخادم نفسه. وتجمع الخلية بين تخزين مشترك ومجموعة من النسخ المتماثلة وخدماتها الداعمة. وبذلك يمكن للنسخ المتماثلة داخل الخلية الوصول إلى نظام الملفات المشترك نفسه، بدلًا من الاحتفاظ بنسخ مستقلة من كل مستودع.

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

تتحقق خطوة القبول من الثوابت الخاصة بالمستودع لضمان أن يمثّل كل إيداع مقبول حالةً صالحة للمستودع. نحدد عقدًا صريحًا لكل مستودع، بحيث تستطيع الفحوصات الآلية منعه من التضخم بشكل مفرط. تُخزَّن الملفات الكبيرة والثنائية، مثل ملفات PDF والصور، عبر Git LFS بدلًا من تخزينها ككائنات Git خام (blobs). ويحافظ التكثيف (compaction) على إتاحة السجل الحديث مع الحد من حجم المستودع. فبعد كل إرسال ناجح، تسأل واجهة CLI خدمة Git عمّا إذا كان المستودع يحتاج إلى التكثيف. وإذا تجاوز عدد الإيداعات المحتفَظ بها حدًا معينًا، تحتفظ خدمة Git بمجموعة أصغر من أحدث الإيداعات فقط. ويُستبدل السجل الأقدم بلقطة بداية واحدة، ثم يُعاد تطبيق الإيداعات الحديثة لتحديث معرّفاتها.

تكبير

تتعامل خطوة مزامنة بسيطة مع الجهات الكاتبة المتزامنة. فهي تتتبع أحدث إيداع مقبول، أي الرأس (head). وعندما تتلقى عملية إرسال، لا تقبلها إلا إذا كانت مبنية على ذلك الرأس. وإن لم تكن كذلك، ترسل استجابة منظَّمة تفيد بأن القاعدة قديمة (stale-base)؛ وعندها يتعين على الخاسر إعادة تطبيق تغييره فوق الرأس الجديد وإعادة إرساله. ويضمن هذا التصميم ألا يستبدل الوكلاء المتزامنون عمل بعضهم بعضًا بصمت، من دون التسبب في تباطؤ كبير. ففي سير العمل الإنتاجي لدينا، يُرفض أقل من 2% من عمليات الإرسال بسبب قِدم القاعدة. وإجمالًا، يبلغ وسيط زمن استجابة الإرسال أقل من 1.7 ثانية، ويبلغ زمن الاستجابة عند p99 أقل من 8 ثوانٍ.

تكبير

تسجّل خدمة Git أيضًا كل تغيير مقبول. فلكل عملية كتابة مقبولة، تضيف إدخالًا إلى صندوق الصادر (outbox)، وهو سجل يذكر المستودع، والإيداع الجديد، والمستخدم الذي أجرى التغيير، والمسارات التي تغيّرت. وتقرأ الخدمات اللاحقة، مثل المحلّل، هذا السجل للعثور على عمل جديد.

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

التخزين: الحفاظ على العمل بشكل دائم

تحفظ طبقة التخزين بيانات المستودعات بشكل دائم وبمعزل عن بيئات Sandbox والنسخ المتماثلة لخدمة Git. توجد المستودعات على AWS S3Files، التي توفر تخزينًا مدعومًا بـ S3 عبر واجهة نظام ملفات يمكن لـ Git القياسي استخدامها من دون تعديل. وكل مستودع هو مستودع Git مجرد (bare) على نظام الملفات المشترك، يحتوي على كائنات المستودع ومراجعه بدلًا من نسخة عمل.

يتيح فصل التخزين عن الحوسبة أن تظل بيئات Sandbox مؤقتة. فيحصل كل وكيل على بيئة Sandbox خاصة به، ويمكن لعدة وكلاء العمل على المشروع نفسه من دون مشاركة جهاز واحد. وإذا تعطلت بيئة Sandbox، فلن يتعرض للخطر إلا العمل الذي لم يُرسَل بعد.

كان بإمكاننا بدلًا من ذلك أن نمنح كل مشروع بيئة Sandbox طويلة الأمد يتشاركها جميع وكلائه، بحيث توجد ملفات المشروع على قرص ذلك الجهاز. لكن ذلك سيربط موارد الحوسبة الخاصة بالوكلاء بمكان تشغيل الجهاز، ويتطلب تجهيزه بسعة تكفي لأكثر فتراته ازدحامًا. كما سيتعين أن يظل سليمًا لأشهر، مع إدارة النسخ الاحتياطي والاسترداد كجزء من نظام تخزين المشروع.

تكبير

المعالجة اللاحقة: جعل المستندات قابلة للقراءة من قِبل الوكلاء

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

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

كيف يستخدم الوكلاء مساحة العمل

يستكشف الوكلاء إصدار المستودع المحمَّل في بيئة Sandbox باستخدام أدوات نظام الملفات القياسية. وبدلًا من اتباع مسار ثابت يقوم على البحث ثم القراءة، فإنهم يسردون المجلدات، ويبحثون في محتويات الملفات باستخدام grep، ويقرأون المقاطع ذات الصلة، ويستفيدون مما يجدونه لتحديد المكان التالي الذي يبحثون فيه.

على غرار Computer، تعتمد Search النهج نفسه عبر أدوات الملفات القياسية الخاصة بها. إذ يبحث وكيل استكشاف منفصل في المشروع ضمن ميزانية أكثر محدودية، ويعيد مسارات الملفات ذات الصلة والمقتطفات الداعمة. ثم يقرأ نموذج الإجابة الملفات المختارة ويُنشئ الإجابة. وتقلل إعادة استخدام بيئة Sandbox موجودة للمشروع وقت الإعداد: فالاتصال بنسخة عمل جاهزة مسبقًا يستغرق نحو 2.9 ثانية، مقارنةً بنحو 8 ثوانٍ عند البدء من الصفر.

تكبير

يجعل النص المحلَّل المستنداتِ الأكبر، مثل ملفات PDF وملفات Office، قابلة للبحث بالأدوات نفسها. يتحقق الوكيل أولًا من بيان (manifest)، وهو قائمة توضح المستندات التي يتوفر لها نص مستخرج، ثم يبحث في ذلك النص ويقرأه كملفات عادية. ولا ينزّل المستند الأصلي إلا عندما لا يكون النص كافيًا، مثلًا لفحص الأشكال أو التخطيط أو البيانات المضمّنة.

قارنّا هذا النهج بالبحث الدلالي عبر فهرس، باستخدام 150 سؤالًا ماليًا يتعلق كل منها بمستند واحد، على مجموعة البيانات نفسها. حقق وكيل الاستكشاف نتيجة 0.867 في استرجاع المستند الصحيح و0.627 في الإجابة الصحيحة، مقابل نحو 0.39 و0.37 للبحث الدلالي، أي أفضل بنحو 1.7 مرة في الإجابات وبمرتين في الاسترجاع، مع زمن استجابة أقل بنحو 25%. ويعمل وكيل الاستكشاف في الغالب على النص المستخرج، ونادرًا ما ينزّل ملفات PDF الأصلية.

تكبير

بنية تحتية مشتركة واحدة

تستخدم الذاكرة الدائمة في Computer البنية التحتية نفسها لنظام الملفات. إذ يخزّن Perplexity Brain، وهو موسوعة المعرفة الخاصة بـ Computer، الذاكرةَ في مستودعات معرفة لها سجلها وسياساتها الخاصة. ويعني فصل المعرفة عن ملفات المشروع أن تحديثات الذاكرة في الخلفية لا تتنافس مع التعديلات على تلك الملفات. وأي جلسة تحتاج إلى الاثنين تحمّل المستودعين معًا.

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

الخلاصة

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

يعمل الوكلاء في بيئات Sandbox مستقلة ومؤقتة، بينما يساهمون في مستودعات دائمة. تُبقي حدود المستودعات النمو تحت السيطرة، وتتيح التنزيلات الصريحة للوكلاء اختيار ما يجلبونه، وتمكّنهم الملفات العادية من الاستكشاف بأدوات مألوفة. ويمكن للتحديثات في الخلفية والتعديلات التفاعلية والمهام المجدولة أن تبني على عمل بعضها بعضًا من دون تنسيق مباشر.

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

الاستشهاد

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}