فاز 16 · درس 6

معماری سلسله‌مراتبی ایجنت‌ها و حالات شکست آن

نوع
مفهومی و ساختنی
زمان
حدود 60 دقیقه
زبان‌ها
Python (stdlib)
پیش‌نیاز
فاز 16 · 05 (الگوی ناظر)
یک ساختار هرمی شبکه‌ای شیشه‌ای و معلق با گره‌های متصل به هم که یکی از شاخه‌های میانی آن دچار شکستگی شده و نور در آن منحرف می‌شود
فهرست مطالب
  1. صورت مسئله
  2. مفاهیم پایه
  3. شکل ساختار
  4. نقاط قوت
  5. نقاط ضعف و شکست
  6. سؤال تعیین‌کننده
  7. پیاده‌سازی با فریم‌ورک مبتنی بر نقش
  8. پیاده‌سازی با فریم‌ورک مبتنی بر گراف
  9. پیاده‌سازی عملی
  10. کاربرد در دنیای واقعی
  11. استقرار و تحویل
  12. تمرین‌ها
  13. اصطلاحات کلیدی
  14. برای مطالعه‌ی بیشتر

در طراحی سیستم‌های چندایجنت (Multi-agent Systems)، وقتی با پروژه‌های پیچیده یا جریان‌های کاری شبیه ساختار سازمانی مواجه می‌شوید، اولین ایده‌ای که به ذهن می‌رسد ایجاد مدیران بالادست و زیردستان تخصصی است. معماری سلسله‌مراتبی تلاش می‌کند چارت سازمانی واقعی را شبیه‌سازی کند؛ اما چالش از جایی آغاز می‌شود که مدل‌های زبانی مانند مدیران انسانی عمل نمی‌کنند و حافظه یا قضاوت پایدار ندارند.

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

الگوی سلسله‌مراتبی (Hierarchical) در واقع همان ناظر تودرتو است: ایجنت‌های مدیر بالادستِ خرده‌مدیرها، و آن‌ها هم بالادستِ کارگران. قابلیت Process.hierarchical در CrewAI نمونه‌ی کلاسیک و کتب درسی این الگو است؛ جایی که یک manager_llm به‌شکل پویا وظایف را واگذار می‌کند و خروجی‌ها را می‌سنجد. معادل آن در LangGraph به‌صورت create_supervisor(create_supervisor(...)) پیاده می‌شود. این الگو زمانی کاملاً طبیعی است که وظیفه‌ی شما بازتاب یک چارت سازمانی واقعی باشد. با این حال، بیشترین احتمال گرفتاری در حلقه‌های باطل مدیریتی (Managerial looping) هم متعلق به همین الگوست؛ وضعیتی که در آن ایجنت‌های مدیر کارها را اشتباه تقسیم می‌کنند، خروجی‌های زیرمجموعه را غلط می‌فهمند یا به توافق نمی‌رسند. در اغلب موارد، الگوی متوالی (Sequential) آن را شکست می‌دهد.

صورت مسئله

وقتی منطق الگوی ناظر جا می‌افتد، گام بدیهی بعدی این است: «چه می‌شود اگر خودِ کارگران هم ناظر باشند؟» تیم‌ها زیرتیم دارند؛ شرکت‌ها از دپارتمان‌هایی تشکیل شده‌اند که خودشان شامل دپارتمان‌های دیگری هستند. معماری‌های سلسله‌مراتبی دقیقاً همین ساختار را بازتاب می‌دهند.

اما مشکل اینجاست: مدیران مبتنی بر مدل زبانی رفتار مشابه مدیران انسانی ندارند. یک مدیر انسانی پیشین‌ها (Priors) و شناخت پایداری از دانسته‌های گزارش‌دهندگانش دارد. در مقابل، یک مدیر مدل زبانی، چارت سازمانی را در هر نوبت گفت‌وگو (Turn) صرفاً بر اساس محتوای کانتکست لحظه‌ای‌اش از نو استدلال و بازسازی می‌کند. کوچک‌ترین انحرافی در آن کانتکست باعث می‌شود کل این درخت وظایف را اشتباه تخصیص دهد.

مفاهیم پایه

شکل ساختار

                 Manager
                 ┌─────┐
                 └──┬──┘
           ┌────────┴────────┐
           ▼                 ▼
       Sub-Mgr A         Sub-Mgr B
       ┌─────┐           ┌─────┐
       └──┬──┘           └──┬──┘
         ┌┴──┬──┐          ┌┴──┐
         ▼   ▼  ▼          ▼   ▼
       W1  W2  W3         W4  W5

