让Agent自动调模型：TREX用搜索树把LLM微调做成了下棋

你有没有经历过这种痛苦：拿到一个开源模型，想要在自己的业务数据上微调一把，结果从数据清洗到训练策略到超参数调优，一轮实验下来两三天，效果还不如直接用大模型API。

更扎心的是，这个过程几乎没法自动化。传统的AutoML能自动调参，但LLM微调远不只是调参——你得选数据、混比例、定训练方案、做评估诊断，每一环都需要研究者的判断力。现有那些AI研究Agent呢？MLAgentBench上跑跑结构化任务还行，面对真实的LLM训练全流程，基本歇菜。

上海人工智能实验室的这篇TREX，做的事情很直接：把LLM微调的整个生命周期自动化，用多Agent协作+搜索树的方式来组织实验。结果在10个真实任务上，1.7B的小模型被它一路从基线调到了接近甚至超过235B参考模型的水平。

核心摘要：TREX是一个多Agent系统，通过Researcher和Executor两个模块协作，自动完成需求分析、文献检索、数据准备、训练配置、模型评估的完整微调流程。最巧妙的地方在于把多轮实验建模成搜索树——用MCTS策略选择探索路径，用记忆上下文防止重复试错。构建了FT-Bench基准（10个真实微调任务），在所有任务上都能持续优化模型性能，部分任务上1.7B模型微调后甚至超越了235B参考模型。这套方案不是底层算法突破，而是工程整合的标杆——把Agent、搜索树、数据处理管线串成了一条真正能跑通的全链路。

论文信息

• 标题：TREX: Automating LLM Fine-tuning via Agent-Driven Tree-based Exploration
• 作者：Zerun Ma, Guoqiang Wang, Xinchen Xie（共同一作）, Yicheng Chen, He Du, Bowen Li, Yanan Sun, Wenran Liu, Kai Chen, Yining Li（通讯）
• 机构：上海人工智能实验室、复旦大学
• 日期：2026年4月15日
• 链接：https://arxiv.org/abs/2604.14116

为什么LLM微调这么难自动化

先说清楚问题的难度在哪。

传统的机器学习AutoML，搜索空间是明确的——超参数、模型架构、特征工程，目标函数也清晰——validation loss。但LLM微调完全是另一个量级的开放性问题。

数据层面，你得决定用什么数据、怎么混合、怎么清洗、要不要合成数据、合成数据用什么策略。训练层面，全量微调还是LoRA？学习率、batch size、epoch数怎么配？要不要多阶段训练？评估层面，指标选什么、坏案例怎么分析、如何归因？

更关键的是，这些决策不是独立的，而是相互耦合的。数据选择影响训练策略，训练策略影响评估诊断，评估诊断又反过来指导数据选择。一轮实验的结论往往成为下一轮实验的输入。

现有AI研究Agent为什么搞不定？两个硬伤：

1. 训练数据规模太大，塞不进Agent上下文。你没法让Agent直接"看"几万条训练数据来决定数据策略，它只能通过间接手段（统计指标、采样分析）来判断。
2. 单轮实验时间成本高。LLM训练不像代码调试可以秒级验证，一轮实验动辄几小时。进化类框架那种批量生成候选再筛选的方式，在这个场景下效率极低。

TREX的系统架构

Figure 1：TREX在TOMG-Bench分子生成任务上的完整研究过程。左上角是任务输入，右上角展示模型性能随实验轮次的提升，左下角是关键步骤详情，右下角是与人类专家微调结果的对比

Figure 2：TREX系统架构——Researcher和Executor双模块协作，多轮实验建模为搜索树

TREX的核心设计是一个双循环架构：

内循环：Researcher和Executor两个Agent协作完成单轮实验

外循环：多轮实验过程建模为搜索树，用MCTS策略规划探索路径

Researcher：实验设计的大脑

Researcher负责实验方案的设计和结果分析。它的工作方式是由粗到细：

1. 先确定高层改进策略——比如"增强训练数据的多样性"或"探索不同的训练算法"
2. 再把策略细化为具体实验计划——包含数据处理流程、训练配置、评估方案

Researcher还配备了两个关键工具： - 学术搜索引擎：从arXiv检索相关文献，获取前沿方法灵感 - HuggingFace数据集定位器：搜索开源数据集作为训练数据来源

每个实验计划通常包含3-5个并行训练配置，研究数据混合比、超参数等变量的影响。说实话，这个设计挺务实的——并行探索比串行试错效率高得多。

Executor：动手干活的工程师

Executor基于OpenHands实现，核心能力是任务规划和代码实现。它把集群任务调度API封装成工具，能直接在GPU集群上提交和监控训练任务。内置了沙箱系统确保实验环境隔离，防止文件读写操作对集群数据造成风险。

