«عبور از گلوگاه پنجره متنی»؛ استراتژی توزیع وظایف میان عامل‌های موازی

اگر هنوز کدها را به‌صورت خطی و تک‌تکه می‌نویسید، احتمالاً بخش بزرگی از ظرفیت ابزارهای جدید را از دست می‌دهید. تصور کنید به‌جای اینکه خودتان تمام جزئیات را پیاده کنید، تیمی از ۱۶ برنامه‌نویس سریع داشته باشید که هم‌زمان دستورات شما را اجرا کنند.

یک توسعه‌دهنده مستقل توانست تنها در ۶ ساعت (از ساعت ۲ تا ۸ عصر)، چهار محصول آماده برای محیط عملیاتی را منتشر کند. او به‌جای نوشتن متوالی کد، از Cursor برای مدیریت ۱۶ عامل (Agent) موازی استفاده کرد. در این رویکرد، کاربر نقش یک مدیر فنی را ایفا می‌کند که موج‌های مختلفی از عامل‌های خودگردان را برای تحقیق، ساخت و تأیید هم‌زمان هدایت می‌کند. این رویکردی است که در ابزارهای پیشرفته‌تر نیز دیده می‌شود؛ برای مثال سازوکار Claude Code در مدیریت تعداد بیشتری از عامل‌های تخصصی برای پروژه‌های تجاری پیچیده به کار گرفته شده است.

خروجی این یک بعدازظهر خیره‌کننده بود: حدود ۵۰۰ کیلوبایت مستندات فنی تولید شد که تقریباً به اندازه یک رمان کوتاه است. در بخش محصول، یک Cloudflare Worker از حالت پرداخت Stripe-only به سیستم پرداخت موازی Stripe + Creem ارتقا یافت. تا پایان این جلسه، چهار محصول واقعی در محیط عملیاتی فعال شدند و تمام ۱۲ نوع رویداد Webhook به‌صورت کامل و سرتاسری (End-to-End) تأیید شدند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی معماری‌های عامل‌محور اشاره کردیم، مشکل اصلی در کدنویسی با هوش مصنوعی، پنجرهٔ زمینه (Context Window) است — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه. وقتی یک عامل تنها تمام وظایف متنوع را بر عهده می‌گیرد، حافظه‌اش به‌هم‌ریخته و کیفیت پاسخ‌ها افت می‌کند. این توسعه‌دهنده با ایجاد زیر-عامل‌های مستقل — که هر کدام پرامپت، پنجرهٔ زمینه و نمونه مدل (Model Instance) مجزای خود را داشتند — در واقع بهره‌وری خود را در زمان واقعی چندین برابر کرد.

تفاوت این روش با کدنویسی سنتی، شبیه تفاوت بین یک برنامه‌نویس تنها با مدیری است که یک تیم کوچک و فوق‌سریع را رهبری می‌کند. در حالی که مغز انسان تک‌رشته‌ای است، ابزارهایی مثل Cursor، Claude Code، Cline یا Aider اجازه می‌دهند چندین جریان کاری را هم‌زمان نظارت کنیم. طبق گزارش این توسعه‌دهنده، اگر چهار زیر-عامل هر کدام ۳۰ دقیقه کار کنند، مدیر در واقع ۱۲۰ دقیقه خروجی را تنها در ۳۰ دقیقه زمان واقعی دریافت می‌کند.

مدل ارکستراسیون موج‌محور

پروژه مورد نظر datenix.xyz (یک API داده B2B) بود. چالش فنی اصلی، اتصال پرداخت Creem به Cloudflare Worker بود. اگرچه این یک کار تخصصی تک‌نفره بود، اما الزامات پیرامونی آن بسیار گسترده بود. برای جلوگیری از انفجار زمینه، توسعه‌دهنده از استراتژی «تقسیم و فتح» استفاده کرد و وظایف را با استفاده از مدل 4.7-fast به بخش‌های متمرکز تقسیم نمود تا هر زیر-عامل در ۳۰ تا ۴۰ دقیقه کار خود را تمام کند.

او ۱۶ عامل را در چهار «موج» مجزا سازماندهی کرد (هر موج ۴ عامل موازی). این تعداد به دلیل محدودیت رابط کاربری Cursor انتخاب شد تا وضعیت هر ۴ عامل به‌طور هم‌زمان بدون شلوغ شدن صفحه، قابل مشاهده باشد:

• موج ۴۸ (کاوش): تمرکز بر کاوش کامل API Creem (شامل ۴۳ نقطه انتهایی، ۱۲ نوع وب‌هوک و اشکال مختلف Payload)، مقایسه Creem در برابر Stripe برای تصمیم‌گیری در مورد اینکه کدام یک اصلی باشند، ایجاد یک برنامه ادغام و طراحی لایه‌های قیمت‌گذاری.
• موج ۴۹ (ساخت): اجرای عملیاتی برای ایجاد Providerهای TypeScript، یک رابط خط فرمان (CLI) برای مدیریت، یک اسکریپت مانیتورینگ و نسخه چهارم صفحه فرود (که شامل بلوک Trust & Safety، صفحه About، صفحه Contact و نشان‌های مربوط به بازگشت وجه یا Refund بود).
• موج ۵۰ (اتمام): تولید دفترچه راهنمای لانچ (شامل ۶ دستور پس از KYC)، برنامه‌های بازنویسی (Refactor)، بهبودهای بوت‌استرپ و یک سند تحویل جلسه (SESSION_HANDOFF) برای یکپارچه‌سازی.
• موج ۵۱ (بررسی عمیق): تحقیق درباره الگوهای تأیید KYC از طریق بررسی Case Studyهای عمومی Creem و موارد رد درخواست، ارزیابی قابلیت پذیرش محصول، صیقل دادن صفحه فرود و توسعه استراتژی پرداخت CN.

بین هر موج، توسعه‌دهنده ۱۵ تا ۲۰ دقیقه زمان برای ادغام خروجی‌ها، استقرار خروجی هر زیر-عامل در پروژه و بررسی تداخلات صرف می‌کرد. این حلقه بازخورد سریع تضمین می‌کرد که هر موج جدید بر اساس به‌روزترین یافته‌های موج قبلی شروع شود. برای مدیریت بهینه‌تر این تعاملات، استفاده از معماری‌های رویداد-محور می‌تواند بن‌بست‌های رایج در سامانه‌های چندعاملی را حذف کند و جریان داده‌ها را روان‌تر سازد.

حذف «انحراف زیر-عامل»

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

• زمینه (حقایق تأییدشده): ۵ تا ۱۰ خط درباره آنچه تأیید شده، اینکه کدها کجا قرار دارند و کدام متغیرهای محیطی (Env Vars) تنظیم شده‌اند.
• دارایی‌های پروژه‌های مشابه: ۳ تا ۵ خط برای شناسایی آنچه می‌توان از پروژه‌های خواهر/مشابه بازیافت کرد تا از اختراع دوباره چرخ جلوگیری شود.
• هدف: ۱ تا ۲ پاراگراف توصیف دقیق خروجی مورد نیاز.
• تحویل: بخش‌های صریح و لیست‌شده برای آنچه باید تولید شود (معمولاً هر بخش چند صد کلمه).
• محدودیت‌ها: خط قرمزهایی مثل «هرگز به این فایل دست نزن»، «پاسخ فشرده بین ۵۰۰ تا ۸۰۰ کلمه باشد» یا «هیچ‌گونه جعل داده‌ای صورت نگیرد».
• بودجه: بازه زمانی ۳۰ تا ۴۰ دقیقه‌ای برای اتمام کار.
• مسیر ذخیره: تعیین دقیق مسیر خروجی روی دیسک.

بر اساس مستندات این متد، نرخ انحراف زیر-عامل‌ها تنها حدود ۱۰٪ است و بروز خطا معمولاً به دلیل عدم دقت یا توصیفات ناکافی در بخش «زمینه» است.

مکانیزم بررسی واقعیت

یک دستور حیاتی — «اول دیسک را بخوان، به خلاصه من اعتماد نکن و تضادها را فوراً گزارش کن» — به عنوان یک چک‌لیست واقعیت داخلی عمل کرد. جعل با اعتمادبه‌نفس (Confident Fabrication) بزرگ‌ترین ریسک زیر-عامل‌ها است. در موج W52، سه عامل از چهار عامل، تضادهایی را گزارش کردند که مانع از ۲۰ ساعت اتلاف وقت شد:

• W52-2: اصلاح سوءتفاهم برند؛ مدل تشخیص داد KL برند لوازم آشپزخانه نیست بلکه مربوط به ورزش Pickleball است و کلمه Kitchen به منطقه غیر-والی (Non-volley zone) اشاره دارد. همچنین ۳۰ SKU، بیش از ۱۰۰ صفحه شهر و ۳۰ راهنما را به عنوان لوازم جانبی پیکلبول شناسایی کرد.
• W52-3: شناسایی اینکه مشخصات SleepGuard پیش از این روی اشتراک سیلیکونی Mouth-tape برای DTC توافق کرده و درخواست‌های جدید برای انتخاب بین SaaS/DTC/Content دیگر منسوخ شده‌اند.
• W52-1: تشخیص اینکه اگرچه ۲۲ فایل DocStruct وجود دارند، اما لایه بیزنس تماماً شامل کدهای Stubs (بدون بدنه) است، بخش Checkout به یک product_id جعلی اشاره می‌کند و مسیر src/lib/ روی دیسک کاملاً خالی است.

نقش عامل اصلی

عامل اصلی صرفاً خالق دیگران نیست، بلکه یک یکپارچه‌ساز سطح بالاست. مسئولیت‌های آن عبارتند از:

