مایکروسافت Routines را در Foundry Agent Service به دسترسپذیری عمومی رسانده است؛ قابلیتی که بخشی از زیرساخت معمول اطراف عاملهای هوش مصنوعی را به یک سرویس مدیریتشده تبدیل میکند. یک Routine میتواند عامل را یکبار در زمان مشخص، بهصورت تکرارشونده طبق برنامه یا در واکنش به یک رویداد خارجی اجرا کند. تنظیم trigger، عمل عامل، connectionها، هویت مورد استفاده و تاریخچه اجرا نیز در همان پروژه Foundry نگهداری میشود.
در نگاه اول این یک قابلیت زمانبندی است، اما تغییر مهمتر معماری آن است. یک عامل خودکار فقط به مدل و ابزار نیاز ندارد؛ باید چیزی وجود داشته باشد که وقوع کار را تشخیص دهد، به سامانه مقصد احراز هویت کند، payload رویداد را به عامل برساند و نتیجه اجرا را ثبت کند. Foundry حالا بخش مهمی از این لایه را داخل پلتفرم آورده است.
سه نوع trigger برای الگوهای اصلی خودکارسازی
نسخه GA از timer، برنامه تکرارشونده و trigger رویدادمحور پشتیبانی میکند. timer برای اجرای یکباره در آینده است. اجرای recurring برای کارهایی مانند گزارش روزانه، بررسی هفتگی یا پایش منظم استفاده میشود. trigger رویدادمحور نیز وقتی تغییری در یک سامانه متصل رخ میدهد عامل را فعال میکند.
مایکروسافت در اعلامیه خود GitHub issue و پیام جدید در کانال Microsoft Teams را از نخستین نمونههای event source معرفی میکند. Foundry رویداد را از connection پیکربندیشده دریافت میکند، payload را به عامل میدهد و نتیجه اجرا را برای بررسی بعدی ثبت میکند. عامل میتواند بر اساس رویداد استدلال کند، ابزارهایش را فراخوانی کند و بدون انتظار برای شروع یک chat از طرف کاربر اقدام بعدی را انجام دهد.
این تفاوت میان «عاملی که قادر به انجام کار است» و «عاملی که واقعاً بخشی از یک فرایند عملیاتی است» را کمتر میکند. عامل ممکن است triage کردن issue را بلد باشد، اما تا زمانی که سامانهای رویداد را ببیند، دسترسی را مدیریت کند و اجرای آن را ثبت کند، خودکارسازی کامل نشده است.
هویت بخشی از تعریف automation میشود
مهمترین جزئیات این عرضه به هویت مربوط است. Routines میتواند عامل و ابزارهایش را با هویت سازنده Routine یا با هویت مستقل خود عامل اجرا کند.
هویت creator دسترسی delegated همان شخص را حفظ میکند و برای ابزارهایی مناسب است که با OAuth کاربر پیکربندی شدهاند. هویت agent در مقابل اجازه میدهد خود عامل با مجوزهای تنظیمشده در Microsoft Entra بهعنوان یک موجودیت مستقل اجرا شود.
این انتخاب صرفاً تنظیم فنی نیست. تعیین میکند یک automation بدون حضور انسان چه دادهای را میتواند بخواند و چه عملی را میتواند انجام دهد. دو Routine ممکن است از یک مدل یکسان استفاده کنند اما سطح دسترسی کاملاً متفاوتی لازم داشته باشند.
نتیجه عملی برای تیمهای مهندسی این است که هویت باید همزمان با trigger و action طراحی شود، نه در پایان پروژه. Routine گزارشگیری شاید دسترسی خواندن گسترده بخواهد ولی نوشتن لازم نداشته باشد. عامل واکنش به رخداد عملیاتی ممکن است فقط به چند مجوز نوشتن محدود، approval مشخص و ثبت کامل اقدامات نیاز داشته باشد.
Reminder برای ادامه کارهای طولانی
مایکروسافت همچنین reminder tool را که فعلاً در preview است توضیح میدهد. Hosted Agent میتواند کاری طولانی را آغاز کند، برای مدتی بعد reminder بگذارد و روی همان conversation دوباره اجرا شود تا وضعیت کار را بررسی کند.
این الگو با schedule خارجی تفاوت دارد. Routine تعیین میکند چه زمانی محیط باید عامل را فعال کند؛ reminder اجازه میدهد خود عامل تشخیص دهد کارش تمام نشده و ادامه بعدی را برنامهریزی کند. ترکیب این دو برای سناریوهایی مانند انتظار برای export، بررسی deployment یا ادامه کار پس از یک approval مفید است.
برای خودکارسازی stateful این موضوع مهم است، چون اگر پلتفرم conversation و context را حفظ کند، توسعهدهنده مجبور نیست تمام لایه polling و persistence را جداگانه بسازد.
تحلیل Aipolix: scheduler وارد control plane عامل میشود
پیام اصلی این عرضه آن است که پلتفرمهای عامل در حال جذب زیرساختهایی هستند که قبلاً بیرون از runtime قرار داشتند. schedule، دریافت event، identity، connection و run history اکنون در یک سطح کنترلی مدیریتشده به هم نزدیک میشوند.
این تمرکز میتواند معماری production را سادهتر کند، چون تعداد سرویسهای جانبی کمتر میشود. از نظر governance نیز مفید است: میتوان دید چه چیزی عامل را فعال کرده، با کدام هویت اجرا شده و چه runهایی اتفاق افتادهاند.
اما سادهتر شدن معماری به معنی حذف مسئله reliability نیست. اعلامیه مایکروسافت میگوید Foundry invocationها را queue میکند و نتایج را ثبت میکند، اما تمام جزئیات delivery guarantee و retry semantics را در همین اعلامیه مشخص نمیکند. پیش از استفاده از Routine برای عملیات برگشتناپذیر، تیم باید رفتار دقیق سیستم در duplicate event، retry، partial failure و replay را در پیکربندی واقعی خود بررسی کند.
این مرز پنهان عملیات است. ممکن است مدل تصمیم درستی بگیرد اما اگر یک event دوبار تحویل شود یا tool call موفق شود و سپس run تکرار شود، نتیجه نهایی اشتباه باشد. طراحی idempotent ابزارها، مجوز حداقلی و approval صریح همچنان مسئولیت application باقی میماند.
چرا GA مهم است
Routines پیش از این در preview وجود داشت؛ بنابراین خبر اصلی صرفاً امکان schedule کردن عامل نیست. تغییر مادی این است که مایکروسافت اکنون این لایه automation را بهعنوان زیرساخت generally available برای استفاده production عرضه میکند.
برای سازمانهایی که از Foundry Agent Service استفاده میکنند، این میتواند بخشی از glue code را حذف کند. بهجای اینکه هر عامل یک scheduler، webhook receiver، queue و run-history store جداگانه داشته باشد، تیم میتواند از Routine مدیریتشده شروع کند و فقط در جاهایی که تضمین یا کنترل ویژه لازم دارد زیرساخت سفارشی اضافه کند.
جهت کلی روشن است: پلتفرمهای enterprise agent از «مدل همراه ابزار» به سمت «نرمافزار خودکاری که در طول زمان اجرا میشود» حرکت میکنند. وقتی trigger، هویت و ادامه کار جزو runtime میشوند، کیفیت سامانه عامل به همان اندازه که به مدل وابسته است به کنترلهای عملیاتی نیز وابسته خواهد بود.