وكلاء الذكاء الاصطناعي والأتمتة: RAG وسير العمل والأدلة

بنيتَ على OpenAI، ثم أردتَ تجربة Claude ومقارنة Gemini — فضاعت منك ساعات في اختلاف أدوات SDK والصيغ ومعالجة الأخطاء لكل مزوّد. بوابة LLM (بوابة الذكاء الاصطناعي / وكيل LLM) وسيط تُدرجه بين تطبيقك والمزوّدين: يعرض واجهة برمجية واحدة متوافقة مع OpenAI للوصول إلى كل نموذج، ويتولّى المهام الشاملة — التبديل الاحتياطي، وتتبّع التكلفة، والمفاتيح الافتراضية، والتخزين المؤقت، وتحديد المعدّل، والقابلية للمراقبة. يغطّي هذا الدليل لماذا تحتاج إليها، وما هي البوابة حقًّا، والأنواع الثلاثة (وكيل مُستضاف ذاتيًا = LiteLLM / مُدار = OpenRouter / SDK = Vercel AI SDK)، وكيف تختار بين LiteLLM وOpenRouter وVercel AI SDK، وكود إعداد أدنى يبدّل نقطة النهاية فقط، والحدود — قفزة زمن استجابة، والبوابة كنقطة فشل جديدة، والرسوم (يفرض OpenRouter 5.5% عند الشراء)، وفقدان الميزات، والخصوصية.

بعد أن تبني وكيل ذكاء اصطناعي، تصطدم دائماً بالجدار نفسه: "حسناً، لكن هل يعمل فعلاً؟" والآلية التي تقرّر ما إذا كان تغيير مطالبة أو نموذج قد جعل الأمور أفضل أم أسوأ اعتماداً على البيانات بدل الحدس هي الـ evals. تنتج نماذج اللغة الكبيرة مخرجاً مختلفاً في كل مرة للمدخل نفسه، لذا لا تناسبها اختبارات الوحدة بالمطابقة الدقيقة. يركّز هذا المقال على خطوات بنائها وتشغيلها فعلياً، ويتناول خمس طرق لقياس الجودة (① المطابقة مع الحقيقة المرجعية ② الفحوصات القائمة على القواعد ③ LLM-as-judge ④ اختبار التراجع ⑤ مراقبة الإنتاج)، والتقييم الخاص بالوكلاء (معدل نجاح المهمة، استدعاءات الأدوات الصحيحة، المسار، التكلفة)، وكيف تبدأ على نطاق صغير من 20 مثال إخفاق، والأخطاء الشائعة، والأدوات الأساسية (Anthropic Console/Evals، OpenAI Evals، LangSmith، Langfuse، Ragas) — وهو مكتوب للممارسين.

سؤال الأتمتة الدائم: «وكلاء الذكاء الاصطناعي أم RPA؟» الإجابة ليست إمّا هذا أو ذاك — اختر بحسب الدور، والنمط الرابح في 2026 هو مزج الاثنين (الهجين). RPA هو «يدان» حتميّتان تشغّلان إجراءً ثابتًا بسرعة ودقة (لكنه ينهار عند تغيّر الشاشة/المواصفات)؛ ووكيل الذكاء الاصطناعي هو «عقل» احتمالي يقرأ الموقف ويقرّر (قويّ في الغموض والاستثناءات، لكن ليس متطابقًا في كل مرة). تغطّي المقالة فرق مبدأ العمل، وجدول مقارنة (مقايضة قابلية التكرار مقابل المرونة)، وكيفية الاختيار (المحور هو «هل يُكتب بالكامل قواعدَ؟» — نعم ← RPA، حُكم لا يُكتب ← وكيل)، واتجاه 2026 (تحوّل روّاد RPA مثل UiPath وAutomation Anywhere وBlue Prism نحو الوكيلية — تقارب؛ لم يعد السؤال «أيهما» بل «أين يقع الاستدلال» = الأولوية للتنسيق)، والحل العملي: نموذج هجين يتولّى فيه العقل (الوكيل) الحُكم/التنسيق وتشغّل اليدان (RPA) التنفيذ الحتمي — لا تضع وكيلًا حيث تُطلب الحتمية، واقرِن الحُكم المفوَّض بحواجز حماية وموافقة بشرية. استنادًا إلى المعلومات الرسمية للموردين، مع أسئلة شائعة.

