دنیای توسعه‌ی هوش مصنوعی هر چند ماه یک‌بار با معرفی یک فریم‌ورک چندایجنت جدید تکان می‌خورد. از AutoGen و CrewAI گرفته تا LangGraph و OpenAI Swarm، هر ابزاری با واژه‌سازی و ادعای کشف بهترین معماری به بازار می‌آید. یادگیری این فریم‌ورک‌ها به‌صورت جداگانه، توسعه‌دهندگان را دچار خستگی و سردرگمی میکند، چرا که ظاهر APIها و تعاریف مفاهیمی مانند «حافظه» یا «نحوه چرخش نوبت» در هرکدام به شکلی نام‌گذاری شده است.
اگر لایه‌ی بازاریابی و ظاهر کدهای این ابزارها را کنار بزنید، متوجه می‌شوید که در پشت‌صحنه تنها چهار جزء بنیادی (Primitive) وجود دارند: ایجنت (Agent)، دستبهدستکردن (Handoff)، وضعیت مشترک (Shared State) و هماهنگکننده (Orchestrator). تمام این فریم‌ورک‌ها صرفاً تنظیماتی گوناگون روی همین چهار محور هستند و در عمل چیز متفاوتی اختراع نکرده‌اند.
این درس به شما کمک میکند با ساخت این چهار جزء از صفر در قالب کدهای پایتون استاندارد، سازوکار واقعی سیستمهای چندایجنت را عمیقاً درک کنید. بعد از این درس، به‌جای سردرگمی در مستندات ابزارهای جدید، می‌توانید هر فریم‌ورک تازه‌ای را در کمتر از یک پاراگراف از نظر معماری تحلیل و گزینه‌ی متناسب با پروژه‌ی خود را انتخاب کنید.
چهار جزء سازنده (Primitive)، نه چیزی بیشتر — ایجنت، دستبهدستکردن (Handoff)، وضعیت مشترک و هماهنگکننده (Orchestrator) — یک فضای طراحی چهاربُعدی را شکل می‌دهند. فریم‌ورک‌های چندایجنت اصلی که در سال 2026 عرضه می‌شوند (AutoGen ،LangGraph ،CrewAI ،OpenAI Agents SDK و Microsoft Agent Framework) هرکدام نقطه‌ای درون همین فضا هستند. در این درس، این اجزا را از صفر می‌سازیم، یک سیستم اسباب‌بازی را روی هر چهار جزء اجرا می‌کنیم و سپس هر فریم‌ورک بزرگ را روی همین محورها نگاشت می‌دهیم تا بتوانید با خواندن فقط یک پاراگراف، هر ابزار جدیدی را تحلیل کنید.
صورت‌مسئله
هر شش ماه یک‌بار فریم‌ورک چندایجنت جدیدی روانه‌ی بازار می‌شود: AutoGen در سال 2023، CrewAI در سال 2024، LangGraph و OpenAI Swarm در سال 2024، Google ADK در آوریل 2025 و نسخه نهایی مایکروسافت (Microsoft Agent Framework RC) در فوریه 2026. بیانیه‌ی مطبوعاتی هرکدام ادعا میکند که «انتزاع درست» را یافته است.
اگر بخواهید آن‌ها را یکی‌یکی یاد بگیرید، فرسوده می‌شوید. ساختار APIها فرق دارد؛ مستندات سرِ تعریف «ایجنت» هم‌نظر نیستند؛ یکی حافظه‌ی مشترک را «تخته‌سیاه» (Blackboard) می‌نامد، دیگری «استخر پیام» (Message Pool) و سومی اسمش را «StateGraph» می‌گذارد. کم‌کم شک می‌کنید که شاید کل این حوزه فقط درگیر سردرگمی و کارهای تکراری بیهوده است.
اما این‌طور نیست. زیر لایه‌ی تبلیغات، این چهار جزء سازنده کاملاً پایدارند. آن‌ها را یک‌بار یاد بگیرید تا بتوانید هر فریم‌ورک جدیدی را با خواندن یک پاراگراف درک کنید.
مفهوم
چهار جزء سازنده
- ایجنت (Agent) — یک پرامپت سیستم به‌همراه فهرستی از ابزارها. بی‌وضعیت (Stateless) است؛ هر بار اجرا با پرامپت سیستم و تاریخچه‌ی فعلی پیامها شروع می‌شود.
- دستبهدستکردن (Handoff) — انتقال ساختاریافته‌ی کنترل از یک ایجنت به ایجنت دیگر. از نظر فنی، فراخوانی ابزاری است که ایجنت جدیدی را برمی‌گرداند یا یالی در گراف است که از یک شرط پیروی میکند.
- وضعیت مشترک (Shared State) — هر ساختار داده‌ای که بیش از یک ایجنت بتواند آن را بخواند (و گاهی بنویسد): استخر پیام، تخته‌سیاه، پایگاه داده کلید-مقدار، یا حافظه‌ی برداری.
- هماهنگکننده (Orchestrator) — هر سازوکاری که تعیین میکند چه کسی نوبت بعدی صحبت است. گزینه‌ها: یک گراف صریح (قطعی)، یک مدل زبانی برای انتخاب گوینده (انعطاف‌پذیر)، فراخوانی Handoff توسط آخرین گوینده (الگوی OpenAI Swarm)، یا یک اسکژولر روی صف کارها (معماری ازدحام / Swarm).
کل فضای طراحی همین است. هر فریم‌ورک صرفاً مقادیر پیش‌فرضی را برای هر محور برمی‌گزیند؛ باقی موارد فقط ظاهر کدنویسی (Syntax) است.
نگاشت فریم‌ورک‌های سال 2026 روی این فضا
| فریم‌ورک | ایجنت | دستبهدستکردن (Handoff) | وضعیت مشترک | هماهنگکننده |
|---|---|---|---|---|
| OpenAI Swarm / Agents SDK | Agent(instructions, tools) |
ابزار، یک Agent برمی‌گرداند | بر عهده‌ی فراخواننده است | فراخوانی بعدی Handoff توسط مدل زبانی |
| AutoGen v0.4 / AG2 | ConversableAgent |
انتخاب‌کننده‌ی گوینده در GroupChat | استخر پیام | تابع انتخاب‌کننده (مدل زبانی یا Round-Robin) |
| CrewAI | Agent(role, goal, backstory) |
Process.Sequential / Hierarchical |
زنجیره‌کردن خروجی‌های Task | مدل زبانی مدیر یا ترتیب ثابت |
| LangGraph | تابع گره (Node) | یال گراف + شرط | کاهنده‌ی (Reducer) گراف StateGraph |
خودِ گراف، به‌صورت قطعی |
| Microsoft Agent Framework | ایجنت + الگوهای ارکستراسیون | وابسته به الگو | ترد / کانتکست | وابسته به الگو |
| Google ADK | ایجنت + کارت A2A | وظیفه‌ی A2A | دست‌سازه‌های (Artifacts) A2A | میزبان تصمیم می‌گیرد |
تفاوت‌های ظاهری بسیار بزرگ به نظر می‌رسند. در باطن، با همان چهار پیچ تنظیم روبه‌روییم.
چرا این موضوع اهمیت دارد؟
وقتی این اجزای پایه را بشناسید، مقایسه‌ی فریم‌ورک‌ها به یک چک‌لیست کوتاه تبدیل می‌شود:
- آیا هماهنگکننده برای مسیریابی به مدل زبانی اعتماد میکند (Swarm) یا منطق مسیر را در کد تثبیت میکند (LangGraph)؟
- آیا وضعیت مشترک کل تاریخچه را نگه می‌دارد (GroupChat) یا نمایی پروژکتشده از آن است (کاهنده‌ی StateGraph)؟
- آیا ایجنتها می‌توانند پرامپت یکدیگر را دستکاری کنند (مدیر در CrewAI) یا فقط حقِ دستبهدستکردن را دارند (Swarm)؟
پاسخ این سه پرسش مشخص میکند در 80% سناریوها کدام ابزار برای مسئله‌ی شما مناسب است. دیگر وقت خود را برای گشتن به دنبال «بهترین فریم‌ورک چندایجنت» تلف نمی‌کنید و سراغ محوری می‌روید که واقعاً برایتان مهم است.
دیدگاه کلیدی: بی‌وضعیت بودن اجزا
همهی اجزا به‌جز وضعیت مشترک، بی‌وضعیت هستند. ایجنت تابعی از (پرامپت، ابزارها) است. دستبهدستکردن یک فراخوانی تابع است. هماهنگکننده همان اسکژولر است. تنها بخش حالت‌دار در کل سیستم، همان وضعیت مشترک است. همهی باگ‌های جذاب هم دقیقاً همین‌جا شکل می‌گیرند: مسموم‌سازی حافظه (Memory Poisoning در درس 15)، رعایت ترتیب پیامها، نسخه‌بندی داده‌ها و رقابت در نوشتن (Write Contention).
فریم‌ورک‌هایی که وضعیت مشترک را پنهان می‌کنند (مانند Swarm)، مسئله را به دوش فراخواننده می‌اندازند. فریم‌ورک‌هایی که آن را متمرکز می‌کنند (چک‌پوینت در LangGraph، استخر پیام در AutoGen)، امکان بازرسی وضعیت را فراهم می‌سازند، اما هزینه‌ی هماهنگی را به پیاده‌سازی خودِ وضعیت مشترک منتقل می‌کنند.
کالبدشکافی تک‌تک اجزا
ایجنت
Agent = (system_prompt, tools, model, optional_name)نه حافظه‌ای دارد و نه وضعیتی. دو ایجنت با پرامپت سیستم و ابزارهای یکسان، کاملاً قابل جایگزینی با یکدیگرند. هر چیزی که شبیه وضعیت اختصاصی برای یک ایجنت به نظر می‌رسد، در عمل درون وضعیت مشترک یا پروتکل دستبهدستکردن قرار دارد.
دستبهدستکردن (Handoff)
Handoff = (from_agent, to_agent, reason, payload)سه روش پیاده‌سازی دست بالا را دارند:
- خروجی تابع (Function Return) — ابزار، ایجنت بعدی را برمی‌گرداند. این الگوی OpenAI Swarm است. ایجنتها منطق مسیریابی را در اسکیمای ابزار (Tool Schema) خود حمل می‌کنند.
- یال گراف (Graph Edge) — رویکرد LangGraph. یال‌ها به‌صورت اعلانی تعریف می‌شوند. مدل زبانی مقداری تولید میکند و یک شرط، گره بعدی را برمی‌گزیند.
- انتخاب گوینده (Speaker Selection) — الگوی GroupChat در AutoGen. یک تابع انتخاب‌کننده (که گاهی خودش فراخوانی یک مدل زبانی است) استخر پیام را بررسی میکند و تصمیم می‌گیرد چه کسی نفر بعدی باشد.
وضعیت مشترک
SharedState = { messages: [], artifacts: {}, context: {} }در ساده‌ترین حالت، فهرستی از پیام‌هاست. اما اغلب فراتر از این می‌رود: دست‌سازه‌های ساختاریافته (خروجی Task در CrewAI)، کانتکست‌های نوع‌دار (کاهنده‌ها در LangGraph)، یا حافظه‌های خارجی (MCP، پایگاه داده‌های برداری).
دو نوع توپولوژی اصلی داریم: استخر کامل (Full Pool) که در آن هر ایجنت همهی پیامها را می‌بیند، و پروژکتشده (Projected) که در آن ایجنتها نمایی متناسب با نقش خود دریافت می‌کنند. استخرهای کامل ساده‌اند، اما به‌سختی مقیاس می‌پذیرند. استخرهای پروژکتشده به‌خوبی مقیاس می‌پذیرند، ولی نیازمند طراحی اولیه‌ی اسکیما هستند.
هماهنگکننده
Orchestrator = ({state, last_speaker}) -> next_agentچهار مدل پیاده‌سازی:
- ایستا (Static) — گراف در زمان ساخت به‌شکل ثابت تعریف می‌شود (حالت قطعی در LangGraph، فرایند ترتیبی در CrewAI).
- انتخاب‌شده توسط مدل (LLM-selected) — یک مدل زبانی استخر پیام را می‌خواند و گوینده‌ی بعدی را انتخاب میکند (AutoGen و فرایند سلسله‌مراتبی در CrewAI).
- هدایت‌شده با Handoff — ایجنت فعلی با صدا زدن یک ابزارِ Handoff خودش تصمیم می‌گیرد (Swarm).
- هدایت‌شده با صف (Queue-driven) — ایجنتها وظایف را از یک صف مشترک برمی‌دارند و گوینده‌ی بعدی صریحی در کار نیست (معماری‌های ازدحام / Swarm و Matrix).
چه چیزهایی میان فریم‌ورک‌ها تغییر میکند؟
وقتی این چهار جزء تثبیت شوند، سایر تصمیم‌های طراحی صرفاً این موارد خواهند بود:
- استراتژی حافظه — چک‌پوینت‌گیری ناپایدار در برابر ماندگار (چک‌پوینتر در LangGraph).
- مرزهای ایمنی — تعیین اینکه چه کسی اجازه‌ی تأیید فرایند دستبهدستکردن را دارد (انسان در چرخه).
- محاسبه‌ی هزینه‌ها — سهمیه‌ی توکن برای هر ایجنت.
- مشاهده‌پذیری (Observability) — ردگیری محاسبات در دست‌به‌دست‌کردن‌ها و ذخیره‌سازی وضعیت برای بازپخش.
همهی این‌ها روی پایه‌ی همان اجزای اصلی پیاده‌سازی می‌شوند و هیچ‌کدام جزء جدیدی به حساب نمی‌آیند.
پیاده‌سازی از صفر
فایل code/main.py این چهار جزء را در حدود 150 خط پایتون خام و فقط با کتابخانه‌ی استاندارد پیاده میکند. در این مثال مدل زبانی واقعی صدا زده نمی‌شود؛ رفتار هر ایجنت با یک منطق اسکریپتی شبیه‌سازی شده تا تمرکز روی ساختار هماهنگی باقی بماند.
این فایل این بخش‌ها را خروجی می‌دهد:
Agent— یک دیتاکلاس شامل نام، پرامپت سیستم، ابزارها و تابع منطق تصمیم‌گیری (Policy).Handoff— تابعی که یک ایجنت جدید برمی‌گرداند.SharedState— یک استخر پیامِ امن برای چندتردی (Thread-safe).Orchestrator— سه گونه‌ی مختلف:StaticOrchestrator،HandoffOrchestratorو نسخه‌ی شبیه‌سازی‌شده‌یLLMSelectorOrchestrator.
این دمو یک پایپ‌لاین سه‌ایجنتی یکسان (تحقیق ← نگارش ← بازبینی) را روی هر سه مدل هماهنگکننده اجرا میکند و در پایان استخر پیام را چاپ میکند. خواهید دید تفاوت خروجی‌ها صرفاً به خاطر این است که چه کسی نفر بعدی را تعیین میکند؛ خودِ ایجنتها و وضعیت مشترک در تمام اجراها کاملاً یکسان هستند.
اجرای کد:
python3 code/main.pyخروجی مورد انتظار: سه بار اجرای هماهنگکننده، هر بار با یک الگو. در پایان هر اجرا، وضعیت نهایی استخر پیام چاپ می‌شود. اگر ایجنت محقق تشخیص دهد که کارش زودتر تمام شده، در اجرای هدایت‌شده با Handoff ایجنت‌های کمتری فراخوانی می‌شوند؛ این بازتاب کوچکی از موازنه‌ی هزینه‌ها و مزایای مسیریابی با مدل زبانی است.
استفاده از ابزارهای واقعی
فایل outputs/skill-primitive-mapper.md مهارتی است که کدهای یک پروژه یا مستندات هر فریم‌ورک چندایجنت را می‌خواند و نگاشت آن را روی این چهار جزء برمی‌گرداند. پیش از اینکه وقت زیادی برای خواندن مستندات یک فریم‌ورک تازه منتشرشده بگذارید، این مهارت را روی آن اجرا کنید تا در یک پاراگراف سازوکارش را بشناسید.
استقرار و بهره‌برداری
قبل از آوردن فریم‌ورک جدیدی به کار، نگاشت اجزای چهارگانه را برایش بنویسید. اگر نتوانستید، یا مستندات آن ناقص است یا فریم‌ورک ادعا میکند جزء پنجمی اختراع کرده است (که بسیار بعید است — فقط نوع متفاوتی از وضعیت مشترک را بررسی کنید که قبلاً ندیده‌اید).
این نگاشت را در سند معماری سیستم خود سنجاق کنید. وقتی عضو جدیدی به تیم ملحق شد، قبل از مستندات API، این نگاشت را در اختیارش بگذارید. هنگام ارتقای نسخه‌های فریم‌ورک هم، تغییرات این نگاشت را مقایسه کنید، نه لیست طولانی لاگ تغییرات را.
تمرین‌ها
- اسکریپت
code/main.pyرا سه بار با منطق‌های تصمیم‌گیری مختلف برای ایجنتها اجرا کنید. بررسی کنید انتخاب هماهنگکننده چطور اجرای ایجنتها را تغییر می‌دهد. - نوع چهارمی از هماهنگکننده را پیاده کنید: مدلی مبتنی بر صف که در آن ایجنتها برای دریافت کار به وضعیت مشترک سر می‌زنند. چه نوع بن‌بستی (Deadlock) ممکن است رخ دهد و چطور آن را شناسایی می‌کنید؟
- راهنمای شروع سریع LangGraph را (https://docs.langchain.com/oss/python/langgraph/workflows-agents) مطالعه و آن را به این چهار جزء ترجمه کنید. کدام انتزاع‌های LangGraph نگاشت 1 به 1 دارند و کدام‌ها صرفاً ابزارهای کمکی و ساده‌سازند؟
- نمونه‌کد OpenAI Swarm را (https://developers.openai.com/cookbook/examples/orchestrating_agents) بخوانید. مشخص کنید Swarm کار با کدام‌یک از این چهار جزء را از همه ارگونومیک‌تر کرده و مسئولیت کدام جزء را تماماً بر دوش فراخواننده گذاشته است.
- یکی از فریم‌ورک‌های جدول را پیدا کنید که وضعیت مشترک را کاملاً پنهان میکند. توضیح دهید وقتی ایجنتها بخواهند در طول فرایندهای Handoff بدون بازخوانی تاریخچه با هم هماهنگ شوند، چه مشکلی به وجود می‌آید.
اصطلاحات کلیدی
| اصطلاح | در گفت‌وگوهای عامیانه | معنای واقعی و فنی |
|---|---|---|
| ایجنت (Agent) | «مدل زبانی با ابزار» | سه‌گانه‌ی (system_prompt, tools, model). بی‌وضعیت. |
| دستبهدستکردن (Handoff) | «انتقال کنترل» | فراخوانی ساختاریافته‌ای که نام ایجنت بعدی و بار داده‌ی (Payload) اختیاری را مشخص میکند. سه روش پیاده‌سازی: خروجی تابع، یال گراف، انتخاب گوینده. |
| وضعیت مشترک (Shared state) | «حافظه» / «کانتکست» | تنها بخش حالت‌دار در یک سیستم چندایجنت. به شکل استخر پیام یا تخته‌سیاه. |
| هماهنگکننده (Orchestrator) | «هماهنگکننده» | سازوکاری که تعیین میکند چه کسی در مرحله‌ی بعد اجرا شود: گراف ایستا، انتخاب‌کننده‌ی مبتنی بر مدل، هدایت‌شده با Handoff یا بر پایه‌ی صف. |
| جزء سازنده (Primitive) | «انتزاع» | یکی از چهار محوری که هر فریم‌ورک پارامترهایش را تعیین میکند؛ نه یک ویژگی اختصاصی در فریم‌ورک. |
| استخر پیام (Message pool) | «تاریخچه‌ی چت مشترک» | نگهداری تمام تاریخچه در وضعیت مشترک. تحلیل رفتار آن آسان است، اما به‌سختی مقیاس می‌پذیرد. |
| وضعیت پروژکتشده (Projected state) | «نمای محدود» | دیدی اختصاصی و محدود به نقش از وضعیت مشترک. به‌خوبی مقیاس می‌پذیرد، اما نیازمند طراحی اسکیما است. |
| انتخاب گوینده (Speaker selection) | «نوبت صحبت چه کسی است» | الگویی در هماهنگکننده که در آن یک تابع (اغلب یک مدل زبانی) ایجنت بعدی را از میان جمع انتخاب میکند. |
برای مطالعه‌ی بیشتر
- راهنمای جامع OpenAI: هماهنگی میان ایجنتها — روتین‌ها و دست‌به‌دست‌کردن‌ها — شفاف‌ترین توضیح درباره‌ی ارکستراسیون مبتنی بر Handoff.
- مستندات نسخه‌ی پایدار AutoGen — قابلیت GroupChat و سیستم انتخاب گوینده، مرجع اصلی برای هماهنگیِ هدایت‌شده با مدل زبانی است.
- جریان‌های کاری و ایجنتها در LangGraph — ارکستراسیون با یال‌های گراف و استفاده از کاهنده‌ها برای مدیریت وضعیت مشترک.
- معرفی CrewAI — ایجنت‌های مبتنی بر نقش، هدف و داستان پیش‌زمینه، و فرایندهای ترتیبی (Sequential) و سلسله‌مراتبی (Hierarchical).
- پروژه‌ی AG2 (ادامه‌ی جامعه‌محور AutoGen) — مسیر توسعه‌ی فعال AutoGen v0.2، پس از اینکه مایکروسافت v0.4 را وارد فاز نگهداری کرد.