CrewAI یا AutoGen؛ نقش‌های آماده در برابر گفت‌وگوی آزاد عامل‌ها

|نویسنده: تیم تحریریه QUASA|6 دقیقه مطالعه
CrewAI یا AutoGen؛ نقش‌های آماده در برابر گفت‌وگوی آزاد عامل‌ها

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

اگر عامل بعدی باید با توجه به پیام‌های میانی انتخاب شود، الگوهای گفت‌وگومحور AutoGen انعطاف بیشتری می‌دهند؛ راهنمای Team در AutoGen نوبت‌دهی ثابت، انتخاب گوینده و واگذاری میان عامل‌ها را شرح می‌دهد. برای تصمیم دربارهٔ پروژهٔ تازه، وضعیت محصول نیز مهم است: مخزن رسمی AutoGen آن را در حالت نگه‌داری معرفی می‌کند و Microsoft Agent Framework را به کاربران تازه پیشنهاد می‌دهد. بنابراین مزیت معماری گفت‌وگومحور AutoGen باید در کنار افق نگه‌داری آن سنجیده شود.

کنترل مسیر در کدام بخش قرار می‌گیرد؟

در CrewAI، Flow جای تعریف مراحل، شاخه‌ها و وضعیت مشترک فرایند است؛ Crew برای بخشی به کار می‌رود که همکاری عامل‌های دارای هدف، ابزار و وظیفهٔ مشخص لازم دارد. این جداسازی برای محصولی سودمند است که باید پس از تولید یک پاسخ، مسیر معینی را ادامه دهد: خروجی عامل‌ها دادهٔ مرحلهٔ بعد می‌شود، اما ترتیب کل فرایند در گفت‌وگوی آن‌ها پنهان نمی‌ماند. حتی می‌توان بخش‌هایی از Flow را بدون سپردن آن‌ها به یک تیم عامل اجرا کرد.

در AutoGen، Team محل هماهنگی گفت‌وگوست. RoundRobinGroupChat عامل‌ها را به ترتیب نوبت می‌دهد؛ SelectorGroupChat با کمک مدل گویندهٔ بعدی را انتخاب می‌کند؛ Swarm انتقال کار را با پیام واگذاری پیش می‌برد. این‌ها شکل‌های متفاوتی از کنترل‌اند، نه یک گفت‌وگوی کاملاً بی‌قاعده. توسعه‌دهنده همچنان اعضای تیم و شرط پایان را تعیین می‌کند، ولی در الگوهای پویا، پیام‌های تولیدشده می‌توانند بر مسیر بعدی همکاری اثر بگذارند.

کدام نوع کار از نقش‌محوری یا گفت‌وگو سود می‌برد؟

فرض کنید، در یک مثال فرضی، سامانه‌ای درخواست داده را دریافت می‌کند، پرس‌وجوی SQL می‌سازد، خروجی را بازبینی می‌کند و پیش از ارسال نتیجه منتظر تأیید می‌ماند. اگر همین ترتیب بخشی از قرارداد محصول باشد، تعریف آن در Flow مرز هر مرحله را روشن نگه می‌دارد. همکاری یک Crew می‌تواند به تولید یا بازبینی محدود شود؛ لازم نیست دریافت درخواست و تصمیم نهایی نیز به نوبت‌های گفت‌وگو تبدیل شوند.

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

زمینهٔ مشترک چه اثری بر توکن و تأخیر دارد؟

در RoundRobinGroupChat پاسخ هر عامل برای دیگر اعضا پخش می‌شود تا زمینهٔ گفت‌وگو را در اختیار داشته باشند. این ویژگی نقد و اصلاح پاسخ را ممکن می‌کند، اما با طولانی‌شدن سابقهٔ پیام‌ها، مقدار متنی که عامل بعدی باید پردازش کند نیز می‌تواند رشد کند. در SelectorGroupChat انتخاب گویندهٔ بعدی خود به تصمیم مدل وابسته است؛ بنابراین صرف شمارش پاسخ‌های نهایی برای برآورد هزینه و تأخیر کافی نیست.

