تحول در ایجنت مانوس با قابلیت Manus Flex؛ کلید اختصاصی مدل هوش مصنوعی دست خودتان است!

قابلیت Manus Flex؛ کلید اختصاصی پردازش هوش مصنوعی در دستان برنامه‌نویس‌ها

پلتفرم مانوس (Manus) از یک ماژول تازه به اسم Manus Flex رونمایی کرده که اصطلاحاً بر پایه رویکرد BYOK (آوردن کلید اختصاصی خود کاربر) کار می‌کنه. با این قابلیت، حالا توسعه‌دهنده‌ها می‌تونن ارائه‌دهنده سرویس پردازش (Inference) مدنظرشون رو وصل کنن و دقیقاً تعیین کنن که کدوم مدل هوش مصنوعی قراره قلب تپنده ایجنت مانوس باشه. در این میان، مانوس همچنان لایه ارکستراسیون و هماهنگی اصلی رو در دست داره؛ یعنی همون بخشی که تسک‌ها رو برنامه‌ریزی می‌کنه، ابزار‌های مختلف رو فرا می‌خونه، محیط‌های اجرایی رو می‌چرخونه و پاسخ‌های مدل رو به کار نهایی تبدیل می‌کنه.

در فاز اول، سه سرویس مطرح یعنی اوپن‌روتر (OpenRouter)، فایروُرکس (Fireworks) و مُدال (Modal) به‌عنوان پارتنرهای اصلی معرفی شده‌اند. تفکیک تهیه مدل از ایجنت مدیریت‌شده به تیم‌ها این فرصت رو میده که از قراردادهای قبلی خودشون با ارائه‌دهنده‌ها، مدل‌های بازوزن (Open-weight) یا نسخه‌های شخصی‌سازی و فاین‌تیون‌شده استفاده کنن، بدون اینکه لازم باشه جریان‌های کاری مانوس رو از اول بازنویسی کنن.

جداسازی لایه‌ها؛ استک ایجنت‌ها دیگر یکپارچه نیست

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

هر کانفیگ در فلکس شامل یک مدل اصلی و یک تنظیمات ویژه برای «تلاش استدلال» (Reasoning Effort) در سرویس متصل‌شده است. این گزینه مشخص می‌کنه مدل‌های سازگار در زمان پردازش چقدر توان محاسباتی رو به یک تسک اختصاص بدن؛ تصمیمی که مستقیماً روی تاخیر زمانی (Latency)، هزینه‌ها و البته کیفیت خروجی اثر می‌ذاره.

یک تسک، دو صورت‌حساب جداگانه!

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

این تفکیک دست تیم‌ها رو باز می‌ذاره تا مصرف مدل رو به حساب همان ارائه‌دهنده مدنظر فاکتور کنن و همزمان از زیرساخت قدرتمند مانوس نهایت استفاده رو ببرن. البته این داستان روی دیگه‌ای هم داره: حالا باید فاکتورها، سهمیه‌ها (Quotas)، محدودیت نرخ درخواست (Rate Limits) و وضعیت پایداری هر سرویس رو جداگانه رصد و مدیریت کنن.

سه مسیر جذاب برای دسترسی به انبوهی از مدل‌ها

مانوس سرویس‌های اوپن‌روتر، فایروُرکس و مُدال رو به‌عنوان شرکای روز عرضه معرفی کرده؛ با این حال، در رابط کاربری گزینه‌هایی مربوط به اوپن‌ای‌آی (OpenAI)، آنتروپیک (Anthropic)، استودیوی هوش مصنوعی گوگل (Google AI Studio)، اکس‌ای‌آی (xAI) و متا (Meta) هم به چشم می‌خوره. به این ترتیب، دسترسی به این مدل‌ها از طریق کانکشن‌های پردازشی پشتیبانی‌شده فراهم میشه، بدون اینکه نیازی باشه خود مانوس تک‌تک این مدل‌ها رو مستقیماً میزبانی و مدیریت کنه.

• اوپن‌روتر (OpenRouter): امکان دسترسی به صدها مدل مختلف رو تنها با یک API و یک حساب کاربری فراهم می‌کنه.
• فایروُرکس (Fireworks): مدل‌های بازوزن و فاین‌تیون‌شده رو روی زیرساخت پردازشی مدیریت‌شده میزبانی می‌کنه.
• مُدال (Modal): از استقرار مدل‌های سفارشی و متن‌باز روی زیرساخت‌های سرورلس GPU پشتیبانی می‌کنه.

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

اختیار بیشتر، دردسر تست‌های جدید‌تر!

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

اما نباید فراموش کرد که عوض کردن مدل پایه ممکنه روی نحوه انتخاب ابزارها، خروجی‌های ساختاریافته، مدیریت حافظه کانتکست، تاخیر و حتی رفتار رد درخواست‌ها (Refusal) اثر بذاره. بنابراین تیم‌هایی که سراغ مدل‌های جدید میرن، حتماً باید این موارد رو تست کنن:

• دقت در فراخوانی توابع و انتخاب ابزار‌ها (Tool and Function Calling)
• انطباق خروجی ساختاریافته با اسکیمای تعیین‌شده
• محدودیت‌های پنجره زمینه (Context Window) و بازدهی در کار‌های طولانی‌مدت
• مدیریت خطاهای ارائه‌دهنده، تایم‌اوت‌ها و محدودیت نرخ درخواست (Rate Limits)
• بررسی هزینه، تاخیر و کیفیت اجرای کار‌ها در تسک‌های نمونه

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

فلکس هم‌مسیر با جریان کلی بازار ایجنت‌ها

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

این طراحی ماژولار مسیر سرراستی پیش پای مانوس می‌ذاره تا بدون دست زدن به سیستم‌های برنامه‌ریزی، استفاده از ابزار یا محیط اجرا، پارتنرهای پردازشی جدیدی اضافه کنه. مرز کار هم برای توسعه‌دهنده‌ها شفاف‌تر از همیشه است: ارائه‌دهنده‌ها توان پردازشی مدل رو تامین می‌کنن و مانوس ران‌تایم و زیرساخت اجرای تسک‌های ایجنت رو به میدان می‌آورد.

چه زمانی سراغ Manus Flex برویم؟

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

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