Agent Framework | The .NET Blog

CodeAct في Agent Framework: كيف تخفض زمن استجابة وكيلك إلى النصف

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

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

في كل مشروع وكلاء، تأتي لحظة تنظر فيها إلى التتبع وتفكر: “لماذا يستغرق هذا كل هذا الوقت؟” النموذج جيد. الأدوات تعمل. لكن هناك سبع جولات ذهاباً وإياباً للحصول على نتيجة يمكن حسابها في مرة واحدة.

هذا بالضبط ما يحله CodeAct — وفريق Agent Framework أصدر للتو دعماً تجريبياً عبر حزمة agent-framework-hyperlight الجديدة.

ما هو CodeAct؟

نمط CodeAct بسيط بأناقة: بدلاً من إعطاء النموذج قائمة من الأدوات لاستدعائها واحدة تلو الأخرى، تعطيه أداة execute_code واحدة وتتيح له التعبير عن الخطة بأكملها كبرنامج Python قصير.

الأسلوب	الوقت	الرموز
التقليدي	27.81 ث	6,890
CodeAct	13.23 ث	2,489
التحسن	52.4%	63.9%

الأمان: الأجهزة الافتراضية الصغيرة Hyperlight

تستخدم حزمة agent-framework-hyperlight الأجهزة الافتراضية الصغيرة Hyperlight. كل استدعاء execute_code يحصل على جهاز افتراضي صغير خاص به تم إنشاؤه حديثاً. بدء التشغيل يُقاس بالمللي ثانية. العزل عملياً مجاني.

تستمر أدواتك في التشغيل على المضيف. الكود التوصيلي الذي يولده النموذج يعمل في بيئة مُعزلة. هذا هو التقسيم الصحيح.

الإعداد الأدنى

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

متى تستخدم CodeAct (ومتى لا تستخدمه)

استخدم CodeAct عندما:

تتضمن المهمة سلسلة من استدعاءات الأدوات الصغيرة (بحث، دمج، حسابات)
زمن الاستجابة وتكلفة الرموز مهمان
تريد عزلاً قوياً للكود الذي يولده النموذج

ابقَ مع استدعاء الأدوات التقليدي عندما:

يُجري الوكيل استدعاءً أو اثنين فقط في كل دور
لكل استدعاء آثار جانبية تستوجب موافقة فردية

جرّبه الآن

pip install agent-framework-hyperlight --pre

اقرأ المنشور الكامل في مدونة Agent Framework.

GPT-5.5 هنا ويأتي إلى Azure Foundry — ما يحتاج مطورو .NET معرفته

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

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

أعلنت Microsoft للتو أن GPT-5.5 متاح عمومًا في Microsoft Foundry. إذا كنت تبني وكلاء على Azure، فهذا هو التحديث الذي كنت تنتظره.

تطور GPT-5

GPT-5: وحّد التفكير والسرعة في نظام واحد
GPT-5.4: تفكير متعدد الخطوات أقوى، قدرات وكالية مبكرة للمؤسسات
GPT-5.5: تفكير أعمق في السياق الطويل، تنفيذ وكالي أكثر موثوقية، كفاءة أفضل في الرموز

ما الذي تغيّر فعلًا

برمجة وكالية محسّنة: يحتفظ GPT-5.5 بالسياق عبر قواعد الشفرة الكبيرة، ويشخّص الإخفاقات المعمارية، ويتوقع متطلبات الاختبار. يستدل النموذج على ما يؤثر فيه أيضًا الإصلاح قبل التصرف.

كفاءة الرموز: مخرجات أعلى جودة مع رموز أقل ومحاولات أقل. انخفاض مباشر في التكلفة والكمون في الإنتاج.

التسعير

النموذج	المدخلات ($/M رمز)	المدخلات المخزنة	المخرجات ($/M رمز)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

لماذا يهم Foundry

يتيح لك Foundry Agent Service تعريف الوكلاء في YAML أو توصيلهم بـ Microsoft Agent Framework أو GitHub Copilot SDK أو LangGraph أو OpenAI Agents SDK — وتشغيلهم كوكلاء مستضافين معزولين مع نظام ملفات دائم وهوية Microsoft Entra مستقلة وتسعير بمقياس صفري.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "أنت مساعد مفيد.", name: "وكيلي");

