AI Agent开放式研究能力探析：瓶颈与科研助手落地实践

这次不聊某个一键部署包，也不推荐具体的开源模型权重。我们把目光放在一个更根本的问题上：AI agents can't yet do open-ended AI research——AI Agent 目前还做不了开放式的 AI 研究。

这里的“开放式研究”不是指“帮我查几篇论文”或者“写一段训练代码”，而是一条完整链路：从阅读文献、发现领域空白、提出可验证假设、设计实验、跑通代码、分析结果，再到修正方向、收敛结论。当前 Agent 做封闭任务已经不错，但把这个链路整体交给它，仍然没有可靠的端到端方案。

这篇文章会做三件事：第一，拆解开放式研究到底难在哪里，为什么不是“多调几次 prompt”就能解决；第二，给出一套评估 Agent 科研能力的思路，以及当前可以落地的科研助手最小架构；第三，补充接口、批量任务、资源占用和合规边界。如果你正准备在团队里搭一个科研提效工具，这篇文章可以直接作为选型参考。

1. 核心结论速览：开放式研究对 Agent 的要求

先看差距。开放式 AI 研究和传统 Agent 任务在结构上就不是一回事，我用一张表说明：

这张表想说明的是：编程 Agent 能工作，是因为每一步都有编译器、测试集、报错信息这类强反馈信号。研究任务里没有这种信号，或者说信号极稀疏。你让 Agent 提出一个新方法，跑了三天实验，最终指标没有提升，系统并不知道是方法本身不行、实现有 bug、数据选错，还是评估指标不合适。

当前社区的多数评测基准面向的是封闭任务，比如 SWE-bench 测软件工程修复、GPQA 测研究生级问答、MATH 测数学解题、ARC-AGI 测抽象推理。它们都能说明“Agent 会不会做某类题”，但没有一个能回答“Agent 能不能独立开展一项研究”。所以从评测体系看，开放式研究的能力评估本身也还在起步阶段。

2. Agent 能做、不能做的边界

要判断“行不行”，先要把研究工作流拆开。科研工作流里有一部分环节是确定性的，Agent 已经能处理得不错；另一部分是开放性环节，仍然是人工核心。

2.1 已经能做的：科研工作流里的确定性环节

以下环节在现有 Agent 系统中已经具备较高的可用性：

• 文献检索与初筛：给定主题，从论文库召回候选文献，按摘要做初步过滤。
• 代码生成与执行：把 idea 转成标准实验代码，尤其是基于 PyTorch、NumPy、Pandas 的常规流程。
• 数据预处理：清洗表格、格式转换、描述性统计。
• 论文写作辅助：改写段落、生成 LaTeX 模板、整理参考文献。
• 结果解释辅助：把训练曲线、指标表转成自然语言描述。

这些环节的共同点是“指哪打哪”，目标明确、输出可校验。将它们串成一条 pipeline 并不复杂：检索模块负责取回材料，代码沙箱负责跑实验，记忆模块负责记进度，LLM 调度器负责编排。一个最小科研助手，用这种架构可以很快上线。

但注意，这里说的永远是“辅助”。每一环都需要人来确认结果是否可信，尤其是文献筛选和结果解释，模型输出可能流畅但并不可靠。

2.2 做不到的：研究链路里的开放性环节

真正把 Agent 挡住的是研究链路里的开放性环节。

第一，问题发现。研究不是从给定问题开始，而是从“这个领域还有什么没解决”开始。Agent 需要阅读大量文献，判断哪些方向值得投入、哪些问题已经被大量工作填充。问题选择本身就是价值判断，当前 Agent 没有可靠的价值函数，它很容易把“最近论文多”当成“值得研究”，把“没人做”当成“创新方向”，但这两者都不能直接等价于研究价值。

