FOREAGENT 这个名字最近在 ACL26 相关的 Auto Research 讨论里出镜率很高。浙大这篇论文之所以被广泛讨论，不是因为又做了一个能自动跑实验的 Agent，而是把关键决策点往前移了一步：在正式跑实验之前，先判断哪个实验方案更值得执行。我第一时间想到的是自己过去那些无效实验清单——很多项目不是模型不行，而是方案选错了方向，或者资源投在了收益最低的环节上。如果你也在做自动研究、Agent 驱动的实验设计，或者只是单纯想减少无效训练和无效调参，这篇博客值得看完。
我会尽量不把讨论停在概念层，而是把它拆成可以落地的判断维度、工作流和排查方法。就算你暂时没有完整复现 FOREAGENT 的代码，也不影响你先在本地实验里试水这套思路。
1. 先理解 FOREAGENT 解决的真正问题
1.1 自动研究里最贵的不是模型，而是决策错误
过去几年，AutoML 和 AutoResearch 的方向大多集中在怎么自动生成特征、自动搜索网络结构、自动挑超参数、自动写代码跑实验。这些工具解决的是“怎么执行”的问题，很少真正解决“该不该执行这个实验”的问题。
结果就是实验数量暴涨，但很多实验从一开始就不值得跑。比如数据没有清洗干净就训练，模型选型和任务不匹配，资源开销远大于预期收益，甚至实验还没跑完就发现评估指标定义错了。这些问题靠调参解决不了，靠增加算力也解决不了，只能回到方案层重新判断。
FOREAGENT 让我觉得有价值的地方，是它把“方案可行性判断”做成了正式研究环节。从公开讨论和论文标题来看，它的核心并不是让 Agent 直接去调用训练脚本，而是在执行之前先对候选方案做一轮评估，让 Agent 只执行那些通过评估的方案。这个思路看起来简单，放进自动研究框架里却会改变整个资源分配方式。
1.2 从执行型 Agent 变成评估型 Agent
传统 Agent 的工作流通常是“接收需求 - 拆解任务 - 调工具 - 返回结果”。这个流程的问题在于，Agent 很容易把“能做”和“该做”混在一起。只要工具能跑通，它就认为方案可行，于是大量计算资源消耗在方案探索上。
FOREAGENT 的做法更像是在执行前增加一道 Gate。候选方案先生成，Agent 按照一套可解释的规则来打分，只有分数达到阈值的方案才会进入真正的实验环境。这个 Gate 可以是 LLM 调用，也可以是一个脚本，还可以是人与 Agent 协作的审批点。核心不是用哪个模型实现，而是把“判断”从隐性决策变成显式流程。
这个变化带来的直接好处是实验成功率会提升，因为大多数无效实验在启动前就被拦住了。坏处也明显：评估本身也有成本，如果评估规则设计得不好，可能把本来值得做的实验也拦截了。所以不能简单理解成“先判断就一定更好”，而是要理解它到底在什么条件下成立。
2. 跑实验前到底要评估哪些维度
要做方案前置评估，第一步不是选模型，而是把评估维度定下来。我一般会从四个方向来看：数据、资源、方法、风险。
2.1 数据与输入条件
数据是最容易被低估的检查项。很多实验方案看起来合理，但实际数据根本拿不到，或者拿到之后格式完全不对，或者标注质量差到不可用。前置评估至少要检查下面几点。
- 数据是否可得：是公开数据集，还是需要爬取，还是需要和合作伙伴申请。
- 格式是否匹配：模型要求的输入格式是否和数据现有格式一致，字段能不能对齐。
- 数据量是否足够：太少会导致过拟合，太多会导致实验周期失控。
- 是否需要清洗：缺失值、重复样本、异常值、时间窗口切分是否正确。
- 标注成本：如果是监督任务，标注一版数据要多少人和多少时间。
这些检查不需要写复杂代码，有时候一个表格就能完成。但对 Agent 来说，需要给它一个明确的检查清单，否则它会默认“文件能加载 = 数据没问题”。这是一个非常常见的失误点。
2.2 资源与运行条件
资源评估要包括硬件、时间、存储和人工干预成本。不要只看显存够不够，还要看任务排队时间、单次运行时长、日志占用的磁盘空间。
判断标准可以这样写：
- 单次小规模实验要多长时间。
- 全量实验要多长时间。
- 训练过程的显存峰值是多少，内存是否够用。
- 输出结果占多大空间，是否需要定期清理。
- 任务失败时有没有自动重试，还是需要人工介入。
在真实环境里，资源评估最好用一次最小样例来验证，而不是靠估算。因为同样的模型在不同框架、不同显卡、不同数据分布下，资源占用差异很大。
2.3 方法与基线预期
方法评估要看三件事：模型是否真实存在、和任务是否匹配、有没有合理的基线作为参照。
模型是否真实存在，包括模型权重能否下载、推理代码能否跑通、依赖环境是否完整。很多研究卡在这里，不是算法不够新，而是某个依赖版本不一致，导致模型加载失败。
和任务是否匹配，要看模型的能力边界。分类任务、生成任务、表格任务、多模态任务对模型的要求完全不同。拿一个擅长文本生成的模型硬套结构化预测，前置评估就应该打低分。
有没有合理基线，决定实验有没有意义。如果所有方法都不如一个简单的 TF-IDF 或者规则方法，那这个研究方向就要重新思考。FOREAGENT 这类系统在做方案评估时，通常会要求候选方案里带有基线对比，否则分数会受到惩罚。
2.4 收益与风险
收益不等于“准确率提升”。有时候一个方案之所以值得做，是因为它让推理速度变快、内存占用变低、结果稳定性变好，或者在少样本场景下泛化更强。前置评估要把这些收益也量化。
风险要写清楚。比如方案 A 理论效果最好，但需要重新训练一个 30B 模型，训练时间可能超过一周，数据清洗成本很高，失败概率也不低。方案 B 效果提升相对小，但只需要在现有模型上做微调，三天内能看到结果。如果目标是快速验证假设，方案 B 可能更值得先做。
我建议给每个方案做一个风险等级：
- 低风险：依赖已有模型，数据规模小，预期可在短时间内完成。
- 中风险：需要中等规模训练或复杂数据处理，可能失败一次。
- 高风险：需要大量计算资源，依赖新环境，或者数据不确定性高。
这个等级不需要非常精确，但可以帮 Agent 在做自动决策时有一个初步的“止损线”。
3. 从 FOREAGENT 的思路到可落地的工作流
直接复现一篇论文需要看官方代码和作者给出的配置。这里讲的是通用落地思路，即使原仓库还没完全整理好，你也能在自己项目里先跑起来。
3.1 先搭一个最小的方案评估器
不要把第一版评估器设计得太复杂。先用一个脚本把候选方案的评估维度列出来，给每个维度打分，最后汇总一个总分。
# 这是示例代码，结构上模拟一个简单的方案评估器 # 实际使用时请根据你的数据和环境调整权重与判断逻辑 def evaluate_scheme(scheme): score = 0 data_score = check_data( path=scheme["data_path"], expected_format=scheme["expected_format"], min_rows=scheme["min_rows"], label_exist=scheme["label_exist"] ) resource_score = check_resource( gpu_required=scheme["gpu_required"], gpu_available=scheme["gpu_available"], time_budget=scheme["time_budget"] ) method_score = check_method( model_name=scheme["model_name"], task_type=scheme["task_type"], has_baseline=scheme["has_baseline"] ) score = 0.4 * data_score + 0.3 * resource_score + 0.3 * method_score return score这个脚本的核心是让判断可复现。每个方案进入正式实验前，都会得到一张“评估票据”，上面写清楚数据分、资源分、方法分，以及最后通过还是拒绝。这样后面出了任何问题，都可以倒查是哪一项判断出了问题。
3.2 用预实验验证“可执行”
评估器只能筛选“看起来可执行”的方案，不能证明“实际可执行”。所以我会在所有候选方案进入全量实验之前，强制加一个最小预实验。
预实验的规模不需要大。比如原计划用 10 万条数据训练，预实验就抽样 1000 条；原计划训练 20 个 epoch，预实验就训练 2 个 epoch；原计划用一个大模型，预实验可能先用一个更小的同结构模型跑通链路。
预实验通过的标准是什么？
- 数据能完整加载，没有编码、路径、字段名问题。
- 模型能完成一次正向和反向传播，显存不爆掉。
- 评估指标能正常计算，不是全为空或者全是 NaN。
- 单次运行时间在可控范围内，方便估算全量运行时间。
只要预实验有一项不通过，先不要继续调参，回到输入侧检查。很多时候问题不在模型，而在数据格式、路径权限或依赖版本。
3.3 多方案时怎么排序和筛选
当候选方案超过 3 个时，不要全部并行跑，也不要只选分数最高的那一个。我建议按下面的顺序处理。
- 先让评估器把所有方案打一遍分。
- 筛掉数据不可用或资源不可行的方案。
- 对剩余方案按分数排序，选 Top 2 到 Top 3。
- 对 Top 3 跑最小预实验。
- 根据预实验的通过情况和时间开销，最终选 1 个方案进入全量实验。
这种做法的好处是：评估器负责大范围快速过滤，预实验负责精细验证，全量实验负责产出最终结论。每一层的成本逐步升高，但不会把预算浪费在早期大量不可行方案上。
4. 在复现或参考 FOREAGENT 时容易踩的坑
好思路不等于好结果。把 FOREAGENT 的思路落地到自己的实验里，有几个坑非常常见。
4.1 评估规则太主观，打分不可解释
如果用 LLM 给方案打分，但既没有固定维度，也没有要求模型输出理由，那这个评估器基本就是一个黑盒。同一个方案可能换一种提问方式，分数就完全不一样。
我会建议每个维度都写清判断标准。比如数据维度：数据路径存在得 1 分，缺失字段超过 5% 不得分，标注样本少于 1000 条不得分。资源维度：预估显存超过可用显存 80% 不得分。方法维度：没有基线对比最多得一半分。这种规则虽然笨，但可解释、可调整，调试起来也方便。
4.2 评估成本反超实验成本
前置评估不是越重越好。如果为了判断一个只需要 5 分钟就能跑完的小实验，却花了一个小时做数据检查、方案打分和预实验，那就是本末倒置。
判断评估成本是否合理的标准很简单：评估花费的时间应该远小于被评估实验的预期运行时间。对于小方案，可以直接跑预实验；对于大方案，才需要用完整的评估器做前置判断。不要把每个任务都套同一个重量级流程。
4.3 把“方案可行”当成了“方案最优”
前置评估通过只能说明这个方案值得执行，不能说明它一定产出最优结果。方案 B 可行，方案 C 也可行，但最终效果取决于很多执行细节。
所以正确的认知是：评估器是做减法的，用来过滤掉高风险、低收益、无法执行的方案；预实验是做验证的，用来确认链路能跑通；最终实验是做决策的，用来得到数据结论。流程结束之后，不要立刻宣称某个方法是“最优”，仍然要看多次运行的平均表现和方差。
4.4 忽略日志与中间结果
自动研究系统最怕的不是失败，而是失败之后不知道发生了什么。很多 Agent 框架只记录最终输出，不记录方案评估理由、预实验参数、失败堆栈和资源占用情况。结果就是模型表现不好时，很难判断是数据问题、模型问题还是评估规则问题。
我在跑这类流程时，会强制要求每个阶段输出一份 JSON 日志，至少要包含方案 ID、时间戳、评估分数、评估理由、预实验状态、错误信息。这样排查问题时就能直接从日志里还原全过程，而不是靠回忆。
5. 用这套思路管理单任务、批量任务和团队协作
FOREAGENT 的思路并不只属于论文场景。放在日常实验管理里，它同样能改善研发流程。
5.1 单任务场景：先写一张实验卡
单任务反而最容易被忽略，因为信息都在自己脑子里，觉得没必要写下来。但只要实验涉及多步调试，就很容易忘记当初为什么选择这个方案。
我会给每个单任务建一张实验卡，内容包括：
- 实验目标：用一句话说清楚想验证什么。
- 输入条件：数据路径、数据量、字段说明。
- 候选方案：至少 2 个，不给自己留“只做一条路”的余地。
- 资源预算：预估显存、内存、单次运行时间。
- 验收标准：什么指标达到多少算通过。
- 回退方案：如果当前方案失败，下一步试什么。
实验卡可以手工写，也可以让一个小助手自动生成。关键是把模糊想法转成可执行、可评估的方案，这在本质上是 FOREAGENT 的轻量版。
5.2 批量任务场景：先赛马，再放量
批量任务最容易犯的错误是“人多力量大”。比如同时开 20 个任务，每个任务都跑全量数据，最后可能全部因为数据格式不一致失败，浪费一整天的算力。
更稳的顺序是：
- 随机抽 2 到 3 个任务做全链路预实验。
- 确认数据加载、模型启动、指标计算都没问题。
- 再分批次放量，先跑 10 个任务，观察成功率。
- 成功率稳定后再扩大到全量。
这个顺序不是为了慢，而是为了把故障控制在最小范围。批量任务里最常见的故障不是模型效果差，而是某些文件解析失败、某些路径不存在、某些样本长度超出模型上限。前置小批量测试主要就是抓这些问题。
5.3 团队协作：统一打分模板和通过标准
如果多人协作，最怕的是每个人对“方案可行”的理解不一样。有人说数据 80% 完整就算可用，有人说必须 100% 完整。如果标准不一致，自动研究系统就会丧失可比性。
团队里最好维护一份统一的方案评估模板，至少包含四个部分：数据、资源、方法、风险。每个部分后面附上检查提示。不要只用分数，还要写理由。比如同样给 3 分，有人是因为显存不足，有人是因为数据量不够，这两者对后续决策的影响完全不同。
6. Agent 没有选对方案时，怎么排查
任何自动评估流程都会出错。FOREAGENT 这类系统的优势不是不出错，而是出错之后有迹可循。
6.1 一套稳定的排查链路
如果 Agent 选了某个方案，最后却跑挂了，我一般按下面的顺序排查。
- 先看评估分数是怎么产生的。评审这个方案的模型是不是用错了评估规则，还是某个维度权重过高。
- 再看输入数据。是不是数据路径、字段名、文件编码在评估阶段和实验阶段不一致。
- 再看资源估计。是不是实际显存比预估高，或者排队时间比预期长。
- 再看预实验。是不是预实验只测了单条样本，没有覆盖边界情况。
- 最后看实验日志。确认失败点是数据加载、模型初始化、训练过程还是评估阶段。
这套顺序不一定能一步到位，但能避免直接盯着模型参数调半天，最后发现只是路径配错。
6.2 一个典型失败回退场景
举个简化例子。Agent 评估了两个方案：方案 A 精度预期高但需要重新训练大模型，方案 B 精度略低但可以基于开源权重微调。评估器给 A 打了高分，因为权重中“预期收益”占比太高。结果全量训练第二天直接 OOM，任务失败。
这时正确的动作不是立刻调低学习率，而是回到评估规则里确认：资源维度是否低估了显存需求？预实验是否只用了极短序列？如果资源维度权重更高，方案 A 可能一开始就不会通过。
回退策略也很明确。如果方案 A 已经执行到一半，先保留中间 checkpoint 和日志，再切到方案 B。不要把所有资源都押在同一个方案上。自动研究系统里的回退不是“失败”，而是正常路径的一部分。能把回退记录做得越完整，下一次评估就越准确。
末尾再留一个建议
我建议你拿到 FOREAGENT 相关代码或思路后，不要急着搭一整套多 Agent 框架。先把“方案评估 - 最小预实验 - 正式执行 - 日志回查”这条最简链路跑通。哪怕只用脚本实现，不用任何 Agent 框架，也能明显减少无效实验。
自动研究真正的价值不是完全取代人的判断，而是把那些可以被规则、数据和预实验验证的判断提前到执行之前。跑实验前先判断哪个方案更值得执行，看起来只是一句话，放到真实研发流程里，就是节省算力、时间、精力的最直接办法。
踩过几次坑之后你会发现，很多失败的实验不是模型不够强，而是方案在进入执行前，根本没有被认真评估过。
