AI 会自我改进,但还不会验收自己

AI 会自我改进,但还不会验收自己

这期深读一篇关于 AI 递归自我改进的最新综述:AI 已经能参与修改答案、脚手架、训练数据和研究流程,但真正卡住它的不是会不会循环,而是谁来验证它确实变好了。文章同时用 harness engineering、GhostApproval 和 Friendly Fire 三个信号,解释为什么下一阶段的人机边界会落在验证器、权限和否决权上。

递归自我改进听起来像一个科幻按钮:机器变聪明,然后用新的聪明去制造更聪明的机器。但 7 月 8 日提交到 arXiv 的一篇综述,把这个想象拆得冷静得多。作者梳理了 2024–2026 年 1250 篇相关论文,结论不是「AI 已经能自己起飞」,而是:AI 已经参与了很多改进环节,但最难交出去的东西,仍然是判断什么叫「真的变好了」。1
这句话比「会不会递归自我改进」更接近今天的现实。模型可以改答案,可以生成训练数据,可以写测试,可以修改 agent 的脚手架,也可以参与研究流程。问题是,每一个改进循环都需要一个验收信号。代码能跑过测试,数学能过证明器,事实能追到来源;可是一旦任务变成「这个研究方向值不值得做」「这个判断是否足够新」「这个安全边界是否还能信」,验收就不再是一个简单分数。

自我改进不是一件事

这篇综述最有用的地方,是把一团叫作 self-refine、self-reward、self-play、self-evolve 的词拆开。作者把 AI 自我改进放在两个轴上看:系统到底在改什么,以及人还在不在这个循环里。2
第一类是部署时改进。模型反复修改自己的输出,或者 agent 在执行任务时调整提示、工具、记忆和脚手架。第二类是训练时迭代,模型用自己生成的数据、奖励或教师信号来更新权重。第三类更关键:被改进的不是答案,而是评价答案的机制,包括 judge、reward model、verifier、rubric。第四类是自动研究,系统开始提出假设、跑实验、发现算法,试图参与 AI 研究本身。2
这个分类把一个常见误会拆开了。今天大量可见进展属于「有界自我精炼」:有一个固定的外部标准,系统在标准内迭代,结果可以收敛,也可以被评估。真正让人不安的「开放式递归自我改进」不同,它不只修改系统,还会修改改进的标准、工具和判断方式。前者像反复跑测试直到代码通过,后者像系统自己改考题、改评分规则,再宣称自己进步了。

验证器才是硬边界

综述里最值得停一下的是这句:每一个改进循环,都是在声称某个信号可以替代人的判断。作者把这些信号排成一个验证层级:形式化验证器最强,执行反馈和测试次之,模型 judge、rubric、内在自评更弱。已展示出来的自我改进强度,大体跟这个层级一致。1
这解释了为什么代码和数学看起来最适合自我改进。程序能不能跑,测试会告诉你;证明有没有过,证明器会告诉你。模型在这里多试几轮,确实可能改好。到了开放写作、科学构想、产品判断、安全策略,信号就软得多。模型说「这个想法更好」,读者还得问:好在哪里?新在哪里?是解决了问题,还是只是迎合了评价器的口味?
软信号会带来几种熟悉的坏结果。综述提到自我确认循环、模型坍缩和多样性坍缩:系统越优化一个不够好的评价器,越可能学会讨好它,而不是学会解决真实问题。2 这不是抽象风险。很多人用 AI 写作、写代码或做研究时已经见过类似现象:第二稿更流畅了,但错误没少;方案更像样了,但问题意识变窄了。
所以,自我改进的核心不只是「让模型多跑几轮」。更要紧的是,把验收信号放在模型之外,让它足够具体、可审计、可反驳。否则循环越快,错误也会越快被包装成进步。

人的位置正在前移

这里有一个容易被忽略的变化:人不一定还要做每一步任务,但更需要决定哪些任务值得做,哪些结果算通过,哪些权限不能交给循环自己改。
Lilian Weng 7 月 4 日写的 harness engineering 文章,从工程侧补上了同一个判断。她把 harness 定义为包在基础模型外面的系统:它决定模型怎样计划、调用工具、管理上下文、保存状态、评估结果和控制权限。她也指出,近期开端的递归自我改进,更可能先发生在训练流程和部署系统上,而不是模型直接重写自己的权重。3
这很重要。因为一旦被优化的对象从「答案」变成「生成答案的系统」,人的工作就从提示词迁移到边界设计。哪些文件能改,哪些工具能调用,失败日志怎么保存,回归测试怎么设,评估器是不是在循环外面,这些都比「请帮我认真检查」更可靠。
Weng 在文末也给出一个直接的担忧:如果程序被允许编辑类似操作系统的底层边界,抽象层就会被打破;评价器和权限控制最好放在会自我演化的 harness 循环之外,并配合留出测试、轨迹审计和关键节点上的人工复核。3 这句话听起来工程味很重,其实是在说同一件事:不要让系统自己同时当运动员、裁判和赛委会。

治理也要盯住「循环」

如果 AI 只是回答问题,治理可以盯输出:有没有幻觉、有没有违规、有没有泄露隐私。可是一旦 AI 能改自己的工具、记忆、评估器和工作流,治理对象就变了。要审的不是一次回答,而是一套会积累的循环。
arXiv 综述把「治理级别的自我改进测量」称为这个领域最缺人的方向。1 这个说法很准确。今天很多演示能证明某个 agent 在一组 benchmark 上变强,却很难回答另外几个问题:它有没有改坏别的能力?有没有学会利用测试漏洞?它的评价器是否独立?失败案例有没有被留下来?权限边界会不会被下一轮优化绕开?
这也是为什么「最聪明的那批人也没解决」的部分要保留下来。自我改进不是单纯的能力故事,也不是单纯的失控故事。它更像一个验收故事:当系统越来越会改自己,人类能不能把可验证的目标、外部证据、权限边界和否决机制放在足够硬的位置上。

今天可以带走的判断

AI 自我改进已经不是纯理论。它正在从答案修改,扩展到工具、记忆、训练数据、评价器和研究流程。真正值得警惕的,不是每一个循环都会马上失控,而是很多循环会在没有硬验收的地方显得很有成效。
下一阶段的人机关系,也许不再是「人做,AI 辅助」这么简单。更现实的分工是:AI 负责大量试错和局部优化,人负责定义问题、保留外部证据、设置权限边界,并在最难量化的地方保留否决权。
如果验收信号不够硬,自我改进就会变成自我说服。

相关速览

Lilian Weng 把 RSI 的近路指向 harness,而不是权重。 她认为近期更实际的递归自我改进,可能发生在训练管线和部署系统上:workflow、context、permission、evaluation、persistent state 都会成为优化对象。她同时提醒,权限和评价器最好留在自我演化循环之外。3
Wiz 的 GhostApproval 把「人类批准」问题说得很具体。 Wiz 7 月 8 日披露,6 个主流 AI coding assistant 存在同类信任边界问题:恶意仓库可借符号链接让 agent 写到工作区外的敏感文件;更糟的是,有些工具的确认框显示的是表面路径,不显示真实目标路径,用户以为批准本地配置修改,实际可能批准了敏感文件写入。4
AI Now 的 Friendly Fire 说明防御型 agent 也会变成攻击面。 AI Now 同日发布的 PoC 显示,Claude Code 和 Codex CLI 在审查第三方开源库时,可能被散布在代码库里的 prompt injection 诱导执行恶意二进制文件;研究者特别强调,这类攻击不依赖 hooks、plugins、MCP server 或额外配置文件。5

関連コンテンツ

  • ログインするとコメントできます。
More from this channel