اگر امروز در حال توسعهی عاملهای هوش مصنوعی هستید، احتمالاً بین نظم سختگیرانهی SDKها و آزادی عمل در مدیریت جریانهای پیچیده مردد بودهاید. مایکروسافت با معرفی Microsoft Agent Framework (MAF) در ۲۷ دسامبر ۲۰۲۵، این تردید را با یک زیرساخت یکپارچه پاسخ داد. تا پیش از این، توسعهدهندگان مجبور بودند بین رویکرد ساختاریافتهی SDK در Semantic Kernel و ارکستراسیون سیال AutoGen یکی را انتخاب کنند؛ اما اکنون با ورود MAF، رقابت برای یافتن بنیاد غالب عاملهای هوش مصنوعی وارد مرحلهی جدیدی شده است.
این ابزار دقیقاً همان لولهکشی فنی است که مایکروسافت برای تبدیل Copilot به یک «سوپر اپلیکیشن» تا سال ۲۰۲۶ به آن نیاز داشت. در واقع، ما شاهد گذاری از مهندسی پرامپت (Prompt Engineering) — که شبیه هنر سؤال درست پرسیدن از یک مشاور باتجربه است — به سمت معماریهای عاملمحور (Agentic) هستیم. این تحول در راستای دیدگاههای گستردهتری است که پیشبینیهایی مبنی بر ورود میلیاردها عامل هوشمند به بازار تا سال ۲۰۳۱ دارد و چشمانداز آیندهی تعامل انسان و ماشین را تغییر میدهد. هدف مایکروسافت این بود که رویکرد سازمانی Semantic Kernel را — که بر اتصالکنندهها (Connectors)، یکپارچگی با پلتفرم و یک سطح توسعهی پایدار تأکید دارد — با الگوهای ارکستراسیون چند-عاملی سبک AutoGen، شامل هماهنگی، جابهجایی (Handoffs) و جریانهای غنیتر بین عاملها، ترکیب کند.
برای توسعهدهندگان .NET، این چارچوب در واقع نسخهی دوم Semantic Kernel یا همان «Semantic Kernel v2» است. طبق اعلام مایکروسافت، سرمایهگذاری اصلی اکنون روی این SDK متنباز و محیط زمان اجرای (Runtime) جدید متمرکز شده است. اگرچه مایکروسافت همچنان اصلاحات امنیتی و رفع باگهای حیاتی را برای نسخههای v1.x ادامه میدهد و تضمین میکند برخی ویژگیها به مرحلهی GA (General Availability) برسند، اما هدف نهایی این است که توسعهدهندگان بتوانند بدون نیاز به بازنویسی کامل کد هنگام انتقال از «دمو» به «استقرار»، تجربیات محلی خود را به سیستمهای عملیاتی تبدیل کنند.
معماری و منطق هسته
Microsoft Agent Framework بر دو مفهوم کلیدی و انتزاعی استوار است:
- عاملهای هوش مصنوعی (AI Agents): موجوداتی که از مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — برای پردازش ورودیها، فراخوانی ابزارها و تولید پاسخها استفاده میکنند. هر عامل در واقع کپسولهای از یک LLM، دستورالعملهای خاص (Instructions) و ابزارهایی است که اجازه دارد از آنها استفاده کند.
- گردشهای کاری (Workflows): یک ارکستراسیون گرافمحور که چندین عامل و تابع را برای انجام کارهای پیچیده و چندمرحلهای به هم متصل میکند.
بر اساس مستندات فنی، یکی از بزرگترین پیشرفتها، سادهسازی فراخوانی تابع (Function Calling) است. برخلاف ثبت verbose و طولانی پلاگینها در نسخههای قدیمی Semantic Kernel، چارچوب MAF از یک AIFunctionFactory استفاده میکند تا متدهای C# را از طریق Reflection (بازتاب) به ابزار تبدیل کند. این امر به توسعهدهندگان اجازه میدهد ابزارهایی را با استفاده از ویژگیهای سادهی [Description] تعریف کنند؛ توصیفاتی که توسط LLM خوانده میشوند تا مدل تشخیص دهد دقیقاً چه زمانی یک تابع خاص را تحریک کند.
جزئیات پیادهسازی: اجرای یک عامل ساده
برای ساخت یک عامل، توسعهدهنده متدهایی را در C# تعریف میکند که دارای ویژگی [Description] هستند. این توصیفات حیاتی هستند زیرا مستقیماً به LLM ارسال میشوند تا هدف ابزار را درک کند. به عنوان مثال، متدی مانند GetWeather با توصیف «دریافت آب و هوا برای یک مکان خاص»، به LLM کمک میکند تا ابزار صحیح را برای پاسخ به سؤال کاربر شناسایی کند.
فرآیند اجرا طبق گزارش مایکروسافت به این ترتیب است:
- ثبت ابزار: متد
AIFunctionFactory.Create()امضای متد و ویژگیهای آن را تحلیل کرده و طرحوارهای (Schema) شامل نام پارامترها، انواع دادهها و توصیفات میسازد که LLM برای فراخوانی نیاز دارد. - ایجاد عامل: متد
CreateAIAgent()یک Wrapper دورChatClientمیسازد. در اینجا پارامترinstructionsنقش پرامپت سیستمی را ایفا میکند و رفتار عامل را هدایت میکند؛ مثلاً میتواند به عامل دستور دهد پیش از پاسخ دادن، حتماً عبارت «یک لحظه صبر کنید» را به کار ببرد. - مدیریت رشته (Thread): با استفاده از
GetNewThread()یک کانتینر حالتدار برای گفتگو ایجاد میشود. این قابلیت اجازه میدهد تا چندین مکالمهی مستقل بهطور همزمان مدیریت شوند بدون اینکه تاریخچهی آنها با هم ترکیب شود. - اجرا: متد
RunStreamingAsync()برای ارسال ورودی کاربر و دریافت پاسخها بهصورت تکهتکه (Chunk) استفاده میشود تا کاربر فوراً بازخورد را مشاهده کند و منتظر تولید کامل پاسخ نماند.
در سناریوی عملی، وقتی کاربر دربارهی آب و هوای پاریس میپرسد، چارچوب درخواست LLM برای فراخوانی ابزار را رهگیری میکند، متد C# مربوطه را اجرا کرده و نتیجه را بهعنوان یک «پیام ابزار» (Tool Message) به مدل بازمیگرداند. سپس LLM این داده را در پاسخ نهایی زبان طبیعی خود ادغام میکند.
قابلیتهای پیشرفته برای محیط عملیاتی
برای عبور از دموهای ساده و رسیدن به سطح تولید (Production)، MAF مکانیسمهای سازمانی زیر را برای پایداری، مشاهدهپذیری و قابلیت انتقال معرفی کرده است:
- خروجی ساختاریافته (Structured Output): با استفاده از
RunAsync<T>()و تبدیل کلاسهای C# به JSON Schema، مدل مجبور است دادهها را در فیلدهای مشخص قرار دهد و از نثر آزاد فاصله بگیرد. این قابلیت بهعنوان یک «داربست استدلالی» عمل میکند که برای یکپارچگی با APIهای پاییندست حیاتی است. برای جلوگیری از توهم (Hallucination) در صورت نبود داده، توسعهدهندگان میتوانند از فیلدهای Nullable یا مقادیر صریح «ناشناس» (Unknown) استفاده کنند. برای مثال در تحلیل یک جلسه، میتوان فیلدهای تایپشدهای برایDate(تاریخ)،DurationMinutes(مدت جلسه به دقیقه)،Attendees(حاضرین)،Decisions(تصمیمات) و یک کلاس تودرتویActionItemشامل شخص مسئول و تاریخ سررسید استخراج کرد. - پایداری رشته (Thread Persistence): این چارچوب از
AgentThreadوChatMessageStoreاستفاده میکند. توسعهدهندگان میتوانند با اتصال ارائهدهندههای ذخیرهسازی سفارشی مانند Redis، SQL یاFileChatMessageStore(ارائهشده)، وضعیت گفتگوها را ذخیره و بازیابی کنند. حالت رشته از طریقthread.Serialize()ذخیره شده و تاریخچهی چت با بازنویسی متدهایAddMessagesAsyncوGetMessagesAsyncدر Store مدیریت میشود. - یکپارچگی با Azure AI Foundry: برای مقیاسپذیری در محیط ابری،
PersistentAgentsClientاجازه میدهد عاملها بهطور کامل در Azure AI Foundry (که سابقاً Microsoft Foundry بود) مدیریت شوند. این ویژگی زیرساخت مدیریتشدهای را فراهم میکند که در آن عاملها و رشتهها بهطور خودکار ذخیره شده و چرخهی حیات آنها توسط ارائهدهندهی ابری کنترل میشود و بدین ترتیب سربار عملیاتی تیمهای DevOps حذف میگردد. - Tولید بازیابیافزا (RAG) یکپارچه: MAF از طریق
TextSearchProviderاجازه میدهد عامل در لحظه جستوجوی برداری را فعال کند. این فرآیند شامل تعریف یک رکورد جستوجو با ویژگیهای[VectorStoreKey]،[VectorStoreData]و[VectorStoreVector]است (مثلاً استفاده از ۳۰۷۲ بعد برای مدلtext-embedding-3-large).
مکانیسم RAG و جستوجوی برداری
در پیادهسازی تولید بازیابیافزا (RAG) — که شبیه دانشآموزی است که قبل از جواب دادن، اول کتاب درسی را باز میکند — ارائهدهندهی جستوجو به جای یک ابزار استاندارد، بهعنوان یک AIContextProviderFactory سیمکشی میشود. جریان منطقی کار به این شکل است:
۱. پرسش کاربر دریافت میشود (مثلاً: «سیاست مرجوعی کالا چیست؟»).
۲. ارائهدهنده، با استفاده از تاریخچه اخیر گفتگو (که مقدار RecentMessageMemoryLimit میتواند مثلاً روی ۶ پیام تنظیم شود)، یک پرسوجوی جستوجو را شکل میدهد.
۳. پایگاهداده برداری (مانند InMemoryVectorStore) نتایج برتر را (معمولاً ۳ مورد اول) بازمیگرداند.
۴. این قطعات متنی بازیابیشده به پنجره زمینه (Context Window) مدل تزریق میشوند و سپس مدل پاسخ نهایی را بر اساس این مستندات تولید میکند.
نیازمندیهای فنی و پشتیبانی زبان
توسعهدهندگان برای پیادهسازی این عاملها به SDK نسخهی .NET 10.0 یا بالاتر نیاز دارند. این چارچوب بهطور خاص برای اکانتهای Azure OpenAI و مدلهای با قدرت استدلال بالا مانند gpt-4.1 یا gpt-5.2 و همچنین استقرار مدلهای Embedding برای سناریوهای RAG طراحی شده است.
پیکربندی معمولاً از طریق یک فایل appsettings.json با کلیدهای زیر انجام میشود:
ModelName: نام استقرار مدل خاص شما.Endpoint: آدرس URL منبع Azure.ApiKey: کلید امنیتی شما.EmbeddingModel: نام استقرار مدل Embedding مورد استفاده در RAG.
اگرچه پیادهسازی C# ویترین اصلی است، اما مایکروسافت پشتیبانی مشابهی را برای پایتون نیز منتشر کرده است. API پایتون از طراحی C# تقلید کرده و از متدهای AzureOpenAIClient و create_agent استفاده میکند. این امر به تیمها اجازه میدهد پروژههای پایتونی موجود خود را مهاجرت دهند یا سیستمهای عاملی چندزبانه را بدون نیاز به بازنویسی منطق زیربنایی توسعه دهند.
تحلیل تحریریه
این یکپارچهسازی یک حرکت استراتژیک برای کاهش «بار شناختی» (Cognitive Load) روی توسعهدهندگان است. مایکروسافت با ادغام فلسفههای Semantic Kernel و AutoGen، در واقع اعتراف میکند که هیچیک از این دو رویکرد بهتنهایی کافی نبودند. هوش مصنوعی سازمانی هم به حاکمیت سختگیرانهی یک SDK نیاز دارد و هم به انعطافپذیری یک گراف چند-عاملی.
برای توسعهدهنده، این به معنای کوتاهتر شدن مسیر از یک آزمایش محلی تا یک سیستم عملیاتی است. در اینجا تضاد میان مدلهای محلی و ابری برجسته میشود؛ جایی که نبردهای پایداری در نظارت زیرساختی نشان داد که مدلهای محلی در مقیاس صنعتی با چه چالشهایی روبروند و چرا اتکا به زیرساختهای مدیریتشده ضروری است. قابلیت جایگزینی یک ذخیرهساز برداری در حافظه (In-memory) با یک پایگاه داده تولیدی، بدون تغییر در سیمکشی عامل، پاسخ مستقیمی به «بدهی فنی» (Technical Debt) است که بسیاری از تیمها در جریان تب AI سالهای ۲۰۲۳-۲۰۲۴ انباشته کردند.
در نهایت، MAF کمتر دربارهی یک ویژگی جدید و بیشتر دربارهی یک «استاندارد جدید» است. این سیگنالی است مبنی بر اینکه «عصر نمونهسازی» (Prototype Era) برای عاملهای هوش مصنوعی به پایان رسیده و «عصر استقرار» (Deployment Era) آغاز شده است؛ جایی که پایداری، مشاهدهپذیری و قابلیت همکاری تنها معیارهای مهم هستند. این رویکرد با استراتژیهای عملیاتی مایکروسافت همسو است، مانند سرمایهگذاری ۲.۵ میلیارد دلاری برای استقرار مهندسان در دفاتر مشتریان تا اطمینان حاصل شود که این ابزارهای پیچیده در محیطهای واقعی به درستی پیادهسازی میشوند. اگر در حال حاضر در حال ساخت عامل هستید، باید ارزیابی کنید که آیا استک فعلی شما میتواند پایداری طولانیمدت رشتهها و خروجی ساختاریافته را بدون نوشتن کدهای تکراری و حجیم (Boilerplate) پشتیبانی کند یا خیر. گام منطقی بعدی برای جامعهی توسعهدهندگان، ایجاد پروتکلهای استاندارد ارتباطی بین-عاملی خواهد بود که فراتر از یک چارچوب واحد گسترش یابد.
گام بعدی شما
- اگر از Semantic Kernel v1 استفاده میکنید، مسیر مهاجرت به MAF را بررسی کنید تا از قابلیت خروجی ساختاریافته بهره ببرید.
- برای کاهش نرخ توهم در اپلیکیشنهای تجاری، متدهای خود را با
[Description]دقیق بازنویسی کنید. - معماری Agent-to-Agent را در محیط Azure AI Foundry تست کنید تا سربار مدیریت سرور را حذف کنید.
این تنها آغاز ماجراست؛ اثر موجگونهی این استاندارد بر پروتکلهای ارتباطی بین-عاملی را در گزارش بعدی بررسی خواهیم کرد.
گفتگو