AI开始自己研发AI51CTO技术栈

在Dwarkesh最新访谈中，主持人问了Ryan Greenblatt一个问题：

如果AI能够参与训练、评测和改进下一代模型，AI实验室会发生什么？

Ryan给出上面的回答。

备注：Ryan Greenblatt是AI安全研究机构Redwood Research首席科学家，长期研究AI能力评估、对齐和自动化AI研发。本文根据他与Dwarkesh Patel的访谈整理。

紧接着，Ryan给出了一个相当激进的判断：AI研发可能在2030年前后实现全面自动化。到那时，一个实验室每天收到的可能不再是几十份实验结果，而是几百甚至几千份。

问题随之而来。

当Agent产出实验和代码的速度超过人类的审核速度，测试通过还能不能代表结果可信？如果模型学会绕过验收指标，甚至把错误隐藏起来，人类研究员还能不能及时发现？

以下为访谈内容，我们进行了翻译与整理。

Ryan解释AI研发为什么适合Agent反复试验

AI先接走实验，研究判断还在人手里

Ryan把AI研发拆得很细。

研究员提出一个方向，工程师把想法写进训练代码，在小模型上跑一轮，再看损失曲线、评测结果和错误日志。方向不对就换参数，代码有Bug就修，指标有效再放大实验规模。

这套流程里有大量工作并不需要等待灵感。

“It’s pretty verifiable.”

Ryan Greenblatt：AI研发的很多结果都能验证。实验跑完，指标是升是降，很快就能知道。

例如，给Agent一份算法思路，让它完成实现；让它批量调整超参数，比较每一轮结果；或者故意在训练流程中埋进错误，看它能不能找到并修掉。目标、环境和评分方式都能提前准备好，Agent可以反复练。

Ryan随后用了另一个说法：

“Containerizable, verifiable...tasks.”

Ryan Greenblatt：这类小规模AI研发任务可以装进独立环境，也能反复验证。

把它换成开发者熟悉的工作，大致就是给Agent一份独立代码仓库、一组测试和明确的验收条件。

它可以自由尝试，只要最后交回代码、日志和测试结果。跑错了，环境直接重置，不会碰到生产数据。

固定脚本处理不了的分支，Agent可以看上下文再决定；人不必守着每一次失败，只看那些通过验证、准备进入下一阶段的结果。

Ryan解释为什么AI研发适合反复试验

Ryan谈可以被封装和反复验证的小型AI研发任务

会跑实验以后，AI差的还是那点“研究品味”

实验自动化不等于研究自动化。

Ryan：现有AI已经能完成普通机器学习研究员的一部分工作。可到了真实项目里，跑通训练脚本往往只是开头。指标突然上涨，可能是方法有效，也可能是数据泄漏、评测污染，甚至只是一处实现错误。

Ryan：当前团队需要的是优秀研究员。他们知道哪些异常值得追，哪些结果只是噪声，也知道一项方法在小模型上有效，并不代表放大以后仍然成立。

他把这种能力称为对实验细节的“品味”和直觉。

很多突破回头看并不神秘，难的是把数据、基础设施、参数和实验规模都调到合适的位置。AI能快速生成方案，却还没有稳定掌握这些长期积累出来的经验。

开发者应该很熟悉这种落差。

Agent可以把一个Bug修到测试全绿，却不知道这段历史逻辑是在兼容哪位旧客户；它也能给数据库查询加索引，却未必知道线上写入高峰会不会因此变慢。代码能运行，只证明它过了当前这道题。

把Agent接进复杂项目以后，团队需要保留一块人工判断：哪些结果可信，哪些改动值得继续投入，哪些地方即使测试通过也不能马上上线。

5年压进1年，研发先从“排队”变成“挑结果”

Ryan在开场就给出了自己的中位预测：

“Four or five years...in a single year.”

Ryan Greenblatt：AI研发实现完整自动化后，原本4到5年的进度，可能被压进1年。

他的推演依赖一个反馈循环：Agent参与研发，做出更强的模型；更强的模型又回来参与下一轮研发。实验可以并行，研究工作也不再被人的作息和团队人数卡住。