这块有个细节值得注意：TREX没有让Researcher直接操作集群，而是通过Executor做中间层。这样做的好处是职责分离——Researcher专注"想"，Executor专注"做"，避免了单一Agent同时处理高层策略和底层实现的认知负担。

AIDP：数据管线的瑞士军刀

TREX专门为LLM数据管线开发了AIDP（AI Data Processor）库，基于HuggingFace Datasets生态系统构建。这不是一个随便封装的工具集，而是经过精心设计的模块化算子集合：

这个AIDP库的重要性在消融实验里体现得很清楚——没有它，Agent连基本的数据管线都搭不稳，实验中途数据处理失败的概率大幅上升。

搜索树：让Agent像下棋一样做实验

这是TREX最核心的设计。

把多轮实验建模成搜索树，每个节点代表一轮实验的结果。从根节点开始，Agent先做基线实验建立起始点，后续迭代中选择UCT分数最高的节点进行细化。

UCT选择策略

其中\(N_v\)和\(N_{P(v)}\)分别是节点\(v\)及其父节点的访问次数，\(Q_v\)是累积奖励（定义为任务评估指标的归一化值）。

你想想看，这个公式其实在做一件事：在"已知好的方向深挖"和"没试过的方向探索"之间做平衡。前半部分\(\frac{Q_v}{N_v}\)是exploitation——选历史表现好的节点继续深入；后半部分是exploration——选被访问少的节点，防止过早收敛。

这就是MCTS在AlphaGo里用的那套思路。只不过AlphaGo搜索的是棋盘状态空间，TREX搜索的是实验方案空间。

记忆上下文：防止重复造轮子

搜索树最大的好处不只是选择策略，而是信息复用。每轮实验的结果、分析、洞察都存在树节点里，后续实验可以直接参考。TREX用了一个精心设计的记忆上下文机制：

三个组成部分各有分工：

• \(\mathcal{P}(v)\)：路径历史——从根到当前节点的轨迹，告诉你"之前是怎么一步步改进到这里的"
• \(\mathcal{S}(v)\)：兄弟节点——同一父节点下的其他尝试，防止和"兄弟"做同质化实验
• \(\mathcal{C}(Tr)\)：关键洞察——整棵树中产生显著增益或重要失败教训的节点，实现全局知识共享

这个设计我觉得是真的漂亮。路径历史让你不丢上下文，兄弟节点让你不做重复功，关键洞察让你站在全局视野上做决策。三者组合在一起，Agent就不再是"每轮从头想"了，而是"带着记忆做研究"。

实验诊断与归因

每轮实验结束后，TREX不是简单地看分数涨没涨，而是做整体诊断分析：检查验证集的失败案例，分析归因，和历史上的实验做对比。这种"诊断-归因-改进"的闭环，跟有经验的研究者做实验的方式非常像。

FT-Bench：专门为LLM微调评估而生的基准

TREX构建了FT-Bench，包含10个来自真实场景的微调任务：

跟现有基准对比一下就很清楚了：

说实话，之前确实没有专门评估LLM微调自动化的基准。MLAgentBench和ScienceAgentBench更偏通用ML实验，RE-Bench只有一个LLM任务，MLEBench那2个任务也是Kaggle竞赛性质的。FT-Bench覆盖了医疗、化学、生物、金融、法律等多个领域，有提供初始数据的也有需要从头找数据的，任务难度梯度设计得合理。

不过有个问题我得多说一句：10个任务的样本量差异非常大——TOMG-Bench有9万训练样本，EconlogicQA只有260条。这种数据量差异可能导致Agent在不同任务上的优化空间天然不均等，实验结果的跨任务可比性需要打点折扣。

实验结果

主实验

基线模型是Qwen3-1.7B，参考模型是Qwen3-235B-2507。评估用的是归一化相对性能增益：

几个观察：

HoC任务上，1.7B模型微调后直接飙到0.896，远超235B参考模型的0.645。 这说明在特定领域的分类任务上，针对性微调的潜力巨大——235B通用模型的知识反而不如1.7B专项模型。

TOMG-Bench上，Gemini3-Pro做后端拿到了0.681，甚至超过了235B参考模型的0.642。 一个1.7B的模型，经过Agent自动微调，在分子生成任务上打败了比自己大138倍的通用模型。

但也有让人冷静的数据：CS-Bench上只涨了15%，LawBench上Qwen3-Next-80B-Thinking反而比Gemini3-Pro好。知识和推理密集型任务的优化空间确实有限，微调的边际收益递减很快。

性能轨迹

Figure 3左：Gemini3-Pro-Thinking后端在TOMG-Bench上的分数轨迹，最终达到0.681

Figure 4左：Gemini3-Pro-Thinking后端在OpenFinData上的分数轨迹，最终达到0.699

从性能轨迹可以看出，TREX不是每轮都在涨分——中间会有回调和波动，但整体趋势向上。这跟真实研究者的实验体验很像：不是每轮改进都有效，但好的实验策略能保证大方向是对的。

