我有同樣的想法，所以我一直在 nanochat 中玩這個。例如，這裡有 8 個代理（4 個 Claude，4 個 Codex），每個代理都有 1 個 GPU 進行 nanochat 實驗（試圖刪除 logit softcap 而不回歸）。簡而言之，它不奏效，而且一團糟……但看起來仍然很漂亮 :) 我嘗試了幾種設置：8 位獨立的單獨研究人員，1 位首席科學家給 8 位初級研究人員分配工作等等。每個研究計劃都是一個 git 分支，每位科學家將其分叉為一個功能分支，使用 git worktrees 進行隔離，簡單的文件用於通訊，暫時跳過 Docker/虛擬機以簡化（我發現指令足以防止干擾）。研究組在 tmux 窗口網格的互動會話中運行（像 Teams 一樣），這樣看起來很漂亮，可以看到他們的個別工作，並在需要時 "接管"，即不使用 -p。 但好吧，迄今為止它不奏效的原因是，這些代理的想法一開始就很糟糕，即使在最高智力下。他們在實驗設計上思考不夠周到，運行一些不合邏輯的變化，沒有創建強有力的基準，也沒有正確地進行消融，沒有仔細控制運行時間或 flops。（舉個例子，昨天一個代理 "發現" 增加網絡的隱藏大小會改善驗證損失，這是一個完全虛假的結果，因為在無限數據範圍內，較大的網絡會有較低的驗證損失，但它也會訓練更長時間，為什麼我必須進來指出這一點並不清楚）。他們非常擅長實施任何給定的範圍明確且描述清楚的想法，但他們不會創造性地生成這些想法。 但目標是你現在正在編程一個組織（例如 "研究組"）及其各個代理，因此 "源代碼" 是構成它的提示、技能、工具等和過程的集合。例如，早上的每日站會現在是 "組代碼" 的一部分。而優化 nanochat 預訓練只是眾多任務之一（幾乎像是一個評估）。那麼——給定一個任意任務，你的研究組在這方面產生進展的速度有多快？