التطوير بالذكاء الاصطناعي والبرمجة: بناء التطبيقات مع AI

أخطاء الشبكة في Claude Code («Can't reach the API server» و«Connection refused» وSSL certificate verification failed وfetch failed) تعني أن الطلب لم يصل إلى خادم Anthropic أصلًا، وليست مصادقة أو تحميلًا زائدًا أو حدّ معدل. وقبل الإصدار v2.1.227 كانت الأخطاء نفسها تظهر بصيغة «Unable to connect to API (ECONNREFUSED)». يشرح المقال معنى كل رسالة حالية، والخروج عند الإعداد الأولي برسالة «Unable to connect to Anthropic services»، وتحذير «Streaming response ended before any complete data was received» حين يغيّر بروكسي الاستجابة، وضبط HTTPS_PROXY، والوثوق بشهادة CA المؤسسية عبر NODE_EXTRA_CA_CERTS، والنطاقات الواجب السماح بها، وسير عمل التشخيص. لا تعطّل التحقق أبدًا عبر NODE_TLS_REJECT_UNAUTHORIZED=0.

حين يتوقّف Claude Code فجأة برسالة «API Error: 529 Overloaded» أو «500 Internal server error»، فهذان حدثان عابران من جانب الخادم — وليسا خطأً في طلبك أو إعداداتك، ولا نفادًا لاستخدامك. يشرح هذا المقال معنى 529 (ازدحام واجهة Anthropic API مؤقتًا) و500 (خطأ داخلي غير متوقّع)، وأنهما لا يستهلكان حصتك، وكيف يعيد Claude Code المحاولة تلقائيًا حتى 10 مرات بتراجع أسّي، والحلول من جانب المستخدم (الانتظار، والتبديل بـ/model، ومراجعة status.claude.com، و/feedback مع request_id)، والتمييز بينه وبين 429 وusage limit و400، وإرشادات المطورين، وكيفية تمييز الارتفاع العابر عن العطل المستمر.

رسالة «You've hit your session limit · resets 3:45pm» في Claude Code ليست خطأً، بل آلية عمل حدود استخدام الاشتراك. يسرد المرجع الرسمي أربع صيغ: session (نافذة الخمس ساعات المتدحرجة)، وweekly (النافذة الأسبوعية)، وOpus وSonnet (حدود لعائلة واحدة من النماذج)؛ ولأن حدّي الجلسة والأسبوع مشتركان بين كل النماذج، فتغيير النموذج لا يعيد الوصول. يشرح المقال معنى كل رسالة وكيف تغيّر النصّ منذ الصياغة القديمة «Claude usage limit reached»، وما الذي يستهلك الحصّة، وما الذي تفعله لحظة بلوغ السقف: تبديل النموذج عبر ‎/model مع حدّ Opus/Sonnet، أو انتظار الإعادة (تلقائياً منذ الإصدار v2.1.234)، أو أرصدة الاستخدام عبر ‎/usage-credits، أو التحوّل إلى API بنظام الدفع حسب الاستخدام، إضافةً إلى كيفية رؤية ما تبقّى عبر ‎/usage والرسائل المشابهة التي لا تعني بلوغ حدّك.

يظهر خطأ «Prompt is too long» في Claude Code عندما يتجاوز إجمالي المدخل، بما فيه السجل والملفات ونتائج الأدوات، حد السياق. يميز المقال بين تلخيص سجل طويل، وتقليل مدخل أول كبير، ومعالجة سبب فشل التلخيص مثل خطأ المصادقة. تُحمّل تعريفات MCP عند الطلب افتراضيًا، ويعتمد توفر سياق 1M على النموذج وطريقة الاتصال والخطة. ويشرح أيضًا عدّ الرموز وأسباب توقف التوليد عند استخدام API مباشرة.

عندما لا يتصل خادم MCP في Claude Code، افحص الحالة وطريقة الاتصال وتفاصيل Issue معًا. قد تشير failed إلى فشل تشغيل stdio أو فشل اتصال HTTP أو رفض ترويسة مصادقة ثابتة. يشرح المقال معنى Connection closed، ومتغيرات البيئة والمراجع غير المعرّفة، وإعدادات المشروع والموافقة، وتشغيل npx على Windows، وسجلات التصحيح، واختبار العملية المطلوبة بعد إعادة الاتصال. ويوضح أن صفر أدوات ليس بالضرورة خطأ، وأن التشغيل المستقل لا يضمن نجاح اتصال MCP.

حين تظهر كلمة «court» ووسوم <invoke>/<parameter> الخام في Claude Code دون أن تُنفَّذ الأداة، فهذه ليست مشكلة في بيئتك بل خلل من جانب النموذج يفسد رمز التحكّم في لحظة التوليد. يرفضه الهيكل بنمط fail-closed فلا خطر من تشغيل أمر خاطئ، لكن بقاء الكتلة المكسورة في السجلّ يجعل النموذج يقلّدها فيتسلسل الفشل. القاعدة: أخفِق مرتين ثم اهرب إلى جلسة جديدة (‎/clear). يشرح المقال الآلية والأسباب وإصلاحات المستخدم والمطوّر وتمييزها عن الأخطاء المشابهة والموقف الرسمي.

إعادة تدريب ذكاء اصطناعي ضخم من الصفر مكلفة للغاية، لكنك تريد تعديله ليناسبك فقط؛ يحقق LoRA (Low-Rank Adaptation) هذه الأمنية بتجميد النموذج الأصلي وتدريب جزء إضافي صغير (محوّل) فقط، مقلّصًا المعاملات القابلة للتدريب إلى أقل من 1% من النموذج الأصلي. يجعل LoRA عملية fine-tuning أرخص وأسرع بكثير، وهو شائع جدًا في توليد الصور مثل Stable Diffusion بوصفه ملفًا صغيرًا يضيف شخصية أو أسلوبًا. يشرح هذا المقال الفكرة عبر تشبيه الرقعة. LoRA رائد fine-tuning كفؤ المعاملات (PEFT): اترك الأوزان الأصلية الضخمة مجمّدة، وأدرج مصفوفة إضافية صغيرة في كل طبقة، ودرّب تلك فقط (W = W0 + BA)؛ ويقوم على فرضية أن الرتبة المنخفضة تكفي، وقد دعمتها تجارب الورقة الأصلية (مع تقارير بأنه يتأخر عن التدريب الكامل في الرياضيات والبرمجة). من فوائده: معاملات أقل من 1% من الأصل (نحو جزء من عشرة آلاف مع GPT-3 175B في الورقة الأصلية)، وذاكرة GPU أقل أثناء التدريب (من 1.2TB إلى 350GB في التجربة نفسها)، وتدريب أسرع وأرخص، ودون زمن استجابة إضافي بعد دمج المحوّل، ونسيان أقل للقدرات الأصلية. أكبر قوته هي المحوّلات القابلة للتبديل: أبقِ أساسًا مشتركًا واحدًا وبدّل ملفات LoRA الصغيرة لكل حالة استخدام فوريًا. يلتقي كثيرون بـ LoRA أولًا في توليد الصور حيث تُشارَك LoRA الخاصة بـ Stable Diffusion التي تعلّمت شخصية أو أسلوبًا. يدمج QLoRA الـ quantization، فيدرّب LoRA فوق أساس 4-bit، مما يتيح fine-tuning نموذج 65B — الذي يتطلب أكثر من 780GB عند تدريبه بالكامل بدقة 16-bit — على GPU واحدة بسعة 48GB، ونموذج 33B على GPU استهلاكية بسعة 24GB، بنتائج مماثلة للطرق بدقة 16-bit في مقارنات الورقة (والورقة نفسها تذكر أنها لم تتحقق من مضاهاة 33B و65B للتدريب الكامل). ومقابل fine-tuning الكامل، يكفي LoRA لمعظم العمل. الأرقام مأخوذة من ظروف تجارب الورقة الأصلية وغيرها وهي إرشادية.

نموذج ضخم بحجم 70B يعمل على حاسوب منزلي واحد بدل رفّ من بطاقات GPU في مركز بيانات (مع إسناد ما لا تتسع له بطاقة GPU استهلاكية إلى المعالج والذاكرة الرئيسية)، وما يجعل هذا ممكناً هو التكميم الذي يخفض الدقة العددية لأوزان النموذج لتقليص الحجم والذاكرة بشكل كبير. بينما ينقل تقطير النماذج المعرفة إلى نموذج أصغر منفصل، يجعل التكميم النموذج نفسه أخف. يشرح المقال الفكرة عبر تشبيه ضغط الصور: يستبدل التكميم الأوزان المخزَّنة بصيغة FP16/FP32 بأعداد صحيحة INT8 أو INT4، فيقلل البايتات لكل وزن (FP32=4، INT8=1، INT4=0.5)؛ ومثل ضغط صورة RAW إلى JPEG تضحي بقليل من الدقة مقابل تخفيف كبير، والمفاجأة هي قلة ما تتنازل عنه. على صعيد الذاكرة، يستخدم 4-bit نحو ربع FP16: ينخفض نموذج 70B من نحو 140GB إلى 35GB، ونموذج 8B بـ4-bit يصبح نحو 4.5-5GB، فيتسع في GPU متوسط بذاكرة 8GB للاستخدام المحلي (دمقرطة LLM). على صعيد الدقة، INT8 شبه خالٍ من الفقد وINT4 يتدهور بحسب ما ورد أقل من 4% في مهام المعرفة العامة، لكن الفقد أوضح في الرياضيات وتوليد الشيفرة والاستدلال الصعب (يظهر كارتفاع طفيف في perplexity)، فاختر عدد البتات للمهمة. الطرق الرئيسية: GPTQ (رائد 4-bit الدقيق)، وAWQ (يحمي أهم ~1% من الأوزان، وتفوّقه على GPTQ يختلف بحسب التقييم)، وGGUF (صيغة llama.cpp/Ollama، من Q2_K إلى Q8_0، مزج CPU+GPU، للتشغيل المحلي)، وQLoRA (أساس 4-bit مع LoRA للضبط الدقيق على GPU استهلاكي). يختلف عن التقطير (الانتقال إلى نموذج أصغر منفصل) والضبط الدقيق (إضافة معرفة المهمة)، وتُستخدم الثلاثة عادةً مجتمعة. للبدء، شغّل نموذج GGUF بـOllama بأمر واحد، واختر Q4/Q8 حسب VRAM، وتجنّب INT4 للشيفرة أو الحساب الدقيق. معظم النماذج الرئيسية تُوزَّع مُكمَّمة سلفاً فتنزّلها وتستخدمها فقط. احتفظ بالذكاء وأسقط الوزن فقط.

الذكاء الاصطناعي الضخم وعالي الأداء ذكي لكنه ثقيل ومكلف؛ ويحل تقطير النماذج (تقطير المعرفة) ذلك بنقل معرفة نموذج معلّم كبير إلى نموذج طالب صغير، مع الحفاظ على أداء قريب من المعلّم بحجم أصغر بكثير وسرعة أكبر. يشرح المقال ذلك بتشبيه المعلّم والطالب. المفتاح هو الـ soft labels: التدريب العادي يُعلّم فقط «الجواب قطة» (hard label)، بينما يمرّر التقطير توزيع الاحتمالات الكامل للمعلّم مثل «90% قطة، 8% كلب، 2% ثعلب»، حيث تحمل درجة التردد معلومات غنية؛ ويقوم معامل temperature بتليين الاحتمالات لكشف العلاقات الدقيقة (مثال واقعي: ميزة OpenAI في واجهتها البرمجية عام 2024 لتدريب نماذج صغيرة على مخرجات نماذج كبيرة). الفوائد: سريع ورخيص، أصغر بكثير مع أداء قريب من المعلّم (TinyBERT أصغر بـ7.5 مرة مع أكثر من 96.8%)، يعمل على الـ edge، وقوي في التخصص. منهجان: white-box (وصول كامل للأوزان والتمثيلات الداخلية، نقل أعمق؛ لنماذجك أو نماذج OSS) و black-box (المخرجات/استجابات API فقط؛ استخدام API شركة أخرى كمعلّم قد يخالف الشروط). ويختلف عن quantization (ضغط دقة أوزان النموذج نفسه) و fine-tuning (مواصلة تدريب نموذج موجود لمهمة) — فالتقطير ينقل المعرفة إلى نموذج صغير منفصل، والثلاثة قابلة للدمج. كان الواقع القانوني وشروط الخدمة قضية كبيرة في 2026: التقنية مشروعة، لكن لدى OpenAI و Anthropic و xAI بنود منع تقطير منافس تحظر استخدام المخرجات لبناء نماذج منافسة. نزاع OpenAI ضد DeepSeek يُظهر أن التقييم يعتمد على شروط API مَن تنطبق، وتحوّل Claude Fable 5/Mythos 5 الطلبات المُصنّفة كتقطير إلى نموذج Opus أقل قدرة. نصائح: استخدم نماذجك أو نماذج OSS مرخّصة كمعلّم، وتحقق من بنود منع التقطير قبل استخدام API تجاري. الأرقام مقتبسة من مواد عامة وتوجيهية.

قلنا في "كيف تبني نظامًا متعدد الوكلاء" إنه يجب تجهيز القياس لكل عملية تسليم قبل إضافة الوكلاء؛ والتقنية التي تشغّل هذا القياس في الإنتاج هي 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.