هل يمكنك تسليم تشغيل AWS إلى الذكاء الاصطناعي؟ في 2026 يمكنك تفويض الكثير. فـ AWS نفسها تقدّم Amazon Q Developer وAgent Toolkit for AWS (مايو 2026 — أكثر من 40 مهارة للوكلاء + خادم AWS MCP Server مُدار + إضافات)، بحيث يمتد الذكاء الاصطناعي من توليد البنية التحتية ككود إلى تشغيل الموارد. يؤطّر هذا الدليل «التفويض» في ثلاثة مستويات (① توليد الكود/البنية التحتية ككود، ② التشغيل/الاستقصاء القائم على القراءة، ③ وكيل ذاتي يشغّل AWS فعليًا)، ويغطّي الأدوات الرئيسية (Amazon Q Developer، وAgent Toolkit، وAWS MCP Server، وTerraform MCP، وBedrock AgentCore) — بما في ذلك مسار أدواتك الخاصة بمنح Claude Code أو Codex واجهة AWS CLI لتشغيل «aws» من الصدفة — والمزايا (بنية تحتية ككود سريعة، وفرز آلي، وأفكار لتحسين التكلفة، ودمقرطة المعرفة)، ثم صلب الموضوع: العيوب (تضخّم صلاحيات IAM، والصلاحية المفرطة كمضخّم لنطاق تأثير الأخطاء/حقن التعليمات، والصلاحيات التي تعمّر بعد المهمة، وانفلات التكلفة — مع حوادث فعلية لحذف قواعد بيانات إنتاجية في 2025-2026)، اعتمادًا على مصادر AWS الرسمية وشركات الأمن. المفارقة الجوهرية: السؤال ليس «هل يستطيع؟» بل «كيف تفوّض دون انفلات أو انفجار في الفاتورة» — وبناء AWS نفسها لحواجز حماية IAM وتدقيق CloudTrail والعزل ضمن Agent Toolkit يبيّن شكل الإجابة. ويشمل المبادئ الخمسة (صلاحيات IAM الأقل امتيازًا، وموافقة بشرية على العمليات المدمّرة، وقابلية المراقبة، وبيانات اعتماد قصيرة العمر تُصدر عند الحاجة، والعزل) وقسم أسئلة شائعة.

أول عقبة عند دمج وكيل ذكاء اصطناعي في عمل حقيقي هي «على أي إطار عمل تبنيه». من منظور المطوِّر ومتّخذ قرار التقنية، يقارن هذا المقال ستة أطر كبرى — LangGraph وCrewAI وAutoGen (المدموج في Microsoft Agent Framework، GA أبريل 2026) وOpenAI Agents SDK وGoogle ADK وClaude Agent SDK — حسب مقاربة التنسيق (رسم بياني موجَّه / طاقم قائم على الأدوار / محادثة GroupChat / تسليمات / شجرة هرمية / حلقة أدوات مستقلة)، واللغة، ومنحنى التعلّم، والتحكم، ونضج الإنتاج، وتكلفة الرموز، وأنسب حالة استخدام. التحذير الأهم: إطار العمل «الأسرع في بناء النموذج الأولي» (CrewAI) قد يكون الأغلى في الإنتاج — نحو 3× من الرموز (41k مقابل 18.5k لـ LangGraph في أحد المعايير) ولاحتمي، ما يجعله غير مناسب للتمويل والرعاية الصحية. كما يشرح كيف جلب 2026 التشغيل البيني عبر MCP (الأدوات) وA2A (وكيل إلى وكيل)، بحيث صار وكلاء من أطر مختلفة يعملون معًا وتلاشى الاحتجاز. ويتضمن دليل اختيار حسب حالة الاستخدام وأسئلة شائعة.

