私も同じことを考えていたので、nanochatで試しています。例えば、こちらは8人のエージェント(4人のClaude、4つのコデックス)で、それぞれ1つのGPUがnanochat実験を実行しています(logitソフトキャップを削除しようと回帰せずに)。要約すると、うまくいかず、めちゃくちゃです...それでも見ていてとても美しい:) いくつかの構成を試しました:8人の独立した単独研究者、1人の主任科学者が8人のジュニア研究者に仕事を割り当てる、などです。各研究プログラムはgitブランチで、各科学者はそれをフィーチャーブランチにフォークし、孤立にはgit worktree、通信にはシンプルなファイル、現時点ではDockerやVMはシンプルに使っています(指示だけで干渉を防ぐのに十分だと感じています)。研究組織は、Teamsのようなインタラクティブなセッションのtmuxウィンドウグリッドで運営されており、見やすく、個々の作業が見やすく、必要に応じて「引き継ぐ」ことができるので、-pは使いません。 でも、今のところうまくいかない理由は、エージェントのアイデアが最初からかなり悪いからです。たとえ最高知能でも。実験設計を慎重に考えず、少し意味不明なバリエーションを使い、強い基準を作らず適切にアブレートし、ランタイムや失敗の管理もしっかりしません。(例えば、昨日あるエージェントがネットワークの隠れサイズを大きくすると検証損失が改善することを「発見」しましたが、これは全くの誤りです。なぜなら、無限のデータ領域では大きなネットワークほど検証損失が小さくなる一方で、その場合は訓練時間が長くなるからです。なぜ私がそれを指摘しに来たのかはよくわかりません。)彼らは、よくスコープ化され説明されたアイデアを実装するのが非常に得意ですが、創造的に生み出すわけではありません。 しかし目標は、組織(例:「研究機関」)とその個々のエージェントをプログラミングしていることであり、「ソースコード」とは、それを構成するプロンプト、スキル、ツール、プロセスの集合体です。例えば、朝の毎日のスタンドアップは今や「組織コード」の一部になっています。そして、nanochatの事前学習の最適化は多くのタスクの一つに過ぎません(ほぼ評価のようなものです)。そして、任意のタスクが与えられたとき、あなたの研究機関はどれくらいの速さで進捗を生み出しますか?