بناء وكيل تحليلات ذكي مع Claude: قصة Blobby من Omni — دليل عملي 2026

تخيل أنك مدير شركة تقنية سريعة النمو ومعك فريق من 25 مهندساً فقط، لكن مئات الشركات تعتمد على منصتك لتحليل بياناتها. أنت تعلم أن مستقبل عملك يعتمد على الذكاء الاصطناعي، لكن كيف تبني وكيل (Agent) — برنامجاً ذكياً يستطيع فهم الأسئلة المعقدة وتحويلها إلى إجابات دقيقة من بياناتك؟ هذا بالضبط ما شاركه CTO شركة Omni في مؤتمر Code with Claude 2026 من Anthropic. في هذا المقال، سنأخذك في رحلة بناء “Blobby” — وكيل التحليلات الذكي — خطوة بخطوة، ونتعلم الدروس التي اكتشفها فريق Omni بعد 18 شهراً من التطوير.

1. ما هي Omni وما مشكلة التحليلات الذكية؟

Omni هي منصة تحليلات تعمل بالذكاء الاصطناعي تتيح لك “التحدث مع بياناتك”. بدلاً من كتابة استعلامات SQL (لغة الاستعلام الهيكلية — وهي الطريقة التقليدية لسؤال قواعد البيانات) المعقدة، يمكنك ببساطة أن تسأل سؤالاً بالعربية أو الإنجليزية وتحصل على إجابة فورية مع رسم بياني.

المتحدث، وهو CTO (كبير مسؤولي التقنية) في Omni، يوضح شيئاً مدهشاً: فريقهم المكون من 25 مهندساً فقط، أنتج commit (تحديثات كود) على مستودعهم الرئيسي بأضعاف ما كانوا ينتجونه قبل استخدام Claude. والأكثر إثارة أنه كـ CTO، كان يتوقع أن يتوقف عن كتابة الكود تماماً بسبب مسؤولياته الإدارية — لكن Claude سمح له بالاستمرار في البرمجة.

تشبيه: تخيل أن فريق بناء منازل مكون من 25 عاملًا فقط تمكن من بناء مدينة بأكملها — هذا ما حدث مع Omni. السر؟ أداة ذكية تضاعف إنتاجية كل مهندس 3-5 أضعاف.

في بداية 2025، قال CTO للفريق: “لا أعرف متى ولا كيف، لكنني أعلم أن وظائفنا تتغير. فلنبدأ بالتجربة.” وبالفعل بدأوا، لكن النقلة النوعية الحقيقية جاءت مع إصدار Claude Opus — حيث قال كبار المهندسين: “الآن هذا حقيقي، هذا يساعد باستمرار.”

2. الطبقة الدلالية (Semantic Layer) — مترجم البيانات

قبل أن نبني أي وكيل، يجب أن نفهم مشكلة أساسية: Claude (نموذج الذكاء الاصطناعي المطور من شركة Anthropic) بارع في الإجابة على الأسئلة العامة، لكنه لا يعرف تفاصيل عملك. إذا أردته أن يجيب عن أسئلة شركتك، يجب أن تخبره كيف تعمل شركتك، والمصطلحات التي تستخدمها، وكيف تبدو بياناتك.

هذا هو دور الطبقة الدلالية (Semantic Layer). شبهها بمترجم فوري يجلس بين المستخدم وقاعدة البيانات:

الطبقة الدلالية تقوم بثلاث مهام رئيسية:

1. تنظيم البيانات (Curation): في الشركات الحقيقية، هناك عشرات الآلاف من جداول البيانات. الطبقة الدلالية تقول: “هذه الجداول مهمة، تجاهل الباقي.”
2. تشفير السياق (Context Encoding): مثلما تستخدم ملف CLAUDE.md مع Claude Code لإعطاء تعليمات للمشروع، الطبقة الدلالية تضع الوصف بجانب كل حقل بيانات.
3. الصلاحيات (Permissions): تضمن أن كل موظف يرى فقط البيانات المسموح له بها.

