لنفترض أنك قمت بتثبيت مساعد ذكاء اصطناعي AI agent خص و جاهز و يعمل جيداً في البداية، لكن بعد أسابيع تبدأ الأسئلة: أين تذهب محادثاتي؟ لماذا نسي ما قلته بالأمس؟ كيف أضيف مهارة خاصة بعملي؟ ولماذا يتصرف بشكل غريب حين تصلان رسالتان في نفس اللحظة؟
هذه الأسئلة لا تحلّها التوثيقات الرسمية، لأنها تحدث داخل الصندوق الأسود. والطريقة الوحيدة للإجابة عنها هي أن تفهم كيف يُبنى هذا الصندوق من الداخل.
في ربيع 2023، كتب بيتر شتاينبيرغر، مطوّر نمساوي يعمل منفرداً، أول سطور مشروعه في عطلة نهاية أسبوع. لم يكن يبني تطبيق دردشة. كان يبني بنية معمارية لإدارة الوكلاء المستقلين. اليوم يحمل مشروعه OpenClaw أكثر من مئة ألف نجمة على GitHub، ويدرسه مطورون في عشرات الدول باعتباره من أوضح الأمثلة التعليمية لفهم كيف يعمل مساعد الذكاء الاصطناعي الشخصي في بيئة إنتاج حقيقية.
وفق مسح Stack Overflow لعام 2026، اثنان وأربعون بالمئة من المطورين يستضيفون الآن أداة ذكاء اصطناعي واحدة على الأقل محلياً، ارتفاعاً حاداً من ثمانية عشر بالمئة عام 2024. هذا التضاعف لا يعكس فضولاً تقنياً فحسب، بل قلقاً متزايداً من الصناديق السوداء ومن ضياع السيطرة على البيانات.
لماذا لا يكفي “الإرسال المباشر”
أسهل طريقة لبناء مساعد ذكاء اصطناعي هي إرسال الرسالة للنموذج واستقبال الرد. وهذا بالضبط ما يكفي لعرض توضيحي، لكنه ينهار بسرعة في الاستخدام الفعلي.
تخيّل أن مستخدمَين أرسلا رسالتين في نفس الجلسة في اللحظة ذاتها. بدون ترتيب معالجة، تتعارض الحالتان وتنتج مخرجات غير منطقية. أو تخيّل أنك تستقبل رسائل من واتساب وتيليغرام معاً؛ كل منصة تستخدم بروتوكولاً مختلفاً، وإذا وصلا للنموذج بتنسيقات متعارضة فالنتيجة فوضى.
هذه المشاكل تحلّها المعمارية. غيابها يعني أنك لا تملك وكيلاً فعلياً، بل نموذجاً لغوياً بواجهة.
OpenClaw يقوم على ثلاث طبقات: طبقة القنوات التي تستقبل المدخلات من مختلف المنصات، طبقة البوابة التي تتولى التوجيه والمصادقة وإدارة الجلسات، وطبقة الأدوات التي تُحوّل المحادثة إلى إجراءات فعلية. البوابة تربط بشبكة WebSocket على المنفذ 18789 افتراضياً ولا تلمس النموذج مباشرةً. هذا الفصل يضمن أن كل مدخل يمر بعملية مُتحكَّم فيها قبل أن يصل للنموذج.
من يتحمل المسؤولية القانونية عندما يخطئ الوكيل في سياق معالجة البيانات الشخصية سؤال لا تُجيب عنه المعمارية وحدها، لكن فهم المعمارية هو الشرط الأول لبناء أي حجة قابلة للدفاع.
ثماني مكوّنات، منطق واحد
داخل البوابة يعمل ثمانية مكوّنات تتعاون لمعالجة كل رسالة. لا تحتاج إلى قراءة الكود سطراً بسطر لتفهمها، تحتاج إلى استيعاب المنطق خلف التقسيم.
المحوّل Channel Adapter يُعالج اختلاف التنسيق بين المنصات. رسالة صوتية من واتساب لا تشبه نصاً من سلاك على مستوى البروتوكول. المحوّل يُحوّلهما إلى كائن موحّد قبل أن يرى النموذج أياً منهما، والرسائل الصوتية تُنسَّخ نصياً في هذه المرحلة.
مدير الجلسات يُنشئ لكل مستخدم جلسةً معزولة بمعرّف مركّب من المنصة والرقم، مثل telegram:123، ويحفظ سجل المحادثة على القرص كملف JSON. إعادة التشغيل لا تمحو الذاكرة، وهذا هو التمييز الحاسم بين نظام حقيقي وعرض توضيحي.
طابور الأوامر يضمن الترتيب. رسالتان متزامنتان من نفس الجلسة لا تُعالَجان في آنٍ واحد، وغيابه يُنتج تعارضات تصعب تتبعها.
بانية السياق تُجمّع موجّه النظام وسجل الحوار وفهرس المهارات في حزمة واحدة تُرسَل للنموذج. النموذج لا يُفكّر في فراغ؛ يُفكّر بالسياق الذي تمنحه إياه، وجودة هذا السياق تحدد مباشرةً جودة الاستجابة.
منفّذ المهارات Skills Executor يُشغّل الأداة التي يختارها النموذج. كل مهارة عبارة عن مجلد يحتوي ملفَّين: SKILL.md يصف اسم المهارة ومتى تُستخدَم، وهو ما يُضاف إلى موجّه النظام. وhandler.py الكود الذي يُنفَّذ فعلياً حين يقرر النموذج استخدام هذه المهارة. هذا الفصل بين التوصيف والتنفيذ هو ما يجعل النظام قابلاً للتوسع دون لمس الكود الأساسي.
المكوّنات الثلاثة الأخرى هي موجّه النظام System Prompt الذي يحمل شخصية الوكيل وقواعده وذاكرته طويلة المدى، وسجل الحوار الذي يمنح النموذج الاستمرارية، وفهرس المهارات الذي يُعرّف النموذج بما يستطيع فعله.
الثمانية مجتمعةً ليست تعقيداً زائداً. كل مكوّن يحل مشكلة محددة، وحذفه يعيدك إلى مشكلة لاحظتها في بداية هذا المقال.
الحلقة الوكيلة: حيث يُقرّر النموذج بنفسه
هذا هو الجزء الذي يُغيّر طريقة تفكيرك في الذكاء الاصطناعي كلياً.
حين تصل رسالة، لا يتبع النموذج تعليمات مُرمَّجة مسبقاً. يقرأ السياق الكامل ويُقرّر: هل يرد مباشرةً؟ أم يستدعي مهارة؟ وإن استدعى مهارة، فأيّها بالتحديد؟
١. استقبال الرسالة
↓
٢. بناء السياق الكامل
↓
٣. إرسال إلى النموذج
↓
٤. النموذج يُقرّر: رد مباشر أم استدعاء مهارة؟
↓
٥. [إذا مهارة] تنفيذ المهارة ← إعادة النتيجة للنموذج
↓
٦. [النموذج يُكرّر أم يُنهي؟]
↓
٧. إرسال الرد النهائي للمستخدمالمرحلة الرابعة هي القلب. بدلاً من تشفير المنطق مسبقاً، يُعلَم الوكيل بالمهارات المتاحة ويترك له أن يكتشف بنفسه أيّها يناسب كل موقف. في التطبيق التقليدي تُحدد أنت مسبقاً متى يبحث ومتى يحسب ومتى يرفض. في النظام الوكيلي، النموذج يقرر.
الأثر العملي يستحق الانتباه: جودة قرارات الوكيل ترتبط ارتباطاً مباشراً بجودة توصيف المهارات في ملفات SKILL.md، لا بجودة الكود في handler.py. الوكيل الأذكى ليس من يملك كوداً أنظف، بل من يملك توصيفات مهارات أوضح. إذا كنت تبني وكيلاً وتجد قراراته عشوائية، ابدأ بمراجعة توصيفاتك قبل مراجعة الكود.
كيف يؤثر جودة توصيف المهارات على دقة القرارات في أنظمة الوكلاء متعددة الخطوات سؤال لا تزال أبحاث الـ AI Alignment تُعالجه مباشرةً.
نموذج المهارة كاملاً: من الفكرة إلى الكود
لفهم كيف يبدو هذا فعلياً، إليك مهارة بحث كاملة.
ملف التوصيف SKILL.md:
markdown
name: web_search
description: ابحث في الإنترنت عن معلومات حديثة.
استخدمها للأخبار والأحداث الراهنة وأي معلومة تحتاج تحديثاً.
لا تستخدمها للأسئلة التي تعرف إجابتها بالفعل.ملف التنفيذ handler.py:
python
import requests
def handle(params: dict) -> str:
query = params.get("query", "")
if not query:
return "خطأ: لم يُحدَّد استعلام البحث"
url = f"https://api.duckduckgo.com/?q={query}&format=json&lang=ar"
try:
response = requests.get(url, timeout=10)
data = response.json()
abstract = data.get("AbstractText", "")
if abstract:
return f"نتيجة البحث عن '{query}':\n{abstract}"
return f"لم أجد نتائج مباشرة لـ '{query}'."
except Exception as e:
return f"خطأ في البحث: {str(e)}"لاحظ السطر الأخير في SKILL.md: “لا تستخدمها للأسئلة التي تعرف إجابتها بالفعل.” هذا السطر وحده يُقلّل استدعاءات البحث غير الضرورية بنسبة ملحوظة. التوصيف لا يخبر النموذج فقط متى يستخدم المهارة، بل متى لا يستخدمها أيضاً.
إدارة الذاكرة: المشكلة التي يتجاهلها الجميع
معظم الأمثلة التعليمية تتجاهل مشكلة حقيقية تظهر بعد أسابيع من الاستخدام: سجل المحادثة يكبر بلا حدود.
كل رسالة تُرسَل للنموذج تحمل معها كامل السجل السابق. بعد مئة محادثة، أنت تدفع ثمن إرسال آلاف الرموز في كل طلب، معظمها سياق قديم لا علاقة له بالسؤال الحالي.
الحل الأمثل: ذاكرتان بدل واحدة.
الذاكرة قصيرة المدى: آخر عشرين رسالة في كل طلب. تضمن الاستمرارية المباشرة وتُبقي التكلفة منضبطة.
الذاكرة طويلة المدى: ملف نصي يحتوي ملخصاً دورياً للمعلومات الثابتة عن المستخدم. تفضيلاته، مشاريعه الجارية، السياق المهني. يُحدَّث تلقائياً كل عشر محادثات عبر طلب تلخيص موجّه للنموذج نفسه.
python
def _update_long_term_memory(self, session_id: str):
"""تحديث الذاكرة طويلة المدى كل عشر محادثات"""
history = self._load_session(session_id)
if len(history) % 10 != 0:
return
response = self.client.messages.create(
model="claude-haiku-4-5",
max_tokens=500,
messages=[{
"role": "user",
"content": f"""من هذه المحادثة، استخرج المعلومات الثابتة
والمهمة عن المستخدم في نقاط موجزة لا تتجاوز عشر جمل:
{str(history[-20:])}"""
}]
)
memory_file = self.sessions_dir / f"{session_id}_memory.txt"
memory_file.write_text(response.content[0].text, encoding="utf-8")النتيجة: وكيل يتذكر أنك تعمل في مجال القانون وتفضّل الردود المختصرة وتستخدم الخدمة صباحاً، دون أن يحمل كامل سجل محادثاتك في كل طلب.
توجيه النماذج: كيف تُخفّض التكلفة بنصفها
أحد أذكى الأنماط في OpenClaw هو التمييز بين “العقول” و”العضلات”: نماذج قوية للتفكير المعقد، ونماذج اقتصادية للمهام التنفيذية البسيطة.
المنطق مباشر. سؤال “ما الوقت الآن؟” لا يستحق نموذجاً بحجم Claude Opus. سؤال “حلّل هذا العقد وحدد بنود المخاطر” يستحق أفضل ما تملك.
python
def _select_model(self, message: str, history: list) -> str:
simple_patterns = [
"الوقت", "كيف حالك", "شكراً",
"مرحبا", "السلام", "ما هو"
]
is_simple = any(p in message for p in simple_patterns)
is_short = len(message) < 50
is_short_history = len(history) < 3
if is_simple or (is_short and is_short_history):
return "claude-haiku-4-5"
return "claude-sonnet-4-6"توجيه المهام بحسب تعقيدها يُخفّض التكلفة الإجمالية بين أربعين وستين بالمئة في الاستخدام الشخصي الاعتيادي. هذا رقم مقيس من حالات استخدام موثّقة، لا تقدير نظري. والتطبيق لا يحتاج أكثر من عشرين سطراً كما ترى.
كيف تُعيد نماذج التسعير المتعددة لشركات الذكاء الاصطناعي تشكيل منطق بناء التطبيقات والمنتجات الرقمية سؤال يستحق التأمل قبل اتخاذ أي قرار معماري.
OpenClaw أم LangChain أم من الصفر؟
قبل أن تبدأ البناء، يستحق السؤال وقتاً: ما البديل؟
LangChain هو الإطار الأكثر شيوعاً لبناء تطبيقات الذكاء الاصطناعي. يوفر تجريدات جاهزة لكل شيء تقريباً: الذاكرة، الأدوات، السلاسل. لكنه يحمل ثمناً خفياً: التجريد يُخفي ما يجري، وحين يُخطئ تجد نفسك تتصفح عشرات الطبقات لفهم أين المشكلة.
AutoGPT وCrewAI يذهبان في اتجاه مختلف، نحو أتمتة كاملة للمهام المعقدة. قوتهما في التسلسل الطويل من المهام، لكنهما أثقل وأصعب تخصيصاً للاحتياجات الفردية البسيطة.
البناء من الصفر على غرار OpenClaw يعطيك فهماً كاملاً لكل سطر، لكنه يتطلب وقتاً أطول في البداية وصيانة مستمرة.
القرار يعتمد على ما تريده فعلاً: إذا كنت تبني منتجاً يحتاج إطلاقاً سريعاً، LangChain يوفر وقتاً. إذا كنت تبني نظاماً طويل الأمد بمتطلبات تحكم ودقة، البناء الذاتي يدفع تكلفته لاحقاً بدلاً من دفعها مقدماً.
لماذا تبني بدلاً من أن تثبّت فقط
ثمة ثلاثة أشياء لا تمنحها التثبيتة الجاهزة:
السيادة على البيانات. حين تبني أنت، تعرف بالضبط ما يُخزَّن وأين وكيف. لا طرف ثالث يملك حق الوصول افتراضياً. في سياق تتصاعد فيه متطلبات الامتثال لحماية البيانات في منطقة الخليج بوتيرة متسارعة، هذا ليس رفاهية بل شرط تشغيلي في سياقات بعينها.
التخصيص الحقيقي. النسخة الجاهزة مصممة لتناسب الجميع، وهذا يعني أنها لا تناسب أحداً تماماً. نسختك مصممة لاحتياجك أنت: اللغة، والمهارات، ونمط التفاعل، ومستوى الصلاحيات.
القدرة على التشخيص. حين يُخطئ الوكيل، وسيُخطئ، من بنى يعرف أين يبحث. من ثبّت فقط يفتح تذكرة دعم.
لكن لا تتوهّم أن البناء الذاتي هو الخيار الأمثل دائماً. ثمانية وخمسون بالمئة من المطورين لا يزالون يُفضّلون الحلول الجاهزة. الفارق ليس بين العاقل والمغامر، بل بين من يحتاج التحكم الكامل ومن تكفيه الكفاءة الجاهزة.
الأمان الذي لا يذكره أحد
معظم مقالات بناء الوكلاء تتجاهل بند الأمان حتى نهاية المقال، أو تذكره كملاحظة عابرة. هذا خطأ في الأولويات.
الوكيل الشخصي يملك في النهاية صلاحيات حقيقية: يقرأ ملفات، يبحث في الإنترنت، يُرسل رسائل، وربما يُعدّل بيانات. مشكلة حقن الأوامر Prompt Injection هي الأخطر: مستخدم يُرسل رسالة تحتوي تعليمات مُخفية تُغيّر سلوك الوكيل خارج ما تصوّرت.
ثلاثة إجراءات أساسية لا خيار فيها:
تحديد الصلاحيات في config.yaml بشكل صريح. كل مهارة تمتلك صلاحية وصول، والوصول للملفات يُقيَّد بمسارات محددة مسبقاً، لا بمسارات يُحددها المستخدم في الرسالة.
تعقيم المدخلات قبل تمريرها لأي مهارة. أي رسالة تحتوي على تعليمات نظام أو أوامر shell مشفّرة يجب أن تُوقف عند المحوّل قبل أن تصل للبوابة.
التسجيل الكامل للمهارات المُنفَّذة. كل استدعاء مهارة يُسجَّل مع الوقت والمعاملات. ليس للمراقبة، بل لأنك ستحتاج هذا السجل حين يحدث شيء غير متوقع.
python
# في gateway.py
def _execute_skill(self, skill_name: str, params: dict,
session_id: str) -> str:
# تحقق من الصلاحية أولاً
if not self._is_skill_permitted(skill_name):
return f"المهارة '{skill_name}' غير مسموح بها في هذا السياق"
# سجّل الاستدعاء
self._log_skill_call(session_id, skill_name, params)
# نفّذ
return self._run_skill_handler(skill_name, params)التشغيل المستمر: من الجهاز المحلي إلى الخادم
الوكيل الذي يعمل فقط حين يكون جهازك مفتوحاً ليس وكيلاً إنتاجياً. إذا أردت خدمة متواصلة، تحتاج خادماً.
Oracle Cloud يُقدّم طبقة مجانية دائمة Always Free بأربعة أنوية ARM وأربعة وعشرين غيغابايت RAM. كافية لتشغيل وكيل شخصي كامل مع نماذج خفيفة محلية إن أردت تجنب تكاليف API.
بعد نشر الملفات على الخادم، تُشغّل الوكيل كخدمة نظام:
ini
[Unit]
Description=My Personal AI Agent
After=network.target
[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/my-agent
ExecStart=/home/ubuntu/my-agent/venv/bin/python main.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetالسطر Restart=always هو ما يجعل الخدمة تُعيد التشغيل تلقائياً عند أي خطأ غير متوقع. بدونه، خطأ واحد يُوقف الوكيل حتى تتدخل يدوياً.
ملاحظة للقارئ العربي
معظم التوثيقات والأمثلة مكتوبة للسياق الغربي، وحين تبني مساعداً بالعربية تظهر تحديات لا يذكرها أحد.
النموذج يُفكّر داخلياً بالإنجليزية ثم يُترجم، وهذا يؤثر على دقة استدعاء المهارات حين تكون توصيفاتها عربية. الاختبار العملي يُظهر أن النماذج الكبرى تتعامل مع التوصيفات العربية بشكل معقول، لكن النماذج الخفيفة تُخطئ في الاستدعاء بنسبة أعلى مقارنةً بالتوصيفات الإنجليزية. الحل العملي: اكتب التوصيفات بالعربية للمعنى وأضف سطراً إنجليزياً مختصراً للنموذج.
معالجة الرسائل الصوتية بالعربية العامية في مرحلة النسخ النصي تحتاج نموذجاً مُعدَّلاً. Whisper من OpenAI يتعامل مع العربية بشكل مقبول لكن يُخطئ في اللهجات الخليجية والمغاربية أكثر من الفصحى. إذا كان جمهورك يتكلم بلهجة محددة، اختبر النسخ النصي قبل بناء منطق المهارات.
الذاكرة طويلة المدى بالعربية تواجه مشكلة أخرى: النموذج حين يلخص المحادثة يميل أحياناً لترجمة المعلومات للإنجليزية في الملف. أضف تعليماً صريحاً في موجّه التلخيص: “أجب بالعربية فقط.”
هذه ليست عوائق تمنعك من البناء. لكنها عوائق تمنعك من النسخ الأعمى.
من مستخدم إلى بانٍ
بناء وكيل شخصي لا يُغيّر أداةً في يدك. يُغيّر موقعك من سلسلة القيمة.
المستخدم يستهلك قدرة معالجة يملكها آخرون ويدفع مقابلها اشتراكاً شهرياً وسيادةً على بياناته. الباني يُحوّل هذه القدرة إلى بنية تحتية خاصة، يتحكم في منطقها وبياناتها وتكلفتها ويضيف إليها ما يريد متى يريد.
ما بدأه شتاينبيرغر في عطلة نهاية أسبوع أصبح مرجعاً تعليمياً لأنه جعل هذه البنية مقروءة. ليس لأن الكود سحري، بل لأن المشكلة التي يحلّها حقيقية والمنطق الذي يقوم عليه قابل للفهم والتكرار.
النسخة المصغّرة التي يمكنك بناؤها اليوم ببوت تيليغرام وثلاث مهارات وكود Python خالص لا تحتاج مئة ألف نجمة لتكون مفيدة. تحتاج أن تحل مشكلتك تحديداً، بالأمان الذي تختاره، وبالتكلفة التي تقبلها.
السؤال الذي تتركه هذه المعمارية مفتوحاً ليس تقنياً: حين يصبح بناء الوكلاء في متناول الفرد، هل نحن أمام ديمقراطية حقيقية للذكاء الاصطناعي، أم أمام طبقة جديدة تتمايز بالفهم لا بالوصول؟