۴ الگوی معماری AutoGen که پس از توقف توسعه همچنان کاربردی هستند

اگر امروز در حال طراحی یک سامانه عامل‌محور هستید، احتمالاً متوجه شده‌اید که ابزارهای آزمایشگاهی به‌سرعت منسوخ می‌شوند، اما منطقِ پشت آن‌ها خیر. مایکروسافت در ۳۱ اکتبر ۲۰۲۵ رسماً AutoGen را به حالت «نگهداری» (Maintenance Mode) برد تا تیم آن با تیم Semantic Kernel ادغام شده و Microsoft Agent Framework را خلق کند.

به نقل از مستندات رسمی مایکروسافت، این چارچوب دیگر ویژگی‌های جدیدی دریافت نمی‌کند و تنها وصله‌های امنیتی و رفع باگ‌های حیاتی برای آن منتشر می‌شود. این یک چرخش راهبردی از ابزارهای آزمایشی به سمت زیرساخت‌های یکپارچه سازمانی است. پروژه‌های موجود همچنان به کار خود ادامه می‌دهند و مایکروسافت برای تسهیل این انتقال، یک راهنمای مهاجرت (Migration Guide) منتشر کرده است. برای توسعه‌دهندگان، این تغییر شبیه جابه‌جایی از یک دفترچه طراحی دستی به یک نرم‌افزار مهندسی دقیق (CAD) است؛ ابزارها عوض می‌شوند، اما قوانین فیزیک — یا در اینجا، منطق ارکستراسیون عامل‌ها — تغییر نمی‌کنند. این چالش جابه‌جایی ابزارها اغلب با ریسک از دست رفتن نقش‌ها و حافظه همراه است، موضوعی که در بررسی لایه‌های حفظ تداوم حافظه در زمان تغییر ابزارها به آن پرداخته‌ایم.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، یکپارچگی زیرساخت‌ها برای کاهش نقاط آسیب‌پذیری ضروری است. این ادغام بخشی از یک روند دو ساله در فضای عامل‌محور (Agentic) است تا از کتابخانه‌های پراکنده به سمت لایه‌های ارکستراسیون مستحکم حرکت کنیم که بتوانند استقرار در مقیاس سازمانی را مدیریت کنند. اگرچه رابط برنامه‌جایی (API) AutoGen در حال جایگزینی است، اما ارزش آموزشی آن باقی می‌ماند؛ زیرا AutoGen محیط اصلی بود که بسیاری از توسعه‌دهندگان برای اولین بار آموختند یک سیستم چندعاملی (Multi-Agent System) در واقعیت چگونه عمل می‌کند.

طبق گزارش تحلیل‌های فنی در dev.to، چهار الگوی معماری AutoGen همچنان برای هر پشته‌ای از ابزارهای هوش مصنوعی حیاتی هستند:

۱. تاریخچه گفتگو به عنوان وضعیت مشترک

در AutoGen، هر جزء یک عامل (Agent) — شبیه کارمندی در یک شرکت که وظیفه مشخصی دارد و فقط از طریق یادداشت با دیگران ارتباط می‌گیرد — است که پیام می‌فرستد و دریافت می‌کند. کلاس پایه ConversableAgent به هر عامل یک نام، یک پیام سیستمی برای تعریف رفتار و قابلیت‌های قابل تنظیم برای ورودی انسانی، اجرای کد و استنتاج اختصاص می‌دهد.

• سازوکار: به‌جای استفاده از یک پایگاه‌داده مجزا برای ردیابی اینکه کدام مرحله به پایان رسیده و چه نتیجه‌ای برگردانده است، AutoGen از خودِ متن گفتگو (Transcript) به عنوان سابقه و رکورد استفاده می‌کند. برای جلوگیری از تداخلات در این وضعیت‌های مشترک، استفاده از چرخه‌های تأیید اتمیک راهکاری مؤثر برای جلوگیری از پاک‌شدن ناخواسته داده‌هاست.
• مزیت: هر عاملی می‌تواند هر آنچه پیش از خود رخ داده را بخواند. عیب‌یابی ساده می‌شود زیرا تنها شامل خواندن لاگی است که از قبل وجود دارد. همچنین افزودن یک عامل جدید نیازی به تغییر در ساختار (Schema) پایگاه‌داده ندارد.
• هزینه: با رشد متن گفتگو در طول زمان، هزینه مصرف پنجره متنی (Context Window) — مثل میز کاری که هرچه کاغذهای روی آن بیشتر شود، فضای کمتری برای تمرکز باقی می‌ماند — در هر گام افزایش می‌یابد. سیستم‌های سالم، تاریخچه مشترک را به‌طور آگاهانه کوچک و ساختاریافته نگه می‌دارند و اجازه نمی‌دهند خروجی‌های تصادفی عامل‌ها در آن انباشته شود.

۲. مسیریابی به عنوان هسته طراحی

انتخاب گوینده بعدی در این سیستم، یک لایه اضافی روی سیستم نیست، بلکه خودِ سیستم است. این ساختار از حلقه‌های ساده دو-عاملی (رفت و برگشتی) تا چت‌های گروهی پیچیده که در آن یک عامل مدیر (Manager Agent) بر اساس متن گفتگو، گوینده بعدی را انتخاب می‌کند، گسترش می‌یابد. شما همچنین می‌توانید توابع سفارشی را برای مسیریابی بر اساس قوانین خاص خود پیاده کنید. در تکامل این ساختارها، رانتایم‌های بادوام در حال جایگزینی حلقه‌های ساده هستند تا پایداری سیستم در جریان‌های کاری طولانی تضمین شود.