والأهم من كل هذا: حلقة التغذية الراجعة (Feedback Loop). لأن البيانات في أي مؤسسة حقيقية تتغير باستمرار، كل سؤال يُطرح على النظام يُغذي التعريفات والسياق — ليتعلم النظام بشكل مستمر.

حتى “الربع الماضي” يعني أشياء مختلفة في أقسام مختلفة. في قسم الهندسة، الربع الماضي هو الربع التقويمي. في قسم المبيعات، هو الربع المالي. الطبقة الدلالية تتعامل مع هذه الفروقات الدقيقة.

3. المرحلة الأولى: سؤال وجواب بسيط

النسخة الأولى من Blobby (BB-1) كانت بسيطة: سؤال واحد، إجابة واحدة. أسرع الفريق ليكتشف أن هذا لا يكفي. المشكلة؟ لا يوجد سياق كافٍ.

تشبيه: تخيل أنك تسأل شخصاً غريباً عن عنوان منزل صديقك دون أن تعطيه اسم الشارع أو رقم المبنى. هذا ما كانت تفعله النسخة الأولى — تسأل Claude دون أي معلومات عن بياناتك.

4. المرحلة الثانية: إضافة السياق والوصف

أدرك فريق Omni أنهم بحاجة لإعطاء Claude “خريطة” لبياناتهم. لذلك أضافوا:

• AI Context (سياق الذكاء الاصطناعي): وصف خاص للـ LLM (نموذج اللغة الكبير — “Large Language Model” وهو النموذج الذي يشغل الذكاء الاصطناعي) يشرح كيف يستخدم كل حقل بيانات ومتى.
• Sample Queries (نماذج استعلامات): أمثلة حقيقية لاستعلامات ناجحة — “هذا هو الاستعلام الذي تجريبه إذا سألك أحدهم عن X.”
• القيم الفعلية (Values): إعطاء Claude عينة من القيم الموجودة في كل حقل. مثلاً، إذا كان حقل “المنطقة” يحتوي قيماً مثل “AMEA, NAM, APAC”، يستنتج Claude أن هذه اختصارات لمناطق عالمية، فإذا سأل المستخدم عن “الولايات المتحدة” يمكنه استخدام “US”.

هذه الإضافات رفعت جودة الإجابات بشكل ملحوظ، لكن Blobby ما زال ليس وكيلاً حقيقياً.

5. المرحلة الثالثة: الحلقة الوكيلية (Agentic Loop)

هنا حدثت القفزة الكبرى: إضافة الحلقة الوكيلية (Agentic Loop) — وهي دورة متكررة يخطط فيها الوكيل، ينفذ، يتحقق من النتيجة، ويصحح الأخطاء بنفسه.

الفريق بنى Agentic Harness (إطار عمل وكيلي — البنية التحتية التي تدير الوكيل) خاصاً به، يتضمن مفهوم المهام (Tasks) الذي تملكه كل وكلاء AI الجيدين.

أكبر تحسين في الجودة جاء من شيئين بسيطين:

1. تعليم Blobby كيف يتعافى من الأخطاء وإعطائه “ميزانية” معينة من المحاولات.
2. الاستثمار في رسائل خطأ وصفية — كلما فشل شيء، يشرح سبب الفشل وكيفية إصلاحه.

وحدهما رفعا درجة الجودة (Quality Score) بشكل دراماتيكي. ثم لاحظ الفريق شيئاً مهماً: نموذج Haiku (النموذج الخفيف من Claude) كان ممتازاً للأسئلة البسيطة، لكنه لم يكن مصمماً للمحادثات الوكيلية المعقدة. فتحولوا إلى Claude Sonnet.

وهذا التحول أدى لطفرة في استخدام العملاء — الذين بدأوا يقولون: “هذا السؤال إما أنني لم أكن لأستطيع الإجابة عليه أبداً، أو كان سيأخذ مني ساعات!”

6. قصة Blubotomies — تشريح الأخطاء