هر گره داخلی وظیفه‌ی برنامه‌ریزی، واگذاری کار و ترکیب نتایج را بر عهده دارد. فقط گره‌های برگ کار را انجام می‌دهند.

نقاط قوت

  • نگاشت واضح به ساختار سازمانی. اگر ماهیت وظیفه واقعاً میان‌دپارتمانی باشد («بخش حقوقی سند را بررسی کند، بخش مالی سند را بررسی کند، تیم فنی سند را بررسی کند، سپس خلاصه برای مدیر ارشد آماده شود»)، ساختار سلسله‌مراتبی کاملاً شفاف است.
  • خلاصه‌سازی محلی. هر خرده‌مدیر پیش از آنکه مدیر ارشد خروجی‌ها را ببیند، نتایج تیم خودش را جمع‌بندی می‌کند. بنابراین مدیر ارشد به‌جای دیدن 15 خروجی از کارگران، سه خلاصه‌ی حاصل از خرده‌مدیران را می‌بیند.

نقاط ضعف و شکست

سه حالت شکست (Failure modes) که گزارش‌های ریشه‌یابی خطای سال 2026 مدام پیدا می‌کنند:

  1. خطای تخصیص وظیفه. مدیر هدف اصلی را می‌خواند، در شکستن کار دچار توهم می‌شود و آن را به خرده‌مدیر اشتباه واگذار می‌کند. از آنجا که خرده‌مدیر وظیفه‌ی محول‌شده را بدون چون‌وچرا انجام می‌دهد، این خطا تازه در مرحله‌ی ترکیب نهایی در بالاترین سطح خود را نشان می‌دهد؛ یعنی درست یک سطح دورتر از جایی که یک انسان می‌توانست مچش را بگیرد.
  2. برداشت نادرست از خروجی. خرده‌مدیر گزارش می‌دهد: «امکان راستی‌آزمایی ادعای X وجود ندارد.» مدیر ارشد آن را این‌گونه خلاصه می‌کند: «ادعای X تأیید نشد.» بار معنایی در هر سطح دچار انحراف می‌شود.
  3. حلقه‌های بی‌پایان توافق. دو خرده‌مدیر با هم اختلاف‌نظر پیدا می‌کنند؛ مدیر ارشد از آن‌ها می‌خواهد که به هماهنگی برسند؛ آن‌ها دوباره کار را به زیردستان واگذار می‌کنند؛ کارگران دوباره اجرا می‌کنند؛ خرده‌مدیران پاسخ‌هایی با تفاوتی جزئی برمی‌گردانند؛ و این چرخه مدام تکرار می‌شود. قابلیت Process.hierarchical در CrewAI با سقف مجاز مراحل جلوی این مشکل را می‌گیرد، اما خود این محدودیت حالا به یک هایپرپارامتر تبدیل شده است.

سؤال تعیین‌کننده

متوالی (پایپ‌لاین خطی) یا سلسله‌مراتبی: آیا کار شما واقعاً از زیرتیم‌های مستقل تشکیل شده است، یا با یک جریان خطی طرف هستید که ادای درخت را درمی‌آورد؟ اگر دومی است، از متوالی استفاده کنید. اگر اولی است، از سلسله‌مراتبی بهره ببرید، اما برای قواعد حل اختلاف و هماهنگی بودجه و محدودیت صریح تعیین کنید.

پیاده‌سازی با فریم‌ورک مبتنی بر نقش

قابلیت Process.hierarchical در CrewAI یک مدل زبانی مدیر را روی کروهای (تیم‌های) متخصص می‌نشاند. مدیر:

  • وظیفه‌ی سطح بالا را دریافت می‌کند،
  • زیروظایف را به کروها تخصیص می‌دهد،
  • خروجی‌های کرو را می‌سنجد،
  • تصمیم می‌گیرد که خروجی را بپذیرد، دوباره واگذار کند، یا به چرخه‌ی تکرار بفرستد.

مستندات: https://docs.crewai.com/en/introduction (بخش «Hierarchical Process» را در Core Concepts ببینید).

پیاده‌سازی با فریم‌ورک مبتنی بر گراف

