AI Apps | The .NET Blog

SQL Server 2025 كقاعدة بيانات جاهزة للوكلاء: الأمان والنسخ الاحتياطي وMCP في محرك واحد

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

لقد تابعت سلسلة Polyglot Tax من Aditya Badramraju باهتمام كبير. الأجزاء 1-3 قدّمت حجة مقنعة لصالح SQL Server 2025 كقاعدة بيانات متعددة النماذج بحق — JSON والرسوم البيانية والمتجهات والبيانات العلائقية كلها في محرك واحد مع مخطط استعلام موحّد. الجزء الرابع يختم السلسلة بالجزء الذي يحدد فعلاً ما إذا كنت ستثق بهذه البنية في الإنتاج.

الخلاصة: قصة الإنتاج قوية.

نموذج أمان واحد لكل نماذج البيانات

هذه هي المشكلة مع البنى متعددة اللغات: عندما يسألك المدقق “أثبت أن Tenant A لا يستطيع رؤية بيانات Tenant B”، عليك الإجابة عن هذا السؤال لكل قاعدة بيانات على حدة. خمس قواعد بيانات، خمس نماذج أمان، خمس براهين.

مع SQL Server 2025، يمكنك تعريف سياسة Row-Level Security واحدة تغطي كل نماذج البيانات:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

من تلك اللحظة، أي استعلام — joins علائقية، استعلامات مسارات JSON، اجتيازات الرسوم البيانية، بحث تشابه المتجهات — يُفلتر تلقائيًا حسب tenant. المحرك يحقن الشرط في خطة التنفيذ قبل أن تغادر أي بيانات التخزين. الشيفرة التي تستدعيه لا تحتاج إلى WHERE TenantID = @id في كل مكان. تختبر السياسة مرة واحدة.

تتراصف الطبقات كذلك: Dynamic Data Masking للأعمدة التي لا ينبغي أن ترى قيمها الكاملة بعض الأدوار، وAlways Encrypted للتشفير من طرف إلى طرف (حتى مسؤولو قواعد البيانات لا يستطيعون قراءتها)، والإجراءات المخزنة كحدّ للامتيازات بحيث لا تستدعي الوكلاء إلا ما كشفته لهم صراحة.

هذا هو الجزء من البنية الذي يهم أكثر في SaaS الخاضع للامتثال. سياسة واحدة، وبُرهان واحد.

نسخ احتياطي موحّد = استعادة ذرّية

أمر واحد، كل نماذج البيانات، ونقطة زمنية متسقة:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

في stack متعدد اللغات، تعني استعادة نقطة زمنية عبر خمس قواعد بيانات تنسيق خمس عمليات استعادة والأمل في أن تتطابق الطوابع الزمنية في حدود ثانية أو ثانيتين. بالنسبة للبيانات المالية، هذا التفاوت غير مقبول. مع قاعدة بيانات واحدة، وسجل معاملات واحد، واستعادة واحدة — الاسترداد ذرّي بحكم التعريف.

جداول Ledger لمسارات تدقيق لا يمكن العبث بها

في القطاعات المنظمة، أنت تحتاج إلى أكثر من “لدينا سجلات”. أنت تحتاج إلى دليل مشفّر على أن تلك السجلات لم تُعدّل:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

كل عملية insert وupdate وdelete تُhashed تشفيريًا داخل بنية شبيهة بالبلوكشين. يمكنك أن تثبت للمدقق — رياضيًا — أن صفًا لم يتم العبث به منذ كتابته. في stack متعدد اللغات، هذه القدرة لا تتوفر بشكل موحّد عبر قواعد البيانات كلها.

تكامل MCP: وكلاء بلا middleware مكتوب يدويًا

السلسلة كانت تتجه إلى هذا: SQL Server 2025 يدعم SQL MCP Server مباشرة، وهذا يعني أن وكلاءك يمكنهم استدعاء قاعدة البيانات عبر نداءات أدوات طبيعية دون أن تكتب middleware لكل عملية.

ادمج ذلك مع الإجراءات المخزنة كحد للامتيازات وRow-Level Security المطبقة على مستوى المحرك، وستحصل على نموذج حيث:

يستدعي الوكيل أداة، مثل “احصل على سياق العميل للحساب 12345”
يترجم MCP ذلك إلى الإجراء المخزن الذي حددته
يفرض محرك SQL عزل tenant وإخفاء الأعمدة تلقائيًا
يحصل الوكيل على البيانات المسموح له برؤيتها فقط

لا توجد طبقة middleware. لا يوجد خطر حقن استعلامات عشوائية. المحرك هو من يتولى التفويض، وليس الوكيل.

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

إذا كنت تبني خدمات .NET وSQL Server هو مخزن البيانات الأساسي لديك، فهذه الرسالة من السلسلة هي: لست بحاجة إلى إضافة Redis للتخزين المؤقت، أو قاعدة بيانات رسومية للعلاقات، أو مخزن متجهات للتمثيلات — SQL Server 2025 يتولى كل ذلك، مع اتساق تشغيلي أفضل من stack متعدد اللغات وأمان موحّد يمكن تدقيقه فعلاً.

تكامل MCP يعني أن وكلاء Semantic Kernel أو سير عمل Microsoft Agent Framework يمكنهم التفاعل مع طبقة البيانات لديك عبر SQL MCP Server نفسه، وبنفس ضمانات الأمان التي ستفرضها على الاستعلامات البشرية.

الختام

سلسلة Polyglot Tax تستحق القراءة من البداية إلى النهاية. الأجزاء 1-3 تثبت قصة مخطط الاستعلام. الجزء 4 يثبت قصة الإنتاج. بالنسبة لمطوري .NET الذين يبنون تطبيقات agent-first أو AI-augmented على Azure SQL، تستحق هذه البنية اعتبارًا جديًا.

المقال الأصلي بقلم Aditya Badramraju: The Polyglot Tax – Part 4.

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.