‏الگوی مشاور-مجری: مدل گرون فقط جایی که لازمه

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

الگوی مشاور-مجری یه استراتژی روتینگ مدله که دو نقش مجزا تعریف می‌کنه. مشاور کارهای پرریسک و استدلالی رو برمی‌داره: پلن‌ریزی، معماری، تجزیهٔ مسئله و بازبینی. مجری کارهای پرحجم پیاده‌سازی رو انجام می‌ده: نوشتن کد، تولید محتوا، تبدیل داده و فراخوانی ابزار. مشاور می‌گه «چی» باید بشه و مجری انجامش می‌ده.

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

فرقش با سوییچ سادهٔ مدل هم همینه: سوییچ ساده ایستاست (همیشه مدل A برای کد، مدل B برای متن)، ولی این الگو پویا و رابطه‌محوره. مشاور فعالانه ورودی مجری رو شکل می‌ده و پلن یا اسپک قدم‌به‌قدم می‌نویسه، بعد خروجی مجری برای بازبینی برمی‌گرده پیش مشاور. نتیجه یه حلقهٔ پلن، اجرا، بازبینی و اصلاحه.

سمت اقتصادی ماجرا، به گفتهٔ نویسنده ورک‌فلویی که ۸۰ درصد مصرف توکنش رو به مجری ارزون‌تر بسپره و مشاور رو روی ۲۰ درصد نگه داره، بسته به ترکیب تسک‌ها ۴۰ تا ۶۰ درصد از هزینهٔ کل اینفرنس کم می‌کنه. کنارش تأخیر کمتر (چون مدل مجری سریع‌تره)، مصرف بهینه‌تر کانتکست و نرخ خطای پایین‌تر هم هست؛ پلن دقیق باعث می‌شه مجری کمتر اشتباه کنه و کمتر ریتری لازم بشه. در عوض پیچیدگی ورک‌فلو بالا می‌ره.

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

نویسنده چند اشتباه رایج رو هم فهرست می‌کنه: پرامپت مبهم برای مشاور (بیشتر انرژی پرامپت‌نویسی باید صرف مشاور بشه، نه مجری)، فرستادن کانتکست بیش از حد به مجری، حذف مرحلهٔ بازبینی برای صرفه‌جویی، استفاده از این الگو برای تسک‌های ساده‌ای که دو سه قدم بیشتر ندارن، و هاردکد کردن مرز تسک به جای اینکه مثل یه پارامتر پیکربندی گاهی بازنگری بشه.

کاربردهای عملی‌ای که مثال زده شده هم متنوعه: پایپ‌لاین تولید کد، تولید محتوای بلند (مشاور طرح تفصیلی می‌نویسه، مجری هر بخش رو جدا می‌نویسه)، تبدیل داده و ETL، و ری‌ویو خودکار کد تو CI/CD. بخشی از مقاله هم به این می‌پردازه که این الگو رو چطور تو MindStudio بدون کد بسازی، چون این پلتفرم روتینگ مدل و ریت‌لیمیت و ریتری رو خودش مدیریت می‌کنه.

نکات کلیدی:

• مشاور پلن می‌ریزه و بازبینی می‌کنه، مجری پیاده‌سازی پرحجم رو انجام می‌ده
• بردن ۷۰ تا ۸۰ درصد مصرف توکن سمت مجری، به گفتهٔ نویسنده ۴۰ تا ۶۰ درصد صرفه‌جویی می‌آره
• کیفیت پلن مشاور مهم‌ترین ورودیه؛ پلن مبهم یعنی خروجی غیرقابل اتکا
• مرحلهٔ بازبینی رو حذف نکن؛ گرفتن خطا سر وقتش از اصلاح بعدی ارزون‌تره
• برای تسک‌های دو سه قدمی و بدون ابهام، یه مدل واحد کافیه