如果说 AlphaFold 解决了一个科学问题，那么现在有一批研究者想解决一个更“自我指涉”的问题：能不能让 AI 自己完成机器学习工程师的全部工作——读数据、写代码、调模型、跑实验、写报告？arXiv 上的新论文 MLExpert 给出了一套系统性的答案。
一、为什么“AI 做机器学习”是一个关键命题
过去两年，我们见证了 LLM 在代码生成领域的爆发式进步。但“写一个函数”和“独立完成一个机器学习项目”之间，隔着巨大的鸿沟。
一个真实的 ML 工程任务是什么样的？拿到一个 Kaggle 竞赛题目或一篇论文的复现需求后，工程师需要：
1. 理解任务：判断这是分类、回归还是生成任务，评估指标是什么
2. 探索数据：分析数据分布、缺失值、特征工程质量
3. 设计方案：选择模型架构、设计训练策略
4. 迭代调试：观察训练曲线，诊断过拟合/欠拟合，调整超参
5. 交付结果：在测试集上验证，整理实验报告
这个流程本质上是长程、开放、需要持续决策的 agent 任务——每一步的选择都会影响后续所有环节。这正是当前 LLM agent 最薄弱的能力区间：不是单步推理不够强，而是在几十上百步的探索中“迷失方向”、重复试错、或者过早放弃。
MLExpert 这篇论文瞄准的正是这个问题：构建一个面向自主机器学习工程的通用智能体模型。这个方向有一个更宏大的名字——AI4AI（AI for AI），其终极愿景是递归自我改进：如果 AI 能自主改进 AI，能力提升就可能从线性变成某种自我加速的过程。
二、MLExpert 的核心设计：从“会聊天”到“会干活”
传统做法是把 GPT-4/Claude 这类通用模型套一个 ReAct 循环，让它在 Jupyter 环境里自己摸索。MLExpert 的思路更进一步：为 ML 工程这个特定领域，专门训练一个通用智能体模型。这里“通用”指的是不局限于某一类 ML 任务——从表格数据到 CV 到 NLP，都能端到端处理。
我们可以用一个架构图来理解这类 agentic ML 系统的工作流：
从工程实现角度看，这类智能体的核心循环可以抽象为如下代码结构（示意性伪代码，展示 agent 与执行环境的交互范式）：
class MLExpertAgent:
"""自主机器学习工程智能体的核心循环"""
def __init__(self, llm, sandbox, memory):
self.llm = llm # 底层/微调后的模型
self.sandbox = sandbox # 隔离代码执行环境(Jupyter/容器)
self.memory = memory # 跨任务经验记忆
def solve(self, task: dict) -> dict:
# 1. 任务理解与规划
plan = self.llm.plan(task["description"], task["metric"])
# 2. 数据探索 (EDA)
eda_report = self.sandbox.run(self.llm.gen_eda_code(task["data"]))
# 3. 端到端迭代：写代码 -> 执行 -> 观察 -> 修正
best_score, best_code = -inf, None
for step in range(self.max_steps):
code = self.llm.gen_training_code(
plan, eda_report,
history=self.memory.recent_experiments(), # 避免重复试错
)
result = self.sandbox.run(code) # 真实执行
self.memory.log(code, result) # 记录经验
if result.score > best_score:
best_score, best_code = result.score, code
if self.llm.should_stop(history=self.memory.recent_experiments()):
break
# 4. 交付
return {"score": best_score, "solution": best_code,
"report": self.llm.write_report(self.memory)}
这段循环里最关键的是 history 和 memory：实验历史的组织方式直接决定了智能体是否会在同一个坑里反复跌倒。这也是 ML 工程类 agent 与普通 coding agent 的本质区别——后者以“代码能否运行”为反馈信号，而前者以“模型指标是否提升”为信号，反馈更稀疏、更嘈杂、延迟更长。
三、评估难题：如何给一个“AI 工程师”打分
这类工作最大的争议点在于评测。目前社区主流的基准包括：
- MLAgentBench：覆盖 Kaggle 竞赛、论文复现等任务的经典基准，衡量端到端完成率与最终性能
- MLE-bench（OpenAI）：从 Kaggle 抽取 75 个竞赛任务，以奖牌区间作为评分标准
- Kaggle 实时榜：最贴近真实世界，但评测成本高、周期长
MLExpert 的定位是“通用智能体模型”——也就是说，它不只是设计一套 prompt 或工具链，而是希望模型本身在训练中习得 ML 工程的通用能力（元学习式的能力内化）。这条路线如果走通，意味着模型面对训练中从未见过的新型任务也能泛化，而不是依赖人工编写的 workflow 脚手架。
值得注意的一个技术趋势是自动化评测本身的自动化。传统人工评分在规模化评估 agent 时成本极高，业界已在探索用 LLM-as-Judge 甚至规则评分系统来替代或降级人工评分——即用 AI 评分先做粗筛，人工只复核高分样本。论文信息中标注的“规则评分（AI 评分降级）”正反映了这种评测流程工程化的实践。
四、冷思考：距离“递归自我改进”还有多远
坦率地说，AI4AI 这个叙事很性感，但需要保持清醒：
第一，评测可能存在过拟合。 Kaggle 竞赛数据和论文代码大量存在于预训练语料中，模型“见过答案”的风险难以完全排除。一个 agent 在 MLE-bench 上拿到金牌水平，可能部分归功于对原始竞赛讨论帖的记忆。 第二，“通用”与“专精”的张力。 顶尖 ML 工程师的价值往往在于对特定领域的直觉（比如做时序预测的人知道什么 trick 在什么场景有效）。通用智能体若缺乏这种深度，可能停留在“合格但平庸”的水平。 第三，递归自我改进的瓶颈可能不在 ML 工程本身。 自动调参、自动搜索架构这些事，AutoML 领域做了十年，收益是真实但渐进的。真正的科学突破依然依赖人类提出好问题、设计好假设——这一点短期内看不到被 agent 替代的迹象。但方向本身毋庸置疑。当 ML 工程的“体力劳动”部分被自动化，人类的角色会进一步上移到问题定义与价值判断。这既是效率革命，也是一次研究范式的迁移。
五、结语
MLExpert 代表的研究路线——用专门训练的通用智能体模型来执行完整的机器学习工程流程——是 AI4AI 方向的一次重要推进。它能否真正引发“递归自我改进”的飞轮，取决于评测的可信度、泛化能力的真实性，以及算力经济性这三个现实约束。对于从业者而言，与其焦虑被替代，不如开始思考：当你的下一个 baseline 是由 agent 一夜跑出来的，你的核心竞争力应该建立在哪里？
