إعداد OpenClaw عندي: جهاز واحد يصنع المواقع الإلكترونية

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

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

الجهاز كله بنظرة واحدة

كل شيء يعيش على آلة واحدة. النماذج تخدم الرموز (tokens) — معظمها الآن عبر واجهة DeepSeek السحابية الرخيصة، والنماذج المحلية احتياط — وبوابة OpenClaw تحوّلها إلى وكلاء مزوّدين بأدوات، والوكلاء يحرّرون محتوى نصيًا صرفًا، ومولّد حتمي (deterministic) يبني الموقع، وسكربت مُحكَم واحد هو الطريق الوحيد إلى الخادم.

ما تحصل عليه في النهاية

الوضع النهائي، قبل أي حديث عن الإعداد:

• "اكتب لي مسودة مقال عن كذا" في الدردشة ← يكتب وكيل مقال Markdown في مجلد content/ الخاص بالموقع، متبعًا مخطط الفرونت ماتر وأسلوب الموقع، ويعيد بناء المعاينة المحلية.
• "انشره" ← يشغّل الوكيل سكربت النشر، وهو افتراضيًا وضع تجريبي: يعرض بالضبط أي الملفات ستتغيّر على الخادم دون أن يلمس شيئًا. النشر الفعلي يتطلّب أمرًا صريحًا مني بـ --go، وحتى حينها يأخذ السكربت نسخة احتياطية من جانب الخادم أولًا ولا يحذف شيئًا أبدًا.
• مرة كل أسبوع، تُوقظ مهمة مجدولة وكيلًا لتحديث الموقع — إصلاح تواريخ قديمة، تحسين مقالات ضعيفة، فحص الروابط — مع فحوص أمان قبل أن يُنشَر أي شيء (التفاصيل في الخطوة 3).
• موقع laserlloyd.com نفسه يُدار بهذه الطريقة.

تقسيم العمل هو صلب الفكرة: الوكلاء يكتبون، والسكربتات تفرض القواعد، وأنا أتّخذ القرار الوحيد المهم — هل يُنشر التغيير أم لا.

العتاد ونظام التشغيل: أي جهاز لينكس يفي بالغرض

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

• أي جهاز لينكس 64-بت — حاسوب صغير، حاسوب مكتبي قديم، حتى حاسوب محمول قادر. 16 جيجابايت ذاكرة تكفي لتشغيل نماذج محلية صغيرة بسلاسة؛ 32 جيجابايت فأكثر تفتح المجال لنماذج متوسطة الحجم تكتب نثرًا أفضل بشكل ملحوظ.
• توزيعة تحوي systemd (كلها تقريبًا) — الجدولة والإشراف على الخدمات أدناه تفترض وجوده.
• Python 3 لمولّد الموقع الثابت، وrsync + SSH للنشر.

لست بحاجة إلى وحدة رسومية (GPU) بشكل صارم. النماذج الصغيرة المضبوطة للتعليمات تعمل بأداء مقبول على المعالج لصياغة النصوص وتحريرها. لكن لأكون صريحًا بعد أشهر من تشغيل الاثنين: واجهة DeepSeek السحابية هي الآن المحرّك الأساسي لإعداد OpenClaw عندي بأكمله. كانت النماذج المحلية المفتوحة هي الخطة الأصلية، وما زالت تعمل، لكن المقايضات تتراكم — دقائق من وقت تحميل النموذج، وتنازع على VRAM بين الخدمات، وذكاء أقل بشكل ملحوظ من نموذج سحابي رخيص جدًا تكلفته كسور من السنت لكل رسالة. المحلي احتياطي وطبقة خصوصية عندي، لا محرّكي اليومي. (الفاتورة الشهرية الحقيقية: نحو 24 دولارًا.)

الخطوة 1: تثبيت بوابة وكلاء ونموذج محلي

قطعتان: شيء يخدم نموذجًا عبر واجهة برمجية متوافقة مع OpenAI، وشيء يحوّل ذلك النموذج إلى وكيل — بأدوات ووصول للملفات ومهام مجدولة.

