Foundry Toolboxes: نقطة نهاية واحدة لجميع أدوات وكلاء الذكاء الاصطناعي

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

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

ثمة مشكلة تبدو عادية حتى تواجهها بنفسك: تبني المؤسسة وكلاء ذكاء اصطناعي متعددة، كل منها يحتاج أدوات، وكل فريق يُهيؤها من الصفر. نفس تكامل البحث على الويب، نفس إعداد Azure AI Search، نفس اتصال خادم GitHub MCP — لكن في مستودع مختلف، من فريق مختلف، ببيانات اعتماد مختلفة، ودون أي حوكمة مشتركة.

أطلقت Microsoft Foundry للتو Toolboxes في معاينة عامة، وهو إجابة مباشرة على هذه المشكلة.

ما هو Toolbox؟

Toolbox هو حزمة أدوات مُسمّاة وقابلة لإعادة الاستخدام، تُعرَّف مرة واحدة في Foundry وتُعرض عبر نقطة نهاية واحدة متوافقة مع MCP. أي بيئة تشغيل وكيل تتحدث MCP يمكنها استهلاكه — دون قيد على Foundry Agents.

الوعد بسيط: build once, consume anywhere. عرِّف الأدوات، هيِّئ المصادقة مركزيًا (OAuth passthrough، الهوية المُدارة في Entra)، انشر نقطة النهاية. كل وكيل يحتاج تلك الأدوات يتصل بنقطة النهاية ويحصل عليها جميعًا.

الأركان الأربعة (اثنان متاحان اليوم)

الركن	الحالة	ما يفعله
Discover	قريبًا	إيجاد الأدوات المعتمدة دون بحث يدوي
Build	متاح	تجميع الأدوات في حزمة قابلة لإعادة الاستخدام
Consume	متاح	نقطة نهاية MCP واحدة تعرض جميع الأدوات
Govern	قريبًا	مصادقة مركزية + إمكانية مراقبة جميع استدعاءات الأدوات