اطلع على الإعلان الكامل لجميع التفاصيل.

أين يتذكر وكيلك الأشياء؟ دليل عملي لتخزين سجل المحادثات

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

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

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

يحدد هذا القرار ما إذا كان المستخدمون قادرين على تفرّع المحادثات، والتراجع عن الردود، واستئناف الجلسات بعد إعادة التشغيل، وما إذا كانت بياناتك تغادر بنيتك التحتية أم لا. نشر فريق Agent Framework تحليلاً متعمقًا.

نمطان أساسيان

مُدار من الخدمة: تخزّن خدمة الذكاء الاصطناعي حالة المحادثة. يحتفظ تطبيقك بمرجع، وتُضمّن الخدمة تلقائيًا السجل ذا الصلة في كل طلب.

مُدار من العميل: يحتفظ تطبيقك بالسجل الكامل ويرسل الرسائل ذات الصلة مع كل طلب. الخدمة عديمة الحالة. أنت تتحكم في كل شيء.

كيف يُجرّد Agent Framework هذا

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("اسمي أليس.", session);
var second = await agent.RunAsync("ما اسمي؟", session);

مرجع سريع للموفرين

الموفر	التخزين	النموذج	الضغط
OpenAI/Azure Chat Completions	العميل	لا ينطبق	أنت
Foundry Agent Service	الخدمة	خطي	الخدمة
Responses API (افتراضي)	الخدمة	متفرع	الخدمة
Anthropic Claude, Ollama	العميل	لا ينطبق	أنت

كيف تختار

تحتاج تفرعًا أو “تراجعًا”؟ → Responses API مُدارة من الخدمة
تحتاج سيادة البيانات؟ → مُدارة من العميل مع موفر بقاعدة بيانات
روبوت محادثة بسيط؟ → خطية مُدارة من الخدمة تكفي

اقرأ المقال الكامل للاطلاع على شجرة القرار الكاملة.

مهارات الوكيل في .NET أصبحت أكثر مرونة من أي وقت مضى

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

إذا كنت تبني وكلاء باستخدام Microsoft Agent Framework، فأنت تعرف القاعدة: تعرّف المهارات، واربطها بمزوّد، واترك الوكيل يقرر أيّها يستدعي. الجديد هو كيفية تأليف تلك المهارات — وقفزة المرونة ملموسة.

يُقدّم التحديث الأحدث ثلاثة أنماط تأليف مميزة لمهارات الوكيل: مستندة إلى الملفات، ومستندة إلى الفئات، ومحدّدة بكود مضمّن. الثلاثة تتوصّل بـ AgentSkillsProviderBuilder واحد، أي يمكنك المزج والتوفيق دون أي منطق توجيه أو كود ربط خاص. دعني أرشدك عبر كل واحدة ومتى تلجأ إليها.

المهارات المستندة إلى الملفات: نقطة البداية

المهارات المستندة إلى الملفات هي بالضبط ما يوحي به اسمها — دليل على القرص بملف SKILL.md، وسكريبتات اختيارية، ومستندات مرجعية. فكّر في الأمر كأبسط طريقة لمنح وكيلك قدرات جديدة:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

تُعلن البيانات الأولية في SKILL.md اسم المهارة ووصفها، ويخبر قسم التعليمات الوكيلَ كيف يستخدم السكريبتات والمراجع:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

ثم تربطها مع SubprocessScriptRunner.RunAsync لتنفيذ السكريبت:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

يكتشف الوكيل المهارة تلقائياً ويستدعي سكريبت التزويد عند الحاجة إلى التحقق من حالة الحساب. نظيف وبسيط.

المهارات المستندة إلى الفئات: الشحن عبر NuGet

هنا تصبح الأمور مثيرة للاهتمام للفرق. المهارات المستندة إلى الفئات تشتق من AgentClassSkill<T> وتستخدم سمات مثل [AgentSkillResource] و[AgentSkillScript] لكي يكتشف الإطار كل شيء عبر الانعكاس:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

الجمال هنا أن فريقاً ما يمكنه تعبئة هذا كحزمة NuGet. تضيفها إلى مشروعك، وتُسقطها في المُنشئ، وتعمل جنباً إلى جنب مع مهاراتك المستندة إلى الملفات دون أي تنسيق:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

