AI Foundry | The .NET Blog

Azure SDK أبريل 2026: AI Foundry 2.0 وما يجب أن يعرفه مطورو .NET

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

غالبًا ما يمر إصدارات SDK الشهرية دون اهتمام. لكن هذا الإصدار يحتوي على بعض الأشياء التي تستحق الانتباه — خاصة إذا كنت تبني باستخدام AI Foundry أو Cosmos DB في Java أو تقوم بتوفير البنية التحتية من كود .NET.

Azure.AI.Projects 2.0.0 — تغييرات جوهرية منطقية

حزمة NuGet Azure.AI.Projects تصل إلى الإصدار المستقر 2.0.0 مع بعض التغييرات المعمارية الهامة. إذا كنت تستخدم المعاينة بالفعل، إليك ما تغير:

تقسيم مساحات الأسماء: Evaluations انتقلت إلى Azure.AI.Projects.Evaluation، وعمليات الذاكرة انتقلت إلى Azure.AI.Projects.Memory. عبارات using الخاصة بك ستحتاج إلى تحديث.
أنواع معاد تسميتها: Insights ← ProjectInsights، Schedules ← ProjectSchedules، Evaluators ← ProjectEvaluators، Trigger ← ScheduleTrigger
اتفاقيات التسمية: خصائص Boolean تتبع الآن اتفاقية Is* بشكل متناسق

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

الخبر السار: إنه مستقر. يمكنك بالفعل الاعتماد على هذه API الآن.

Cosmos DB Java: إصلاح أمان حاسم (RCE)

هذا جدي. مكتبة Java Cosmos DB (azure-cosmos) الإصدار 4.79.0 تتضمن إصلاح أمان حاسم لثغرة تنفيذ تعليمات برمجية عن بعد (CWE-502).

المشكلة كانت إلغاء تسلسل Java في CosmosClientMetadataCachesSnapshot و AsyncCache و DocumentCollection. الإصلاح يستبدل إلغاء تسلسل Java بالتسلسل المستند إلى JSON، مما يلغي فئة كاملة من هجمات إلغاء التسلسل.

إذا كان لديك أي خدمات Java تستخدم Azure Cosmos DB، حدث إلى 4.79.0 فورًا. هذا ليس اختياريًا.

مكتبات Provisioning جديدة لـ .NET

موجة من مكتبات Provisioning المستقرة وصلت إلى 1.0.0 هذا الشهر — هذه هي المكتبات التي تتيح لك تعريف البنية التحتية لـ Azure في كود C# بدلاً من قوالب ARM أو Bicep:

العديد غيرها في beta.1، تغطي API Management و Batch و Compute و Monitor و MySQL و Security Center. إذا كنت تقوم بالبنية التحتية ككود من .NET — خاصة مع عمليات نشر Aspire — هذه المكتبات هي نقطة الدخول الخاصة بك.

Azure AI Agents Java: 2.0.0 GA

مكتبة Java Azure AI Agents تصل أيضًا إلى التوفر العام هذا الشهر. التغييرات الجوهرية الرئيسية:

عدة أنواع enum تم تحويلها إلى فئات قائمة على ExpandableStringEnum (أكثر مرونة للقيم الجديدة)
فئات نموذج *Param أعيدت تسميتها إلى *Parameter
MCPToolConnectorId ← McpToolConnectorId (حروف متسقة)
تحميل زائد جديد مناسب لـ beginUpdateMemories

خلاصة

العنوان الرئيسي لمطوري .NET هذا الشهر هو وصول Azure.AI.Projects 2.0.0 إلى الاستقرار — إذا كنت تبني باستخدام AI Foundry، الآن هو الوقت لتثبيت الإصدار المستقر وتحديث الاستيرادات الخاصة بك. لمتاجر Java التي تستخدم Cosmos DB، التحديث الأمني عاجل.

ملاحظات الإصدار الكاملة في aka.ms/azsdk/releases. المقال الأصلي: Azure SDK Release (April 2026).

68 دقيقة يومياً لإعادة شرح الكود لكوبايلوت؟ هناك حل لذلك

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المنشور تلقائيًا. للنسخة الأصلية، انقر هنا.

أتعرف تلك اللحظة حين تصل جلسة Copilot الخاصة بك إلى /compact وينسى الوكيل تماماً ما كنت تفعله؟ تمضي الدقائق الخمس التالية وأنت تعيد شرح بنية الملفات، والاختبار الفاشل، والطرق الثلاث التي جرّبتها بالفعل. ثم يحدث الأمر مرة أخرى. ومرة أخرى.

قاس Desi Villanueva ذلك: 68 دقيقة يومياً — فقط في إعادة التوجيه. ليس في كتابة الكود. وليس في مراجعة PRs. فقط في إلحاق الذكاء الاصطناعي بما كان يعرفه بالفعل.

اتضح أن هناك سبباً ملموساً لهذا، وحلاً ملموساً أيضاً.

كذبة نافذة السياق

يأتي وكيلك برقم كبير على العلبة. 200 ألف رمز. يبدو هائلاً. عملياً، هو حد أعلى وليس ضماناً.

إليك الحساب الحقيقي:

200 ألف رمز من السياق الإجمالي
ناقص نحو 65 ألفاً لأدوات MCP المحمّلة عند البدء (~33%)
ناقص نحو 10 آلاف لملفات التعليمات مثل AGENTS.md أو copilot-instructions.md

هذا يترك لك تقريباً 125 ألفاً قبل أن تكتب كلمة واحدة. والأسوأ من ذلك — نماذج اللغة الكبيرة لا تتدهور بسلاسة مع امتلاء السياق. إنها تصطدم بجدار عند نحو 60% من السعة. يبدأ النموذج بفقدان أشياء ذُكرت قبل 30 دورة، ويخالف ردوداً سابقة، ويختلق أسماء ملفات كان قد ذكرها بثقة قبل 10 دقائق. وتسمّي الصناعة هذا مشكلة “lost in the middle”.

الحد الفعلي: 45 ألف رمز قبل أن تتدهور الجودة. وهذا ربما يعني 20-30 دورة فقط من الحوار النشط قبل أن يبدأ الوكيل بالابتعاد عن المسار. وهذا هو سبب وصولك إلى /compact كل 45 دقيقة — ليس لأنك ملأت 200 ألف رمز، بل لأن النموذج أصبح متدهوراً بالفعل عند 120 ألفاً.

ضريبة الدمج

كل /compact يكلفك حالة التدفق. أنت في جلسة تصحيح عميقة. السياق المشترك بُني خلال 30 دقيقة. الوكيل يعرف بنية الملفات، والاختبار الفاشل، والفرضية. ثم تأتي التحذيرات.

تجاهلها → يصبح الوكيل أضعف تدريجياً، ويبدأ باختلاق الحالة القديمة
نفّذ /compact → يحصل الوكيل على ملخص من فقرتين لتحقيق استمر 30 دقيقة

في كلتا الحالتين تخسر. في كلتا الحالتين أنت تعيد سرد مشروعك له كما لو كان موظفاً جديداً في يومه الأول.

الجزء القاسي؟ الذاكرة موجودة بالفعل. يكتب Copilot CLI كل جلسة إلى قاعدة بيانات SQLite محلية في ~/.copilot/session-store.db — كل ملف تم لمسه، كل دورة، كل نقطة تحقق. كل شيء موجود على القرص. الوكيل فقط لا يستطيع قراءته.

auto-memory: طبقة استرجاع، لا نظام ذاكرة

هذه هي الفكرة الأساسية وراء auto-memory: لا تبنِ نظام ذاكرة جديداً — ابنِ طبقة استعلام للقراءة فقط فوق النظام الموجود بالفعل.

pip install auto-memory

حوالي 1,900 سطر من Python. بلا تبعيات. يُثبّت في 30 ثانية.

بدلاً من إغراق السياق بنتائج grep، تمنح الوكيل وصولاً جراحياً إلى ما يهم فعلاً:

العملية	الرموز	ما الذي تحصل عليه
`grep -r "auth" src/`	~5,000–10,000	500 نتيجة، معظمها غير مهم
`find . -name "*.py"`	~2,000	كل ملفات Python، من دون سياق
إعادة توجيه الوكيل	~2,000	أنت تشرح ما كان ينبغي أن يعرفه
`auto-memory files --json --limit 10`	~50	الملفات العشرة التي عملت عليها أمس

هذه زيادة بمقدار 200 مرة. يتجاوز الوكيل الحفر الأثري ويذهب مباشرة إلى ما يهم.

النهج الموصى به: عندما تقترب من استخدام 50-70% من السياق، شغّل /clear ثم اكتب: “راجع الجلسات الأخيرة التي ناقشنا فيها الموضوع X”. بدلاً من حرق 12 ألف رمز في عمليات بحث عمياء، يستخرج auto-memory السياق الملائم في 50 رمزاً.

لماذا يهم هذا لمطوري .NET

إذا كنت تستخدم GitHub Copilot CLI في أعمال .NET — إعداد الخدمات، تصحيح استعلامات EF Core، التكرار على مكونات Blazor — فإن مشكلة تآكل السياق تضربك بالقدر نفسه. الحلول المعقدة ذات المشاريع المتعددة، والمكتبات المشتركة، وسلاسل الاستدعاء العميقة هي بالضبط نوع قواعد الشيفرة التي يفقد الوكيل تتبّعها أسرع من غيرها.

دليل التثبيت يشرح كيفية توجيه Copilot CLI إليه. إنها إعدادات لمرة واحدة.

بصراحة؟ استرجاع 68 دقيقة يومياً ليس مجرد تحسين بسيط لجودة الحياة. هذا يقارب 6 ساعات في الأسبوع.

خلاصة

تآكل السياق قيد معماري حقيقي، وليس خطأً سيُصلح لاحقاً. يتجاوز auto-memory هذا القيد بمنح وكيلك آلية استرجاع رخيصة ودقيقة بدلاً من إعادة استكشاف مكلفة ومضطربة. إذا كنت تقوم بتطوير جاد بمساعدة الذكاء الاصطناعي مع GitHub Copilot CLI، فهذه الإضافة تستحق 30 ثانية من التثبيت.

جرّبه: auto-memory على GitHub. المنشور الأصلي لـ Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.