یک ایجنت واحد که هم درخواست را بفهمد، هم سند پیدا کند، هم تصمیم بگیرد و هم چند سامانه را تغییر دهد، در نسخه نمایشی جذاب است. در محیط واقعی، این تمرکز مسئولیت ردگیری خطا و کنترل دسترسی را دشوار می‌کند. معماری چندایجنتی کار را میان نقش‌های محدود تقسیم می‌کند، اما فقط زمانی ارزش دارد که فرایند واقعا چندمرحله‌ای و قابل تفکیک باشد.
هدف زیادکردن تعداد اجزا نیست. هر ایجنت باید مسئولیت، ورودی، خروجی، ابزار و حد اختیار مشخص داشته باشد. یک هماهنگ‌کننده نیز مسیر کار را نگه می‌دارد و تصمیم می‌گیرد مرحله بعد چیست.
چه زمانی تقسیم به چند ایجنت منطقی است؟
- مراحل فرایند تخصص و داده متفاوت دارند؛
- هر نقش به مجموعه محدودی از ابزارها نیاز دارد؛
- بخشی از کار باید مستقل آزمایش یا جایگزین شود؛
- فرایند نقاط توقف، تأیید یا اجرای موازی دارد؛
- لازم است مسئولیت هر تصمیم و عمل جدا ثبت شود.
اگر کار یک پرسش و پاسخ ساده یا استخراج یک فیلد است، چندایجنتی معمولا هزینه و احتمال خطا را بی‌دلیل افزایش می‌دهد.
نقش‌ها را بر اساس کار تعریف کنید
نام‌هایی مانند «ایجنت پژوهشگر» یا «ایجنت مدیر» کافی نیست. نقش باید به یک خروجی آزمون‌پذیر متصل باشد؛ مثلا دریافت و اعتبارسنجی درخواست، بازیابی اسناد مجاز، تهیه پیشنهاد، کنترل قواعد و ثبت نتیجه. هر نقش فقط ابزارهای لازم همان مرحله را دریافت کند.
هماهنگ‌کننده باید وضعیت را نگه دارد
هماهنگ‌کننده وضعیت فرایند، مرحله جاری، خروجی‌های تأییدشده و خطاها را در یک مخزن پایدار ثبت می‌کند. اتکا به متن گفت‌وگو برای نگهداری وضعیت کافی نیست. اگر سرویس قطع شود، باید بتوان کار را از آخرین مرحله معتبر ادامه داد، نه اینکه همه عملیات دوباره اجرا شوند.
قرارداد میان ایجنت‌ها را ساختاریافته کنید
هر خروجی باید قالب مشخص، نسخه، شناسه پرونده و وضعیت اعتبارسنجی داشته باشد. متن آزاد برای انتقال میان مراحل باعث می‌شود خطای یک بخش در بخش بعدی بزرگ‌تر شود. فیلدهای اجباری، مقادیر مجاز و پیام خطا را مثل یک API داخلی تعریف کنید.
اجرای دوباره نباید نتیجه را دو بار ثبت کند
فراخوانی ابزارها باید تا حد ممکن idempotent باشد. اگر مرحله ثبت سفارش به دلیل قطع ارتباط دوباره اجرا شد، سامانه باید همان نتیجه قبلی را برگرداند یا پیش از ایجاد رکورد جدید وجود آن را بررسی کند. برای هر عمل یک کلید یکتا و سابقه وضعیت نگه دارید.
اختیار هر نقش را محدود کنید
ایجنت بازیابی سند نباید امکان ویرایش CRM داشته باشد و ایجنت تهیه پیش‌نویس نباید پیام را مستقیم ارسال کند. مجوزها را بر اساس نقش، داده، عمل و محیط جدا کنید. عملیات حساس به تأیید انسانی یا یک سرویس کنترل قواعد سپرده شود.
خطا چگونه مهار می‌شود؟
برای تأخیر، خروجی نامعتبر، نبود داده، ردشدن مجوز و خطای ابزار مسیر جدا بنویسید. تعداد تلاش مجدد محدود باشد و پس از آن پرونده به صف بررسی برود. هماهنگ‌کننده نباید یک پاسخ ناقص را به‌عنوان موفقیت به مرحله بعد بفرستد.
ارزیابی را هم در سطح جزء و هم کل انجام دهید
هر ایجنت با مجموعه آزمون خودش سنجیده شود: دقت بازیابی، اعتبار قالب یا موفقیت اجرای ابزار. سپس سناریوی کامل از ورودی تا نتیجه نهایی آزمایش شود. ممکن است همه اجزا به‌تنهایی خوب باشند اما تحویل میان دو مرحله باعث از دست‌رفتن اطلاعات شود.
با دو نقش شروع کنید
پایلوت را به هماهنگ‌کننده و یک نقش تخصصی محدود کنید. ثبت مسیر، توقف امن و کنترل دسترسی را کامل بسازید و بعد نقش بعدی را اضافه کنید. معماری‌ای که نتوان آن را روی کاغذ توضیح داد، در رخداد عملیاتی نیز قابل مدیریت نخواهد بود.
برای شناخت اجزای پایه، مقاله ایجنت هوش مصنوعی سازمانی چیست؟ و برای کنترل اختیار، راهنمای حاکمیت و امنیت هوش مصنوعی را بخوانید. برای طراحی یک فرایند چندمرحله‌ای نیز از مرکز پشتیبانی سوهاب AI درخواست مشاوره ثبت کنید.