تظهر كلتا المهارتين في النص التوجيهي للنظام للوكيل. يقرر الوكيل أيّهما يستخدم بناءً على المحادثة — لا حاجة لكود توجيه.

المهارات المضمّنة: الجسر السريع

تعرف تلك اللحظة حين يبني فريق آخر بالضبط المهارة التي تحتاجها، لكنها لن تُشحن لدورة تطوير كاملة؟ AgentInlineSkill هو جسرك:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

أضفها إلى المُنشئ تماماً كالأخريات:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

حين تُشحن حزمة NuGet أخيراً، تستبدل المهارة المضمّنة بالمستندة إلى الفئات. الوكيل لا يلاحظ الفرق.

لكن المهارات المضمّنة ليست مجرد جسور. إنها أيضاً الخيار الصحيح حين تحتاج إلى توليد مهارات ديناميكياً في وقت التشغيل — فكّر في مهارة واحدة لكل وحدة عمل محمّلة من الإعداد — أو حين يحتاج سكريبت إلى الإغلاق على حالة محلية لا تنتمي إلى حاوية حقن التبعيات.

موافقة السكريبت: الإنسان في الحلقة

لنا نحن مطوّري .NET الذين يبنون وكلاء في الإنتاج، هذا هو الجزء الذي يفتح محادثات النشر فعلاً. بعض السكريبتات لها عواقب حقيقية — تسجيل شخص ما في المزايا، أو الاستعلام عن البنية التحتية للإنتاج. فعّل UseScriptApproval ويتوقف الوكيل قبل تنفيذ أي سكريبت:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

حين يريد الوكيل تشغيل سكريبت، يُعيد طلب موافقة بدلاً من ذلك. تجمع تطبيقك القرار — موافقة أو رفض — ويستمر الوكيل وفقاً لذلك. في البيئات الخاضعة للتنظيم، هذا هو الفرق بين “يمكننا نشر هذا” و"الفريق القانوني يقول لا."

لماذا يهمّ هذا التوليف

القوة الحقيقية ليست في أي نمط تأليف منفرد — بل في التركيب. يمكنك:

البدء صغيراً بمهارة مستندة إلى ملفات، والتكرار على التعليمات، وشحنها دون كتابة C#
شحن مهارات قابلة لإعادة الاستخدام كحزم NuGet تضيفها فرق أخرى بسطر واحد
سد الفجوات بمهارات مضمّنة حين تحتاج شيئاً الآن
تصفية أدلة المهارات المشتركة بمسندات حتى يحمّل وكيلك فقط ما ينبغي
إضافة رقابة بشرية للسكريبتات التي تلمس أنظمة الإنتاج

كل هذه تتركّب عبر AgentSkillsProviderBuilder. لا توجيه خاص، ولا منطق شرطي، ولا فحوصات نوع المهارة.

خلاصة القول

مهارات الوكيل في .NET أصبحت الآن تمتلك نموذج تأليف مرناً حقاً. سواء كنت مطوراً فردياً ترسم نموذجاً أولياً بمهارات مستندة إلى الملفات، أو فريق مؤسسة يشحن قدرات مُعبّأة عبر NuGet، فإن الأنماط تناسب الجميع. وآلية موافقة السكريبت تجعلها جاهزة للإنتاج في البيئات التي تحتاج فيها إلى تلك نقطة التفتيش البشرية.

اطّلع على الإعلان الأصلي للشرح الكامل، ووثائق Agent Skills على Microsoft Learn، وأمثلة .NET على GitHub للتطبيق العملي.

بناء واجهات مستخدم متعددة الوكلاء في الوقت الفعلي دون أن تبدو صندوقاً أسود

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

إليك الحقيقة حول الأنظمة متعددة الوكلاء: تبدو رائعة في العروض التوضيحية. ثلاثة وكلاء يتبادلون العمل، ويحلّون المشكلات، ويتخذون القرارات. ثم تحاول عرضها أمام مستخدمين حقيقيين… فلا شيء. مؤشر دوّار. ولا فكرة عن أيّ وكيل يفعل ماذا، أو لماذا النظام متوقف. هذا ليس منتجاً — هذه مشكلة ثقة.