المدير التنفيذي لـ Omni، كأي مدير تنفيذي جيد، كان المستخدم الأكثر انتقاداً. يقول للفريق: “أعرف أن هذا الشيء جيد جداً، لكنه أخطأ في هذا السؤال. اذهب وأصلحه.” رد المهندسون: “كولن، نماذج LLM غير متوقعة قليلاً — عليك تقبل أنها لن تكون مثالية دائماً.” فأجاب: “ليس جيداً كفاية، اذهب وأصلحه.”

هذا قادهم إلى استثمار كبير في فهم التتبعات (Traces) — سجلات كاملة لكل جلسة استخدام. وهذه التتبعات قادتهم لسلسلة “جراحات كبرى” أطلقوا عليها Blubotomies.

أهم اكتشاف: مشكلة الدماغ المنقسم (Split Brain). التصميم الأصلي كان ذكياً جداً: وكيل خارجي مسؤول عن إنشاء قائمة المهام (يفهم كل البيانات المتاحة)، ووكيل فرعي مسؤول عن توليد الاستعلامات (SQL). لكن عند فحص التتبعات، اكتشفوا أن الوكيل الخارجي كان يطلب من الوكيل الفرعي: “أجب عن سؤال حول Pull Requests GitHub وبيانات الدعم ولخص هذه الأشياء.” والوكيل الفرعي يجيب: “لا أستطيع — هذا يحتاج استعلامات متعددة!”

تشبيه: تخيل أنك تطلب من مساعدك أن يرسم لك خريطة، وهو يمرر الطلب لشخص آخر لا يعرف سوى رسم خطوط مستقيمة. المشكلة ليست في أي منهما، بل في الفجوة بين ما يطلبه الأول وما يستطيع الثاني تنفيذه.

الحل كان بسيطاً وعميقاً: دمج الدماغ (Consolidating the Brain). سحبوا أدوات الوكيل الفرعي إلى الوكيل الخارجي — لم يعد هناك انقسام. هذا وحده حسّن بشكل كبير أداء النظام على التقييمات الصعبة.

7. SQL بدلاً من JSON المملوك — قفزة الكفاءة

قفزة النوعية التالية جاءت من اتجاه غير متوقع. في البداية، كانت Omni تستخدم تنسيق JSON (تنسيق بيانات منظم — JavaScript Object Notation) خاص بها لتمثيل الاستعلامات. لكن أحد المهندسين، Steven، أخرج كوداً قديماً من الرف — محرك تحليل SQL (SQL Parser) بنته Omni في أيامها الأولى.

المنطق كان: Claude بارع في كتابة SQL، ولغة SQL معيار عالمي معروف، لمَ لا ندع Claude يكتب SQL مباشرة ثم نحلّلها؟ هذا وفر شيئين:

1. لم نعد نعلّم Claude لغة JSON خاصة بنا — هو يعرف SQL أصلاً.
2. استعلامات أكثر كفاءة — بدلاً من 3-4 استعلامات متسلسلة، استعلام واحد مع CTEs (Common Table Expressions — تعبيرات الجدول المشترك التي تتيح استعلامات معقدة بخطوات متوسطة).

المفارقة المدهشة: Claude يحب CTEs، ومحلل Omni ممتاز في تحليلها! زواج مثالي.

8. الهندسة الحالية: الحلقة الخارجية والداخلية

هذا هو شكل Blobby اليوم:

• الحلقة الخارجية (Outer Loop): مسؤولة عن نقاط التفتيش (Checkpoints) وضمان التعافي من الفشل.
• الحلقة الداخلية (Inner Loop): مجموعة أدوات (Tools) تتوسع باستمرار — توليد لوحات البيانات، التصورات (Visualizations)، أدوات التحقق، وحتى أدوات لنمذجة البيانات نفسها وتحسين الطبقة الدلالية.

لديهم أيضاً نظام تقييم (Eval System) داخلي، ويبنون نظاماً للعملاء أيضاً. CTO يعترف: “أحب التقييمات، لكن ليس للسبب المعتاد. أحب التقييمات لأن لديّ بيانات التتبعات الخام (Raw Trace Data). أحب أن أقول: هذا كان سيئاً، لماذا؟ وأنظر للبيانات.” هذه هي الملاحظة (Observability) — القدرة على رؤية ما يحدث داخل الوكيل — وهي أهم من التقييم نفسه من وجهة نظره.