خادم النموذج. LM Studio، Ollama، أو خادم llama.cpp — كلها تعمل. أيًا كان اختيارك، شغّله كخدمة systemd للمستخدم كي يصمد أمام إعادة التشغيل:

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # فحص سلامة

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

• اربط البوابة بالحلقة الداخلية (loopback) وضع أي واجهة دردشة خلف مصادقة. وكيل بوصول طرفية ليس شيئًا تتركه مفتوحًا على شبكتك.
• قيّد مجلد عمل الوكيل بمستودع الموقع. يحتاج إلى تحرير content/، لا مجلد المستخدم الرئيسي عندك.

طبقتان: وكلاء محليون للروتين، ونموذج سحابي قوي للإصلاحات

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

الطاقم: كل بوت على الجهاز

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

البوت	الوظيفة	يعمل على	DisPatch (مقفل)	DisPatch (مفتوح)
Bits	مكتب الاستقبال — الوكيل الذي تتحدث إليه؛ يفهم الطلب ويوزّعه على المتخصص المناسب	DeepSeek flash (سحابي)	—	✔
Brains	المفكّر الجاد — المواصفات، المراجعات، أي شيء يستحق الانتظار	DeepSeek reasoner (سحابي)	—	✔
Flash	المهام السريعة والمتابعات المجدولة — الحارس الذي يطارد العمل المتأخر	DeepSeek flash (سحابي)	—	✔
Hermes	جسر وكيل البرمجة — العمل البرمجي الموزَّع	DeepSeek (سحابي)	—	✔
Doxy	حصان العمل المحلي — المهام الكثيفة والخاصة التي لا ينبغي أن تغادر المنزل	نموذج محلي بـ122 مليار معامل (vLLM)	—	✔
Charley	الرؤية — "ما الموجود في هذه الصورة؟"، المهام المرتبطة بالصور	Gemma 31B (محلي، LM Studio)	✔	✔
Alpha و Beta	مساعدون عامون آمنون للعائلة — أسئلة الواجبات المدرسية، الدردشة اليومية	DeepSeek flash (سحابي)	✔	✔
Terminex	ليس وكيلًا — طرفية Reasonix البرمجية في DisPatch، وهي PTY حقيقية داخل المتصفح	DeepSeek (سحابي)	—	✔

كيف يؤدون بصراحة:

• البوتات المعتمدة على DeepSeek هي المحرّكات اليومية. وكلاء الطبقة السريعة (Bits، Flash، Alpha، Beta) يجيبون خلال ثوانٍ، تكلفتهم كسور من السنت لكل رسالة، ولا يحتاجون إلى إحماء أبدًا. Brains، على طبقة الاستدلال، يستغرق وقتًا أطول ملحوظًا لكل إجابة — وهذا هو المقصود، فهو من تسلّمه المشكلات التي تستحق التفكير — وما زال يكلّف سنتات قليلة لكل جلسة. الفاتورة المقاسة للحزمة بأكملها موجودة في مقال التكلفة.
• البوتات المحلية أبطأ وأقل ذكاءً، لكنها خاصة ومجانية. نموذج Doxy البالغ 122 مليار معامل يستغرق دقائق ليُحمَّل في الذاكرة، وأدواره الطويلة قد تستغرق عدة دقائق إضافية؛ اضطررت لرفع مهل البوابة تحديدًا لاستيعابه. نموذج رؤية Charley هو الاستثناء الذي يبقى مشغولًا — وصف الصور شيء لا تفعله أي طبقة سحابية رخيصة هنا، فالنموذج المحلي يستحق VRAM الذي يشغله.
• المجموعة الآمنة مملّة عن قصد. Alpha وBeta وCharley هم قائمة الوضع المقفل: معلومات عامة ورؤية، بلا أدوات تلمس الملفات أو الأنظمة. هذا ما يجعل تسليم الهاتف لطفل أمرًا عاديًا تمامًا.

الخطوة 2: موقع ثابت وسكربت نشر مُحكَم