نشر فريق Microsoft Agent Framework للتو شرحاً رائعاً حول دمج مهام سير عمل MAF مع AG-UI، وهو بروتوكول مفتوح لبث أحداث تنفيذ الوكيل إلى واجهة المستخدم الأمامية عبر Server-Sent Events. وبصراحة؟ هذا هو الجسر الذي كنا نفتقده.

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

إذا كنت تبني تطبيقات مدعومة بالذكاء الاصطناعي، فمن المحتمل أنك اصطدمت بهذا الجدار. تنسيق الواجهة الخلفية يعمل بشكل رائع — يُسلّم الوكلاء العمل لبعضهم، وتنطلق الأدوات، وتُتخذ القرارات. لكن الواجهة الأمامية لا تعرف شيئاً مما يجري خلف الكواليس. يعالج AG-UI ذلك من خلال تعريف بروتوكول قياسي لبث أحداث الوكيل (مثل RUN_STARTED وSTEP_STARTED وTOOL_CALL_* وTEXT_MESSAGE_*) مباشرةً إلى طبقة واجهة المستخدم عبر SSE.

العرض التوضيحي الذي بنوه هو سير عمل دعم العملاء المؤلف من ثلاثة وكلاء: وكيل فرز يوجّه الطلبات، ووكيل استرداد يتعامل مع شؤون المال، ووكيل طلبات يدير الاستبدالات. لكل وكيل أدواته الخاصة، وطوبولوجيا التسليم معرّفة صراحةً — لا توجيه مبني على التخمين من النص التوجيهي.

طوبولوجيا التسليم هي النجم الحقيقي

ما لفت انتباهي هو كيف يتيح لك HandoffBuilder إعلان رسم بياني توجيه موجّه بين الوكلاء:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

يُنشئ كل add_handoff حافةً موجّهةً مع وصف بلغة طبيعية. يُولّد الإطار أدوات التسليم لكل وكيل بناءً على هذه الطوبولوجيا. وهكذا تكون قرارات التوجيه مرتكزةً على بنية التنسيق الخاصة بك، لا على ما يمليه نموذج اللغة الكبير. وهذا أمر بالغ الأهمية لموثوقية الإنتاج.

الإنسان في الحلقة بطريقة فعلية

يعرض هذا التوضيح نمطَي مقاطعة تحتاجهما أي تطبيق وكيل في العالم الحقيقي:

مقاطعات موافقة الأدوات — عندما يستدعي وكيل أداةً محدّدة بـ approval_mode="always_require"، يتوقف سير العمل ويُرسل حدثاً. تعرض الواجهة الأمامية نافذة موافقة باسم الأداة وحججها. لا حلقات إعادة محاولة تستهلك الرموز — مجرد تدفق توقف-موافقة-استئناف نظيف.

مقاطعات طلبات المعلومات — عندما يحتاج وكيل إلى مزيد من السياق من المستخدم (كمعرّف طلب مثلاً)، يتوقف ويسأل. تعرض الواجهة الأمامية السؤال، يردّ المستخدم، ويستأنف التنفيذ من حيث توقف بالضبط.

يتدفق كلا النمطين كأحداث AG-UI قياسية، لذا لا تحتاج واجهتك الأمامية إلى منطق مخصص لكل وكيل — فهي تُصيّر أيّ حدث يأتي عبر اتصال SSE.

الربط بينهما بسيط بشكل مفاجئ

التكامل بين MAF وAG-UI يتلخص في استدعاء دالة واحدة:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

يُنشئ workflow_factory سير عمل جديداً لكل خيط، لذا تحصل كل محادثة على حالة معزولة. تعالج نقطة النهاية كل تسليك SSE تلقائياً. إذا كنت تستخدم FastAPI بالفعل (أو يمكنك إضافته كطبقة خفيفة الوزن)، فهذا يكاد يكون بلا احتكاك.

رأيي

بالنسبة لنا كمطوّري .NET، السؤال الفوري هو: “هل يمكنني فعل هذا في C#؟” إطار عمل Agent متاح لكلٍّ من .NET وPython، وبروتوكول AG-UI مستقل عن اللغة (فهو مجرد SSE). لذا بينما يستخدم هذا العرض التوضيحي بالتحديد Python وFastAPI، فإن النمط ينتقل مباشرةً. يمكنك ربط ASP.NET Core minimal API بنقاط نهاية SSE باتباع نفس مخطط أحداث AG-UI.