• موازنه: هر بار که یک مدل تصمیم می‌گیرد چه کسی صحبت کند، یک فراخوانی استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — اضافه می‌شود که باعث افزایش تأخیر، هزینه و ایجاد منبعی از عدم قطعیت (Nondeterminism) در جریان کنترل می‌شود.
• راهبرد: از مسیریابی توسط مدل‌های زبانی (LLM Routing) فقط زمانی استفاده کنید که وظیفه نیازمند قضاوت درباره محتوای مبهم باشد. اگر می‌توانید قانون مسیریابی را به زبان ساده بنویسید، آن را به صورت یک دستور شرطی (Switch Statement) کدنویسی کنید. این کار همان نتیجه را به‌صورت رایگان و با ثبات کامل ارائه می‌دهد.

۳. تخصیص مدل مجزا برای هر عامل

یکی از اثرگذارترین تغییرات اقتصادی، اختصاص مدل‌های مختلف به عامل‌های مختلف است. این رویکرد بهره‌وری را بسیار بیشتر از تنظیم پرامپت (Prompt Tuning) افزایش می‌دهد.

• لایه‌بندی مدل‌ها: از مدل‌های پیشرو (Frontier) برای تک‌مرحله‌ای که نیازمند استدلال عمیق است استفاده کنید. برای کارهای مسیریابی، فرمت‌بندی، استخراج داده و خلاصه‌سازی، از مدل‌های کوچک و ارزان بهره ببرید.
• حفاظت از بودجه: اکثر گام‌ها در یک جریان کاری صرفاً برای شکل دادن به داده‌ها جهت مرحله بعدی هستند. پرداخت هزینه‌های مدل‌های پیشرو برای این وظایف، همان جایی است که بودجه‌های پروژه‌های چندعاملی به‌طور نامحسوس تمام می‌شود.
• استواری زیرساخت: لایه استنتاج AutoGen مواردی مثل کشینگ (Caching)، مدیریت نرخ درخواست‌ها (Rate Limiting)، ردیابی هزینه و جایگزینی خودکار (Automatic Fallback) بین ارائه‌دهندگان مختلف را مدیریت می‌کرد. این امر تضمین می‌کرد که اگر یک ارائه‌دهنده «بعدازظهر بدی» داشت (اختلال داشت)، کل سیستم کرش نکند. این لیست به عنوان یک چک‌لیست حیاتی برای ارزیابی هر چارچوب جایگزین عمل می‌کند تا ببینیم آیا می‌تواند در برابر خطای 429 (Too Many Requests) دوام بیاورد یا خیر.

۴. مرز اجباری اجرا

این چارچوب به‌طور سخت‌گیرانه بین AssistantAgent (که استدلال می‌کند و کد می‌نویسد) و UserProxyAgent (که کد را در یک محیط ایزوله یا سندباکس اجرا می‌کند و ورودی انسان را منتقل می‌کند) تفکیک قائل می‌شود.

• مکانیزم کنترل: عامل کاربر (UserProxyAgent) طوری تنظیم می‌شود که هر اقدام را تأیید کند، برخی را بپذیرد یا کاملاً به‌صورت خودکار عمل کند.
• مزایای امنیتی: جداسازی نویسنده از اجراکننده، یک نقطه مرکزی برای دروازه تأیید و سندباکس ایجاد می‌کند. این کار از پراکندگی تدابیر امنیتی در تعریف هر عامل، جایی که امکان حسابرسی (Audit) آن‌ها وجود ندارد، جلوگیری می‌کند.
• انعطاف عملیاتی: خودمختاری به یک مقدار تنظیمات (Configuration Value) تبدیل می‌شود، نه بازنویسی کد. توسعه‌دهنده می‌تواند سیستم را با تأیید کامل انسانی عرضه کند، دو هفته رفتار آن را نظارت کند و سپس برای دسته‌های خاصی که اعتماد کسب کرده‌اند، دروازه تأیید را باز کند.

این تحول نشان می‌دهد که «جنگ چارچوب‌ها» در حال تثبیت است. برندگان کسانی نخواهند بود که دستورات وارد کردن (Imports) یک کتابخانه خاص را حفظ کرده‌اند، بلکه کسانی هستند که مفاهیم زیربنایی اجرای ایزوله، ارکستراسیون چت گروهی و مسیریابی مدل‌محور را درک می‌کنند.

برای توسعه‌دهنده، این بدان معناست که پشته تولیدی (Production Stack) شما در آتش نمی‌سوزد، اما مسیر مهاجرت اکنون روشن است. هدف این است که یادگیری سطح API را متوقف کنید و یادگیری الگوهای ارکستراسیونی را آغاز کنید که حتی پس از اعلان‌های منسوخ شدن (Deprecation Notices) نیز باقی می‌مانند.

گام بعدی شما

• اگر پروژه جدیدی را امروز آغاز می‌کنید، توصیه می‌شود مستقیماً بر روی Microsoft Agent Framework بسازید و از تاریخچه AutoGen به عنوان نقشه‌ای برای درک دلیل طراحی جدید استفاده کنید.
• معماری پروژه‌های فعلی خود را بر اساس تفکیک «نویسنده» و «اجراکننده» بازبینی کنید تا امنیت سیستم تضمین شود.
• برای کاهش هزینه‌ها، مدل‌های کوچک (SLM) را جایگزین مدل‌های گران‌قیمت در مراحل مسیریابی و فرمت‌بندی کنید.

برای کسانی که به دنبال جزئیات بیشتر در مورد فراخوانی ابزارها (Tool Calling)، استقرار و مقایسه چارچوب‌ها هستند، گزارش کامل در Auto Learning Agents در دسترس است. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.