کتابخانه‌ی LangGraph از فراخوانی‌های تودرتوی create_supervisor استفاده می‌کند. ناظر داخلی گراف مخصوص به خود را دارد؛ ناظر بیرونی با گراف داخلی مثل یک گره‌ی مات برخورد می‌کند. این شیوه برای اشکال‌زدایی تمیزتر از CrewAI است (می‌توانید هر گراف را جداگانه گام‌به‌گام ردگیری کنید)، اما تغییر شکل پویای درخت با آن دشوارتر است.

مرجع: https://reference.langchain.com/python/langgraph-supervisor.

سلسله‌مراتبتفویض به پایین، بازگشت به بالا
HIERARCHYA manager splits the goal and delegates down through sub-managers to workers; results return along the same edges. The risk: an LLM manager re-reasons the whole tree each turn, so small context drift misallocates work and the structure loops. Often a flat sequence beats it.MGRABw0w1w2w3blue = delegation down · gold = results bubbling up
یک مدیر هدف را خرد کرده و از طریق مدیران میانی به عامل‌های اجرایی تفویض می‌کند؛ نتایج در امتداد همان یال‌ها بازمی‌گردند. ریسک اینجاست: مدیر LLM در هر نوبت گفت‌وگو کل درخت را دوباره استدلال می‌کند، بنابراین انحراف جزئی بافت (context drift) کار را به اشتباه تخصیص می‌دهد و ساختار دچار حلقه می‌شود. اغلب اوقات یک توالی مسطح بهتر از آن عمل می‌کند.

پیاده‌سازی عملی

فایل code/main.py یک ساختار سلسله‌مراتبی 3 سطحی را اجرا می‌کند:

  • مدیر ارشد: وظیفه را به دو شاخه‌ی «فنی» و «حقوقی» تقسیم می‌کند،
  • خرده‌مدیر فنی: کار را بین کارگران «فرانت‌اند» و «بک‌اند» تقسیم می‌کند،
  • خرده‌مدیر حقوقی: یک کارگر دارد.

این دمو مسیر ایدئال و بی‌دردسر (happy path که در آن همه هم‌نظرند) را در برابر یک مسیر دست‌کاری‌شده نشان می‌دهد؛ جایی که مدیر ارشد هنگام خرد کردن وظیفه، بخش «حقوقی» را به اشتباه «مالی» برچسب می‌زند و اثر دومینویی این خطا را مشاهده می‌کنید: خرده‌مدیر مطیعانه کار مالی انجام می‌دهد، خلاصه‌ساز ارشد یافته‌های مالی را گزارش می‌کند، و سؤال حقوقی اصلی کلاً بی‌پاسخ می‌ماند.

اجرا:

python3 code/main.py

خروجی هر دو مسیر را در کنار هم نشان می‌دهد تا مقایسه‌ی شفافی از «آنچه خواسته شده بود» در برابر «آنچه تحویل داده شد» داشته باشید.

کاربرد در دنیای واقعی

فایل outputs/skill-hierarchy-fitness.md ارزیابی می‌کند که آیا یک وظیفه‌ی مشخص باید از الگوی سلسله‌مراتبی، متوالی یا ناظر تخت استفاده کند یا خیر. ورودی‌ها: شرح وظیفه، ساختار سازمانی، بودجه‌ی هماهنگی. خروجی: پیشنهاد الگو همراه با حالت‌های شکست مشخصی که باید برایشان گاردریل بگذارید.

استقرار و تحویل

اگر سیستم سلسله‌مراتبی را مستقر می‌کنید:

  • عمق درخت را حداکثر روی 2 قفل کنید. سه سطح عملاً بیشتر خطاها را از دید پایش و مشاهده‌پذیری پنهان می‌کند.
  • بودجه‌ی هماهنگی صریح بگذارید. حداکثر دورهای مجاز رفت‌وبرگشت را پیش از آنکه مدیر ارشد ملزم به نهایی‌سازی (commit) تصمیم شود تعیین کنید؛ معمولاً 2 دور.
  • منشأ و سندیت (Provenance) را در هر ترکیب ثبت کنید. خلاصه‌ی هر گره باید مشخصاً ارجاع دهد که از خروجی‌های کدام برگ‌ها به دست آمده است.
  • روی انحراف در شکستن کار هشدار بگذارید. نحوه‌ی خرد کردن کار توسط مدیر را در هر گام لاگ کنید؛ با پرسش کاربر diff بگیرید. اگر شکست کار دیگر سؤال اصلی را پوشش نمی‌دهد، بلافاصله آلرت بزنید.

