عنوان: از دستیار تا اجراکننده: تغییر معماری

کتابچه راهنمای «الگوهای تحول عامل‌محور» (Agentic Transformation Patterns) مایکروسافت برای سال ۲۰۲۶، توضیح می‌دهد که چگونه عامل‌های هوش مصنوعی باید بازسازی شوند تا از حالت صرفاً دستیار برای کاربران، به حالت اجرای واقعی کارها تغییر یابند. این کتابچه هزینه مشخصی برای این تلاش تعیین کرده است: بین ۲۶ تا ۶۰ هفته-مهندس برای زیرساخت‌های اصلی، پیش از آنکه حتی یک عامل در حالت اجرا (execution-mode) عرضه شود. شرکت‌هایی که این تغییر را نادیده بگیرند، با خطر ساخت ابزارهای شکننده‌ای روبرو هستند که نمی‌توانند به‌طور ایمن به‌تنهایی عمل کنند.

سازمان‌ها اکنون در حال آزمایش دستیارهای مبتنی بر مدل‌های زبانی بزرگ (LLM) هستند که پیش‌نویس ایمیل‌ها را می‌نویسند، قطعه‌کدهای پیشنهادی ارائه می‌دهند یا داده‌ها را استخراج می‌کنند. این عامل‌ها در حالت «دستیار» (assist) باقی می‌مانند: یک انسان هر خروجی را بررسی می‌کند و یک لایه پوششی (wrapper) نازک، درخواست را به مدل هدایت کرده و پاسخ را بازمی‌گرداند. این معماری ارزان و سریع پیاده‌سازی می‌شود، اما به‌طور عمدی تصمیم‌گیری و نوشتن داده‌ها را بر عهده کاربر می‌گذارد.

زمانی که یک سازمان می‌خواهد عامل یک گردش کار کامل را اجرا کند — مانند پر کردن یک پایگاه داده، فعال کردن یک فرآیند پایین‌دستی یا تأیید یک تراکنش — مدل دیگر نمی‌تواند یک جعبه سیاه باشد که پاسخ خود را برای تأیید به انسان تحویل دهد. عامل باید به‌عنوان یک سرویس خودمختار، با هویت مستقل، وضعیت پایدار (persistent state) و شبکه‌های ایمنی داخلی عمل کند. مایکروسافت استدلال می‌کند که طراحی قدیمیِ «فقط دستیار» را نمی‌توان با وصله‌پینه کردن به یک سیستم آماده برای اجرا تبدیل کرد؛ این کار مستلزم بازطراحی کامل بر اساس هفت ستون معماری است.

هفت ستون عامل‌های هوش مصنوعی آماده برای اجرا

  • اختیار (Authority) – تغییر از مجوزهای «تفویض‌شده توسط کاربر» به هویت‌های پایدار عامل که دارای حقوق دسترسی محدود (scoped) هستند. عامل باید بتواند بدون نیاز به توکنِ انسان، خود را در سرویس‌های پایین‌دستی احراز هویت کند.
  • مرزها (Boundaries) – جایگزینی استدلال‌های موردی (ad-hoc) مدل برای محاسبات حساس با مسیرهای کد قطعی (deterministic). هر چیزی که نیاز به دقت دارد — مانند محاسبات مالی یا بررسی‌های انطباق — باید در نرم‌افزارهای تأییدشده اجرا شود، نه اینکه از خروجی مدل استنباط گردد.
  • طرح‌واره‌ها (Schemas) – گذار از تبادل داده‌های با نوعِ loose به یک طرح‌واره استاندارد (canonical schema) که تحت مالکیت یک ناظر داده (data steward) مشخص است. این کار مانع از آن می‌شود که عامل، رکوردهای ناقص یا اشتباهی بنویسد که سیستم‌های پایین‌دستی قادر به پردازش آن‌ها نباشند.
  • تشخیص خطا (Failure Detection) – جایگزینی نظارت انسانی با تله‌متری مداوم و پایش پیامدهای تجاری. سیستم باید به‌طور خودکار ناهنجاری‌ها، مانند حجم‌های غیرمنتظره تراکنش، را شناسایی کرده و در صورت عبور از حد مجاز، عامل را متوقف کند.
  • وضعیت (State) – جایگزینی نشست‌های چت کوتاه‌مدت با وضعیت‌های پایدار و محدود به مورد (case-scoped) که در یک سیستم ثبت مرجع (system of record) ذخیره می‌شوند. یک عامل اجراکننده ممکن است نیاز داشته باشد مراحل قبلی، ردپای حسابرسی یا ترجیحات کاربر را در طول روزها یا هفته‌ها به یاد بیاورد.
  • بازگشت به عقب (Rollback) – جایگزینی «اجرای مجدد دستور» (re-run the prompt) با رویکردهای منبع‌گرایی رویداد (event-sourcing) یا تراکنش‌های جبرانی که بتوانند اقدامات را به‌طور قابل‌اعتمادی خنثی کنند. اگر عامل مرتکب اشتباهی شد، پلتفرم باید بدون مداخله دستی، اثرات جانبی را به حالت قبل بازگرداند.
  • قابلیت حسابرسی (Auditability) – ارتقا از متن‌های ساده چت به گزارش‌های (logs) مربوط به هر اقدام که هر عملیات را به نسخه و هویت خاصی از عامل متصل می‌کند. با این کار، نهادهای ناظر و حسابرسان داخلی می‌توانند دقیقاً ردیابی کنند که عامل چه کاری را، در چه زمانی و تحت کدام سیاست انجام داده است.

این تغییرات افزونه‌های اختیاری نیستند؛ بلکه یک مدل عملیاتی جدید برای اتوماسیون مبتنی بر هوش مصنوعی را تشکیل می‌دهند. مایکروسافت تخمین می‌زند که ساخت این زیربنا بین ۲۶ تا ۶۰ هفته-مهندس زمان خواهد برد.

چرا هزینه اهمیت دارد

این کتابچه نسبت به به‌کارگیری عامل‌های حالت اجرا برای وظایف کم‌ارزش که تنها چند دقیقه از گردش کار کاربر می‌کاهند، هشدار می‌دهد. در چنین مواردی، سرمایه‌گذاری مهندسی از هرگونه افزایش اندک در بهره‌وری بیشتر خواهد بود. فرآیندهایی را هدف قرار دهید که پیامدهای قابل‌اندازه‌گیری دارند — مانند تکمیل سفارش، رسیدگی به خسارت یا گزارش‌های انطباق — جایی که اجرای خودمختار مستقیماً به کاهش هزینه‌ها یا کاهش ریسک منجر می‌شود.

برای مالکیت بر طرح‌واره‌های داده‌های خود، به اقتدار سازمانی نیاز دارید.

دیدگاه مخالف: آیا حالت «فقط دستیار» کافی است؟

برای بسیاری از سناریوهای پشتیبانی داخلی — مانند پیش‌نویس یادداشت‌های جلسه یا ارائه مقالات پایگاه دانش — تأیید انسانی همچنان یک شبکه ایمنی کاربردی است. هزینه این کار، کندتر شدن زمان چرخه‌ها و تداوم وابستگی به نیروی انسانی برای تصمیم نهایی است.

نتیجه‌گیری روشن است: انتقال عامل‌های هوش مصنوعی از یک نقش حمایتی به یک نقش خودمختار، صرفاً تغییر یک گزینه (feature toggle) نیست؛ بلکه بازنویسی کامل معماری است. شرکت‌هایی که نیازهای مهندسی و حاکمیتی را دست‌کم می‌گیرند، با خطر عرضه ربات‌های شکننده روبرو هستند.