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

ليس تحديث GPT-5.6 مجرد رفع للأداء، بل إعادة هيكلة من نموذج رئيسي واحد إلى منظومة من 3 نماذج: Luna ($0.20/$1.20) للمعالجة الضخمة، وTerra ($2/$12) الذي يقدّم جودة بمستوى GPT-5.5 بـ40% من سعر 5.5 — كان نصف السعر عند الإطلاق ثم صار 40% بعد خفض الأسعار في 30 يوليو 2026 — وSol ($5/$30) الذي يرفع الأداء بنفس السعر مع SWE-Bench Pro من 58.6 إلى 64.6% (أرقام OpenAI). نرتّب هنا ما الذي تغيّر من 5.5 إلى 5.6، وأثر ذلك على الفاتورة، وإلى أي نموذج ينبغي أن تنتقل حسب استخدامك.

مقارنة غير متماثلة بين GPT-5.6 Sol المتعدّد الاستخدامات بنصف السعر ($5/$30) و Claude Fable 5 الأعلى مستوى آنذاك لكن بضِعف السعر ($10/$50). يتفوّق Fable 5 في البرمجة على مستوى الإنتاج الفعلي (SWE-Bench Pro 80.0% مقابل 64.6% في جدول OpenAI) والاستقلالية طويلة الأمد، بينما يتصدّر Sol تشغيل الطرفية (TerminalBench 88.8%) والقدرة الإجمالية للوكلاء مع كفاءة رموز أعلى بـ 54%. نوضّح كيف تختار بين القطبين حسب حالة الاستخدام والتكلفة لكل مهمة مكتملة، مع تنبيه إلى أن OpenAI شكّكت في اختبار SWE-bench Pro نفسه.

مقارنة معمّقة بين قطبي البرمجة بالذكاء الاصطناعي في يوليو 2026: Claude Opus 4.8 (28 مايو) والطراز الأعلى Sol من GPT-5.6 (9 يوليو). مجالات تفوّقهما متعاكسة تقريبًا: يتصدّر Sol في التحكم بالطرفية والقدرة الوكيلة الشاملة (TerminalBench 2.1 88.8% مقابل Opus 78.9%، Agents' Last Exam 53.6، Coding Agent Index 80)، بينما يتصدّر Opus 4.8 في البرمجة على مستوى الإنتاج (SWE-bench Pro 69.2% مقابل Sol 64.6%) ويُبرز الصدق (يمرّر عيوب شيفرته دون إشارة بنحو ربع معدل الجيل السابق، ولا يُغفل الإبلاغ عن الإخفاقات المهمة إلا في 3.7% من الحالات). أما GPQA Diamond وFrontierMath، اللذان قيل إنهما غير معلنين، فموجودان في جدول التقييم لدى OpenAI ويتقدّم فيهما Sol (كما في GraphWalks 1M)، وفي SWE-bench Pro يتقدّم Opus حتى في جدول OpenAI نفسها، ففي صميم البرمجة يتفوّق Opus. نتناول جدول المواصفات وتفاصيل الاختبارات ومشكلة الاختبارات غير المعلنة والتكلفة الفعلية ($25 مقابل $30 وكفاءة رموز +54%) وخريطة القوة والضعف والاختيار حسب الاستخدام واستراتيجية المزوّدين المزدوجين.

أطلقت OpenAI النموذج GPT-5.6 للتوفر العام في 9 يوليو 2026، مستبدلةً بنية «العادي + Pro» القديمة بتشكيلة من ثلاثة نماذج: Luna (سريع ومنخفض التكلفة، $0.20/$1.20)، وTerra (متوازن، $2/$12، بمستوى GPT-5.5 وبـ40% من سعر وحدة Sol)، وSol (الرائد، $5/$30)، وذلك بحسب أسعار 30 يوليو 2026. يتصدّر Sol المرتبة الأولى في Agents' Last Exam (53.6) وفي Coding Agent Index (80)، وتتفوّق نسبته 88.8% في TerminalBench 2.1 على Claude Fable 5 (83.1%)——غير أن Claude Fable 5 يتصدّر بوضوح في SWE-Bench Pro على مستوى الإنتاج بنسبة 80.0% مقابل 64.6% لـ Sol. يغطّي هذا المقال الفروق بين النماذج الثلاثة، والأسعار، والاختبارات المرجعية، والميزات الجديدة (Programmatic Tool Calling، وChatGPT Work، والنموذج الصوتي ثنائي الاتجاه GPT-Live)، والتوفر حسب خطة ChatGPT، ومقارنة مع Claude (Fable 5 / Opus 4.8)، وكيفية الاختيار حسب الاستخدام——كل ذلك مستندًا إلى الإعلان الرسمي من OpenAI والاختبارات المستقلة.

بنيتَ على 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 قبل الإطلاق. للأنظمة متعددة الوكلاء المراقبة ضرورية لأن الإخفاقات تختبئ في سلاسل متعددة الخطوات.

الجزء العملي التالي لمقال «ما هو نظام الوكلاء المتعددين؟». القاعدة الأساسية: ابنِ بوكيل واحد أولاً ولا تُضِف وكلاء إلا بأقل قدر بعد الاصطدام بحدّ فعلي (وجدت دراسة من Google Research أن جميع تكوينات الوكلاء المتعددين كانت أسوأ بنسبة 39–70% في مهمة تسلسلية صارمة، وتذكر Anthropic أن أنظمة الوكلاء المتعددين تستهلك نحو 15 ضعف رموز المحادثة). الشكل الأساسي هو نمط supervisor: الوكلاء الفرعيون في Claude Agent SDK، وagents as tools في OpenAI Agents SDK. إلى جانب الخطوات الخمس (التقسيم، تعريف الـ workers، تصميم الـ supervisor، التسليم، القياس)، يقدّم المقال شيفرة مصغّرة للحزمتين وفق وثائقهما الرسمية (supervisor واحد مع باحث ومراجع)، وطريقة تقييد أدوات كل دور، وحدوداً في ثلاث طبقات (maxTurns وmax_turns والإنفاق)، ومتى تختار التسليم، والتقسيم الجيد والسيئ للأدوار، وإخفاقات واجهتها Anthropic فعلاً (50 وكيلاً فرعياً لسؤال بسيط، بحث مكرر) مع حلولها.

بعد أن أصبح وكلاء الذكاء الاصطناعي أمرًا شائعًا، صار التحدي التالي هو كيفية جعل الوكلاء يتعاونون فيما بينهم. إذا كان 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.