الوكلاء وووردبريس يمتزجان بشكل سيئ — قاعدة بيانات، تسجيل دخول، إضافات، وPHP كلها سطح هجوم وكلها أنماط فشل. مولّد موقع ثابت هو الشريك الطبيعي للوكيل: الموقع بأكمله ملفات نصية صرفة في مجلد، البناء أمر واحد، و"النشر" نسخ ملف. مولّدي بضع مئات من أسطر Python (Jinja2 + Markdown + YAML)؛ Hugo وEleventy وZola تعمل بالطريقة نفسها. المهم هو العقد:

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

النقطة الأخيرة هي جوهر هذا الإعداد كله. هذا شكل سكربتي:

./deploy.sh preflight   # يفحص SSH، مجلد الويب الهدف، ميزانية الحجم
./deploy.sh             # بناء + rsync تجريبي — يطبع ما سيتغيّر
./deploy.sh --go        # بناء + نسخ احتياطي من جانب الخادم + نشر + تحقّق

وما يضمنه السكربت، بترتيب الأهمية:

1. وضع تجريبي افتراضيًا. تشغيله دون وسائط لا يمكن أبدًا أن يعدّل الخادم. يستطيع الوكيل تشغيله بحرية ليُريني نشرًا معلّقًا.
2. لا يحذف أبدًا. rsync يعمل دون --delete. وكيل مرتبك قد يستبدل صفحة بنسخة أحدث؛ لا يستطيع محو الموقع.
3. ينسخ احتياطيًا أولًا. مع --go، يأخذ السكربت أرشيف tarball من جانب الخادم لمجلد الويب قبل استبدال أي ملف (محتفظًا بآخر عدد قليل من النسخ). إن فشل النسخ الاحتياطي، يُلغى النشر.
4. يفشل مغلقًا (fail-closed). بيان ناقص، مضيف غير قابل للوصول، أو قيمة إعداد نائبة (placeholder) يُلغي التشغيل قبل بدء rsync. الملفات المصدرية (القوالب، السكربتات، الإعدادات) مستبعدة استبعادًا صارمًا فلا يمكن أن تصل أبدًا إلى مجلد الويب العام.
5. يتحقق بعد ذلك. يجلب الصفحة الرئيسية المباشرة ويبحث عن علامة مولّد يضعها البناء — استجابة HTTP 200 وحدها قد تكون إيجابية كاذبة إن كانت الاستضافة القديمة لا تزال تجيب على النطاق.

الوكيل مسموح له بتشغيل الاختبار التجريبي والفحص المسبق (preflight) متى شاء. علامة --go محجوزة لي وحدي. هذا التباين البسيط يحوّل "ذكاء اصطناعي لديه وصول شبيه بـ SSH إلى موقعي الإنتاجي" من أمر مرعب إلى أمر مملّ.

الخطوة 3: تحديثات مجدولة أسبوعيًا، مع ضوابط أمان

القطعة الأخيرة تجعل الأمر ذاتي الصيانة. مؤقت systemd ينطلق مرة كل أسبوع ويسلّم الوكيل تعليمات ثابتة: راجع الموقع، حدّث أي شيء عفا عليه الزمن، شدّد المقالات الضعيفة، تحقّق من الروابط الداخلية، وأودِع النتيجة — لا تنشرها. هذه المهمة نفسها هي ما يصون هذا المقال بالذات: جزء من تعليماتها هو "أعِد قراءة مقال إعداد OpenClaw، أصلح أي شيء انحرف عن الواقع، واختم تاريخ updated:." التاريخ أعلى هذه الصفحة هو ذلك الختم.

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

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

