كان لدي نفس الفكرة، لذا كنت ألعب بها في nanochat. على سبيل المثال، هنا 8 وكلاء (4 كلود، 4 كودكس)، مع بطاقة رسومات واحدة لكل منها تجري تجارب nanochat (محاولة حذف سجل الدخول بدون انحدار). الخلاصة هي أن الأمر لا يعمل وهو فوضى... لكنها لا تزال جميلة جدا للنظر :) جربت بعض الترتيبات: 8 باحثين مستقلين منفردين، وعالم رئيسي واحد يعطي عملا ل8 باحثين مبتدئين، وهكذا. كل برنامج بحثي هو فرع git، كل عالم يجمعه إلى فرع ميزات، وgit worktrees للعزل، وملفات بسيطة للاتصالات، وتخطي Docker/VMs للبساطة حاليا (أجد أن التعليمات كافية لمنع التداخل). تعمل منظمات البحث في شبكات نوافذ tmux من الجلسات التفاعلية (مثل Teams) بحيث يكون الأمر جميلا للنظر إليه، ورؤية أعمالهم الفردية، و"السيطرة عليه" إذا لزم الأمر، أي بدون -p. لكن حسنا، السبب في أنه لا يعمل حتى الآن هو أن أفكار العملاء سيئة جدا خارج الصندوق، حتى عند أعلى مستوى ذكاء. لا يفكرون جيدا في تصميم التجارب، ويقدمون بعض التنويعات غير المنطقية، ولا يخلقون خطوط أساس قوية ولا يفصلون الأمور بشكل صحيح، ولا يتحكمون بدقة في مدة التشغيل أو الإخفاقات. (كمثال، اكتشف وكيل أمس أن زيادة حجم الشبكة المخفي يحسن فقدان التحقق، وهو نتيجة زائفة تماما نظرا لأن الشبكة الأكبر ستحصل على خسارة تحقق أقل في النظام اللانهائي للبيانات، لكنها أيضا تتدرب لفترة أطول بكثير، وليس واضحا لماذا اضطررت للدخول وأشير إلى ذلك). هم بارعون جدا في تنفيذ أي فكرة محددة النطاق وموصوفة بشكل جيد، لكنهم لا يولدونها بشكل إبداعي. لكن الهدف هو أنك الآن تبرمج منظمة (مثل "منظمة بحثية") ووكلائها الأفراد، لذا فإن "الشيفرة المصدرية" هي مجموعة من الطلبات والمهارات والأدوات وما إلى ذلك والعمليات التي تتكون منها. على سبيل المثال، أصبح الوقوف اليومي في الصباح جزءا من "قانون المنظمة". وتحسين التدريب المسبق على nanochat هو مجرد واحدة من العديد من المهام (يشبه تقريبا التقييم). ثم - إذا أعطيت مهمة عشوائية، كم سرعة تحقيق جهة البحث الخاصة بك تقدما فيها؟