بسیاری از توسعهدهندگان هنگام ساخت سیستمهای چندایجنت با فریمورکهای متداول، به بنبست معماری همگام برخورد میکنند: بروز یک خطا در ابزار یا پاسخ یک مدل، کل پشتهی فراخوانی را از کار میاندازد و افزودن همزمانی نیازمند بازنویسیهای پیچیده است. مدل اکتور (Actor Model) این چالش را با جداسازی حافظه و تبدیل ارتباطات به پیامهای ناهمگام حل میکند؛ الگویی بنیادین که در بازطراحی فریمورکهایی مانند AutoGen v0.4 به هستهی اصلی ارکستراسیون بدل شده است.
درک این الگو از این جهت حیاتی است که ساختار سنتی زنجیرهای جای خود را به سیستمهای تابآور میدهد. در مدل اکتور، هر ایجنت وضعیت خصوصی و صندوق دریافت خود را دارد و کرش کردن یک بخش، به معنای توقف کل چرخه نخواهد بود؛ قابلیتی که هم در طراحی رانتایمهای محلی و هم در سیستمهای توزیعشده مزیت بزرگی محسوب میشود.
کد پیادهسازی این درس صرفاً با کتابخانهی استاندارد Python اجرا میشود و برای درک مفاهیم آن به سختافزار خاص یا پردازش ابری نیازی ندارید؛ بنابراین پیادهسازی آن روی سیستمهای شخصی بدون هیچ پیچیدگی جانبی ممکن است.
ایجنتها در نقش اکتور (Actor): تبادل ناهمگام پیام، هندلرهای رویدادمحور، تفکیک خطا (fault isolation) و همزمانی طبیعی. بخش تحقیقات مایکروسافت در ژانویه 2025 با معرفی AutoGen v0.4، ارکستراسیون ایجنتها را بر پایهی این مدل بازطراحی کرد. این فریمورک اکنون در حالت نگهداری (maintenance mode) قرار دارد و Microsoft Agent Framework (پیشنمایش عمومی اکتبر 2025) جانشین عملیاتی آن است.
اهداف یادگیری
- مدل اکتور را تشریح کنید: ایجنتها در نقش اکتور، پیامها بهعنوان تنها روش ارتباط بینفرایندی (IPC) و تفکیک خطا بهازای هر اکتور.
- سه لایهی API در AutoGen v0.4 یعنی Core، AgentChat و Extensions و کاربرد هرکدام را نام ببرید.
- توضیح دهید چرا جداسازی تحویل پیام از پردازش آن، تفکیک خطا و همزمانی طبیعی ایجاد میکند.
- یک محیط اجرای (runtime) اکتور را با کتابخانهی استاندارد Python پیادهسازی کنید و فرایند بازبینی کد دورایجنت را روی آن اجرا کنید.
مسئله چیست؟
بیشتر فریمورکهای ایجنت همگام هستند: یک ایجنت تولید میکند و دیگری در همان پشتهی فراخوانی (call stack) مصرف میکند. بروز خطا کل پشته را میخواباند، همزمانی بهصورت وصلهپینهای اضافه شده است و توزیعشدگی مستلزم بازنویسی کامل کد خواهد بود.
پاسخ AutoGen v0.4: مدل اکتور. هر ایجنت اکتوری با یک صندوق دریافت (inbox) اختصاصی است. پیامها تنها شیوهی تعاملاند. محیط اجرا تحویل پیام را از پردازش آن جدا میکند. خطاها درون همان یک اکتور مهار میشوند. همزمانی ماهیتی بومی دارد و توزیعشدگی صرفاً تغییر بستر انتقال (transport) است.
مفهوم
اکتورها
یک اکتور شامل این اجزاست:
- وضعیت اختصاصی (که هرگز مستقیماً از بیرون دستکاری نمیشود).
- یک صندوق دریافت (صف پیام).
- یک هندلر:
receive(message) -> effectsکه اثرهای جانبی آن میتواند «پاسخ دادن»، «ارسال به اکتور دیگر»، «ساخت اکتور جدید»، «بهروزرسانی وضعیت» یا «توقف خود» باشد.
دو اکتور نمیتوانند حافظهی مشترک داشته باشند؛ تنها راه تعامل، ارسال پیام است.
سه لایهی API
AutoGen v0.4 سطح دسترسی خود را به سه بخش تقسیم میکند:
- Core: فریمورک سطح پایین اکتور شامل
AgentRuntime،Agent،MessageوTopic. تبادل ناهمگام پیام و مبتنی بر رویداد. - AgentChat: رابط سطح بالای وظیفهمحور (جایگزین ConversableAgent در نسخهی v0.2) شامل
AssistantAgent،UserProxyAgent،RoundRobinGroupChatوSelectorGroupChat. - Extensions: یکپارچهسازیها با OpenAI، Anthropic، Azure، ابزارها و حافظه.
چرا جداسازی پیام مهم است؟
در مدل نسخهی v0.2، فراخوانی agent_a.chat(agent_b) بهشکل همگام، agent_a را تا زمان بازگشت پاسخ از agent_b مسدود میکرد. در v0.4، متد send(agent_b, msg) پیام را در صندوق دریافت agent_b میگذارد و بلافاصله برمیگردد. محیط اجرا بعداً پیام را تحویل میدهد. این سازوکار سه دستاورد دارد:
- تفکیک خطا. از کار افتادن ایجنت B باعث توقف ایجنت A نمیشود؛ محیط اجرا خطا را درون هندلر B مهار میکند و دربارهی ادامهی کار (لاگ، تلاش مجدد یا ارسال به صف پیامهای پردازشنشده) تصمیم میگیرد.
- همزمانی طبیعی. پیامهای زیادی میتوانند همزمان در جریان باشند و اکتورها پیامهای صندوق دریافت خود را همزمان پردازش میکنند.
- آمادگی برای توزیعشدگی. چه اکتور درون یک فرایند باشد و چه روی میزبانی دیگر، صندوق دریافت و بستر انتقال انتزاع کاملاً یکسانی دارند.
توپولوژیها
- RoundRobinGroupChat: ایجنتها نوبت به نوبت و در چرخهای ثابت پیش میروند.
- SelectorGroupChat: یک ایجنت انتخابکننده، براساس محتوای گفتوگو تصمیم میگیرد چه کسی نوبت بعدی را در دست بگیرد.
- Magentic-One: تیم مرجع چندایجنت برای وبگردی، اجرای کد و کار با فایل که بر پایهی AgentChat ساخته شده است.
مشاهدهپذیری
پشتیبانی از OpenTelemetry توکار است. هر پیام یک اسپن (span) ثبت میکند و فراخوانیهای ابزار (tool calls) طبق قراردادهای معنایی (semantic conventions) مربوط به GenAI در OTel سال 2026 (درس 23)، ویژگیهای gen_ai.* را بههمراه دارند.
وضعیت: حالت نگهداری
اوایل 2026: AutoGen v0.7.x برای کارهای پژوهشی و ساخت نمونهی اولیه پایدار است. مایکروسافت توسعهی فعال را به Microsoft Agent Framework منتقل کرده که جانشین آمادهی تولید آن است (پیشنمایش عمومی در 1 اکتبر 2025؛ انتشار نسخهی نهایی 1.0 GA برای اواخر سهماههی اول 2026 هدفگذاری شده بود). الگوهای AutoGen بهخوبی به فریمورک جدید منتقل میشوند، چون مدل اکتور ایدهای ماندگار است.
پیادهسازی
فایل code/main.py یک محیط اجرای اکتور را با کتابخانهی استاندارد پیادهسازی میکند:
Message: محمولهی نوعدار باsender،recipient،topicوbody.Actor: کلاس انتزاعی با متدreceive(message, runtime).Runtime: حلقهی رویداد با صف مشترک، تحویل پیام و تفکیک خطا.- دموی دو اکتوری:
ReviewerAgentکد را بررسی میکند،ChecklistAgentچکلیست را پیش میبرد و تا رسیدن به توافق به تبادل پیام ادامه میدهند.
اجرایش کنید:
python3 code/main.py
ردگیری محاسبات (trace) روند تحویل پیام، خطای شبیهسازیشده در یکی از اکتورها بدون کرش کردن دیگری و در نهایت توافق روی یک نتیجهی مشترک را نشان میدهد.
کاربردها
- AutoGen v0.4/v0.7 (نگهداری): پایدار برای پژوهش، نمونهسازی اولیه و الگوهای چندایجنت.
- Microsoft Agent Framework: جانشین عملیاتی (پیشنمایش عمومی اکتبر 2025)؛ همان ایدههای مدل اکتور با یک API بهروزرسانیشده.
- توپولوژی Swarm در LangGraph (درس 13): الگویی مشابه از طریق دستبهدست کردن با ابزارهای مشترک.
- محیط اجرای اختصاصی اکتور: مناسب وقتهایی که به بستر انتقال خاصی (مثل NATS، RabbitMQ یا gRPC) نیاز دارید.
خروجی آماده
فایل outputs/skill-actor-runtime.md یک محیط اجرای مینیمال اکتور بههمراه قالب تیم (RoundRobin یا Selector) برای وظیفهی چندایجنت مدنظر شما تولید میکند.
تمرینها
- یک صف پیامهای پردازشنشده (dead-letter queue) بسازید: وقتی یک هندلر با خطا متوقف شد، پیام ناموفق را برای بازبینی انسانی کنار بگذارید. در پروژهی کوچک شما چقدر پیش میآید که پیامی وارد این صف شود؟
- ساختار
SelectorGroupChatرا پیادهسازی کنید: یک اکتور انتخابکننده بسازید که با توجه به وضعیت گفتوگو، مشخص کند چه کسی باید پیام بعدی را پردازش کند. - بستر انتقال توزیعشده اضافه کنید: صف درونفرایندی را با یک سرور JSON-over-HTTP عوض کنید تا اکتورها بتوانند در فرایندهای جداگانه اجرا شوند.
- بهازای هر پیام یک اسپن OTel (یا ساختار سادهسازیشدهی معادل) متصل کنید. ویژگیهای
gen_ai.agent.nameوgen_ai.operation.nameرا مطابق درس 23 صادر کنید. - پست معماری AutoGen v0.4 را بخوانید. کد نمونهی خود را به API واقعی
autogen_coreمنتقل کنید. از چه نکاتی صرفنظر کرده بودید که در محیط عملیاتی واقعاً اهمیت دارند؟
اصطلاحات کلیدی
| اصطلاح | در گفتوگوها | معنای دقیق فنی |
|---|---|---|
| اکتور (Actor) | «ایجنت» | وضعیت اختصاصی + صندوق دریافت + هندلر؛ بدون حافظهی مشترک |
| پیام (Message) | «رویداد» | محمولهی دادهای نوعدار؛ تنها روش تعامل اکتورها |
| صندوق دریافت (Inbox) | «صندوق پستی» | صف پیامهای در انتظارِ هر اکتور |
| محیط اجرا (Runtime) | «میزبان ایجنت» | حلقهی رویدادی که پیامها را مسیریابی و خطاها را تفکیک میکند |
| تاپیک (Topic) | «کانال» | مسیر انتشار-اشتراکِ نامگذاریشده بین اکتورها |
| تفکیک خطا (Fault isolation) | «بگذار کرش کند» | از کار افتادن یک اکتور بقیه را متوقف نمیکند |
| RoundRobinGroupChat | «تیم با نوبت چرخشی ثابت» | ایجنتها نوبت به نوبت و منظم پیش میروند |
| SelectorGroupChat | «تیم با مسیریابی براساس بافتار» | انتخابکننده تعیین میکند چه کسی نوبت بعدی باشد |
| Magentic-One | «تیم مرجع» | تیم چندایجنت برای وب، کد و فایلها |
مطالعهی بیشتر
- AutoGen v0.4, Microsoft Research — یادداشت بازطراحی
- LangGraph overview — رویکرد جایگزین مبتنی بر گراف
- OpenTelemetry GenAI semantic conventions — اسپنهایی که AutoGen بهصورت پیشفرض صادر میکند