第二，假设生成。提出一个可验证、有信息量的假设，需要领域理解和一定的创造力。大模型能生成大量“听起来合理”的假设，可合理不等于新颖，更不等于可检验。很多假设在形式上是完整的，一旦落到验证环节就会发现缺少可控变量或者没有可用的数据集。

第三，实验设计。给定一个假设，要设计恰当的对照实验、选择评估指标、控制变量。这里 Agent 很容易被“方便计算的指标”带偏，用准确率替代真正反映效果的指标，或者忽略 baseline 设置不当的问题。实验设计错误通常在后期才暴露，返工成本极高。

第四，结果判断。实验跑完了，结果意味着什么？是支持假设，还是需要推翻重来？Agent 习惯把“训练成功”当作“研究结论成立”，把“指标提升”当作“方法有效”。在标准 benchmark 上这或许够用，但开放研究中，指标提升可能是数据泄漏、评估偏差或偶然波动导致的，Agent 很难自主识别这些陷阱。

一句话总结：确定性环节已经能用，开放性环节才是研究的核心。这也是“AI agents can't yet do open-ended AI research”这个判断的最直接技术依据。

3. 为什么开放式研究这么难

如果只是任务边界模糊，那加长上下文、增加推理步数也许能缓解。但开放式研究的难点更深，它牵扯到架构、评估、工具和工程多个层面。

3.1 没有可执行的验证闭环

Agent 在编程任务里能 work，核心原因是每一步都有验证信号。代码写错了会报错，测试不过就是不过。研究任务没有这种即时反馈：你提出一个方法，跑了很多轮实验，最终指标没有提升，系统并不知道该调整方法、改代码、换数据，还是重新审视假设。

这种“反馈稀缺”是研究任务和常规 Agent 任务本质不同的地方。编程 Agent 有编译器和测试集驱动，研究 Agent 缺少一个能自动判断“研究好不好”的 oracle。现在有一些团队尝试用 LLM 当评审者，给研究方案或论文打分，但评审模型本身也存在偏见和幻觉问题，它的判断不能替代真实实验验证。

3.2 长程规划稳定性不足

开放式研究的执行链很长：读文献、写方案、写代码、跑实验、分析、写报告，完整链路往往有几十甚至上百步。每一步都可能出错，而且错误会累积。当前 Agent 在短任务上表现亮眼，但在长程执行中会出现几个典型问题：中途遗忘初始目标、重复执行同一个动作、在分支选择上反复横跳、无法判断“当前是否应该停下来”。

工程上有两个常见缓解方向。一是把任务显式拆成里程碑，写入外部记忆，每个里程碑单独验证；二是引入“反思—修正”循环，定期让模型复盘已完成步骤和初始目标是否一致。这两种方法能改善稳定性，但会显著增加 token 消耗和整体耗时，实际收益需要按场景测试。

3.3 幻觉与事实核查

研究对事实性要求极高。一个引文错误、一个公式写错、一个实验数据记错，都可能让整篇结论失效。大模型的幻觉在开放任务中尤其危险，因为模型没有“是否在编造”的主观感知，它只会流畅地输出一段自信的内容，哪怕这段内容没有依据。

因此，科研 Agent 不能默认模型输出为真。工程上至少要做三件事：检索结果必须附带来源，关键结论必须回到原始数据核对，模型生成的代码必须在沙箱里跑通后才能采纳。没有这些护栏，科研 Agent 的输出只能当参考，不能当结果。

3.4 上下文窗口与状态管理

研究过程积累的信息量远大于单次对话。一篇长论文就可能接近模型上下文窗口上限，更不用说整个研究链路。Agent 需要同时管理已有结论、实验记录、待办事项、失败日志，这已经超出“把更多内容塞进窗口”的思路，必须引入外部记忆和结构化状态。

目前常用方案是：用向量数据库存文献笔记，用任务清单文件记录进度，用实验日志目录保存中间结果。Agent 每次只加载当前任务需要的信息，而不是一次性吞入全部上下文。这种设计更可靠，也更接近一个真实研究助手的运作方式，但它本质是状态管理，不是理解能力。

