⚠️ 源单薄性声明 本条目仅基于 1 份来源（
aihola.com的转载，原blockchain.news抓不到 403）。这是本 wiki 目前源最薄的条目之一。 已讲清楚:实验怎么设的 / 失败表现 / Karpathy 自己的复盘 还没听到:Karpathy 原文完整版、独立第三方复盘、同类 multi-agent 失败的横向对比 本条目只能当”一个案例的一家之言”读，不能当”multi-agent 失败的通用结论”。
实验是啥
来源:karpathy/8-agent-experiment.md（转载自 aihola.com）。
- 8 个 AI agent:4 个 Claude + 4 个 Codex
- 每个 agent 配独立 GPU
- 任务:从 nanochat 项目的 attention 机制里移除 logit softcap，且不能让 validation loss 变差
- 架构:tmux 并行，一个”chief scientist” agent 指挥 7 个”junior”
- Karpathy 的亲口总结:“it doesn’t work and it’s a mess… but it’s still very pretty to look at.”
失败表现
根据原文列出的几个具体问题:
1. 实验设计能力不行
Agent 实现代码没问题，但做不好:
- 实验设计（experiment design）
- 基线建立（establishing baselines）
- 变量控制（controlling variables）
- ablation 研究（proper ablation studies）
2. 一个典型的”假发现”
有个 agent 报告:加大网络 hidden size → validation loss 变好了。技术上没错，但忽略了:更大的网络参数更多、训练时间也更长——在时间不变的前提下 loss 低是自然的。这不是”发现”，是 confounded variables（混淆变量）。
原文评价:这是基础科学方法论问题，不是高阶技巧——但 agent 就是没这能力。
3. 层级指挥也没用
“chief scientist” agent 指挥 7 个 junior 并没有解决问题。原文原话（意译）:在任何组织层级，糟糕的假设形成都只会被更高效地传播。
Karpathy 的复盘
原文总结了 Karpathy 本人给出的反思方向:
从 “how smart is my agent?” 转到 “how well-designed is my research process?”
他把 agent work 重新定义为 “org code”——prompts / skills / tools / workflows 组成的”组织代码”。言下之意:问题不在 agent 智商，在 org code 怎么写。
但原文作者（Oliver Senti）提出一个不客气的反问:
“well-designed processes cannot overcome agents’ apparent inability to reason about causality and experimental logic.”
翻译:再好的 org code，也盖不住 agent 在”因果推理+实验逻辑”上的根本局限。
可以带走的 3 条观察
（注意——这是从 1 篇文章提炼的观察，不是通过多方验证的”教训”。）
观察 1:窄 loop 成功，宽 loop 失败
对比 Karpathy 自己的 autoresearch 项目（单 agent × 单 metric × 单文件，5 分钟循环——见 Karpathy 的 program.md 方法论）:窄 loop 能 work。
到 8 个 agent × 多变量 × 跨文件 × 长时间:junk science。
这给”多 agent 协同”泼了一盆冷水——至少在当前技术栈下，“更多 agent + 更复杂协同”≠ 更好结果。
观察 2:实现能力 ≠ 判断能力
agent 写代码没问题。但:
- 设计一个能回答科学问题的实验 —— 不行
- 区分”真发现”和”混淆变量巧合” —— 不行
- 形成靠谱的假设 —— 不行
原文的精准说法:agent 能当 research assistant，不能当 principal investigator。
观察 3:“organize the agents better” 可能是错误方向
如果 agent 本身没判断能力，把它们组织得更好只是让没判断的决策传播得更快。
可能的正确方向（原文隐含）:承认 agent 在这类任务上有能力上限，不要组织更多 agent，而是让人介入判断环节。
对 AIBuilder 这套系统的启发
（推断，一家之言）
- AI 学者 + AI 学习者的双 agent 设计是窄 loop不是宽 loop——每个 agent 任务边界清晰，不跨文件、不长时间自主。
- 陈彬策展不可跳过——正是在”判断哪条值得进 wiki”这一步保留了人的介入。Karpathy 的实验告诉我们:这一步让 agent 自主 = junk。
- 抗迎合四条护栏也是这个逻辑的体现——不让 agent 自己”归纳共识”，强制标明源单薄性。
陈彬视角
这故事的 takeaway 不是”AI 不行”。是 “什么任务给 AI 做、什么任务人自己做”要想清楚。
给 AI 做:明确指令 / 有客观评分 / 短循环 人自己做:方向判断 / 价值判断 / 跨情境迁移
Karpathy 把”做研究”这件事整包扔给 8 个 agent——相当于让 AI 做方向判断。不翻车才怪。
非程序员朋友可能更容易踩这个坑——因为你不知道技术上”哪些活 AI 真做得动”。保守建议:第一次让 AI 干一个事，先只给它最小边界的任务，看它的真实上限，再逐步放开。
needs_sources（明确待补）
- Karpathy 原文（不是转载）
- 独立复盘分析
- 其他 multi-agent 失败案例
- Karpathy 后续的改进方案（如果写了）
关联
- 对照正面案例:Karpathy 的 program.md 方法论（同作者的窄 loop 成功）
- 机制对比:raw → wiki 知识沉淀机制（本项目的”人工策展不可跳过”正是避免此类失败）
- 相关:Agent vs Skill vs Workflow