قلنا في "كيف تبني نظامًا متعدد الوكلاء" إنه يجب تجهيز القياس لكل عملية تسليم قبل إضافة الوكلاء؛ والتقنية التي تشغّل هذا القياس في الإنتاج هي AI observability. فهي تُظهر ما تفعله LLMs والوكلاء فعليًا في الإنتاج (أي نموذج وبأي prompt، وأي أدوات وعمليات بحث، وما الذي أُعيد، وكم استغرق وكلّف) حتى تتبّع رجوعًا إلى السبب. الفرق الحاسم عن مراقبة التطبيقات العادية: قد يعيد الذكاء الاصطناعي 200 OK في 50ms ومع ذلك يهلوس بثقة، فمعظم الإخفاقات إخفاقات جودة (هلوسة، استرجاع ضعيف، إجابات غير آمنة، مهام غير مكتملة) لا إخفاقات بنية تحتية. تقوم الـobservability على ثلاث ركائز: traces (طلب واحد كشجرة spans) وmetrics (زمن الاستجابة والتكلفة والـtokens) وlogs. والمعيار OpenTelemetry GenAI يلتقط الـprompts والاستجابات والـtokens واستدعاءات الأدوات بمخطط محايد قابل للتغذية في Datadog/Grafana. الفرق الأكثر خلطًا هو observability مقابل evals: الأولى تُظهر ما حدث، والثانية تقيس جودة الإجابة (الدقة وgroundedness والأمان). تنقسم المقاييس إلى تشغيلية (تكلفة، زمن استجابة، tokens) وجودة (هلوسة، groundedness الأهم لـRAG، أمان، إتمام المهمة)، مع كشف الهلوسة عبر LLM-as-a-judge ودرجات groundedness. الأدوات الرئيسية: LangSmith وLangfuse وArize Phoenix وMLflow وAgentOps وOpenTelemetry. ابدأ بالتقاط traces ثم صوّر المقاييس واربط evals قبل الإطلاق. للأنظمة متعددة الوكلاء المراقبة ضرورية لأن الإخفاقات تختبئ في سلاسل متعددة الخطوات.

بعد استيعاب المفهوم في «ما هو نظام الوكلاء المتعددين؟»، هذا هو الجزء العملي التالي. باستخدام نمط supervisor المعياري لعام 2026، يرشد المبتدئين عبر بناء من 5 خطوات. المبدأ الأساسي: ابنِ بوكيل واحد أولاً وأضِف الوكلاء بأقل قدر فقط بعد بلوغ حد ما (نحو 80% من الحالات تكفيها واحد؛ واستخدام نظام متعدد لعمل بسيط أحادي المسار يضخّم التكلفة 3-10x ويخفض الدقة -39-70% في المهام التسلسلية حسب أبحاث Google). ثلاث علامات للانتقال: فصل التخصصات، التوازي، فصل القرار. نمط supervisor (يتلقى المهمة الكلية، يقسّمها، يفوّضها إلى workers متخصصين، ويجمّع النتائج) هو ما تقاربت عليه وكلاء Claude Code الفرعيون وLangGraph Supervisor وOpenAI Agents SDK، لأوسع دعم ونمط فشل معروف وسهولة التدقيق. الخطوات الخمس: التقسيم، تعريف الـ workers، تصميم الـ supervisor، التسليم، القياس مع حدود قصوى وعمليات تقييم وحواجز أمان. الدرس: الموجّهات والأدوات وحزمة التقييم تحدد النجاح أكثر من إطار العمل.

بعد أن أصبح وكلاء الذكاء الاصطناعي أمرًا شائعًا، صار التحدي التالي هو كيفية جعل الوكلاء يتعاونون فيما بينهم. إذا كان MCP يربط الوكيل بأدواته، فإن A2A (Agent2Agent) يربط الوكيل بوكيل آخر — معيار مفتوح يتيح لأنظمة الذكاء الاصطناعي المبنية على مزوّدين وأُطر عمل مختلفة أن تكتشف بعضها وتتواصل وتتعاون عبر اصطلاح مشترك. أطلقته Google في أبريل 2025، وتبرّعت به لمؤسسة Linux Foundation في يونيو، ووصل إلى الإصدار v1.0 في 2026. يغطّي هذا الدليل للمبتدئين ما هو A2A (بتشبيه آداب الشراكة التجارية)، ولماذا نحتاجه (وكلاء متخصّصون يتناوبون العمل — وكيل تخطيط ثم وكيل حجز فنادق ثم وكيل دفع)، وكيف يختلف عن MCP (MCP عمودي، الوكيل ↔ الأدوات؛ وA2A أفقي، الوكيل ↔ الوكيل؛ والجمع بينهما هو الإعداد القياسي ذو الطبقتين)، وكيف يعمل (تُستخدم بطاقة وكيل — ملف JSON يشبه «بطاقة العمل» عند /.well-known/agent-card.json — لاكتشاف القدرات، ثم تحمل المهمة (Task) الطلب عبر حالات مثل working وinput-required وcompleted، وتُعيد النتيجة (Artifact) المُخرَج، كل ذلك عبر HTTP وServer-Sent Events وJSON-RPC 2.0، مع إبقاء الوكلاء دواخلهم خفيّة)، ووضعه الحالي والتطبيق (حتى أبريل 2026: 150+ مؤسسة في بيئة الإنتاج، 22,000+ نجمة على GitHub، وحِزم تطوير بخمس لغات — Python وJavaScript وJava وGo و.NET — بمشاركة Microsoft وSalesforce وSAP وServiceNow). القاعدة المساعدة على التذكّر: الاتصال بالأدوات = MCP، والاتصال بالأنداد = A2A.