مثال عملي

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="البحث في الوثائق والرد على issues في GitHub",
 tools=[
 {"type": "web_search", "description": "البحث في الوثائق العامة"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

بعد النشر، تُوفر Foundry نقطة نهاية موحدة. اتصال واحد، جميع الأدوات.

لا قيد على Foundry Agents

تُنشأ Toolboxes وتُدار في Foundry، لكن سطح الاستهلاك هو بروتوكول MCP المفتوح. يمكن استخدامها من وكلاء مخصصة (Microsoft Agent Framework، LangGraph)، وGitHub Copilot وبيئات IDE الأخرى المتوافقة مع MCP.

لماذا يهم هذا الآن

موجة الوكلاء المتعددة تصل إلى الإنتاج. كل وكيل جديد هو سطح جديد للإعداد المكرر والبيانات الاعتمادية القديمة والسلوك غير المتسق. أساس Build + Consume كافٍ للبدء في المركزة. حين يصل ركن Govern، ستتوفر طبقة أدوات قابلة للمراقبة الكاملة ومُتحكَّم بها مركزيًا لكامل أسطول الوكلاء.

خلاصة

لا يزال مبكرًا — معاينة عامة، Python SDK أولًا، مع Discover وGovern في الطريق. لكن النموذج راسخ والتصميم الأصيل لـ MCP يعني أنه يعمل مع الأدوات التي تُبنى بالفعل. جميع التفاصيل في الإعلان الرسمي.

أين تستضيف وكلاء الذكاء الاصطناعي على Azure؟ دليل عملي للقرار

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

إن كنت تبني وكلاء ذكاء اصطناعي بـ .NET في الوقت الراهن، ربما لاحظت شيئاً: ثمة الكثير من طرق استضافتها على Azure. Container Apps، وAKS، وFunctions، وApp Service، وFoundry Agents، وFoundry Hosted Agents — وكلها تبدو معقولة حتى تحتاج فعلاً إلى اختيار واحدة. نشرت Microsoft للتو دليلاً شاملاً لاستضافة وكلاء Azure AI يوضّح هذا الأمر، وأريد تحليله من منظور مطوّر .NET عملي.

الخيارات الستة في لمحة

إليك كيف أُلخّص المشهد:

الخيار	الأنسب لـ	أنت تُدير
Container Apps	التحكم الكامل في الحاويات دون تعقيد K8s	إمكانية المراقبة، الحالة، دورة الحياة
AKS	الامتثال للمؤسسات، متعدد المجموعات، شبكات مخصصة	كل شيء (هذا هو الهدف)
Azure Functions	المهام الوكيلة قصيرة الأمد المدفوعة بالأحداث	شبه لا شيء — خادم حقيقي بلا خوادم
App Service	وكلاء HTTP البسيطة، حركة المرور المتوقعة	النشر، إعداد التوسّع
Foundry Agents	وكلاء بدون كود عبر البوابة/SDK	شبه لا شيء
Foundry Hosted Agents	وكلاء بأُطر مخصصة مع بنية تحتية مُدارة	كود وكيلك فقط

الخيارات الأربعة الأولى هي حوسبة للأغراض العامة — يمكنك تشغيل وكلاء عليها، لكنها لم تُصمَّم لذلك. الخياران الأخيران وكيل-أصيل: يفهمان المحادثات ومكالمات الأدوات ودورات حياة الوكلاء كمفاهيم أولى.

Foundry Hosted Agents — النقطة الأمثل لمطوّري وكلاء .NET

ها هو ما لفت انتباهي. تقع Foundry Hosted Agents في المنتصف تماماً: تحصل على مرونة تشغيل كودك الخاص (Semantic Kernel، Agent Framework، LangGraph — ما تشاء) لكن المنصة تتولى إدارة البنية التحتية وإمكانية المراقبة وإدارة المحادثات.

القطعة الرئيسية هي Hosting Adapter — طبقة تجريد رفيعة تربط إطار وكيلك بمنصة Foundry. بالنسبة لـ Microsoft Agent Framework يبدو هكذا:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

هذه هي قصة استضافتك بالكامل. يتولى المحوّل ترجمة البروتوكول، والبثّ عبر server-sent events، وسجل المحادثات، وتتبع OpenTelemetry — كل ذلك تلقائياً. لا middleware مخصص، لا سباكة يدوية.

النشر بسيط بشكل حقيقي

نشرت وكلاء إلى Container Apps من قبل وتعمل، لكنك تنتهي بكتابة الكثير من كود الربط لإدارة الحالة وإمكانية المراقبة. مع Hosted Agents وـazd، يكون النشر:

# تثبيت إضافة وكلاء AI
azd ext install azure.ai.agents

# التهيئة من قالب
azd ai agent init

# بناء، رفع، نشر — انتهى
azd up

ذلك الأمر الواحد azd up يبني حاويتك، ويرفعها إلى ACR، ويُوفّر مشروع Foundry، ويُنشئ نقاط نهاية النماذج، ويُشغّل وكيلك. خمس خطوات في أمر واحد.

إدارة المحادثات المدمجة

هذا الجانب هو الذي يُوفّر أكثر الوقت في الإنتاج. بدلاً من بناء مخزن حالة محادثة خاص بك، تتولى Hosted Agents ذلك بشكل أصيل:

# إنشاء محادثة دائمة
conversation = openai_client.conversations.create()

# الدور الأول
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# الدور الثاني — السياق محفوظ
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

لا Redis. لا مخزن جلسات Cosmos DB. لا middleware مخصص لتسلسل الرسائل. المنصة تتولى الأمر ببساطة.

إطاري للقرار

بعد مراجعة الخيارات الستة جميعها، إليك نموذجي الذهني السريع:

هل تحتاج إلى بنية تحتية صفرية؟ ← Foundry Agents (بوابة/SDK، بلا حاويات)
هل لديك كود وكيل مخصص لكنك تريد استضافة مُدارة؟ ← Foundry Hosted Agents
هل تحتاج مهاماً وكيلة مدفوعة بالأحداث قصيرة الأمد؟ ← Azure Functions
هل تحتاج أقصى تحكم في الحاويات دون K8s؟ ← Container Apps
هل تحتاج امتثالاً صارماً ومتعدد المجموعات؟ ← AKS
هل لديك وكيل HTTP بسيط بحركة مرور متوقعة؟ ← App Service

لمعظم مطوّري .NET الذين يبنون بـ Semantic Kernel أو Microsoft Agent Framework، من المرجح أن تكون Hosted Agents نقطة البداية الصحيحة. تحصل على التوسّع إلى الصفر، وOpenTelemetry المدمج، وإدارة المحادثات، ومرونة الإطار — دون إدارة Kubernetes أو تمديد سلسلة إمكانية مراقبة خاصة بك.

خلاصة القول

مشهد استضافة الوكلاء على Azure ينضج بسرعة. إن كنت تبدأ مشروع وكيل ذكاء اصطناعي جديداً اليوم، أُوصي بجدية بالنظر في Foundry Hosted Agents قبل الوصول إلى Container Apps أو AKS من عادة. البنية التحتية المُدارة توفّر وقتاً حقيقياً، ونمط Hosting Adapter يتيح لك الحفاظ على اختيار إطارك.

اطّلع على الدليل الكامل من Microsoft ومستودع Foundry Samples للحصول على أمثلة عملية.

Microsoft-Foundry | The .NET Blog