در CrewAI نیز افزودن عامل و وظیفه می‌تواند فراخوانی مدل و متن زمینهٔ بیشتری وارد اجرا کند. Flow به توسعه‌دهنده امکان می‌دهد همکاری را به مرحله‌ای محدود کند که واقعاً به آن نیاز دارد، اما این طراحی به‌تنهایی مصرف توکن پایین را تضمین نمی‌کند. معیار مناسب، مجموع مصرف و زمان رسیدن به خروجی قابل‌استفاده برای یک وظیفهٔ یکسان است؛ طول دستورها، شمار بازبینی‌ها، ابزارهای فراخوانی‌شده و شرط توقف می‌توانند نتیجه را تغییر دهند.

بنچمارک مهندسی داده چه چیزی را نشان می‌دهد؟

در جدول بنچمارک مهندسی داده، برای اجراهای گزارش‌شده با مدل Groq Llama 3.3 70B، پرامپت‌ها و مهلت یکسان، میانگین CrewAI حدود ۵۰۰۵ توکن و ۲۰ ثانیه و میانگین AutoGen حدود ۵۶۷۸ توکن و ۱۷٫۹ ثانیه ثبت شده است. در همین مقایسه، CrewAI توکن کمتری مصرف کرده و AutoGen زودتر به پایان رسیده است. این دو سنجه به‌تنهایی کیفیت پاسخ را تعیین نمی‌کنند.

وظایف گزارش شامل تولید SQL، رفع اشکال خط لوله و تبدیل داده‌اند. اعداد حاصل چارچوب‌ها در پیکربندی و محیط همان آزمون هستند؛ به هر برنامه‌ای که از CrewAI یا AutoGen استفاده کند تعمیم پیدا نمی‌کنند. توصیف منتشرشدهٔ مجموعه نیز دربارهٔ شمار وظایف یکدست نیست، پس بهتر است از میانگین‌های آن برای فهم جهت تفاوت در همین اجرا استفاده شود، نه برای ادعای برتری عمومی یک چارچوب.

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

توقف و تأیید انسانی چگونه در مسیر قرار می‌گیرند؟

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

در CrewAI، راهنمای بازخورد انسانی در Flow مکث برای دریافت نظر انسان و هدایت ادامهٔ جریان بر اساس تأیید، رد یا درخواست اصلاح را توضیح می‌دهد. محل این مکث باید پیش از اقدامی باشد که به تأیید نیاز دارد، نه صرفاً پس از تولید متن عامل. اگر بازبینی زمان‌بر است، همان راهنما امکان نگه‌داشتن وضعیت Flow و ادامهٔ آن پس از رسیدن پاسخ را نیز شرح می‌دهد.

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

مسیر انتخاب برای پروژهٔ تولیدی

  • اگر مراحل، شاخه‌ها و وضعیت از پیش معلوم‌اند، Flow در CrewAI مبنای مناسبی است. Crew را در مرحله‌ای قرار دهید که تقسیم کار نقش‌محور به خروجی آن ارزش می‌افزاید.
  • اگر مسئله به نقد متقابل یا انتخاب عامل بعدی بر اساس پیام‌های میانی وابسته است، الگوهای Team در AutoGen با آن سازگارند. برای پروژهٔ تازه، وضعیت نگه‌داری AutoGen را نیز در تصمیم فنی لحاظ کنید.
  • اگر خروجی پیش از اقدام حساس به تأیید نیاز دارد، نخست محل مکث و مسیر تأیید یا رد را مشخص کنید؛ سپس سازوکار Flow یا Team را با آن هماهنگ سازید.

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

بیشتر بخوانید:

اشتراک‌گذاری:

عضویت در خبرنامه

تازه‌ترین اخبار Web3، هوش مصنوعی و رمزارز را مستقیم در صندوق ایمیل خود دریافت کنید.

0