• فحص الأسرار. فحص أنماط على الفرق (diff) بحثًا عن أي شيء يشبه مفتاح واجهة برمجية أو رمزًا مميّزًا أو كلمة مرور أو اسم مضيف خاص. أدوات مثل gitleaks تفعل هذا جاهزة. أي اكتشاف يُلغي التشغيل — فشل مغلق، بلا استثناءات.
• فحص الاحترافية المهنية. جولة ثانية بنموذج لغوي، بتوجيه مختلف عن الكاتب، تراجع التغييرات المودَعة مقابل سؤال واحد: "هل ستكون شركة مرتاحة لنشر هذا؟" النبرة، الادّعاءات، مهام TODO غير المكتملة، النص النائب (placeholder). الفشل يترك التغييرات مودَعة لمراجعة بشرية بدل النشر.
• يجب أن ينجح البناء، بما في ذلك فاحص الروابط/الأصول — صورة معطوبة أو رابط داخلي ميت يُفشل التشغيل قبل أن يصل إلى سكربت النشر أصلًا.

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

إعادة إنتاج هذا

كل ما سبق قابل للبناء انطلاقًا من هذا الوصف — لا شيء فيه احتكاري. الوصفة مختصرة:

1. اختر جهاز لينكس وثبّت خادم نماذج محلي (LM Studio، Ollama، llama.cpp) كخدمة systemd.
2. ثبّت بوابة وكلاء (OpenClaw أو ما شابهها) مربوطة بالحلقة الداخلية؛ أنشئ وكيل ويب ماستر واحدًا بأدوات ملفات/طرفية مقتصرة على مجلد الموقع.
3. انقل الموقع إلى مولّد ثابت إن لم يكن كذلك بالفعل — محتوى Markdown يدخل، أمر بناء واحد يخرج.
4. اكتب سكربت النشر المُحكَم بالضمانات الخمس أعلاه: وضع تجريبي افتراضي، بلا حذف، نسخ احتياطي أولًا، فشل مغلق، تحقّق بعد النشر. هذه القطعة تستحق أكبر قدر من العناية؛ نحو 150 سطرًا من bash.
5. أضف المؤقت الأسبوعي وفحصي الأمان (فحص أسرار + مراجعة محتوى بنموذج لغوي)، بفشل مغلق.
6. أبقِ --go بشريًا حتى يكسب خط الأنابيب ثقتك بخلاف ذلك.

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

مطبّات

• سكربت النشر يجب أن يكون الطريق الوحيد. أول مرة تشغّل فيها أنت (أو وكيل) rsync يدويًا "لمرة واحدة فقط"، تكون قد صنعتَ الحادثة التي وُجد السكربت لمنعها. سكربتي يستبعد الملفات المصدرية استبعادًا صارمًا ويرفض إعدادات النائبة تحديدًا لأن أمرًا لمرة واحدة لن يفعل ذلك.
• استجابة HTTP 200 وحدها ليست نشرًا ناجحًا. أثناء هجرتي من ووردبريس، ظلّت الاستضافة القديمة تجيب على النطاق — كل "تحقّق" كان ينجح بينما الملفات الجديدة جالسة دون استخدام. ضمّن علامة مولّد في بنائك وابحث عنها في الصفحة المباشرة.
• الوكلاء تتّبع المخطط الذي تريهم إياه، بما في ذلك مهام TODO. إن كان قالب مقالك يحوي نصًا نائبًا، سينشر نموذج كسول TODO: excerpt here حرفيًا. هذا نصف سبب وجود فحص المحتوى الاحترافي.
• لا تدع الكاتب يراجع نفسه. نفس النموذج، نفس التوجيه، نفس النقاط العمياء. المراجع يحتاج توجيهًا مختلفًا على الأقل، ونموذجًا مختلفًا في الأفضل.
• مهام النموذج اللغوي المجدولة تحتاج مهلًا زمنية وافتراضية "مودَع، لا منشور". مهمة أسبوعية قادرة على النشر دون إشراف ستنشر يومًا شيئًا غريبًا الساعة السادسة صباح الأحد. الإيداع لا يكلّفك سوى مراجعة واحدة.
• فحوص الأسرار مكانها في خط الأنابيب، لا في تعليمات الوكيل. "لا تُدرج أسرارًا أبدًا" في توجيه هو مجرّد أمنية؛ فحص فاشل-مغلق على الفرق (diff) هو ضابط فعلي.