تمرین‌ها

  1. اسکریپت code/main.py را اجرا کنید و مسیر ایدئال و بی‌دردسر را با مسیر دست‌کاری‌شده بسنجید. چند دست‌به‌دست شدن بین مدیران طول می‌کشد تا خروجی نهایی کاملاً از پرسش کاربر دور شود؟
  2. یک سطح سوم اضافه کنید (مدیر ارشد ← خرده‌مدیر ← خرده‌مدیر سطح پایین‌تر ← کارگر). با افزایش عمق بسنجید که مسیر دست‌کاری‌شده هر چند وقت یک‌بار خودش را اصلاح می‌کند و چند وقت یک‌بار کاملاً دچار انحراف می‌شود.
  3. در سطح هر خرده‌مدیر یک کارگر «کاناری» بگذارید که همیشه پرسش اولیه‌ی کاربر بدون تغییر از او پرسیده می‌شود. از پاسخ کاناری برای تشخیص انحراف در شکستن کار استفاده کنید. در صورت اختلاف‌نظر میان کاناری و پاسخ ترکیبی نهایی، مدیر باید چه واکنشی نشان دهد؟
  4. مستندات Process.hierarchical در CrewAI را بخوانید. یک گاردریل عینی را که CrewAI اعمال می‌کند پیدا کنید (مثل محدودیت گام‌ها یا محدودیت manager_llm) و توضیح دهید کدام حالت شکست را هدف می‌گیرد.
  5. ناظران تودرتو در LangGraph را با ساختار سلسله‌مراتبی CrewAI مقایسه کنید. در کدام‌یک تشخیص حلقه‌های حل اختلاف کم‌هزینه‌تر است؟

اصطلاحات کلیدی

اصطلاح آنچه به زبان می‌آورند معنای واقعی آن
Hierarchical «الگوی چارت سازمانی» ناظران بالادست ناظران دیگر؛ فقط برگ‌ها کار انجام می‌دهند.
Manager LLM «رئیس» مدل زبانی که در یک گره‌ی داخلی، کار را می‌شکند، تخصیص می‌دهد و می‌سنجد.
Decomposition drift «رئیس رشته‌ی کار از دستش در رفت» شکستن کار توسط مدیر ارشد دیگر سؤال اولیه را پوشش نمی‌دهد.
Reconciliation loop «جلسات بی‌انتها» خرده‌مدیران اختلاف دارند؛ مدیر ارشد دوباره کار را واگذار می‌کند؛ کارگران از نو اجرا می‌کنند؛ این حلقه تا اتمام بودجه ادامه می‌یابد.
Depth-2 ceiling «بیشتر از 2 سطح عمیق نشوید» گاردریل تجربی: رفتن به 3 سطح یا بیشتر قابلیت مشاهده‌پذیری را نابود می‌کند.
Canary question «داده‌ی واقعی در تمام سطوح» کارگری که همیشه سؤال اولیه دست‌نخورده از او پرسیده می‌شود تا انحراف شناسایی شود.
Provenance chain «کی چی گفت» ردگیری محاسبات از هر ترکیب نهایی تا خروجی‌های برگ که آن را ساخته‌اند.

برای مطالعه‌ی بیشتر

سؤالات متداول

چه زمانی باید معماری سلسله‌مراتبی را جایگزین خط لوله متوالی (Sequential) کنیم؟

تنها زمانی از سلسله‌مراتبی استفاده کنید که وظیفه واقعاً از بخش‌های کاملاً مستقل و موازی (مانند دپارتمان‌های حقوقی، فنی و مالی) تشکیل شده باشد؛ در غیر این صورت، خط لوله متوالی ساده‌تر، ارزان‌تر و بسیار پایدارتر است.

چرا حداکثر عمق مجاز درخت سلسله‌مراتبی باید 2 سطح باشد؟

با رسیدن به عمق 3 یا بیشتر، امکان مشاهده‌پذیری (Observability) و ریشه‌یابی خطاها به‌شدت کاهش می‌یابد و خطاهای تجزیه وظایف در سطوح میانی پنهان می‌مانند.

انحراف در شکستن کار (Decomposition drift) چیست؟

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

ما رو توی گوگل بیشتر ببین

با افزودن نکست ادمین به «منابع ترجیحی» گوگل، درس‌ها و مطالب ما را در بخش اخبار برتر جستجو بیشتر می‌بینید.