طراحی سیستم چند ایجنتی؛ تقسیم مسئولیت و تحویل کار بدون گم شدن زمینه

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

در قسمت هفدهم یک تیم ایجنتی با smolagents ساختیم. در این قسمت از مجموعه‌ی آموزش هوش مصنوعی تخته سبز، از زاویه‌ی طراحی به همین موضوع نگاه می‌کنیم. کی چند ایجنت لازم است؟ چه الگوهایی وجود دارد؟ و مهم‌تر از همه، چطور کار را میان ایجنت‌ها تحویل دهیم بدون اینکه شواهد و زمینه در طول راه گم شوند؟

کی چند ایجنت لازم است؟

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

مزایا نسبت به یک ایجنت

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

درسنامه‌ی مایکروسافت مثال خوبی دارد. یک آژانس سفر کوچک را با یک آژانس زنجیره‌ای مقایسه کنید. در آژانس کوچک یک نفر همه‌ی کارها را انجام می‌دهد؛ از پرواز تا هتل. در آژانس زنجیره‌ای، هر کار را کارشناس خودش انجام می‌دهد. برای حجم کم، آژانس کوچک کافی است؛ برای حجم زیاد و کارهای پیچیده، مدل دوم بهتر کار می‌کند.

کی یک ایجنت بهتر است؟

یک ایجنت وقتی بهتر است که کار با یک مجموعه دستورالعمل و ابزار انجام شود و به تحویل به متخصص نیازی نباشد. مثلاً یک ربات پشتیبانی که از یک پایگاه دانش و چند ابزار محدود به پرسش‌های رایج پاسخ می‌دهد. یا دسته‌بندی ساده‌ای که هزاران بار در ساعت تکرار می‌شود.

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

اجزای اصلی سیستم چند ایجنتی

پیش از پیاده‌سازی، باید اجزای این الگو را بشناسید. با مثال رزرو سفر، این اجزا روشن‌تر می‌شوند.

ارتباط، هماهنگی و معماری

ایجنت‌های پرواز، هتل و خودرو باید با هم ارتباط داشته باشند و اطلاعات ترجیحات و محدودیت‌های کاربر را رد و بدل کنند. باید تصمیم بگیرید این ارتباط چطور انجام شود و چه پروتکلی دارد. سازوکار هماهنگی هم لازم است؛ مثلاً اگر کاربر هتلی نزدیک فرودگاه می‌خواهد، ایجنت هتل باید از نتیجه‌ی ایجنت پرواز خبر داشته باشد.

هر ایجنت هم معماری داخلی خودش را دارد تا تصمیم بگیرد و از تعامل‌ها یاد بگیرد. الگوی کلی سیستم هم باید انتخاب شود؛ متمرکز، غیرمتمرکز یا ترکیبی. در معماری متمرکز، یک هماهنگ‌کننده همه‌ی پیام‌ها را مدیریت می‌کند. در معماری غیرمتمرکز، ایجنت‌ها مستقیم با هم صحبت می‌کنند.

دیده‌پذیری و انسان در حلقه

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

دوم، انسان در حلقه. در بیشتر موارد باید مشخص کنید ایجنت‌ها کی باید از انسان کمک بخواهند. مثلاً وقتی کاربر هتل یا پروازی خاص می‌خواهد که ایجنت‌ها پیشنهاد نداده‌اند، یا پیش از هر پرداخت.

سه الگوی چندایجنتی

سه الگوی رایج برای ساخت برنامه‌های چندایجنتی وجود دارد. هر کدام برای نوع خاصی از کار مناسب است.

چت گروهی

در این الگو چند ایجنت در یک گفت‌وگوی گروهی با هم پیام رد و بدل می‌کنند. کاربردهای رایجش همکاری تیمی، پشتیبانی مشتری و شبکه‌های اجتماعی است. هر ایجنت می‌تواند به همه یا به یک ایجنت خاص پیام بدهد.

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

تحویل کار

در الگوی تحویل کار، هر ایجنت یک مرحله از گردش کار را انجام می‌دهد و کار را بر اساس قواعد مشخص به ایجنت بعدی می‌سپارد. کاربردهای رایجش پشتیبانی مشتری، مدیریت وظایف و خودکارسازی گردش کار است.

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

فیلترینگ مشارکتی