الخلاصة الأكبر هي أن واجهات المستخدم متعددة الوكلاء أصبحت مصدر قلق من الدرجة الأولى، لا فكرة لاحقة. إذا كنت تبني أي شيء تتفاعل فيه الوكلاء مع البشر — دعم العملاء، أو مسارات الموافقة، أو معالجة المستندات — فإن مجموعة تنسيق MAF وشفافية AG-UI هي النمط الواجب اتباعه.

خلاصة القول

AG-UI + Microsoft Agent Framework يمنحانك أفضل ما في العالمين: تنسيق متين متعدد الوكلاء في الواجهة الخلفية، ورؤية في الوقت الفعلي في الواجهة الأمامية. لا مزيد من تفاعلات الوكيل كصندوق أسود.

راجع الشرح الكامل ومستودع بروتوكول AG-UI للتعمق أكثر.

إطار عمل Microsoft Agent يصل إلى الإصدار 1.0 — إليك ما يهمّ فعلاً لمطوّري .NET

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

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

إذا كنت تتابع رحلة Agent Framework منذ أيام Semantic Kernel وAutoGen الأولى، فهذا الخبر مهمّ. وصل Microsoft Agent Framework للتو إلى الإصدار 1.0 — جاهز للإنتاج، مع واجهات برمجية مستقرة، والتزام بالدعم طويل الأمد. متاح لكلٍّ من .NET وPython، وهو مستعد فعلاً للأعباء الحقيقية.

دعني أتجاوز ضجيج الإعلان وأركّز على ما يهمّ إذا كنت تبني تطبيقات مدعومة بالذكاء الاصطناعي باستخدام .NET.

الملخص السريع

يوحّد Agent Framework 1.0 ما كان يُعرف بـ Semantic Kernel وAutoGen في حزمة تطوير واحدة مفتوحة المصدر. تجريد وكيل واحد. محرك تنسيق واحد. مزوّدو ذكاء اصطناعي متعددون. إذا كنت تتنقل بين Semantic Kernel لأنماط المؤسسات وAutoGen لمهام سير العمل متعددة الوكلاء على مستوى البحث، يمكنك التوقف عن ذلك. هذه هي الحزمة الواحدة الآن.

البدء سهل بشكل غير عادل

إليك وكيل عملي في .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

هذا كل شيء. بضعة أسطر وأمامك وكيل ذكاء اصطناعي يعمل على Azure Foundry. المكافئ في Python موجز بالقدر نفسه. أضف أدوات الدوال، والمحادثات متعددة الأدوار، والبث التدريجي كما تشاء — سطح الواجهة البرمجية يتوسع دون أن يصبح معقداً.

تنسيق متعدد الوكلاء — هذا هو الأمر الحقيقي

الوكلاء الفرديون مناسبون للعروض التوضيحية، لكن سيناريوهات الإنتاج عادةً ما تحتاج إلى تنسيق. يأتي Agent Framework 1.0 مزوّداً بأنماط تنسيق مجرّبة مباشرةً من Microsoft Research وAutoGen:

التسلسلي — يعالج الوكلاء بالترتيب (كاتب ← مراجع ← محرر)
المتزامن — توزيع على وكلاء متعددين بالتوازي، وتجميع النتائج
التسليم — يفوّض وكيل إلى آخر بناءً على النية
المحادثة الجماعية — يناقش وكلاء متعددون ويتقاربون على حل
Magentic-One — نمط متعدد الوكلاء على مستوى البحث من MSR

جميعها تدعم البث، ونقاط التفتيش، وموافقات الإنسان في الحلقة، والإيقاف المؤقت/الاستئناف. جزء نقاط التفتيش بالغ الأهمية — تتيح لمهام سير العمل الطويلة الأمد الصمود في وجه إعادة تشغيل العمليات. لنا نحن مطوّري .NET الذين بنينا مهام سير عمل دائمة مع Azure Functions، يبدو هذا مألوفاً.

الميزات الأكثر أهمية

إليك قائمتي المختصرة بما يستحق المعرفة:

خطّافات البرمجيات الوسيطة. تعرف كيف يمتلك ASP.NET Core مسارات برمجيات وسيطة؟ المفهوم نفسه، لكن لتنفيذ الوكيل. اعترض كل مرحلة — أضف سلامة المحتوى، والتسجيل، وسياسات الامتثال — دون لمس نصوص الوكيل التوجيهية. هذه هي الطريقة التي تجعل الوكلاء جاهزين للمؤسسات.

