مایکروسافت در روز نوآوری ابری و هوش مصنوعی خود در بنگلور، از یک پشته (stack) هوش مصنوعی عامل‌محور رونمایی کرد و محصولاتی از جمله Microsoft IQ، Fabric IQ، یک لایه Ontology و چارچوب حاکمیتی Agent 365 را معرفی نمود. این اقدام، تمرکز را از چت‌بات‌های مستقل به «عامل‌های» (agents) خودمختاری تغییر می‌دهد که در سرویس‌های ابری شرکت پیمایش می‌کنند و شرکت‌ها را مجبور می‌کند در نحوه ساخت، اجرا و نظارت بر هوش مصنوعی بازنگری کنند.

چرا این تغییر در حال حاضر اهمیت دارد

بسیاری از شرکت‌ها در مرحله‌ی میان «اثبات مفهوم» (PoC) و «استقرار کامل» متوقف می‌شوند. گلوگاه اصلی، مدل‌ها نیستند؛ بلکه زیرساخت‌های اتصالی (plumbing) هستند—یعنی حاکمیت، هویت و قابلیت مشاهده‌پذیری (observability) که باعث می‌شود یک عامل، قابل اعتماد و مطابق با قوانین باقی بماند. پشته جدید مایکروسافت این شکاف زیرساختی را پر می‌کند و یک لایه هوش قابل استفاده مجدد ارائه می‌دهد که بر روی هر پلتفرم داده و هر مدل زبانی بزرگ (LLM) قابل اجراست.

اجزای سازنده‌ای که مایکروسافت معرفی کرد

  • Microsoft IQ – یک لایه هوش که در محیط (tenant) مشتری قرار می‌گیرد و کنترل مستقیم بر پرامپت‌ها، حافظه و سیاست‌ها را به آن‌ها می‌دهد.
  • Fabric IQ – همان قابلیت که در سرویس data-fabric مایکروسافت تعبیه شده است، به‌طوری که تحلیل‌ها و هوش مصنوعی از یک زمینه (context) مشترک استفاده می‌کنند.
  • Ontology – یک مدل زنده و ماشین‌خوان از فرآیندها، موجودیت‌ها و روابط یک کسب‌وکار، که به عامل‌ها اجازه می‌دهد بدون نیاز به کدنویسی سخت‌افزاریِ قوانین، درک کنند «چه کسی چه کاری انجام می‌دهد».
  • Agent 365 – یک چارچوب حاکمیتی که هویت، دسترسی مبتنی بر نقش و ردپای حسابرسی (audit trails) را به هر عامل هوش مصنوعی متصل می‌کند و اجازه می‌دهد با عامل، مانند یک کارمند در سیستم‌های منابع انسانی یا امنیتی برخورد شود.

این اجزا در کنار هم، یک «چت‌بات» را به یک «همکار دیجیتال» تبدیل می‌کنند که داده‌ها را فراخوانی می‌کند، جریان‌های کاری را فعال می‌سازد و در چارچوب‌های سازمانی تصمیم‌گیری می‌کند.

آنچه متخصصان می‌توانند امروز از این موضوع بیاموزند

۱. شرح وظایف یک عامل را تعریف کنید – با هر دستیار هوش مصنوعی مانند یک «نقش» با مهارت‌ها، دستورالعمل‌ها و هویت منحصربه‌فرد برخورد کنید. وقتی عاملی رفتار نادرستی داشت، ابتدا مسئولیت‌های تعریف‌شده آن را بررسی کنید، نه فقط پرامپتی را که آن را فعال کرده است. ۲. مدل را تعویض‌پذیر کنید – با جداسازی LLM از زیرساخت‌های اطراف، یک شرکت می‌تواند GPT را با Claude، Llama یا هر مدل آینده‌ای بدون بازسازی کل پشته جایگزین کند. در این حالت، سرمایه‌گذاری در لایه ارکستراسیون (orchestration) باقی می‌ماند، نه در خودِ مدل. ۳. به جای جایگزینی، پوشش دهید (Wrap, don't rip) – سیستم‌های قدیمی می‌توانند از طریق آداپتورها به هوش مصنوعی متصل شوند. شرکت Kotak Mahindra این موضوع را با لایه‌بندی Azure Voice Live روی زیرساخت تلفنی موجود خود نشان داد و ثابت کرد که نیازی به بازنگری و نوسازی کامل نیست. ۴. با تنظیم دقیق (tuning) به عنوان یک فرآیند مداوم برخورد کنید – تنظیم دقیق (Fine-tuning) نیازمند یک چرخه شامل آماده‌سازی داده‌ها، آموزش، ارزیابی و نظارت بر عملکرد است. بدون یک خط لوله ارزیابی (evaluation pipeline)، هر تلاش برای تنظیم دقیق، کورکورانه خواهد بود. ۵. با داده‌های پاک شروع کنید – یکی از شرکت‌کنندگان فاش کرد که یک چهارم گزارش‌های آن‌ها هرگز مورد استفاده قرار نگرفته است. وارد کردن داده‌های نامنظم به یک عامل، فقط باعث خودکارسازی آن آشفتگی می‌شود. ابتکارات مربوط به کیفیت داده و منطقی‌سازی گزارش‌ها باید پیش از استقرار گسترده هوش مصنوعی انجام شود.

ایده‌های عملی برای یک پشته سازمانی

  • یک داشبورد مشاهده‌پذیری (observability) یکپارچه بسازید که هزینه‌های مرتبط با هوش مصنوعی، تأخیر (latency) و سلامت خط لوله‌ها را ردیابی کند.
  • از پروتکل‌های MCP برای در دسترس قرار دادن انبارهای داده داخلی برای عامل‌ها استفاده کنید تا جابجایی داده‌ها ایمن و قابل حسابرسی باشد.
  • مدل‌های معنایی (semantic models) ایجاد کنید که پرس‌وجوهای مدیریت هزینه را به زبان طبیعی ترجمه کنند؛ تا تیم‌های مالی بتوانند بپرسند «هزینه ابری ما در فصل گذشته چقدر بود؟» و بلافاصله پاسخ بگیرند.
  • استفاده آزمایشی از GitHub Copilot را در تیم‌های توسعه برای خودکارسازی بازبینی کد (code reviews) آغاز کنید و هم افزایش سرعت و هم کاهش خطاها را اندازه‌گیری کنید.