一、事件概述

arXiv 上出现了一篇新论文 《AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks》（arXiv:2609.38288，cs.AI，v1 提交于 2026 年 9 月 29 日）。作者包括 Hongjin Qian、Chaofan Li、Kun Luo、Wenqing Wei、Jianlyu Chen、Shuqi Lu、Yuyang Hu、Hongwang Xiao、Hui Wang、Chaozhuo Li、Qiwei Ye、Zhicheng Dou、Defu Lian、Zheng Liu 共 14 人。

论文的核心主张可以概括为一句话：让 Agent 在测试时反复迭代、把当前解改得更好，这种”自我改进”能力是可以被训练出来的，而且是与领域无关的。

作者把自我改进能力定义为：在测试阶段（test time）对一个解进行迭代式精炼的能力。他们认为这依赖两项互补的子能力：

  • 反思（reflection）：产出一个比当前解更好的解；
  • 长程执行（long-horizon execution）：让这种迭代在几十甚至更多轮之后依然有效，而不是几轮之后就退化。

论文的假设是：这两项能力本身不绑定具体领域，因此可以在那些”天然适合监督”的场景里先学会，再迁移到别的任务上。基于这个假设，AREX-2 从机器学习任务和算法编程任务中合成了长程改进轨迹数据，因为这两个领域都提供可验证反馈（verifiable feedback），并且”奖励持续迭代”——也就是说，多改几轮确实能拿到更好的结果。

在这份数据上训练后，基于 Qwen3.8-27B 构建的 Agent 在多个基准上取得结果，并宣称随着迭代轮数预算（budget of rounds）增加，性能持续提升。

原文提到代码与模型将会发布，但摘要页给出的只是占位链接，具体仓库地址与发布状态原文未说明。

二、关键技术点

1. 问题定义：测试时迭代精炼

论文没有把”自我改进”定义成权重层面的持续学习，而是定义为测试阶段的解迭代：给定一个任务，Agent 不断审视当前解、生成新解、替换旧解，在推理预算内逼近更优结果。这种定义把问题从”改模型”挪到了”改推理过程”，与当下推理时计算（test-time compute）的路线一致。

2. 两项能力为何要分开看

作者把能力拆成 reflection 与 long-horizon execution，理由是：

  • 只有反思没有长程执行，第 2、3 轮之后收益就会衰减甚至震荡；
  • 只有长程执行没有反思，多轮也只是重复采样，不构成”改进”。

这个拆法本身是有工程价值的——迭代能力的天花板往往不是”想不出更好的解”，而是”改了几轮之后开始改坏”。

3. 数据来源：机器学习 + 算法编程

训练数据不是人工标注，而是合成（synthesize）长程改进轨迹。选这两个领域的理由，原文给出的是两点：可验证反馈、以及奖励持续迭代。换句话说，这两类任务有类似单元测试或评测指标的客观信号，可以判断”这一轮是否真的变好了”，从而支持对改进过程本身进行监督。

至于轨迹具体怎么合成、是否使用搜索/拒绝采样/强化学习、训练是 SFT 还是 RL，原文摘要未说明。

4. 基座模型与成绩

Agent 基于 Qwen3.8-27B 构建。原文给出的结果如下：

基准 成绩 所属方向
MLE-bench Lite 81.8 机器学习工程任务
Frontier-CS 70.7 算法/计算机科学任务
BrowseComp 84.0 深度研究（浏览检索）
HLE 52.6 深度研究（人类最后考试）
GAIA 92.2 深度研究（通用助手）
DeepSearchQA 93.8 深度研究（深度搜索问答）

论文强调两点：一是在 ML 与算法编程上训练出的长程反思能力，迁移到了深度研究类任务；二是随着迭代轮数预算增加，性能持续提升。原文没有给出与其他系统的完整对照表，也未说明这些分数的评测配置与对比基线，这部分需要等全文与代码放出后才能判断。

三、对数据科学或 AI Agent 落地的意义

第一，它给出了 ML 工程自动化的一条可行路径。 MLE-bench 系列本身就是”让 Agent 做 Kaggle 式建模”的评测，81.8（Lite 版本）说明 Agent 已经能在有明确评测指标的数据科学流程里，通过多轮”提特征—调模型—看分数—再改”稳定获得增益。对实际的数据科学工作流来说，这比”一次生成一段建模代码”更接近真实工作方式：真实建模本来就是反复试错。

第二，它把”可验证反馈”当成了能力工厂，而不是任务终点。 论文的思路是：在一个有客观信号的领域里学会”怎么变好”，然后把这种元能力搬到没有明确奖励的领域（深度研究、开放问答）。对做 Agent 落地的团队，这意味着可以选择自己业务里反馈最明确的那一段流程（例如有离线评测、有单元测试、有 A/B 指标）来构造长程迭代数据，再迁移到反馈模糊的环节。

第三，多轮预算可换性能，直接对应成本与延迟的取舍。 如果”轮数预算增加、性能提升”这一结论在更细的曲线上成立，那么 Agent 产品的推理成本就可以做成可调档位：简单请求跑几轮，关键任务跑几十轮。这比单纯放大模型参数更容易做资源分配。

第四，迁移的边界仍需验证。 摘要只给出了几个标杆数字，没有说明迁移在什么条件下失效、反思会不会引入”看起来更好但实际更差”的自我欺骗。这恰恰是落地时最需要防的一类失败。

四、我的技术点评

这篇论文最有意思的地方不是分数，而是它对”自我改进”的定义方式。把自我改进锚定在测试时迭代，而不是权重更新，等于回避了持续学习里最麻烦的灾难性遗忘与在线数据分布问题，把难点转移到”数据里有没有长程改进的信号”。这也解释了为什么必须挑 ML 和算法编程：这两个领域能自动判定”这一轮比上一轮好”，监督信号几乎免费。

不过我持三点保留意见。

其一，“长程”到底有多长、曲线是否单调，摘要里看不到。只说了”随着轮数预算增长持续提升”，但没有给出不同基准上的轮数—性能曲线，也没有说明是否出现平台期或回退。工程上真正关心的是”第几轮开始不划算”，这个信息缺失。

其二，从可验证领域迁移到深度研究，机制上并不显然。在 ML 任务里，反思的锚点是评测分数；在 BrowseComp、HLE 这类任务里并没有可调用的验证器，此时”反思”更可能退化成自我一致性检查或复述。84.0 / 52.6 / 92.2 / 93.8 这组数字确实强，但没有基线对比，就无法判断增益来自长程反思数据，还是来自 Qwen3.8-27B 基座本身加长推理。

其三，合成轨迹的数据质量是这类工作的真正瓶颈。自己造数据、自己判定”这轮变好了”，很容易把合成器的偏好一起训进去——模型学到的可能是”符合合成器口味”的改写方式，而不是真正的改进策略。论文摘要没有交代合成流程与去偏手段，这是我最想看到细节的部分。

总结一下：AREX-2 把”可验证反馈 → 长程反思数据 → 跨域迁移”这条链条完整地走了一遍，方向是当前 Agent 研究里少见的”元能力”思路，值得跟踪。但在代码与模型放出、能看到训练细节和轮数曲线之前，我对它的判断是——方法论比数字更有参考价值。

五、原文链接

  • 论文页面：https://arxiv.org/abs/2609.38288
  • arXiv 编号：arXiv:2609.38288v1 [cs.AI]
  • 提交时间：2026 年 9 月 29 日
  • 代码与模型：原文称将会放出（Code will be released / models will be released），具体地址原文未说明