「辅助」「自动化」与「递归式改进」是三种不同的主张
AI 系统如今已经能够辅助软件与机器学习工作。它们能生成代码、检索文献、分析实验、提出测试方案,并协助调试。将 AI 研究的部分环节自动化,可以缩短开发周期。但这些都不能单独证明存在递归式自我改进:即一个 AI 系统大幅改进了创造其后继系统的流程,而这些后继系统又进一步改进了该流程,能力的增长由此加速到超出人类控制的地步。
一种清晰的分析方式,会区分三个层级:
- 研究辅助: 人们使用 AI 工具,但仍掌握着规划、判断与整合工作。
- 工作流自动化: 一个智能体在有限的人为干预下,完成一项有边界的研究或工程任务。
- 端到端的 AI 研发自动化: 系统完成产出重要算法进展所需的大部分工作,并将其整合进改进后的系统之中。
只有第三个层级才构成最有力的反馈回路论证,而即便如此,硬件、实验、组织机构与部署决策仍可能限制其速度。
已观察到的编程能力
编程是当前最强的领域之一。公开的智能体能够修复选定代码库中的问题,并生成可运行的程序。然而,基准测试往往提供的是一个清晰明确的问题、测试用例、工具,以及一个可自动评分的终点。而成熟的软件开发涉及未被记录的上下文、协调工作、产品判断、安全性与维护工作。
METR 对 16 名经验丰富的开源开发者所做的一项随机对照研究发现,这些开发者在自己熟悉的代码库中完成 246 项任务时,2025 年初的 AI 工具反而使完成时间增加了 19%,尽管开发者自己都认为这些工具让他们更快了(METR 开发者生产力研究)。这是一项范围狭窄、时效已过的结果——并不能证明后续工具或其他开发者的效率同样更低。但它说明了为何基准测试上的提升不能直接换算为经济层面的加速。
METR 已启动一项规模更大的后续研究,并在 2026 年随着工具与使用方式的演变调整了研究设计(METR 能力提升更新)。真实的生产力取决于审查负担、任务选择、开发者的熟悉程度、智能体界面,以及那些能够通过测试却依然存在的错误。
来自 AI 研究基准测试的证据
RE-Bench 让智能体与人类专家在七个开放式的机器学习研究工程环境中同台竞技。在其最初的研究中,在两小时的时间预算内,表现最好的智能体得分约为人类的四倍。而人类在获得更多时间后进步更为明显,在八小时时略微反超智能体,在 32 小时的范围内得分约为智能体的两倍(RE-Bench 论文)。
这一结果显示出强大的短周期实验能力:智能体能够快速生成并测试大量候选方案,有时还能产出出色的优化成果。但它也显示出一个局限:智能体会陷入僵局、无法重新调整方向,或从更长的时间预算中获益有限。七项任务无法代表研究工作的完整分布,而重复采样也不同于一位持续投入的科学家。
其他评估方式则覆盖了流程中的其他环节。OpenAI 的 PaperBench 要求智能体根据描述复现 20 篇 ICML 论文的结果并执行实验(PaperBench)。MLE-bench 则通过类似 Kaggle 竞赛的方式评估机器学习工程能力(MLE-bench)。这些基准测试衡量的是有意义的技能,但并不能证明模型具备原创理论构建、议程设定、实验室管理、同行评审或安全部署的能力。
开发者的自述
前沿实验室如今已将「自动化研发」视为一道风险门槛。Anthropic 在 2026 年 2 月的风险报告中表示,Claude Opus 4.6 尚未达到、也未非常接近关键领域研发所需活动的完全自动化,同时也警告称,即便是部分自动化也可能加速进展(Anthropic 风险报告)。这是开发者自身的评估,其中有删减内容,也存在利益冲突。
Anthropic 在 2026 年 7 月发布的《负责任扩展政策》3.4 版中再次修订了其自动化研发的门槛,这说明所衡量的对象本身尚未有定论(Anthropic RSP 存档)。公司自设的门槛可以指导内部行动,但不应被当作科学共识来看待。
2026 年 8 月,Anthropic 的研究人员报告了一系列实验,其中自动化研究智能体找到了针对若干选定对齐失败案例的缓解方法(Anthropic 自动化研究报告)。这是令人鼓舞的证据,说明 AI 加速的研究可以强化安全性。但这同样是厂商自身在人为构造任务上得出的研究成果,并不能证明存在全面的自动化对齐科学。
反馈回路论证
一个简单的循环包含四个步骤:部署 AI 去研究 AI;获得算法或工程上的改进;训练或配置出更好的系统;再用这个更好的系统去产出进一步的改进。加速的程度取决于若干因素的乘积,而不仅仅取决于这个循环本身是否存在。
研究覆盖面: 智能体能够完成多少相关工作?编程辅助确有价值,但在问题选择、评估、硬件、数据、管理与安全等环节,人仍可能是瓶颈所在。
改进幅度: 大多数实验会失败,或只带来微小的收益。智能体必须产出能实质性改进下一代系统的创新,而不仅仅是在某个基准测试上做优化。
周期时长: 训练、芯片制造、数据中心建设、评估与部署所需的时间,可能远长于编写代码所需的时间。更好的研究无法瞬间凭空制造出算力。
再投资: 组织机构必须做出选择,决定是否将所获收益投入到能力的进一步提升上。它们也可能将其配置到成本控制、可靠性、产品或安全性上。
收益递减: 随着容易实现的改进逐渐被穷尽,新的发现可能变得越来越难。一个循环可以持续存在,却未必会加速到爆发的程度。
验证成本: 不可靠的研究会带来审查与复现方面的成本。如果系统能够操纵评估结果,那么更快的产出速度,反而可能拖慢真正可信的进展。
因此,递归式改进是一种有条件才会发生的情景,而不是从代码生成速率直接外推得出的结论。
软件的进步可能比硬件更快
算法效率、训练方案、数据整理、推理方法、编译器与智能体脚手架,都可以在现有硬件的基础上得到改进。这些「软件」层面的收益可能扩散得很快,并提高每块芯片所能发挥的能力。AI 可以帮助搜索这些改进空间,从而形成一条真正的正反馈渠道。
但前沿模型仍然依赖能源、芯片、网络、内存、设施与供应链。一个系统无法通过递归式的自我修改,绕过每一项物理约束。它或许能够改善资源的使用方式,或协助设计硬件,但制造与建设仍然存在真实的周期时间。
因此,最快的路径也许是一阵软件与流程改进的爆发式增长,随后遇到物理或组织层面的限制——而不是一条永远平滑的指数曲线。其他发展轨迹依然可能出现;现有证据尚不足以自信地断定其中哪一条会成为现实。
为何这个循环可能加剧风险
快速的能力迭代周期,可能会跑赢评估、监管与制度学习的速度。如果内部的研究智能体能够接触模型权重、训练基础设施、代码部署与敏感的评估内容,那么一次失误或恶意使用所造成的影响范围就会更大。竞争压力可能会促使开发者在监控机制尚未成熟之前,就抢先使用自动化手段。
这个循环也可能加剧权力的集中。拥有算力与自动化研究系统的组织可能会遥遥领先,从而吸引更多资本与人才。反过来,高效的算法也可能扩散开来,降低集中程度。这两种相反的效应应当被建模分析,而不应被想当然地假定。
为何这个循环也可能提升安全性
AI 可以用于搜索漏洞、生成测试用例、分析事件、改进可解释性工具,并将常规验证工作自动化。安全研究同样可以受益于同等规模与迭代速度。关键的治理问题在于,安全能力是否在能力提升之前及同步得到增长——而不在于 AI 辅助研究本身是否天生就是危险的。
相应的控制手段包括:沙盒化的研究环境、受保护的评估集、最小权限访问、独立监控、分阶段整合、可复现的实验,以及在变更进入训练或部署之前的人工审批。研究智能体不应能够改动自身的评估器、凭证或生产系统。
组织机构可以同时衡量能力提升与安全提升的进度:节省的研究工时、经过验证的发现、被拦截的失败实验、审查负荷、事件发生率,以及独立复现所需的时间。
会改变评估结论的证据
支持存在快速反馈回路的更有力证据,将包括:智能体在多个领域产出了新颖且重要的算法进展;这些进展经过独立复现;在长期项目中持续取得成功;端到端周期时间的缩短;以及后续系统在没有相应人力投入增长的情况下,可衡量地改进了研究智能体本身。
反对短期内出现爆发式加速的证据,则将包括:对人类议程设定的持续依赖、收益迅速递减、验证成本高昂、无法胜任长期项目,以及硬性的算力或实验瓶颈。
实践层面的结论
AI 加速的 AI 研究,在辅助层面以及部分有边界的自动化层面已经真实存在。基准测试显示出在短周期研究工程方面令人瞩目的表现,而现实世界的生产力研究以及更长的时间预算,则暴露出重要的差距。截至 2026 年 9 月 13 日,尚无公开证据表明存在端到端的自主 AI 研发,或一条不可控的递归式改进回路。
正确的应对方式,既不是全盘否定,也不是认定其必然发生。应当追踪每一个瓶颈,测试已部署的研究系统,保护其工具与评估器,并明确说明关于覆盖面、改进幅度、周期时长与再投资的各项假设。