العقل الثاني العلني
Second Mind — gpt4ar

نظرة داخلية على بنية Clawdbot (المعروف سابقًا بـ Moltbot) — ترجمة عربية

2026-01-30•العودةالزيارات: 58
تحت المراجعة
AIAgentsToolsOpenClawArchitectureNews
مفاهيم ذات صلة
Lane QueuesSession JSONLHybrid Memory SearchContext Window GuardTooling Surface

المصدر (النص الأصلي): https://x.com/Hesamation/status/2017038553058857413

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

مخطط مبسّط لمعمارية Clawdbot/Clawd كما ورد في المصدر

الترجمة العربية

ألقيتُ نظرة من الداخل على معمارية Clawdbot (المعروف أيضًا باسم Moltbot) وكيف يدير تنفيذ الوكيل (Agent executions)، واستخدام الأدوات (tool use)، والمتصفح (browser)، وغير ذلك.

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

بدأ هذا الأمر بدافع فضول شخصي: أردتُ أن أفهم كيف يدير Clawd “الذاكرة” (memory) وما مدى موثوقيتها. في هذا المقال سأمرّ على مستوى “سطحي” من طريقة عمل Clawd.

ما هو Clawd تقنيًا؟

لكي يكون الأمر واضحًا للجميع: Clawd هو مساعد شخصي يمكنك تشغيله محليًا (على جهازك) أو عبر واجهات برمجة نماذج (model APIs)، ويمكنك الوصول إليه بسهولة حتى من هاتفك. لكن… ما هو فعليًا في الجوهر؟

في جوهره، Clawdbot هو تطبيق CLI مكتوب بـ TypeScript. ليس Python، ولا Next.js، ولا تطبيق ويب. هو عبارة عن عملية (process) تعمل على جهازك وتقوم بالآتي:

  • تعمل على جهازك وتفتح خادم Gateway ليتولى كل اتصالات القنوات (Telegram، WhatsApp، Slack… إلخ)

  • تُجري اتصالات مع واجهات نماذج الذكاء الاصطناعي (Anthropic، OpenAI، نماذج محلية… إلخ)

  • تنفّذ الأدوات محليًا

  • وتفعل ما تريد على جهازك.

المعمارية (Architecture)

ولتفسير المعمارية بشكل أبسط، إليك مثالًا لما يحدث عندما ترسل رسالة إلى Clawd وحتى لحظة استلامك للنتيجة.

عندما تكتب إلى Clawd على أحد تطبيقات المراسلة، يحدث التالي:

1) مُحوّل القناة (Channel Adapter)

محوّل القناة يأخذ رسالتك ويعالجها (توحيد/تطبيع الرسالة، استخراج المرفقات…).

لكل تطبيق مراسلة (أو لكل مصدر إدخال) “محوّل” مخصص.

2) خادم الـGateway

خادم الـGateway — وهو منسّق المهام/الجلسات (task/session coordinator) — يستقبل رسالتك ثم يمررها إلى الجلسة المناسبة.

هذا هو قلب Clawd. إذ يمكنه التعامل مع عدة طلبات متداخلة.

ولكي يُسلسل العمليات (serialize operations)، يستخدم Clawd صفّ أوامر مبني على مفهوم المسارات (lane-based command queue).

لكل جلسة (session) “مسار” (lane) مخصص لها، والمهام منخفضة المخاطر القابلة للتوازي يمكن تشغيلها في مسارات متوازية (مثل مهام الـCron).

المصدر: https://x.com/Hesamation/status/2017038553058857413

تكملة الترجمة (الجزء الإضافي)

لماذا “Lane Queue” أفضل من فوضى async/await؟

يشرح الكاتب أن هذا النهج يختلف عن استخدام async/await بشكل عشوائي (spaghetti). فالمبالغة في التوازي تُضعف الموثوقية وتحوّل المشروع إلى “كابوس تصحيح أخطاء” بسبب:

  • تداخل السجلات (logs) بشكل يجعلها غير قابلة للقراءة.

  • احتمالات مستمرة لسباقات الحالة (race conditions) إذا كانت هناك حالة مشتركة.

الفكرة أن التسلسل (Serial) هو الوضع الافتراضي، والتوازي (Parallel) يتم الذهاب إليه بشكل صريح عندما تكون متأكدًا أنه آمن. وهذا قريب من خلاصة شائعة في عالم الوكلاء: اسأل نفسك دائمًا “ما الذي يمكن توازيه بأمان؟” بدل “ما الذي أحتاج لقفله (lock)؟”.

3) مشغّل الوكيل (Agent Runner)

هنا يدخل الذكاء الاصطناعي فعليًا. وفق الوصف:

  • يقرر أي نموذج يجب استخدامه.

  • يختار مفتاح الـAPI المناسب، وإذا فشل مفتاح/بروفايل معيّن يتم وضعه في فترة تهدئة (cooldown) وتجربة التالي.

  • يستخدم نموذجًا بديلًا (fallback) إذا فشل النموذج الأساسي.

ثم يقوم مشغّل الوكيل بتجميع “system prompt” بشكل ديناميكي، اعتمادًا على:

  • الأدوات المتاحة (tools)

  • المهارات (skills)

  • الذاكرة (memory)

  • تاريخ الجلسة (session history) المُخزّن عادة في ملف .jsonl

بعد ذلك تمر البيانات على “حارس نافذة السياق” (Context Window Guard) للتأكد من وجود مساحة كافية في نافذة السياق. وإذا كانت النافذة ممتلئة تقريبًا، فإما:

  • يتم ضغط/تلخيص الجلسة (compact) لتوفير مساحة، أو

  • يتعامل النظام مع الحالة بشكل آمن (يفشل gracefully بدل الانهيار).