4. 如何评估 Agent 的科研能力

既然端到端开放研究还无法实现，评估就不能只盯着“它能不能独立完成一项研究”这种问题，而应该把链路拆开，分环节测试。

4.1 分阶段评测，而不是端到端评测

建议把研究能力分成五个独立维度：

• 文献综述能力：给定主题，能否快速筛选出关键文献并提炼核心观点。
• 假设生成质量：能否提出可验证、有信息量、非复述的假设。
• 实验设计合理性：能否生成有对照、有合理指标的实验方案。
• 代码实现正确性：能否把实验方案转成可运行、结果可复现的代码。
• 结果解读与报告生成：能否基于实验结果写出严谨、不夸大的结论。

每一维度单独设计评测任务、单独给分。这样既能看清楚 Agent 在哪些环节已经具备实用价值，也能帮助团队定位瓶颈。比如某系统“代码生成很强但假设生成偏弱”，那团队就会知道它更适合做实验执行助手，而不是研究方向参谋。

4.2 现有基准的边界

社区现有的基准大多是单一能力评测，它们不能回答开放式研究的问题：

• SWE-bench 测的是代码修复，目标明确，有测试集验证。
• GPQA 测的是研究生级知识问答，虽有难度，但答案是唯一的。
• MATH 测的是数学解题，推理路径可验证。
• ARC-AGI 测的是抽象推理，但它更多反映模式泛化能力。

这些基准的共同点是“答案总是存在的”。开放式研究没有标准答案，评估者甚至要在研究完成后反复讨论“这项工作是否真的推进了领域”。所以用现有基准去预测 Agent 的研究能力，结论会明显偏乐观。更稳妥的判断是：现有基准能测“会不会做题”，但还不能测“会不会做研究”。

4.3 一个简单的分阶段评估 prompt 模板

团队内部如果只想快速观察 Agent 的研究倾向，可以先从“假设生成”这个环节测起。下面是一个通用评估模板，适合在两三天内跑出初步感受：

你是一名 AI 领域的研究员。请阅读以下论文摘要列表，找出其中尚未被充分探索的方向，并给出 3 个可验证的研究假设。 要求： 1. 每个假设必须明确说明研究对象、干预方式、预期效果、验证方法。 2. 假设不能是已有论文的直接复述。 3. 用 JSON 输出，字段为 hypothesis、rationale、verification。 论文摘要列表： [粘贴实际摘要]

运行这个测试时，重点不是看假设是否“正确”，而是看三点：Agent 是否会编造一个无法验证的理由；它能否把假设和给定摘要明确区分开；它给出的验证方法是否具体到可以执行。这些观察能让你快速知道当前模型在开放任务上的真实水平。

5. 当前可行的科研 Agent 搭建方案

虽然开放式研究暂时走不通，但科研助手 Agent 是可以落地的。这里给出一套最小可行架构，不绑定具体厂商，可以直接在团队内部验证。

5.1 最小架构

一个可用的科研助手至少包含四个模块：

• 调度器：LLM 主控，负责理解用户需求、拆分任务、调用其他模块。
• 检索模块：调用论文搜索接口，返回候选文献和摘要。
• 代码执行沙箱：隔离运行 Python 脚本，避免模型生成的代码污染宿主机。
• 记忆模块：保存文献笔记、实验记录、任务状态。

模块之间用结构化消息通信。用户提一个任务，调度器拆解后调用检索模块取回材料，再把材料交给代码沙箱做分析，最后由调度器汇总输出。整个过程看起来像一条流水线，但每步都留有人工检查点。

5.2 检索与文献管理模块

检索模块可以包装论文搜索 API，也可以先维护一个本地论文库。一个通用检索请求模板如下：

