我也有同样的想法，所以我一直在 nanochat 中玩这个。例如，这里有 8 个代理（4 个 Claude，4 个 Codex），每个代理都有 1 个 GPU 运行 nanochat 实验（试图删除 logit softcap 而不出现回归）。总结一下，它不工作，而且一团糟……但看起来还是很漂亮 :) 我尝试了几种设置：8 个独立的单人研究者，1 个首席科学家给 8 个初级研究者分配工作，等等。每个研究项目都是一个 git 分支，每个科学家将其分叉到一个功能分支，使用 git worktrees 进行隔离，简单的文件用于通信，暂时跳过 Docker/VM 以简化（我发现说明足以防止干扰）。研究组织在 tmux 窗口网格的交互式会话中运行（像 Teams 一样），这样看起来很漂亮，可以看到他们的个人工作，并在需要时“接管”，即没有 -p。 但好吧，迄今为止它不工作的原因是代理的想法一开始就很糟糕，即使在最高智能下也是如此。他们没有仔细考虑实验设计，运行了一些不太合理的变体，没有创建强基线，也没有正确消融事物，没有仔细控制运行时间或 flops。（举个例子，昨天一个代理“发现”增加网络的隐藏层大小可以改善验证损失，这在无限数据情况下是一个完全虚假的结果，因为更大的网络在无限数据情况下会有更低的验证损失，但它训练的时间也更长，我不明白为什么我必须进来指出这一点）。他们非常擅长实施任何给定的、范围明确且描述清晰的想法，但他们并不能创造性地生成这些想法。 但目标是你现在正在编程一个组织（例如，一个“研究组织”）及其各个代理，因此“源代码”是构成它的提示、技能、工具等和流程的集合。例如，早上的每日站会现在是“组织代码”的一部分。而优化 nanochat 预训练只是众多任务之一（几乎像评估一样）。那么——给定一个任意任务，你的研究组织多快能在其上产生进展？