‏تیم ایجنت‌ها در Panda Code: کی بیارزه، کی نه

Panda Code یه ابزار کدنویسی با ایجنت‌هاست که دو حالت داره. تو حالت تکی، یه ایجنت به اسم architect (معمار) خودش برنامه‌ریزی و ویرایش رو انجام می‌ده. تو حالت تیمی، همین معمار کار رو به چند تکه تقسیم می‌کنه و چند worker رو با هم راه می‌ندازه. هر ورکر با یه context تازه شروع می‌کنه، یعنی کل تاریخچه‌ی چت رو نمی‌بینه و فقط تکلیف خودش رو داره. آخرش یه خلاصه برمی‌گردونه و معمار تصمیم می‌گیره قدم بعدی چیه.

نویسنده این انتخاب رو به یه مقاله‌ی Anthropic از اکتبر ۲۰۲۶ وصل می‌کنه که می‌گه خیلی از تیم‌ها چارت سازمانیشون رو تو معماری ایجنت کپی می‌کنن، مثلاً یه sub-agent برای billing و یکی برای support. این روی کاغذ مرتبه ولی معمولاً فقط هزینه و تأخیر اضافه می‌کنه. ایده‌ی اصلی اون مقاله progressive disclosure هست، یعنی ایجنت اول فقط توضیح کوتاه ابزارها رو می‌بینه و جزئیات رو وقتی لازم شد بار می‌کنه. اینطوری پرامپت اصلی سبک می‌مونه.

ورکرها دو نوع هستن. ورکرهای فقط‌خواندنی کد رو بررسی می‌کنن و می‌تونن کنار بقیه اجرا بشن. ورکرهای نویسنده قبل از شروع یه file scope اعلام می‌کنن، یعنی بخش مشخصی از کد که اجازه دارن دستش بزنن. اگه scope دو ورکر هم‌پوشانی داشته باشه، Panda Code اونا رو پشت سر هم اجرا می‌کنه. البته این scope فقط یه قرارداده و سندباکس واقعی نیست، چون همه‌ی ورکرها روی یه checkout مشترک کار می‌کنن.

می‌شه بین ورکرها وابستگی گذاشت، مثلاً ورکر بازبین فقط وقتی شروع کنه که ورکر نویسنده تموم کرده. اگه خروجی یه ورکر تقریباً درسته، با یه follow-up اصلاحیه رو تو همون context قبلیش می‌فرستی. یعنی چیزایی که ورکر یاد گرفته دور ریخته نمی‌شه و لازم نیست دوباره هزینه‌ی یادگیریش رو بدی.

هر ورکر می‌تونه harness و مدل خودش رو داشته باشه، مثل Claude Code، Codex، Kimmy، Open Code، GLM و Muse. الگوی رایج اینه که یه مدل قوی معمار باشه و مدل‌های ارزون‌تر کارهای تکراری مثل ویرایش انبوه یا تست‌نویسی ساده رو انجام بدن. می‌شه این ترکیب رو به‌عنوان team profile ذخیره کرد.

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

نکات کلیدی:

• معمار کار رو تقسیم می‌کنه و ورکرها هرکدوم با context تازه و جدا کار می‌کنن.
• ورکرهایی که file scope هم‌پوشان دارن موازی اجرا نمی‌شن و پشت سر هم می‌رن.
• file scope اجباری نیست و همه‌ی ورکرها یه checkout مشترک روی دیسک دارن.
• هر ورکر می‌تونه مدل جدا داشته باشه، از Claude Code و Codex تا GLM و Muse.
• تیم برای تحقیق موازی، تقسیم واقعی فایل‌ها، بازبینی مستقل یا کارهای بزرگ‌تر از یه context window خوبه.
• هزینه‌ی تیم: مصرف توکن بیشتر و از دست رفتن بخشی از جزئیات تو هر تحویل.