Multi-agent در Responses API؛ تقسیم کار پیش از زیاد کردن عامل‌ها

OpenAI قابلیت multi-agent را در Responses API به‌صورت beta معرفی کرده است. در این الگو، یک نمونه GPT‑۵.۶ می‌تواند چند زیرعامل را برای بخش‌های مستقل یک مسئله هماهنگ کند و نتیجه‌ها را ترکیب کند. وعده اصلی، کاهش زمان wall-clock و بهتر شدن کارهای پیچیده‌ای است که می‌توان آن‌ها را به مسیرهای نسبتاً جدا تقسیم کرد.

#چه مسئله‌ای واقعاً چندعاملی است؟

یک تحقیق مقایسه‌ای ممکن است به عامل‌های جدا برای جست‌وجو، استخراج داده و نقد شواهد نیاز داشته باشد. یک پروژه کدنویسی می‌تواند بررسی dependency، اجرای تست و تحلیل performance را موازی کند. در هر دو نمونه، خروجی هر مسیر باید contract مشخصی داشته باشد و عامل نهایی بداند کدام evidence را پذیرفته است.

اگر مرحله دوم به تصمیم مرحله اول وابسته باشد، موازی‌سازی مصنوعی است. اضافه کردن عامل برای تولید متن مشابه نیز کیفیت را بالا نمی‌برد؛ فقط هزینه و هماهنگی را بیشتر می‌کند. OpenAI در راهنما تأکید می‌کند که multi-agent برای کارهایی مناسب است که مستقل یا قابل تقسیم‌اند، نه برای هر درخواست طولانی.

#معماری هماهنگی

عامل اصلی باید task را به subtask، schema و شرط پایان تبدیل کند. زیرعامل‌ها نباید بدون مرز به تمام ابزارها و تاریخچه دسترسی داشته باشند. هر کدام context کمینه، ابزار لازم و timeout جدا می‌خواهند. نتیجه باید با شناسه مسیر و منبع ثبت شود تا عامل ترکیب‌کننده بتواند تناقض را تشخیص دهد.

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

#beta یعنی قرارداد ثابت نیست

این ویژگی در beta است و OpenAI در حال جمع‌آوری بازخورد توسعه‌دهندگان است. بنابراین تیم نباید آن را بدون abstraction داخلی مستقیماً در قلب فرایند حیاتی قرار دهد. محدود کردن تعداد زیرعامل‌ها، ثبت trace و نگه داشتن fallback تک‌عاملی، هزینه تغییر API یا رفتار مدل را پایین می‌آورد.

برای ارزیابی، کار یکسان را با مسیر تک‌عاملی و چندعاملی اجرا کنید. wall-clock، تعداد token، موفقیت نهایی، تناقض‌ها و نیاز به اصلاح انسانی را بسنجید. اگر سرعت بیشتر با evidence کمتر یا هزینه بالاتر همراه است، چندعاملی بودن مزیت نیست.

Multi-agent یک الگوی تقسیم مسئولیت است. ارزش آن از طراحی مسئله، قرارداد خروجی و کنترل runtime می‌آید؛ نه از تعداد اسامی که در نمودار معماری کشیده شده‌اند.

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