بنيت نظام RAG لكن جودة البحث متوسطة — وهنا بالضبط تساعد إعادة الترتيب. تعيد إعادة الترتيب تقييم المرشحين الذين جُمعوا بشكل تقريبي عبر البحث بالتضمين (المتجهات) حسب صلتهم بالاستعلام، ثم تعيد ترتيبهم وتُبقي الأفضل فقط؛ وهذه الخطوة الواحدة قد تُغيّر جذريًا جودة إجابات نظام RAG. يغطي هذا الدليل للمبتدئين ما هي إعادة الترتيب (بتشبيه الفرز الأولي والمقابلة النهائية)، ولماذا نحتاجها (البحث بالتضمين يحوّل الاستعلام والمستندات إلى متجهات بشكل منفصل، فيحكم على الصلة بخشونة فقط، والترتيب السيئ يخفض جودة الإجابة مباشرةً — وتذكر الأبحاث مكسبًا في دقة RAG يبلغ نحو 40% من إضافة إعادة الترتيب، وأصبح طبقها فوق البحث الهجين معيار 2026)، وكيف يعمل الاسترجاع على مرحلتين ("اجمع بسعة" بالبحث بالتضمين السريع من أجل الاستدعاء، ثم "صفِّ بذكاء" بالمُعيد للترتيب من أجل الدقة، ثم سلِّم الأعلى إلى نموذج اللغة الكبير)، ولماذا يكون المُعيد للترتيب أدق (المُرمِّز الثنائي bi-encoder يحوّل الاستعلام والمستند إلى متجهين على حدة وهو سريع لكنه تقريبي؛ والمُرمِّز المتقاطع cross-encoder يُدخلهما معًا ويُخرج درجة صلة 0–1، دقيق لكنه ثقيل — لذا تجمع بالمُرمِّز الثنائي السريع وتصفّي بالمُرمِّز المتقاطع الدقيق)، ثم النماذج والتنفيذ (نوع الـ API مثل Cohere Rerank وVoyage وJina؛ ومفتوح المصدر مثل BGE reranker وmixedbread وFlashRank؛ والتقييم بنموذج لغة كبير مثل RankLLM — فقط استرجع 50–100 وصفِّ إلى أعلى 5). المبدأ: اجمع بسعة، صفِّ بذكاء، واضبط الأعداد بتقييمات الذكاء الاصطناعي.

بعد أن تتمكّن من بناء تطبيقات الذكاء الاصطناعي، تأتي المرحلة التالية وهي تشغيلها بأمان. يمكن خداع نماذج اللغة الكبيرة بمدخلات خبيثة، أو تسريب بيانات سرية، أو الجزم بهراء بثقة؛ والآلية الأمنية التي تمنع ذلك هي حواجز الأمان للذكاء الاصطناعي، التي أصبحت جزءاً أساسياً من الإنتاج في 2026 مع وقوع حوادث وكلاء الذكاء الاصطناعي فعلياً. حواجز الأمان قواعد ومرشّحات تكبح المدخلات الخطيرة والمخرجات غير المرغوبة، فتفحص مدخلات المستخدم قبل أن تصل إلى النموذج والإجابة قبل أن تعود — طبقة أمان مستقلة منفصلة عن النموذج نفسه. التهديدات الرئيسية هي حقن الأوامر (الأكبر) وكسر القيود وتسريب البيانات (البيانات السرية، PII، موجّه النظام) والهلوسة أو المخرجات الضارة. تعمل الحماية على طبقتين: حواجز الإدخال (كشف الحقن وكسر القيود، كشف/إخفاء PII، تقييد المواضيع، التعقيم) وحواجز الإخراج (تصفية المحتوى الضار، منع التسريب، فحص الهلوسة، التحقق من التنسيق). حقن الأوامر — المصنّف الأكثر خطورة على OWASP LLM Top 10 — يأتي بصيغة مباشرة (يكتب المستخدم «تجاهل كل التعليمات السابقة») وغير مباشرة (أوامر مخفية في صفحة ويب أو مستند RAG)، والحقن غير المباشر لا يحجبه RAG وحده، لذا تحتاج المستندات المسترجعة إلى فحص خاص بها. يغطّي هذا الدليل للمبتدئين أيضاً الأدوات (LLM Guard، Guardrails AI، NeMo Guardrails، Llama Guard، وميزات الأمان السحابية من Azure وAWS وOpenAI) والمبادئ العملية للدفاع المتعمّق وأقل امتياز والموافقة البشرية والمراقبة المستمرة.

