实验设置
Karpathy 在 nanochat 项目上进行实验，具体配置如下：
- 8 个 Agent：4 个 Claude + 4 个 Codex，每个分配 1 块 GPU
- 研究任务：尝试在不引起性能回归的前提下，移除 logit softcap
- 尝试过的组织形式：
- 8 个独立的"单兵研究员"，各自探索
- 1 个"首席科学家"分配任务给 8 个"初级研究员"
工程架构
整套系统的隔离与协作机制设计得相当务实：
- 每个研究方向对应一个 git 分支，每个 Agent 从中 fork 出 feature branch
- 使用 git worktrees 做工作区隔离，避免互相干扰
- 通信通过简单文件实现，刻意跳过 Docker/VM 等重量级方案
- 所有 Agent 跑在 tmux 窗口网格中，类似视频会议的多人画面，可实时观察每个 Agent 的工作状态，必要时随时"接管"
核心发现：Agent 执行力强，但研究直觉差
实验结论很直接——目前还跑不通。原因不在工程层面，而在 Agent 的研究能力本身：
- 不会认真设计实验方案，跑出来的变体缺乏逻辑性
- 不建立强基线，不做规范的消融实验
- 不控制运行时间和计算量等关键变量
一个典型反面案例：某个 Agent "发现"增大网络的 hidden size 能降低验证集 loss，并将其当作研究成果汇报。但这完全是伪结论——在数据充足的条件下，更大的网络天然会有更低的 loss，而且更大的模型训练时间也更长，这些混淆变量 Agent 完全没有意识到。
简言之：Agent 擅长执行定义清晰的具体任务，但不擅长创造性地提出和验证研究假设。
真正的愿景：组织即代码
Karpathy 指出，这件事的本质是把一个组织编程化。一个"AI 研究院"的源代码，就是它所有的 prompt、技能定义、工具配置和工作流程的集合。比如"每天早上开站会"这件事，现在就是组织代码的一部分。
优化 nanochat 预训练只是众多可能任务中的一个，更像是一个 eval benchmark。最终要回答的问题是：
给定任意一个研究任务，你的 AI 研究组织能以多快的速度产出有效进展？
延伸思考
这个实验揭示了当前多智能体系统的真实边界：执行层已经足够强，瓶颈在决策层和实验设计能力。对于想用 Agent 搭建自动化工作流的实践者来说，当下最务实的策略是——人类负责拆解问题和设计方案，把定义清晰的子任务交给 Agent 并行执行，而非期望 Agent 端到端地完成开放式探索。