与人类专家对比

在TOMG-Bench上，TREX在Qwen3-1.7B上获得了0.498的性能增益；而人类专家用OpenMolIns-Large在Llama3.1-8B和Llama3.2-1B上分别只提升了0.189和0.139。

在OpenFinData上，TREX在1.7B上获得0.205增益；FEVO的纯RL方案在32B模型上只提升0.025，完整CPT-SFT-RL管线才能提升0.207。

1.7B的模型被Agent调到了接近32B完整管线的水平，这个对比还是很有说服力的。

消融实验

搜索策略消融

对比了三种搜索策略：MCTS、贪心最佳优先搜索（GBFS）、顺序扩展搜索（SES）。

Figure 5左：MCTS vs GBFS vs SES在oMeBench上的对比，MCTS波动最小、一致性最好

MCTS在整个实验过程中表现出更优的稳定性，波动显著低于GBFS和SES。GBFS容易陷入局部最优——总是选当前最好的节点深入，忽略了其他可能有潜力的方向。SES则缺乏全局视野——总是从上次的节点继续，错过了回溯到更优起点的机会。

MCTS的exploration-exploitation平衡在这个场景下确实更合适。

AIDP工具消融

Figure 6左：有/无AIDP工具在oMeBench上的对比，无AIDP性能提升大幅受限

没有AIDP库时，性能改进大幅低于使用AIDP时，而且实验更容易中途因数据处理失败而中断。这个结果不意外——Agent写数据处理代码本来就是最容易出bug的环节，有了封装好的算子，出错的概率大大降低。

坏案例分析消融

Figure 7左：有/无坏案例分析在oMeBench上的对比，分析坏案例带来更有效的迭代

加入坏案例分析后，Agent能更有效地迭代——知道哪里做错了，才能有针对性地改进。这也是为什么TREX的诊断归因机制是必要的。

我的判断

TREX真正值钱的地方在于工程整合，而不是某个单一组件的技术突破。

MCTS做实验规划不新鲜——I-MCTS在2025年就把内省式MCTS用在AutoML上了。OpenHands做Agent执行也不新鲜。AIDP的数据算子更是标准的工程封装。但把这套东西串起来，让一个系统从需求分析到模型训练到评估诊断全链路自动跑通，而且真的能在10个任务上持续涨分——这个工程难度比看起来大得多。

几个值得肯定的点：

1. 搜索树的记忆上下文设计确实精巧，路径历史+兄弟节点+关键洞察三者互补，解决了Agent"每轮从头想"的老问题
2. FT-Bench填补了LLM微调自动化评估的空白，10个任务覆盖多领域、多难度梯度
3. 与人类专家的对比实验很有说服力，1.7B调到接近32B管线的效果不是随便能做出来的

但也有让我皱眉的地方：

1. 对Researcher后端的依赖太重了。Gemini3-Pro做后端在9/10任务上优于Qwen3-Next-80B-Thinking，说明系统性能的天花板很大程度上取决于"大脑"的推理能力。如果Researcher本身就不够聪明，搜索树再精巧也没用。
2. 搜索树的节点粒度太粗。每个节点是一整轮实验（包含3-5个并行配置），而不是单个训练配置。这意味着MCTS的选择其实是在"实验方案"层面做决策，而不是在更细粒度的"超参数"层面。这种粗粒度搜索能否真正逼近全局最优，我觉得存疑。
3. 计算成本没有充分讨论。10个任务各跑约20轮实验，每轮3-5个并行配置，总训练次数在600-1000次之间。这个计算量在研究场景下可以接受，但离"人人可用"还差得远。
4. 任务设计有偏向。4个任务来自化学/生物领域，这些领域的数据通常有清晰的结构化评估标准，Agent比较容易判断好坏。但如果换成更开放的任务（比如创意写作、对话质量评估），Agent的诊断归因能力可能会打折扣。

说到这个，TREX跟同期的AutoML-Agent（ICML 2025）和I-MCTS（EACL 2026 Findings）比，定位其实不太一样。AutoML-Agent关注的是从数据检索到模型部署的全流程AutoML，粒度更粗；I-MCTS关注的是AutoML场景下MCTS的内省式扩展，搜索策略更精细。TREX卡在中间——专注LLM微调这个垂直场景，用工程整合的方式把现有技术串成了可用的全链路。

如果你在做LLM微调的工程化落地，TREX的搜索树+记忆上下文这套框架值得借鉴。尤其是"把实验过程建模成搜索树"这个思路，不限于LLM微调，任何需要多轮试错的优化场景都可以用。但别指望它能替代有经验的研究者——在当前Researcher的推理能力限制下，它更像是"一个靠谱的初级研究助手"，而不是"自动驾驶的研究者"。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我