import requests # 通用检索请求模板，实际接口按你使用的论文服务调整 def search_papers(query: str, top_k: int = 5): url = "https://your-paper-search-service.example.com/search" params = {"q": query, "k": top_k} response = requests.get(url, params=params, timeout=30) response.raise_for_status() return response.json()["results"] results = search_papers("AI agent open-ended research") for item in results: print(item["title"], item["url"])

实际落地时，建议把检索结果写入本地 SQLite 或 JSON 文件，再抽取摘要存入向量库。这样 Agent 后续检索不是每次都打外部接口，而是先查本地缓存，能显著降低延迟和外部 API 成本。

5.3 代码执行与实验记录

代码执行模块必须隔离。不要在宿主机上直接运行 Agent 生成的脚本，推荐用 Docker 沙箱：

# 通用沙箱启动示例，实际镜像和挂载路径需要按项目调整 docker run --rm \ -v /path/to/workspace:/workspace \ -w /workspace \ python:3.11 \ python run_experiment.py

实验记录方面，建议每次实验都写一个 JSON 元文件：实验名、时间、参数、指标、结论。这个文件既给 Agent 读，也给人复核。即使 Agent 的最终总结不可信，人还能回到原始记录检查问题出在哪一步。

5.4 记忆与状态管理

记忆模块更推荐“任务清单加文件缓存”的方式，而不是只靠向量数据库。一份简洁的 PROGRESS.md 可以很好地保存研究状态：

# Research Status ## Current Question [当前研究问题] ## Done - [x] 文献初筛完成，保留12篇 - [x] baseline实验跑通，准确率52.3% ## Doing - [ ] 对比方法A实验，预计2小时 ## Blocked - [ ] 数据B未获得授权，等待回复

文件即状态的好处是调试直观。Agent 每次操作前后读取和更新这个文件，人也能随时打开看到进度。相比纯向量数据库，这种方式在科研场景下更容易排查“Agent 是否偏离方向”的问题。

6. 接口 API 与批量任务视角

科研 Agent 一旦跑通，下一步往往是接入团队内部工具。这里从接口设计和批量任务两个角度给出通用方案。

6.1 把科研助手暴露为 API 服务

推荐把科研 Agent 包装成 HTTP 服务，前端通过任务 ID 轮询结果。同步请求在科研场景很容易超时，因为一次文献分析或实验运行可能持续几分钟甚至更久。

一个通用接口设计：

POST /api/research-task { "task": "对指定列表的论文提取核心方法并生成对比表", "paper_ids": ["p1", "p2", "p3"], "output_format": "markdown" }

后端异步执行任务，返回 task_id，前端轮询状态接口获取结果。实际实现中要注意鉴权，科研任务往往涉及内部数据，接口不应该暴露在不可信网络。

6.2 批量文献处理

批量处理是科研场景最常见的使用方式：给一个论文集，让 Agent 提取方法、指标、结论，生成对比表。Python 调用示例：

import requests import time # 通用异步任务模板，实际接口路径按项目调整 result = requests.post( "http://127.0.0.1:8000/api/research-task", json={ "task": "提取每篇论文的模型名称、数据集、核心指标", "paper_ids": [f"p{i}" for i in range(1, 21)], }, timeout=10, ).json() task_id = result["task_id"] while True: status = requests.get( f"http://127.0.0.1:8000/api/task-status/{task_id}", timeout=10, ).json() if status["state"] == "finished": print(status["output"]) break elif status["state"] == "failed": raise RuntimeError(status["error"]) time.sleep(5)

批量任务设计上要留意三点：单次任务的论文数量不要过多，避免上下文溢出或单次处理时间过长；每个子任务尽量独立，一个失败不影响其他结果；失败任务要有重试机制，并且记录错误日志。

6.3 成本与请求频率

科研 Agent 在推理调用上的成本不可忽视。一个完整 pipeline 可能包含检索、摘要、分析、报告等多个环节，每个环节都要调用大模型。团队应当设计缓存策略：同一篇论文的摘要结果缓存下来，下次直接复用；或者先用本地小模型做粗筛，只有高价值内容才调用更贵的服务。这样能大幅压低长期运行成本。