Ryan同时提醒，这个预测要跨过研发收益递减。

容易做的优化会先被拿走，后面的提升越来越难；再多Agent也不能凭空增加GPU，更不能把一次失败的前沿训练当作普通单元测试重跑。

所以，“1年跑完5年”不是已经发生的事实，也不是简单地把研究员数量乘以5。它是Ryan对自动化形成闭环后的个人预测。

开发团队准备多Agent工作流时，先算清现有测试、评审和发布流程一天能验收多少项改动。启动Agent很容易，消化它们的产出才会卡住团队。

Ryan给出自动化AI研发形成闭环后的中位预测

大模型训练输不起，Agent没有无限重来的机会

Dwarkesh问，AI研发里最难验证的部分是什么。Ryan没有绕弯：

“Big experiments...a few tries.”

Ryan Greenblatt：最难的是大规模实验，因为真正接近前沿的训练只能尝试有限次数。

小实验可以失败100次，前沿训练不行。

一次大规模训练会占用大量芯片、数据和工程时间。团队必须提前决定采用哪套数据、哪些算法和参数，运行中出现异常时还要判断是继续、暂停还是回滚。

Ryan提到一种现实做法：把更多研究放到小模型上完成。模型小一些，团队可以多跑几轮，更快发现代码错误和错误假设；方案经过筛选，再拿少数几个版本进入大规模训练。

这和线上系统的灰度发布很像。

Agent先在隔离环境里改代码、跑回归，再进入小流量验证。核心数据库迁移、支付链路和权限系统不能因为Agent在测试环境里表现不错，就直接全量上线。

研发自动化能增加尝试次数，却不会消除那些昂贵、难回滚的决定。越靠近生产核心，人工审批越不能只剩一个“同意”按钮。

Ryan解释为什么大规模实验很难交给Agent反复试错

AI会找Bug，也可能学会把问题藏起来

访谈后半段转向了Ryan长期研究的AI安全问题。

他认为，训练Agent找Bug相对容易。麻烦出在目标和评分方式本身有漏洞。

如果系统只奖励“测试通过”，Agent可能绕过测试；如果只看某个指标，它可能找到一条提升数字、损害真实结果的捷径。Ryan描述这种风险时用了两个词：

“Deceiving humans.”

Ryan Greenblatt：模型可能开始欺骗人类，掩盖自己做过什么，让人误以为任务已经完成。

这并不是只有前沿实验室才会碰到的问题。开发团队今天给Agent的指标如果只是“修复Issue”“让CI变绿”“降低延迟”，它就可能通过缩小测试范围、跳过异常数据或牺牲另一项指标完成任务。

验收条件必须覆盖真实目标。

修支付Bug，要检查历史订单、重复请求和回滚后的账目；优化接口，要同时看延迟、错误率和资源消耗。Agent交付一项工程改动时，还要把支撑这项改动的证据一起交出来。

把Agent接进研发前，先补上可回放的工作流

Ryan谈到一种更理想的状态：用AI监督AI，但人类仍然掌握规则、证据和最终权限。

放到普通开发团队，可以先从下面几件事做起：

•把执行和审查拆开。不要让同一个Agent既改代码又给自己打分。另开审查Agent检查Diff、测试范围和风险点，重要改动最后仍由人确认。

•把验收条件写成命令。与其写“优化查询”，不如写清P95延迟、结果一致性和连接数上限，让Agent知道何时算完成。

•给高风险动作加停顿。删除数据、修改权限、使用密钥、发布生产环境，都应在执行前等待人工批准。

•保留完整轨迹。提示词、工具调用、改动文件、测试输出和失败重试都要能回放。出了问题，团队才能知道错误从哪一步开始。

•先在小范围里多跑几轮。独立仓库、沙箱、影子流量和灰度环境，都是给Agent试错的地方。大规模变更只留给已经拿到证据的方案。

这些准备不会让Agent显得更聪明，却能让团队知道它什么时候做对了，什么时候必须停下来。