这次不聊某个一键部署包也不推荐具体的开源模型权重。我们把目光放在一个更根本的问题上AI agents cant yet do open-ended AI research——AI Agent 目前还做不了开放式的 AI 研究。这里的“开放式研究”不是指“帮我查几篇论文”或者“写一段训练代码”而是一条完整链路从阅读文献、发现领域空白、提出可验证假设、设计实验、跑通代码、分析结果再到修正方向、收敛结论。当前 Agent 做封闭任务已经不错但把这个链路整体交给它仍然没有可靠的端到端方案。这篇文章会做三件事第一拆解开放式研究到底难在哪里为什么不是“多调几次 prompt”就能解决第二给出一套评估 Agent 科研能力的思路以及当前可以落地的科研助手最小架构第三补充接口、批量任务、资源占用和合规边界。如果你正准备在团队里搭一个科研提效工具这篇文章可以直接作为选型参考。1. 核心结论速览开放式研究对 Agent 的要求先看差距。开放式 AI 研究和传统 Agent 任务在结构上就不是一回事我用一张表说明维度传统 Agent 任务开放式 AI 研究任务边界明确定义如“修复这段代码”“翻译这篇文档”边界开放研究方向需要自行发现验证方式测试用例、规则匹配、人工检查实验数据、统计显著性、同行评审规划长度几十步以内中间目标清晰数百步以上中间目标需要动态调整失败反馈报错信息明确可重试实验失败可能是方法、数据、假设任一环节出错评估标准单一指标如 Pass1、BLEU、准确率多维综合判据结论本身可能存在争议这张表想说明的是编程 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 cant 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, paramsparams, timeout30) 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: [fp{i} for i in range(1, 21)], }, timeout10, ).json() task_id result[task_id] while True: status requests.get( fhttp://127.0.0.1:8000/api/task-status/{task_id}, timeout10, ).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 输出内容明显编造文献检索模块未生效或模型直接生成引用检查输出中的 URL 是否真实存在强制 Agent 只基于检索结果回答增加引用校验Agent 生成代码运行报错依赖缺失、环境冲突、代码错误查看沙箱错误日志先用最小环境测试依赖再跑完整脚本大批量处理时任务卡住并发过高、外部 API 限流、内存不足查看队列长度和日志降低并发增加超时和重试实验结果不一致随机种子未固定、数据分集不统一检查实验配置固定随机种子记录完整实验参数长任务中途方向偏离任务过长、Agent 状态丢失查看 PROGRESS.md 是否持续更新缩小任务范围增加里程碑检查调用外部 API 频繁失败超时、鉴权失效、频率超限检查 HTTP 状态码增加缓存错峰执行检查鉴权配置排在最后但最值得警惕的问题是Agent 在科研场景中表现得过于“顺滑”。它常常把不确定的内容包装成确定结论输出。排查这种问题没有捷径只能多问一句结论有原始数据支撑吗来源能查到吗科研场景下人工复核永远不能省。9. 最佳实践与合规边界合规是科研工具很容易忽略、但不能踩的红线。科研 Agent 处理文献、论文、私有数据时至少要确认以下几点版权不要对受版权保护的全文做大规模复制和再发布只做摘要提取和事实性信息抽取。数据隐私如果涉及受保护的人类数据或企业内部数据必须确认已获得授权部署环境要做网络隔离。学术诚信Agent 生成的内容需要人工确认后才能进入论文或报告不能直接作为研究结论所有引用必须真实可查。多模态素材一旦涉及人脸、声音等特殊素材必须保证授权链条完整避免肖像权、声音权纠纷。工程实践上建议按这样的顺序推进先跑通最小闭环。第一次部署只让 Agent 完成“给 3 篇论文生成对比表”不要一上来就做全自动研究。保留一套可复现配置。模型版本、prompt、依赖环境都要固定否则结果无法复现。目录分离管理。输入数据、中间产物、最终输出分开存放不混在一起。批量任务加日志和重试。科研任务耗时长失败不重试会浪费大量时间。API 服务只暴露在可信网络内。增加鉴权避免被外部调用消耗额度。10. 现状判断与下一步回到标题AI agents cant yet do open-ended AI research。从当前公开能力和评测现状看这个判断是成立的。但“cant”应该读成“暂时还不行”不是“永远不行”。Agent 在确定性科研子任务上已经能显著提效瓶颈集中在问题发现、验证闭环和长程规划三个开放性环节。如果你正在搭建科研 Agent第一条建议是先验证文献理解和批量处理能力这部分最容易出效果第二条是验证代码生成和实验记录自动化这个能直接减少重复劳动第三条才是尝试让它参与研究方向讨论并且每个关键节点保留人工决策。最容易踩的坑是期望过高。把 Agent 当成一个能独立完成研究的研究员你大概率会失望把它当成一个能读文献、跑实验、写记录的高效助手你会觉得它确实有用。后续值得关注的扩展方向包括反思与自我修正框架的成熟度、外部记忆方案在长任务中的实用性、评测基准从封闭任务向半开放任务迁移的进展以及多 Agent 协作在研究场景中的真实收益。这些方向都在快速迭代等到下一次再评估“Agent 能不能做研究”时结论很可能会比现在乐观一些。