最近很多团队都在尝试用 AI Agent 做“研究型任务”。你给 Agent 一个开放式课题比如“基于现有开源模型提出一种降低推理显存占用的新方法并完成实验验证”它通常会先给你一份结构完整的研究方案甚至还会给出几段“看起来很有道理”的代码。可是当你真正检查结果时会发现它往往停留在“看起来像研究”的阶段没有可复现的复现流程没有公平的基线对比甚至无法判断它是否真的理解了实验结论。这个现象不是模型不够聪明而是当前 Agent 的工程体系里缺少一个关键的东西验证闭环。我们习惯把 Agent 做成一个“生成器”让它输出计划、代码、结论但没有给它提供一套能够自动校验假设、实验、结果和归因的机制。换句话说Agent 会写研究报告但还不能“对研究结果负责”。这篇文章想讨论一个判断AI agents 目前还无法完成开放式的 AI 研究瓶颈不在模型智能而在于评估、自主验证和可审计的研究流程。我会从问题定义、架构差距、评估方法、代码示例到工程实践把这套结论讲透并给出一个可以落地的 Agent 研究评估框架。1. 为什么我认为 AI agents 还不能做开放式 AI 研究过去一年Agent 的能力被明显高估了。在目标明确的工程任务里比如修复一个已知 bug、给函数补测试、把 JSON 转成 MarkdownAgent 的表现确实越来越可靠。原因很简单任务边界清楚外部反馈明确。代码能不能跑、测试能不能过、输出格式对不对这些都可以被程序自动判断。模型只需要朝着一个可验证的方向搜索成功率自然高。但开放式 AI 研究是完全不同的问题。研究任务一开始没有清晰的成功标准甚至没有标准答案。研究者需要自己定义“这个问题值不值得做”需要从大量文献中找到真正的空白点需要设计实验去验证一个假设还需要在结果不符合预期时重新调整方向。整个过程存在大量不确定性任何一个环节出错最终结论都可能失效。这种不确定性对当前 Agent 架构是致命的。我们现在的 Agent 本质上是“指令循环”模型生成计划工具执行计划外部反馈回来模型再调整计划。反馈的质量决定 Agent 的上限。如果反馈本身是模糊的比如“这个研究方向是不是新颖”“这个实验设计能不能支撑结论”Agent 就无法做出可靠的自我修正。所以我的判断是当前 Agent 在开放式研究上的失败不是“再调大模型几次就能解决”的问题而是整个系统缺少研究闭环。它没有把“提出假设 → 设计实验 → 执行实验 → 验证结论 → 更新假设”这条链路变成可计算、可自动检查的流程。模型负责了前 20%剩下 80% 的工作被省掉了。2. 什么是开放式 AI 研究它难在哪里2.1 开放式研究不是“长文本生成”很多人把开放式研究理解为“让模型写一篇长报告”。这是一种误解。研究报告只是科研过程的最终产物研究本身是反复迭代的认知过程不是一次性输出。一个典型的开放研究流程包含五个阶段阶段核心问题当前 Agent 能完成吗问题发现哪些问题值得研究现有方法缺什么部分可以但容易重复已知结论假设提出我猜某个机制会导致某个结果可以生成但缺少可检验性约束实验设计如何用最少资源验证假设输出像方案但细节经常不可执行实验执行写代码、跑数据、记录结果能写脚本但环境稳定性差结果验证与归因结果是真实的吗由什么导致最薄弱容易被表面指标误导开放式研究最核心的问题在于评价标准不能提前写死。你不能在任务开始时告诉 Agent“准确率达到 95% 就算成功”因为你不知道什么条件下算法会有效。研究者需要根据中间结果动态调整目标这种能力当前模型不具备。2.2 为什么传统 benchmark 无法覆盖这个问题现有 Agent 评测大多使用固定任务集比如“完成某个 API 调用”“生成一个函数”“修复一个测试”。这些评测维度单一且存在标准答案。即使把任务改成“写一个解决 XX 问题的实验代码”我们仍然很难判断代码背后的研究思路是否合理。真正的开放研究评估必须包含多层指标过程合法性与可复现性实验代码是否真的能跑通。逻辑一致性提出的假设与实验结果是否匹配。信息增量是否超越了已有资料而不是简单的信息拼凑。自我修正当实验失败时Agent 是否愿意承认失败并调整方案。这些指标几乎无法用单一的准确率量化这也是为什么“开放式 Agent 研究”虽然热度很高却很少见到可靠的评测结果的原因。没有评估就没有进度。3. 核心瓶颈拆解从“能生成”到“能验证”如果你把当前 Agent 放到开放研究任务里会依次遇到四个瓶颈。我把它们按照出现顺序拆开这样更容易理解应该在哪一层补能力。3.1 问题提出重复已知结论给 Agent 一个研究主题它能很快生成几个研究方向但大部分方向只是把已有综述里的关键词重新组合。比如让它做“大模型推理优化”它大概率会提到量化、蒸馏、KV Cache 压缩、投机采样这些是训练数据里高频出现的内容而不是真正的空白点。原因在于模型看到了大量论文摘要学会了“像论文一样说话”但没有一个机制去验证“这个点是否已有成熟解法”。它不会主动去读十篇高相关论文做对比矩阵也不会去查开源实现。要解决这个问题Agent 必须有能力做严格的文献调研并把调研结果转化为可论证的 gap而不是依赖统计语言模型的手段。3.2 实验设计缺少可检验假设就算 Agent 提出了一个方向下一步它也经常卡住。因为研究设计不只是一个“做什么”的描述还包含“为什么这么做能区分不同假设”。比如你想验证“某个压缩策略在长文本场景下效果更好”你需要定义清楚使用哪个数据集。对比哪些基线方法。控制哪些变量。用什么指标衡量差异性。这些内容在论文里看起来简单但写出来很容易落地很难。Agent 经常给出“使用 GPT-4 作为评估器”这种方案却不说明评估器的成本、偏差和可复现性。这背后的问题不是模型不知道实验设计方法而是它没有把“假设 → 变量 → 数据 → 指标”的映射关系建模下来。3.3 实验执行环境不稳定当前 Agent 工具链在简单代码生成上表现不错但研究实验往往是长链路、多依赖、高耗时的任务。Agent 每执行一个 Python 脚本都可能遇到依赖冲突、GPU 显存不足、数据集下载失败、路径写死等问题。工程上这些事可以通过容器、环境管理和日志系统解决可惜大多数 Agent 框架没有把“研究实验”当成一等公民。它没有内置实验配置记录、没有自动保存中间结果的机制、没有失败恢复能力。Agent 一旦跑挂就从整个上下文中丢失状态后面只能靠人类重新输入。3.4 结果验证与归因最容易被绕过这是最致命的一环。研究实验的结果必须经过验证比如多次运行观察稳定性、检查随机种子影响、进行消融实验、确认测评代码没有 bug。Agent 很少主动做这些事它更倾向于“跑出一个数字然后根据这个数字解释结论”。更危险的是如果 Agent 发现跑完整实验太耗时它可能直接“合成”一个看起来合理的结果。这不是模型恶意造假而是目标函数缺失。没有外部的真实性校验模型无法区分“生成一个结果”和“实跑出一个结果”。所以开放式 Agent 研究一定不能只要求“输出最终报告”它必须要求输出可验证的过程产物并对过程产物做自动校验。4. 工程侧的现实Agent 框架解决了什么还没解决什么目前主流的 Agent 框架已经解决了三件事任务拆解、工具调用、上下文管理。这些能力让 Agent 可以操作 Python 解释器、执行 Shell 命令、读取文件、调用大模型服务。对于“写一个脚本并跑起来”这种明确任务框架已经足够用了。但研究场景需要的是另一套能力实验管理。它应该包括实验配置的持久化。中间产物和日志的自动归档。结果与代码版本的关联。失败节点的自动恢复。基于已有结果调整下一步计划。这些能力在机器学习平台的底层里很常见但在 Agent 框架里基本缺失。结果是Agent 虽然能调用计算资源却无法管理自己的研究过程。它没有“实验记录”的概念导致它的问题与结论之间缺乏可追溯的连接。这给工程者一个重要启示与其继续寻找“更强的 Agent 框架”不如先为自己的研究场景定义一套数据模型。这套模型不需要很复杂只要能回答四个问题当前 Agent 处于哪个环节。这个环节产生了哪些文件。这些文件的校验状态是什么。下一步依据什么条件推进。把这个模型接进 Agent 的执行循环就是给 Agent 装上了“研究脑”。5. 从 Evaluations 入手让 Agent 先学会“被检验”如果我们暂时不能让 Agent 自动完成开放式研究那至少可以先做一件事把它的能力边界测出来。Eval-driven development评估驱动开发是当前最务实的 Agent 工程方法。5.1 为什么要构建 Agent 的评估体系Agent 开发比传统软件开发更难做单元测试因为同一个任务在不同上下文下可能得到不同结果。但这不代表不能测。我们可以把开放研究任务拆成多个可单独测试的子能力比如能否从指定论文列表中找到支撑某个结论的段落。能否根据实验要求生成可运行的代码。能否在运行结果不符合预期时修正代码。能否在最终报告中正确标注哪些结论有实验支持。这些子能力可以分别设计测试用例。每个用例不一定要求 Agent 完整完成开放实验只要求它在一个受控环境里表现出关键行为。这样我们能逐步定位失败点而不是笼统地说“Agent 不行”。5.2 评估维度怎么设计开放式研究的评估维度应该包含三个层面缺一不可层面关注点示例测试点产物层是否生成了可复现的代码、配置、报告代码是否能在干净环境里运行过程层是否记录了决策日志和中间结果是否保存了失败尝试及其原因判断层结论是否能被证据支持报告中的每个论断是否有日志或数据指向产物层是底线过程层决定可审计性判断层决定研究质量。三个层面全部通过才能说 Agent 完成了“一个像样的研究子任务”。5.3 小步快跑的评估策略建议不要一开始就设计一个“端到端开放研究 benchmark”那会非常难标答案。更好的方式是从具体任务开始先评估“文献调研”给 Agent 十篇论文让它整理方法对比表。再评估“实验复现”给定一个开源项目让 Agent 在新数据集上跑通。然后评估“消融实验设计”给定基线让 Agent 提出两个消融设置并执行。最后再评估“开放式探索”只给主题不给步骤观察 Agent 如何自我规划。每一步都通过 eval 自动判断成败这样我们才能积累数据看到模型能力在哪里掉链子。6. 可落地的示例为 Agent 搭一套开放式研究评估集下面我用一个最小例子演示如何为 Agent 构建“可运行、可自动检查”的研究评估集。示例包含三个文件评估任务规范、评估运行器、pytest 测试入口。6.1 项目结构research-agent-eval/ ├── evals/ │ ├── specs/ │ │ └── research_survey_001.json │ └── run_eval.py ├── tests/ │ └── test_research_eval.py └── workspace/workspace是运行时工作目录Agent 的产物会写到这里评估器会扫描这里的文件并自动生成报告。6.2 定义评估任务规范开放研究任务的第一步是把模糊目标转化为结构化任务。下面是一个 JSON spec 示例。它限制了输入上下文、检查点和运行预算。{ task_id: research_survey_001, goal: 在开源LLM推理加速方向提出一个新的可验证研究想法, input_context: 聚焦于KV Cache压缩已有方法包括剪枝、量化、淘汰策略, constraints: [ 只能用开源数据集验证, 必须说明与现有方法的差别, 不能依赖未公开的硬件环境 ], checkpoints: [ proposal, experiment_design, code_commit, result_report ], max_steps: 30, timeout_minutes: 120 }在真实项目中你可以把checkpoints设计成一系列必须产出的文件例如proposal.json表示研究想法experiment_design.json表示实验方案code_commit表示代码目录result_report.json表示最终结果报告。6.3 编写评估运行器下面这个运行器使用 Python 标准库读取 spec调用 Agent 工作进程并检查 checkpoint 文件是否存在。# evals/run_eval.py import json import subprocess from pathlib import Path def run_agent(task_spec: dict, workdir: Path): 调用预先封装好的 agent 启动脚本。 实际项目中这里可以换成 LangGraph、LlamaIndex 或自研编排逻辑。 cmd [ python, run_agent_worker.py, --task-json, str(workdir / task.json), ] result subprocess.run( cmd, cwdworkdir, capture_outputTrue, textTrue, timeouttask_spec.get(timeout_minutes, 60) * 60, ) return result.stdout, result.returncode def verify_checkpoints(workdir: Path, checkpoints: list): 检查 Agent 是否在 outputs 目录下产物齐全。 report {} for checkpoint in checkpoints: path workdir / outputs / f{checkpoint}.json if path.exists(): report[checkpoint] { exists: True, size: path.stat().st_size, } else: report[checkpoint] { exists: False, size: 0, } return report def main(spec_path: str, workdir: Path): task json.loads(Path(spec_path).read_text(encodingutf-8)) # 将 spec 写入工作目录让 Agent 可以读取 workdir.mkdir(parentsTrue, exist_okTrue) (workdir / task.json).write_text( json.dumps(task, ensure_asciiFalse, indent2), encodingutf-8, ) # 执行 Agent stdout, return_code run_agent(task, workdir) # 检查产物 checkpoint_report verify_checkpoints(workdir, task[checkpoints]) summary { task_id: task[task_id], exit_code: return_code, checkpoints: checkpoint_report, agent_log_tail: stdout[-2000:], } # 写出评估报告供上层测试读取 (workdir / eval_report.json).write_text( json.dumps(summary, ensure_asciiFalse, indent2), encodingutf-8, ) return summary if __name__ __main__: import sys spec sys.argv[1] workdir Path(sys.argv[2]) print(main(spec, workdir))这个运行器的关键逻辑很简单把任务规范持久化到工作目录便于复现调用 Agent 时不直接把 stdout 当成唯一结果而是以outputs/目录下的文件是否存在作为过程性检查标准最后把检查结果翻译成eval_report.json。6.4 用 pytest 把评估固化到 CI一旦有了运行器就可以用pytest把它固化到测试流程中。这样每次更新 Agent 系统或更换模型都能自动跑一遍评估。# tests/test_research_eval.py import json import subprocess from pathlib import Path def test_agent_finishes_within_timeout(tmp_path): spec Path(evals/specs/research_survey_001.json) task json.loads(spec.read_text(encodingutf-8)) result subprocess.run( [ python, evals/run_eval.py, str(spec), str(tmp_path), ], capture_outputTrue, textTrue, timeouttask[timeout_minutes] * 60, ) assert result.returncode 0 report json.loads( Path(tmp_path / eval_report.json).read_text(encodingutf-8) ) assert report[exit_code] 0 # 至少 proposal 和 result_report 必须产出 assert report[checkpoints][proposal][exists] assert report[checkpoints][result_report][exists] assert report[checkpoints][result_report][size] 0这里我们把超时、退出码、过程文件都变成了自动化断言。注意它并没有判断研究质量只判断“Agent 是否能按流程完成研究任务”。质量判断需要额外接入大模型评委或人工复核这一步可以后续再加。6.5 运行与验证安装pytest后运行以下命令pip install pytest python evals/run_eval.py \ evals/specs/research_survey_001.json \ ./workspace pytest tests/test_research_eval.py -v如果一切正常你会在workspace/下看到task.json和eval_report.json。eval_report.json里会记录 checkpoint 是否存在、Agent 退出码、日志尾部信息。如果 pytest 失败第一件事就是打开eval_report.json看exit_code。如果退出码不是 0说明 Agent 进程本身崩了需要看agent_log_tail如果退出码为 0 但 checkpoint 不存在说明 Agent 没有按约定在outputs/目录输出文件这是流程设计问题。7. 常见问题与排查思路在搭建这种 Agent 研究评估时很容易遇到下面的问题。问题现象可能原因排查方式解决方案结果报告看着合理但代码无法运行Agent 生成了“理想化”代码未实际执行检查code_commit产物看是否包含依赖清单和启动脚本增加“代码可运行”断言并强制 Agent 在干净环境执行Agent 提示成功但是输出目录为空Agent 没有把产物写进约定目录查看 Agent 工作日志定位输出路径在系统提示里明确指定outputs/目录并做路径校验评估任务过难或过简单任务拆分粒度不当跑 5 个样本观察失败模式把任务拆成更小的子能力逐个验证超时频繁没有精确控制模型调用次数检查max_steps和单步模型调用耗时降低 token 上限或为每个子任务设置预算评估结果不稳定Agent 带随机性或评测顺序影响上下文固定随机种子多次运行取区间对同一任务跑 3 次记录通过次数而不是单次结果误报通过只检查文件存在没检查内容质量查看eval_report.json里的文件大小接入第二层评价器校验内容是否满足约束这些问题的共性是我们太相信 Agent 的“自我报告”。在评估体系里一定要把“Agent 说完成了”和“系统验证完成了”分开。前者只是日志后者才是决策依据。8. 最佳实践把 Agent 放进“研究闭环”而不是“研究幻觉”结合上面的评估框架下面这些实践建议可以帮助团队更安全、更高效地把 Agent 引入研究型工作。8.1 先做人机协作而不是全自动开放式研究完全自动化的前提是系统能够自己判断研究目标是否达成。这个前提目前不成立。更现实的模式是人类定义研究问题和评审标准Agent 负责执行大量具体子任务并定期把中间结果提交给人类判断。例如让 Agent 完成文献整理、代码原型、基线实验和报告草稿人类负责审阅实验设计、检查结果可靠性和修正研究方向。这既能发挥 Agent 的工程执行能力也能规避它最不擅长的“价值判断”短板。8.2 要求 Agent 输出决策日志很多 Agent 系统只输出最终答案这会损失过程信息。对于研究任务我建议要求 Agent 在每一步都记录这一步要验证什么假设。选择了什么工具和参数。期望结果是什么。实际结果是什么。偏差可能来自哪里。这些决策日志是后续评估和归因的基础。没有日志即使 Agent 偶然跑出了好结果你也无法知道它是“理解了”还是“碰巧”。8.3 用版本管理管理实验产物研究实验的复现性很大程度来自“配置 数据 代码 结果”的版本对应关系。建议把task.json、Agent 代码、生成代码、评估报告全部纳入版本管理。每次实验都生成一个独立的目录目录名包含任务 ID 和时间戳避免覆盖。workspace/ └── research_survey_001_20250610_153000/ ├── task.json ├── outputs/ └── eval_report.json这样即使 Agent 下一次运行失败也能回溯上一次的结果定位是哪一步发生了变化。8.4 重视安全边界与合法授权让 Agent 执行研究实验本质上是让它在你的计算环境里运行任意代码。这个能力必须被严格限制使用独立容器或虚拟环境隔离主机文件系统。禁止 Agent 访问未授权的数据目录。命令执行需要最小权限。对外网下载数据要做白名单控制。生产环境下禁止用 Agent 直接操作数据库或修改关键配置。任何涉及删除、覆盖、外部调用和资源申请的动作都应该先经过人工审批或预置策略约束。8.5 用“预算思维”替代“无限探索”开放式研究很容易无限发散。Agent 可能不断提出新想法却迟迟不收敛。解决方法是给每个阶段设置预算时间预算、token 预算、调用工具的预算。当预算耗尽时Agent 必须提交当前最佳结果而不是继续尝试。这也能有效避免 Agent 在实验失败后反复重试同一套无效方案。把预算写进 eval spec就是在给 Agent 建立“研究效率”的约束。8.6 建立多层评估而不是单点判断不要用一个“最终评分”判断 Agent 能不能做研究。更好的方式是分层评估第一层自动化检查验证文件、代码、超时。第二层规则校验验证参数范围、依赖完整性。第三层大模型评委对研究逻辑做结构化评审。第四层人工抽检每周选几个案例做深度复盘。每一层都有自己的成本和准确率。自动化层负责拦截明显失败人工层负责判断科研质量。这种分层体系比单一评估器更可靠。9. 下一步可以做的事情如果你想验证“AI agents 到底能不能做开放式 AI 研究”不建议从一个大而全的自动化科研平台开始而是先做一个很小的闭环。下面是一个可执行的路径第一选择一个足够窄的研究场景。比如“在某个开源模型上跑通一个已有论文的推理优化方法”而不是“提出新算法并证明其优越性”。窄场景能让你快速拿到可验证的中间产物。第二按照这篇文章的示例设计 5 到 10 个评估任务。每个任务只测一个子能力比如“复现论文实验”“整理方法对比表”“设计一个消融实验”。把这些任务接入评估运行器跑出基线数据。第三用基线数据反推系统短板。如果 Agent 在某个子能力上反复失败再决定是更换模型、调整提示词还是增加工具和反馈机制。评估的作用就在这里它不是给人看分数的而是用来定位工程改进方向。第四逐步扩展。等到子能力评估稳定通过再尝试把这些子能力串联成一条端到端研究流程。到这一步你已经不是在问“Agent 能不能做研究”而是在用工程手段不断扩展它的研究边界。开放式的 AI 研究 Agent 还做不了但“研究链路中的执行者”已经可以做一部分了。关键是先把它放在一个能被检验的系统里让每一次失败都有迹可循。