در این الگو چند ایجنت متخصص با هم یک پیشنهاد می‌سازند. هر ایجنت از زاویه‌ی تخصص خودش به موضوع نگاه می‌کند. مثلاً برای پیشنهاد سرمایه‌گذاری، یک ایجنت کارشناس صنعت است، دیگری تحلیل تکنیکال انجام می‌دهد و سومی تحلیل بنیادی. پیشنهاد نهایی کامل‌تر از نظر هر یک به‌تنهایی است.

در یک مجموعه‌ی آموزشی، همین الگو برای پیشنهاد دوره کاربرد دارد. یک ایجنت محتوای دوره را می‌سنجد، دیگری سطح دانشجو را و سومی برنامه‌ی زمانی‌اش را. جدول زیر سه الگو را مقایسه می‌کند.

قرارداد تحویل؛ حفظ شواهد در زنجیره

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

ساختار پیام تحویل

راه‌حل، یک قرارداد تحویل مشترک است. همه‌ی ایجنت‌ها خروجی‌شان را با یک قالب ثابت تحویل می‌دهند:

from pydantic import BaseModel, Field

class Claim(BaseModel):
    text: str
    source_ids: list[str] = Field(min_length=1)  # ادعای بدون منبع پذیرفته نمی‌شود
    confidence: float = Field(ge=0, le=1)

class Handoff(BaseModel):
    from_role: str
    task: str
    claims: list[Claim]
    open_questions: list[str] = []

فیلد source_ids با حداقل یک عضو، ادعای بی‌منبع را از همان ابتدا رد می‌کند. open_questions هم مواردی را نگه می‌دارد که ایجنت نتوانست جواب بدهد؛ به‌جای اینکه آن‌ها را حدس بزند یا حذف کند.

یک مسئول برای پاسخ نهایی

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

سناریوی عملی؛ یابنده، سنجنده، نویسنده

در دستیار آموزشی ما سه نقش داریم. یک نقش منابع دوره را پیدا می‌کند، نقش دوم تناسب آن‌ها را با نیاز کاربر می‌سنجد و نقش سوم پاسخ نهایی را می‌نویسد. ورودی آزمون پرسش کاربر و قالب مشترک تحویل برای نتیجه‌ی هر نقش است.

اقدام و معیار پذیرش

اقدام مورد بررسی، تحویل نتیجه همراه منبع و میزان اطمینان به نقش بعدی است. خروجی هر نقش را جدا ثبت کنید تا بتوانید مسیر هر ادعا را از ابتدا تا پاسخ نهایی دنبال کنید.

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

نمونه‌ی شکست؛ ادعایی که معتبر به نظر می‌رسد

شکستی که باید عمداً دنبالش بگردید این است: ادعای بدون منبع در هر مرحله روان‌تر بازنویسی شود تا جایی که معتبر به نظر برسد. نقش اول حدس می‌زند «احتمالاً این دوره پیش‌نیاز ندارد». نقش دوم آن را «این دوره پیش‌نیاز ندارد» می‌نویسد. نقش سوم با اطمینان کامل به کاربر می‌گوید.

قرارداد تحویل با منبع اجباری، این زنجیره را در همان قدم اول قطع می‌کند. این نمونه را عمداً در آزمون بسازید و مطمئن شوید ادعای بی‌منبع به پاسخ نهایی نمی‌رسد.

تمرین عملی؛ قرارداد تبادل داده میان نقش‌ها

خروجی این تمرین قرارداد تبادل داده میان نقش‌ها و مقایسه با نسخه‌ی ساده است:

1. طرح‌واره‌ی Handoff را برای سه نقش یابنده، سنجنده و نویسنده پیاده کنید.
2. پنج پرسش را در نسخه‌ی سه‌نقشی و نسخه‌ی تک‌ایجنتی اجرا کنید و کیفیت، زمان و هزینه را مقایسه کنید.
3. نمونه‌ی شکست بالا را بازسازی کنید و ببینید قرارداد جلویش را می‌گیرد یا نه.

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

سخن پایانی

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

در قسمت بعد ساخت جریان کار ایجنتی را می‌بینیم؛ وضعیت، پیام و مسیر اجرای قابل آزمون.

این آموزش بر پایه‌ی درس Multi-Agent Design Patterns از مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.