7. 资源占用与性能观察

科研 Agent 的资源占用分两部分来看。

第一部分是大模型推理资源。如果使用本地开源模型，显存大小和 GPU 算力会直接影响响应速度。不同模型、不同量化等级、不同并发度，显存占用和吞吐差异很大，具体数字必须以本机工具观察为准。一个通用参考是：24GB 显存可以比较从容地运行不少主流通用模型，但这不意味着所有工作负载都够，仍需按实际推理参数测试。

第二部分是外部依赖资源，包括论文检索服务、代码沙箱、数据库。这部分主要消耗网络带宽和 CPU。批量任务并发过高时，很容易触发外部 API 的限流策略，导致任务大面积失败。

性能观察建议关注这几项：

• nvidia-smi看 GPU 使用率和显存占用。
• 请求日志看单次调用延迟。
• 任务队列长度看并发设置是否合理。
• 缓存命中率看重复请求是否过多。

8. 常见问题与排查清单

科研 Agent 的部署和使用过程中，问题主要集中在以下几类：

排在最后但最值得警惕的问题是：Agent 在科研场景中表现得过于“顺滑”。它常常把不确定的内容包装成确定结论输出。排查这种问题没有捷径，只能多问一句：结论有原始数据支撑吗？来源能查到吗？科研场景下，人工复核永远不能省。

9. 最佳实践与合规边界

合规是科研工具很容易忽略、但不能踩的红线。科研 Agent 处理文献、论文、私有数据时，至少要确认以下几点：

• 版权：不要对受版权保护的全文做大规模复制和再发布，只做摘要提取和事实性信息抽取。
• 数据隐私：如果涉及受保护的人类数据或企业内部数据，必须确认已获得授权，部署环境要做网络隔离。
• 学术诚信：Agent 生成的内容需要人工确认后才能进入论文或报告，不能直接作为研究结论；所有引用必须真实可查。
• 多模态素材：一旦涉及人脸、声音等特殊素材，必须保证授权链条完整，避免肖像权、声音权纠纷。

工程实践上，建议按这样的顺序推进：

1. 先跑通最小闭环。第一次部署只让 Agent 完成“给 3 篇论文生成对比表”，不要一上来就做全自动研究。
2. 保留一套可复现配置。模型版本、prompt、依赖环境都要固定，否则结果无法复现。
3. 目录分离管理。输入数据、中间产物、最终输出分开存放，不混在一起。
4. 批量任务加日志和重试。科研任务耗时长，失败不重试会浪费大量时间。
5. API 服务只暴露在可信网络内。增加鉴权，避免被外部调用消耗额度。

10. 现状判断与下一步

回到标题：AI agents can't yet do open-ended AI research。从当前公开能力和评测现状看，这个判断是成立的。但“can't”应该读成“暂时还不行”，不是“永远不行”。Agent 在确定性科研子任务上已经能显著提效，瓶颈集中在问题发现、验证闭环和长程规划三个开放性环节。

如果你正在搭建科研 Agent，第一条建议是先验证文献理解和批量处理能力，这部分最容易出效果；第二条是验证代码生成和实验记录自动化，这个能直接减少重复劳动；第三条才是尝试让它参与研究方向讨论，并且每个关键节点保留人工决策。

最容易踩的坑是期望过高。把 Agent 当成一个能独立完成研究的研究员，你大概率会失望；把它当成一个能读文献、跑实验、写记录的高效助手，你会觉得它确实有用。

后续值得关注的扩展方向包括：反思与自我修正框架的成熟度、外部记忆方案在长任务中的实用性、评测基准从封闭任务向半开放任务迁移的进展，以及多 Agent 协作在研究场景中的真实收益。这些方向都在快速迭代，等到下一次再评估“Agent 能不能做研究”时，结论很可能会比现在乐观一些。