يعتمد RAG والبحث الدلالي والتوصيات جميعًا على بطل خفي: embedding (التضمين / المتجه). embedding هو معنى النص (أو الصورة) مُحوَّلًا إلى سلسلة من الأرقام — أي متجه. تصبح كلمة «كلب» قائمة من مئات إلى آلاف الأرقام تعمل بوصفها «إحداثيات للمعنى»، فتقع الكلمات المتقاربة في المعنى قرب بعضها (كلب وجرو متقاربان؛ كلب وسيارة متباعدان)، ويُقاس القرب بمقاييس مثل cosine similarity. مثال شهير: «ملك − رجل + امرأة ≈ ملكة». ولذلك يمكن للآلة أن تحكم على قرب المعنى حتى عندما لا تتطابق الحروف. يغطي هذا الدليل للمبتدئين ما هو embedding («خريطة للمعنى»)، ولماذا يقيس القرب المعنى (الأبعاد وcosine similarity)، وفيمَ يُستخدم (RAG والبحث الدلالي والتصنيف وإزالة التكرار والتوصيات والوسائط المتعددة)، وكيف تختار نموذج embedding (نوع API مثل OpenAI text-embedding-3 وCohere وGemini وVoyage؛ ونوع مفتوح المصدر مثل BGE-M3 وNomic وQwen3؛ إضافةً إلى Matryoshka التي يمكنها تقليص 3,072 بُعدًا إلى 1,024 مع الحفاظ على نحو 95% من الجودة بثلث التكلفة تقريبًا)، وقواعد بيانات المتجهات (Pinecone وWeaviate وQdrant وChroma وpgvector) مع بداية من ثلاث خطوات (اختر نموذجًا، حوّل الوثائق إلى متجهات وخزّنها، حوّل السؤال إلى متجه وابحث). التضمينات هي أساس تنفيذ RAG.

صقلت مطالباتك، وأضفت معرفة عبر RAG، وربما أجريت الضبط الدقيق — فكيف تتأكد أنه تحسّن فعلًا؟ هنا تتصدّر تقييمات الذكاء الاصطناعي المشهد، وبحلول 2026 صار التقييم جوهريًا إلى حدّ تسميته "بنية تحتية". تعني تقييمات الذكاء الاصطناعي قياس جودة مخرجات LLM بشكل منهجي (الدقة، الهلوسات، الالتزام بالصيغة، النبرة) على مقياس ثابت بدل الإحساس؛ وبدونها يبقى التحسين مجرد حدس. هناك طريقتان: التقييم القائم على الكود للعناصر القابلة للقياس آليًا (المطابقة التامة، الصيغة، الكلمات المطلوبة أو المحظورة — سريع ورخيص ومستقر)، وLLM-as-judge للعناصر الذاتية (استخدام نموذج LLM قوي بوصفه حَكَمًا لمنح درجات للمخرجات، عبر المقارنة الزوجية أو تسجيل مخرج واحد). والمبدأ: قِس بالكود كل ما يستطيع الكود قياسه. لـ LLM-as-judge تحيّزات الإطناب والموضع وتفضيل الذات؛ وحلولها استخدام عائلة نماذج مختلفة كمُقيّم، وتبديل الترتيب والتقييم مرتين، ووضع الإيجاز في معيار التصحيح، والمعايرة مقابل الحكم البشري. المقاييس الخشنة (pass/fail أو 1–3) تتفوّق على الدقيقة 1–10. وفي الممارسة، شغّل ثلاث طبقات — فحوصات كود فورية عند كل تغيير، واختبارات تراجع ليلية بـ LLM-as-judge، ومراقبة إنتاج مستمرة — مستخدمًا أدوات مثل DeepEval وPromptfoo وRAGAS لـ CI إضافةً إلى Braintrust وLangSmith وArize للمراقبة. ابدأ بجمع 10 مخرجات جيدة و10 سيئة وتقييمها.