الذاكرة القابلة للتوصيل. سجل المحادثة، وحالة المفتاح-القيمة الدائمة، والاسترجاع القائم على المتجهات. اختر خلفيتك: Foundry Agent Service، أو Mem0، أو Redis، أو Neo4j، أو أنشئ واحدة خاصة بك. الذاكرة هي ما يحوّل استدعاء نموذج لغوي عديم الحالة إلى وكيل يتذكر السياق فعلاً.

وكلاء YAML التعريفيون. عرّف تعليمات وكيلك وأدواته وذاكرته وطوبولوجيا التنسيق في ملفات YAML خاضعة للتحكم بالإصدار. حمّل وشغّل باستدعاء واجهة برمجية واحدة. هذا تغيير جذري للفرق التي تريد التكرار على سلوك الوكيل دون إعادة نشر الكود.

دعم A2A وMCP. يتيح MCP (Model Context Protocol) للوكلاء اكتشاف الأدوات الخارجية واستدعاءها ديناميكياً. يُمكّن A2A (بروتوكول الوكيل-إلى-الوكيل) التعاون عبر أوقات التشغيل — يمكن لوكلاء .NET التنسيق مع وكلاء يعملون في أطر عمل أخرى. دعم A2A 1.0 قادم قريباً.

ميزات المعاينة التي تستحق المتابعة

شُحنت بعض الميزات كمعاينة في 1.0 — وظيفية لكن الواجهات البرمجية قد تتطور:

DevUI — مصحّح أخطاء محلي يعمل بالمتصفح لتصوير تنفيذ الوكيل وتدفقات الرسائل واستدعاءات الأدوات في الوقت الفعلي. فكّر في الأمر كـ Application Insights لكن للتفكير الوكيلي.
GitHub Copilot SDK وClaude Code SDK — استخدم Copilot أو Claude كإطار وكيل مباشرةً من كود التنسيق. ضع معاً وكيلاً قادراً على البرمجة إلى جانب وكلائك الأخرى في نفس سير العمل.
Agent Harness — بيئة تشغيل محلية قابلة للتخصيص تمنح الوكلاء الوصول إلى الصدفة ونظام الملفات وحلقات المراسلة. فكّر في وكلاء البرمجة وأنماط الأتمتة.
المهارات (Skills) — حزم قدرات نطاق قابلة لإعادة الاستخدام تمنح الوكلاء قدرات منظمة جاهزة.

الترحيل من Semantic Kernel أو AutoGen

إذا كان لديك كود Semantic Kernel أو AutoGen حالي، فهناك مساعدو ترحيل مخصصون يحللون كودك ويولّدون خطط ترحيل خطوة بخطوة. يرشدك دليل ترحيل Semantic Kernel ودليل ترحيل AutoGen عبر كل شيء.

إذا كنت على حزم RC، فالترقية إلى 1.0 مجرد رفع رقم الإصدار.

خلاصة القول

Agent Framework 1.0 هو المعلم الإنتاجي الذي كانت فرق المؤسسات تنتظره. واجهات برمجية مستقرة، ودعم متعدد المزوّدين، وأنماط تنسيق تعمل فعلاً على نطاق واسع، ومسارات ترحيل من كلٍّ من Semantic Kernel وAutoGen.

الإطار مفتوح المصدر بالكامل على GitHub، ويمكنك البدء اليوم بـ dotnet add package Microsoft.Agents.AI. اطّلع على دليل البدء السريع والأمثلة للبدء عملياً.

إذا كنت تنتظر إشارة “آمن للاستخدام في الإنتاج” — فهذه هي.

الاستجابات في الخلفية في Microsoft Agent Framework: لا مزيد من القلق من انتهاء المهلة

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

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

إذا بنيت أي شيء باستخدام نماذج التفكير مثل o3 أو GPT-5.2، فأنت تعرف المعاناة. يبدأ وكيلك في التفكير في مهمة معقدة، يجلس العميل ينتظر، وفي مكان ما بين “كل شيء على ما يرام” و"هل تعطل؟" تنتهي مهلة اتصالك. كل ذلك العمل؟ ضاع.