4) استدعاء نموذج اللغة (LLM API Call)

الاستدعاء نفسه يدعم البث (streaming) ويقدم طبقة تجريد (abstraction) فوق مزودين مختلفين. ويمكنه أيضًا طلب “تفكير موسّع” (extended thinking) إذا كان النموذج يدعمه.

5) الحلقة الوكيلية (Agentic Loop)

إذا أعاد النموذج “استدعاء أداة” (tool call)، ينفّذ Clawd الأداة محليًا ثم يضيف النتائج إلى المحادثة. تتكرر هذه الدورة حتى:

  • يعيد النموذج نصًا نهائيًا، أو

  • يصل إلى الحد الأقصى للدورات (الافتراضي تقريبًا ~20).

وهنا — حسب الكاتب — يحدث “السحر” خصوصًا في ميزة استخدام الكمبيوتر (Computer Use).

6) مسار الاستجابة + حفظ الجلسة

الاستجابة تعود للمستخدم عبر القناة (Telegram/…)، ويتم حفظ الجلسة في ملف JSONL: كل سطر يمثل كائن JSON يحتوي على رسالة المستخدم، واستدعاءات الأدوات، والنتائج، والاستجابات… إلخ. وهذا جزء أساسي من “ذاكرة مبنية على الجلسة”.

كيف يتذكر Clawd؟

بدون ذاكرة، يصبح أي مساعد مثل “سمكة ذهبية”؛ ينسى بسرعة. ووفق النص، يعتمد Clawd على نظامين:

1) سجلات الجلسات (Session transcripts) بصيغة JSONL. 2) ملفات ذاكرة طويلة المدى بصيغة Markdown مثل MEMORY.md أو داخل مجلد memory/.

وللبحث داخل الذاكرة، يستخدم مزيجًا (Hybrid) من:

  • بحث دلالي (Vector search)

  • وبحث بالكلمات المفتاحية (Keyword/FTS)

مثال: البحث عن “authentication bug” يمكن أن يجد وثائق تتحدث عن “auth issues” (دلاليًا) ويطابق العبارة حرفيًا (كلمات مفتاحية).

تقنيًا (بحسب النص):

  • يستخدم SQLite للتضمينات/الفهرسة.

  • ويستخدم FTS5 (امتداد SQLite) للبحث بالكلمات المفتاحية.

  • مزود الـembeddings قابل للتغيير.

ويستفيد من “مزامنة ذكية” (Smart Syncing) عبر مراقبة تغييرات الملفات (file watcher). ولا توجد “واجهة خاصة لكتابة الذاكرة”؛ الوكيل ببساطة يكتب إلى ملفات memory/*.md عبر أدوات الكتابة العادية.

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

“مخالب” Clawd: كيف يستخدم الكمبيوتر؟

يرى الكاتب أن إحدى نقاط القوة الأساسية (moat) هي أن Clawd يمتلك “كمبيوترًا” يستطيع استخدامه.

  • أداة exec لتشغيل أوامر على:
  • sandbox (افتراضيًا داخل Docker)
  • الجهاز المضيف (host)

  • أجهزة بعيدة (remote)

  • أدوات ملفات: read / write / edit

  • أداة المتصفح (Browser) المبنية على Playwright

  • إدارة عمليات طويلة: process لتشغيل/إيقاف/قتل العمليات في الخلفية

الأمان (وحدوده)

يشير النص إلى وجود نظام موافقات (allowlist) للأوامر:

  • “اسمح مرة” / “اسمح دائمًا” / “ارفض”

وملف موافقات على نمط:

// ~/.clawdbot/exec-approvals.json
{
  "agents": {
    "main": {
      "allowlist": [
        { "pattern": "/usr/bin/npm", "lastUsedAt": 1706644800 },
        { "pattern": "/opt/homebrew/bin/git", "lastUsedAt": 1706644900 }
      ]
    }
  }
}

ويذكر أن بعض الأوامر “الآمنة” تكون مُعتمدة مسبقًا (مثل: jq, grep, cut, sort, uniq, head, tail, tr, wc)، بينما تُحظر تراكيب خطيرة افتراضيًا مثل:

npm install $(cat /etc/passwd)      # command substitution
cat file > /etc/hosts              # redirection
rm -rf / && echo "failed"          # chained commands
(sudo rm -rf /)                    # subshell

المتصفح: “لقطات دلالية” بدل صور ثقيلة

يوضح الكاتب أن أداة المتصفح لا تعتمد أساسًا على screenshot، بل على لقطة دلالية (semantic snapshot): تمثيل نصي لشجرة الوصول (ARIA) مثل:


- button "Sign In" [ref=1]

- textbox "Email" [ref=2]

- textbox "Password" [ref=3]

- link "Forgot password?" [ref=4]

- heading "Welcome back"

ويذكر ثلاث فوائد أساسية لهذا الأسلوب:

  • التصفح ليس دائمًا مهمة “بصرية”؛ كثير منه قابل للحل نصيًا.

  • حجم أقل بكثير (مثلًا: 50KB بدل عدة MB للصورة).

  • تكلفة رموز (tokens) أقل من معالجة صورة كاملة.

مفاهيم للتوسّع (روابط مباشرة)

📥 تنزيل بصيغة Markdown
روابط
تواصل
© 2026 جميع الحقوق محفوظة.