9. كلود كود كمصدر إلهام — أكل طعامك بنفسك

ربما أجمل جزء في القصة: استخدام Claude Code (أداة البرمجة الذكية من Anthropic) لم يساعدهم فقط على البرمجة بشكل أسرع — بل علمهم كيف يصممون وكيلاً أفضل.

تشبيه: مثل طاهٍ يتعلم طبخ أطباق جديدة ليس فقط بقراءة الوصفات، بل بتجربة المطاعم الفاخرة. استخدام Claude Code علّم مهندسي Omni ما هي خصائص “الحزام الجيد” للوكيل.

يقول CTO: “من الصعب جداً على أي شخص بناء نظام لا يستطيع هو نفسه تصور استخدامه. كون مهندسينا يستخدمون Claude Code يومياً ساعدهم على فهم ما يريد المستخدمون من Blobby.” عندما احتاجوا طريقة جديدة لاستكشاف النموذج الدلالي (Semantic Model)، قالوا: “لنرَ كيف يفعلها Claude Code — لأن النموذج الدلالي ليس مختلفاً كثيراً عن قاعدة الكود.”

فلسفة Omni من منظور المنتج: AI لبناء واجهات المستخدم، ثم التحقق والتعديل يدوياً. الوكيل يبني لوحة البيانات، والمستخدم يعدلها ويحسّنها.

🔗 روابط ذات صلة

• أنظمة الوكلاء المتعددين 2026: من CrewAI إلى MCP — دليل شامل لأنظمة الوكيل المتعدد
• How we Claude Code — شرح مبسط لكيفية استخدام Claude Code
• بناء وكيل AI لاستقبال العملاء والرد عليهم: دليل شامل 2026

📚 المصادر والمراجع

• الفيديو الأصلي — Building the best agentic analytics harness: Powered by Claude, built with Claude Code — محاضرة من مؤتمر Code with Claude 2026
• وثائق Anthropic الرسمية — Claude API و Claude Code
• موقع Omni الرسمي — منصة التحليلات الذكية

💎 خاتمة

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

❓ الأسئلة الشائعة

ما الفرق بين Semantic Layer ووكيل AI العادي؟

الطبقة الدلالية (Semantic Layer) هي طبقة ترجمة بين سؤال المستخدم وقاعدة البيانات. تشرح معنى البيانات وتعطي سياقاً. الوكيل AI هو برنامج يستخدم هذه الطبقة ليخطط وينفذ ويتحقق. باختصار، الطبقة الدلالية هي “القاموس”، والوكيل هو “المترجم”.

لماذا تحولت Omni من Haiku إلى Sonnet؟

لأن المحادثات الوكيلية (Agentic Conversations) أصبحت أطول وأكثر تعقيداً. Haiku (النموذج الخفيف من Claude) ممتاز للأسئلة البسيطة المباشرة، لكن المحادثات متعددة الخطوات تحتاج نموذجاً أقوى مثل Sonnet.

ما هي مشكلة Split Brain في وكلاء AI؟

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

كيف يساعد تحليل SQL في تحسين أداء الوكيل؟

بدلاً من تعليم Claude تنسيق JSON خاص بشركتك للاستعلامات، دعه يكتب SQL مباشرة — لغة يعرفها أصلاً. هذا ينتج استعلامات أكثر كفاءة ويحتاج محاولات أقل، لأن SQL لغة معيارية عالمية وClaude بارع فيها.

هل يمكنني بناء وكيل تحليلات مشابه لمشروعي الصغير؟

نعم! ابدأ بالخطوات التالية: حدد أسئلتك الشائعة، أنشئ قاموساً لمصطلحات عملك، استخدم نموذج LLM مثل Claude أو GPT لترجمة الأسئلة لاستعلامات SQL، وأضف حلقة تغذية راجعة (Feedback Loop) حيث يتعلم النظام من كل سؤال جديد. لا تحتاج لفريق من 25 مهندساً — ابدأ صغيراً ووسّع تدريجياً.