أصدر Microsoft Agent Framework للتو الاستجابات في الخلفية — وبصراحة، هذه من الميزات التي كان يجب أن تكون موجودة منذ اليوم الأول.

مشكلة الاستدعاءات الحاجبة

في نمط الطلب-الاستجابة التقليدي، يحجب عميلك حتى ينتهي الوكيل. هذا يعمل بشكل جيد للمهام السريعة. لكن عندما تطلب من نموذج تفكير إجراء بحث معمق أو تحليل متعدد الخطوات أو إنشاء تقرير من 20 صفحة؟ أنت تتطلع إلى دقائق من الوقت الفعلي. خلال تلك الفترة:

يمكن أن تنتهي مهل اتصالات HTTP
تقلبات الشبكة تقتل العملية بأكملها
يحدق مستخدمك في مؤشر تحميل متسائلاً إذا كان أي شيء يحدث

الاستجابات في الخلفية تقلب هذا رأساً على عقب.

كيفية عمل رموز الاستمرارية

بدلاً من الحجب، تطلق مهمة الوكيل وتحصل على رمز استمرارية. فكر فيه كتذكرة مطالبة في ورشة إصلاح — لا تقف عند الكاونتر تنتظر، بل تعود عندما يكون جاهزاً.

سير العمل مباشر:

أرسل طلبك مع AllowBackgroundResponses = true
إذا كان الوكيل يدعم المعالجة في الخلفية، تحصل على رمز استمرارية
استعلم حسب جدولك حتى يعود الرمز null — هذا يعني أن النتيجة جاهزة

إليك الإصدار بـ .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

إذا أكمل الوكيل فوراً (المهام البسيطة، النماذج التي لا تحتاج معالجة في الخلفية)، لا يُعاد رمز استمرارية. كودك يعمل فقط — بدون معالجة خاصة.

البث مع الاستئناف: السحر الحقيقي

الاستعلام مناسب لسيناريوهات “أطلق وانسَ”، لكن ماذا عن عندما تريد تقدماً في الوقت الفعلي؟ الاستجابات في الخلفية تدعم أيضاً البث مع استئناف مدمج.

كل تحديث مبث يحمل رمز استمراريته الخاص. إذا انقطع اتصالك في منتصف البث، تستأنف من حيث توقفت تماماً:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

يستمر الوكيل في المعالجة من جانب الخادم بغض النظر عما يحدث مع عميلك. هذا تحمّل للأعطال مدمج دون كتابة منطق إعادة المحاولة أو قواطع الدائرة.

متى تستخدم هذا فعلاً

ليست كل استدعاءات الوكيل تحتاج إلى استجابات في الخلفية. للإكمالات السريعة، أنت تضيف تعقيداً بدون سبب. لكن إليك أين تتألق:

مهام التفكير المعقدة — تحليل متعدد الخطوات وبحث معمق وأي شيء يجعل نموذج التفكير يفكر فعلاً
توليد محتوى طويل — تقارير تفصيلية ووثائق متعددة الأجزاء وتحليل مستفيض
الشبكات غير الموثوقة — عملاء الجوال ونشرات الحافة وشبكات VPN المؤسسية المتذبذبة
أنماط واجهة المستخدم غير المتزامنة — أرسل مهمة، اذهب افعل شيئاً آخر، عد للنتائج

بالنسبة لنا كمطوري .NET الذين يبنون تطبيقات مؤسسية، النقطة الأخيرة مثيرة للاهتمام بشكل خاص. فكر في تطبيق Blazor حيث يطلب مستخدم تقريراً معقداً — تطلق مهمة الوكيل، تعرض له مؤشر تقدم، وتتركه يستمر في العمل. بدون مشاكل WebSocket، بدون بنية تحتية مخصصة للطوابير، فقط رمز واستعلام دوري.

خلاصة القول

الاستجابات في الخلفية متاحة الآن في .NET وPython من خلال Microsoft Agent Framework. إذا كنت تبني وكلاء يفعلون أي شيء أكثر تعقيداً من الأسئلة والأجوبة البسيطة، فهذا يستحق إضافته إلى أدواتك. نمط رمز الاستمرارية يبقي الأمور بسيطة مع حل مشكلة إنتاجية حقيقية جداً.

اطلع على الوثائق الكاملة للرجوع الكامل إلى واجهة برمجية والمزيد من الأمثلة.