• بررسی خروجی موج‌ها برای خطاهای سینتکسی، تداخل مسیرها (Path Collisions) و نام‌گذاری‌ها.
• تحلیل دقیق بازگشت‌ها؛ برای مثال در موج W49-2، عامل اصلی یک باگ کوچک در async-wrapping در CLI مدیریت را طی ۵ دقیقه شناسایی کرد.
• به‌روزرسانی فایل‌های handoff/TODO/DECISIONS تا موج‌های بعدی از آخرین واقعیت‌های پروژه آگاه باشند.
• فشرده‌سازی گزارش‌های ۳ تا ۵ هزار کلمه‌ای زیر-عامل‌ها به خلاصه‌های ۲۰۰ تا ۵۰۰ کلمه‌ای برای جلوگیری از فشار به پنجرهٔ زمینه و سقوط کیفیت مدل.
• تصمیم‌گیری اجرایی نهایی درباره پذیرش یا رد پیشنهادات فنی. مثلاً پیشنهاد W50-2 برای به تعویق انداختن Refactor تایپ‌اسکریپت تا سال اول پذیرفته شد، اما پیشنهاد W49-2 برای افزودن لایه KV cache رد شد چون ترافیک فعلی هنوز چنین نیازی را توجیه نمی‌کرد.

عملکرد و محدودیت‌ها

در کل این جلسه، حدود ۵۰۰ کیلوبایت مستندات تولید شد. توسعه‌دهنده شخصاً تنها ۱٬۰۰۰ خط منطق اصلی — مانند توزیع‌کننده وب‌هوک ۱۲-رویدادی، اعتبارسنج‌های HMAC و مهاجرت‌های D1 — را نوشت و کارهای پیرامونی مثل تست‌ها، مستندات و CLIهای مدیریتی را به زیر-عامل‌ها سپرد.

این مقیاس‌پذیری محدودیت عملی دارد. هر خروجی فشرده زیر-عامل حدود ۵۰۰ تا ۱٬۰۰۰ توکن هزینه دارد و سربار عامل اصلی (پردازش، فراخوانی ابزارها و ویرایش‌ها) ۳٬۰۰۰ تا ۵٬۰۰۰ توکن به ازای هر زیر-عامل اضافه می‌کند. با ۱۶ زیر-عامل، حجم زمینه عامل اصلی به ۵۰٬۰۰۰ تا ۸۰٬۰۰۰ توکن می‌رسد. اگرچه مدل‌های با پنجره ۲۰۰ هزار توکن ظرفیت بیشتری دارند، اما کیفیت خروجی با شلوغ شدن جلسه افت می‌کند. حد عملی، ۱۲ تا ۱۶ زیر-عامل در هر جلسه است. برای بازنشانی، از یک سند SESSION_HANDOFF با حجم ۳۰ کیلوبایت برای انتقال وضعیت به جلسه جدید استفاده می‌شود. در این مسیر، پروتکل MCP با جداسازی وابستگی عامل‌ها به ابزارها می‌تواند انعطاف‌پذیری بیشتری در مدیریت این زیر-عامل‌ها فراهم کند.

استراتژی تقسیم وظایف

تجربه نشان داد که یک موج چهار-عامل باید «مکمل» باشد، نه «رقابتی».

• مکمل: یک عامل API را می‌کاود، یکی رقبا را مقایسه می‌کند، یکی کد می‌خواند و دیگری قیمت را طراحی می‌کند. این چهار گزارش غیر-هم‌پوشان مستقیماً به هم متصل می‌شوند.
• رقابتی: چهار عامل را هم‌زمان مأمور کنید تا «برنامه ادغام» بنویسند. نتیجه چهار برنامه متفاوت است که ادغام آن‌ها زمان‌بر است و چرخه پردازش و توکن‌ها را هدر می‌دهد.

گام بعدی شما

• اگر در حال حاضر باگ‌ها را تک‌تک رفع می‌کنید یا APIها را یکی-یکی می‌خوانید، قابلیت پیچیده بعدی خود را به چهار کاوش موازی (کاوش، مقایسه، ساخت و ادغام) تقسیم کنید تا ببینید چقدر می‌توانید خروجی خود را افزایش دهید.
• برای هر زیر-عامل، از یک قالب سخت‌گیرانه شامل «حقایق تأییدشده» و «محدودیت‌ها» استفاده کنید تا نرخ توهم را به زیر ۱۰٪ برسانید.
• نقش خود را از کدنویس به «مدیر ارکستراتور» تغییر دهید. زمان شما باید از تایپ کردن کد به نوشتن پرامپت‌های دقیق (۲ تا ۳ هزار کلمه برای هر موج)، خواندن بازگشت‌ها و استقرار فایل‌ها منتقل شود.
• برای کسانی که نگران تحلیل رفتن مهارت‌ها هستند، این توسعه‌دهنده تأکید می‌کند که انسان باید همچنان هر خط کد تولید شده توسط AI را بخواند و تأیید کند؛ در غیر این صورت، یک باگ در محیط عملیاتی شما را کور خواهد کرد. با مدیریت شخصی منطق هسته و تفویض کارهای پیرامونی، شما همچنان مرجع نهایی می‌مانید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.