تصور کنید برنامه‌ای می‌نویسید که نه تنها به سوالات پاسخ می‌دهد، بلکه می‌داند دو جلسه پیش کاربر درباره چه موضوعی صحبت کرده و حالا می‌تواند بر اساس آن، کدی را اجرا کند. این تجربه، تفاوت اصلی میان یک چت‌بات ساده و یک سامانه عامل‌محور است. در حالی که تعاملات استاندارد هوش مصنوعی به یک حلقه گذارای «پرسش و پاسخ» (Prompt-and-Response) محدود شده است، سرویس جدید مایکروسافت این محدودیت را می‌شکند.
طبق مستندات فنی منتشر شده در ۱۹ ژوئیه ۲۰۲۶، سرویس Azure AI Foundry Agent Service به توسعه‌دهندگان .NET اجازه می‌دهد تا از چرخه ساده‌ی «پرسش و پاسخ» خارج شوند و سیستم‌های استدلالی بسازند که حافظه را در طول جلسات مختلف حفظ می‌کنند. در این مدل جدید، عامل‌ها به‌جای ذخیره در حافظه موقت اپلیکیشن (Volatile App Memory)، به‌عنوان منابع پایدار (Durable Resources) در پروژه تعریف می‌شوند و بنابراین حتی پس از بسته شدن برنامه نیز وجود دارند.
برای سال‌ها، برنامه‌نویسان با مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به‌صورت توابعی بدون وضعیت (Stateless) تعامل داشتند. یعنی یک پرامپت می‌فرستادید و یک پاسخ متنی می‌گرفتید. اما این رویکرد زمانی شکست می‌خورد که مدل نیاز داشته باشد یک API خارجی را فراخوانی کند، در یک سند خصوصی جستجو کند یا جزئیاتی را از ۱۰ مرحله قبل به یاد آورد. سرویس جدید مایکروسافت دقیقاً همین‌جا وارد می‌شود تا به عنوان لایه ارکستراتور (Orchestration Layer) عمل کرده و همزمان «مغز» و «ابزارها» را مدیریت کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی معماری‌های عامل‌محور اشاره کردیم، انتقال مدیریت وضعیت از سمت کلاینت به سمت سرور، کلید مقیاس‌پذیری در سیستم‌های هوش مصنوعی است. برای درک بهتر این گذار، می‌توان به رویکرد معماری xAgent در جایگزینی رابط‌های چت با محیط‌های متمرکز بر تکلیف اشاره کرد که دیدگاه مشابهی را در مدیریت عملیات پیاده کرده است.
زمینه: گذار از چت به عامل‌ها
یک عامل در Azure AI Foundry از سه جهت اصلی با فراخوانی‌های استاندارد LLM متفاوت است:
نخست، پایدار (Durable) است، به این معنا که به عنوان یک منبع در داخل پروژه Foundry تعریف می‌شود و باقی می‌ماند.
دوم، ابزارآگاه (Tool-aware) است و توانایی فراخوانی توابع سفارشی یا ابزارهای داخلی را دارد.
سوم، دارای وضعیت (Stateful) است، که اجازه می‌دهد گفتگوها تداوم یابند و بستر یا کانتکست در طول چندین نوبت گفتگو (Multi-turn) حفظ شود.
برای توسعه‌دهندگان .NET، این مسیر با استفاده از کدهای تایپ‌شده (Typed) در C# بسیار ساده و بهینه شده است. این رویکرد نیاز به درگیری با Payloadهای خام REST را از بین می‌برد و امکان ساخت سیستم‌هایی را فراهم می‌کند که بتوانند استدلال کنند، از ابزارها استفاده کنند و اقدامات عملی (Action) را به اجرا درآورند.
برای شروع، داشتن یک پروژه در Azure AI Foundry و استقرار مدلی مثل gpt-4o-mini ضروری است. به نقل از راهنمای فنی مایکروسافت، یکی از چالش‌های فنی حیاتی، نیاز به نقش دسترسی Foundry User RBAC است؛ بدون این دسترسی خاص در سطح Resource Group، توسعه‌دهندگان اغلب با یک خطای ۴۰۳ بی‌صدا (Silent Error) در هنگام فراخوانی‌های SDK مواجه می‌شوند. این مورد یک الزام مجزا از نقش‌های استاندارد Cognitive Services است و اغلب کسانی را که از سرویس‌های ساده Azure OpenAI می‌آیند، دچار سردرگمی می‌کند.
راه‌اندازی پیاده‌سازی
راه‌اندازی محیط را می‌توان با ایجاد یک اپلیکیشن کنسول در .NET 10.0 آغاز کرد (با استفاده از دستور dotnet new console -n FoundryAgentLab -f net10.0). توسعه‌دهندگان باید بسته‌های Azure.AI.Projects و Azure.Identity را به پروژه اضافه کنند. برای مدیریت احراز هویت، توصیه می‌شود از دستور az login به صورت محلی استفاده شود تا نیازی به کدگذاری سخت (Hardcoding) کلیدهای امنیتی در متن برنامه نباشد.
برای اینکه کد به درستی اجرا شود، سه متغیر محیطی (Environment Variables) ضروری باید پیکربندی شوند:
PROJECT_ENDPOINT: URI مشخص برای API پروژه هوش مصنوعی.MODEL_DEPLOYMENT_NAME: نام مدل مستقر شده (مثلاً "gpt-4o-mini").AGENT_NAME: یک شناسه سفارشی برای عامل (مثلاً "my-dotnet-agent").
مکانیسم اصلی این سیستم بر پایه AIProjectClient می‌چرخد که به عنوان نقطه ورود اصلی برای مدیریت عامل‌ها، گفتگوها و پاسخ‌ها عمل می‌کند.
جزئیات فنی پیاده‌سازی
- تعاریฟ Declarative: با استفاده از
PromptAgentDefinitionتوسعه‌دهندگان مدل و دستورالعمل‌ها را توصیف می‌کنند (برای مثال: "شما یک مدرس کمک‌کننده در زمینه .NET/Azure هستید"). سپس سرویس، تمام لایه‌های زیرساختی اجرای کد را مدیریت می‌کند. - کنترل نسخه: هر به‌روزرسانی در تنظیمات یا دستورالعمل‌های عامل، از طریق متد
CreateAgentVersionیک نسخه جدید ایجاد می‌کند. این قابلیت به تیم‌ها اجازه می‌دهد روی پرامپت‌ها تکرار و آزمایش کنند و در صورت بروز مشکل، تغییرات را بدون مختل کردن محیط عملیاتی (Production) به حالت قبل بازگردانند. - مدیریت وضعیت: شیء
ProjectConversationتضمین می‌کند که بستر گفتگو در دیالوگ‌های چند مرحله‌ای حفظ شود. در آزمایش‌های عملی ارائه شده در راهنما، یک عامل توانست بدون اینکه برنامه‌نویس به صورت دستی تاریخچه گفتگو را در پرامپت بگنجاند، در پاسخ به سوالی درباره پایتخت، به درستی به کلمه "فرانسه" که در مراحل قبل ذکر شده بود ارجاع دهد. - مدیریت پاسخ: کلاینت
ProjectResponsesClientاز پیش به یک عامل خاص و یک ID گفتگو متصل است. این ساختار اجازه می‌دهد تا با فراخوانی‌های سادهCreateResponseمتن خروجی را دریافت کرد.
این چارچوب، کارهای سنگین زیرساختی مثل نسخه‌بندی پرامپت و پایداری جلسه را از کد اپلیکیشن خارج کرده و به ابر Azure منتقل می‌کند. برای شما به این معناست که سد ورود به «مهندسی هوش مصنوعی» (AI Engineering) به شدت پایین آمده است؛ دیگر نیازی به ساخت پایگاه‌داده سفارشی برای ذخیره تاریخچه چت یا نوشتن Wrapperهای پیچیده برای مدیریت منطق فراخوانی ابزارها (Tool-calling logic) نیست. SDK این سرویس برای الگوهای DI-friendly و مدل‌های تایپ‌شده طراحی شده است، به گونه‌ای که بیشتر شبیه به یک افزونه بومی اکوسیستم .NET است تا یک API متصل شده از بیرون.
مقیاس‌پذیری به الگوهای عامل‌محور (Agentic Patterns)
تفاوت بین یک فراخوانی ساده چت و یک سیستم «عامل‌محور» زمانی که الگو مقیاس می‌گیرد، کاملاً روشن می‌شود. توسعه‌دهندگان می‌توانند با پیاده‌سازی موارد زیر، از خروجی‌های صرفاً متنی فراتر روند:
- ابزارهای داخلی: ادغام Code Interpreter (مفسر کد)، File Search (جستجوی فایل) یا Bing Grounding به مدل اجازه می‌دهد به طور خودکار تصمیم بگیرد چه زمانی از این سرویس‌ها برای یافتن پاسخ دقیق‌تر استفاده کند.
- توابع سفارشی (Custom Function Tools): اتصال ابزارهای تابعی اختصاصی به عامل، اجازه می‌دهد مدل در میانه گفتگو، مستقیماً کدهای داخلی اپلیکیشن شما را فراخوانی و اجرا کند. در این راستا، شناخت ابزارهای کلیدی برای عبور از بن‌بست‌های اجرای عملیاتی می‌تواند به توسعه‌دهندگان در مدیریت بهتر این توابع کمک کند.
- منابع نام‌گذاری شده: چون عامل‌ها به عنوان منابع نسخه‌بندی شده و پایدار وجود دارند، می‌توانند در سطح کل تیم به اشتراک گذاشته شوند، به جای اینکه در اسکریپت‌های انفرادی توسعه‌دهندگان دفن شوند.
اگر می‌خواهید اجرای کامل این پیاده‌سازی را ببینید، یک ویدئوی آموزشی جامع همراه با این راهنما وجود دارد که مراحل تنظیم پورتال و فرآیند عیب‌یابی (Debugging) را برای کسانی که به زبان‌های هندی یا Hinglish دنبال می‌کنند، نمایش می‌دهد. 🎥 ویدئوی کامل را اینجا ببینید: https://youtu.be/mrsEsculrNg
گام بعدی شما
- اگر از اکوسیستم .NET استفاده می‌کنید، SDK جدید
Azure.AI.Projectsرا جایگزین فراخوانی‌های مستقیم API کنید. - دسترسی‌های RBAC خود را در Azure بررسی کنید تا با خطای ۴۰۳ مواجه نشوید.
- برای پیاده‌سازی اولین عامل، روی ترکیب gpt-4o-mini و ابزار Code Interpreter تمرکز کنید.
اما تأثیر این یکپارچگی بر هزینه استنتاج در مقیاس سازمانی موضوع دیگری است — در تحلیل ما درباره بهینه‌سازی هزینه‌های GPU در Azure بخوانید.
گفتگو