AI Agent做不了开放式研究？失败模式、边界与辅助落地

把“让一个AI agent独立完成开放式AI研究”这句话提交给任何一个主流agent框架然后等着它自己读论文、设计实验、写代码、跑训练、出报告——这个画面很吸引人。但至少到现在这个阶段我的实测结论更接近那句判断AI agents cant yet do open-ended AI research。它不是单个模型能力不足而是整个自主研究执行循环有很多很难绕开的硬限制。这篇文章想聊的就是为什么做不到、卡在哪些地方以及在明确边界之后我们应该怎么把agent当研究工具用。1. 先把“开放式AI研究”拆成能测试的问题很多人讨论AI agents做科研时会把“能写代码”“能调API”“能跑通一个测试”和“能做研究”混为一谈。实际上这是两个完全不同难度层级的问题。1.1 开放式研究和普通agent任务不在同一个难度层级普通agent任务有一个共同特点边界清楚。比如“完成这段代码的单元测试”“把这份日志里的报错按时间排序”“调用某个接口并返回JSON字段”。这类任务的输入输出都可以被自动校验做得好不好有明确标准路径空间也不大。agent在这些任务上表现很好稳定性和速度都可以接受。但开放式AI研究不是这样。它的任务描述是类似“发现当前多模态模型在小样本学习上的不足并提出一种改进方法”这种级别。这句话里没有任何一个地方告诉你第一步该读哪篇论文应该复现哪个baseline判断基线好坏用什么指标实验失败后换哪个方向什么程度算“改进成功”最终交付的是一份报告、一个模型权重还是一套代码这些决策点在真实科研里恰恰是最核心的智力劳动。现在的agent能做的是“给定一个明确子问题后完成对应的代码、数据或实验脚本”但它很难自主完成“如何定义子问题、如何判断子问题优先级、如何把多个子问题的结果合成一个研究闭环”。1.2 现在agent真正擅长的是边界清晰的任务我并不是说agent在科研里没用。我见过它能做得非常好的场景把某篇论文的代码仓库跑通、把某个数据集从原始格式清洗成训练格式、给一段模型源码补上可复现的配置文件、搜索某个方法在不同任务上的指标。这些任务的共同点是输入明确、输出明确、验收标准明确。当任务达到这种“三明确”状态时agent的自主性才有价值。它能自动尝试多种参数组合、能处理异常路径、能生成中间结果。但一旦任务变回“你自己看着办判断一下什么方向有前景”agent就会开始出问题。这不是某个模型的参数不够大而是当前agent的执行范式在设计上就不是为这种无边界任务准备的。很多人在评估agent能不能做研究时最大的误区是拿一个边界清晰的子任务去测试得出“agent已经能做研究了”的结论。真正的研究任务前置了太多概念判断和价值判断这些部分恰恰是agent目前最薄弱的环节。2. 自己跑过几轮agent研究任务后我看到的真实失败模式我长期做agent工程落地也在探索agent辅助科研的边界。最近一段时间我专门拿一些研究型任务试过不同agent框架和流程包括任务分解、工具调用、自我反思、自我进化这类方向。结果很稳定短任务表现好长任务表现崩开放式任务基本失控。2.1 方向漂移看起来一直在推进实际一直在绕路最典型的问题不是报错而是方向漂移。给agent一个研究目标后它会自己拆成十几个子任务。前两三个子任务还算切题后面就开始不受控地细化一些边角问题。例如让它“对比两种注意力机制在长文本场景下的效果差异”它前几步还会正确选择模型和数据但跑到中段注意力机制本身的对比还没做完它已经开始详细处理一些不相干的数据清洗细节甚至把时间花在优化某个可视化代码的配色上。最后给出的报告看起来内容很多但核心实验没有完成深入度也不够。这种模式我见得非常多。它暴露的问题是agent能执行任务的“下一步”但它不具备“这一步和最终目标的相关性判断”。当路径分支特别多、优先级没有预先定义时它就是会倾向于做那些简单、可执行、能快速产生输出的事情而不是做那些真正重要的科研判断。2.2 验证断档代码能跑通但实验设计支撑不了结论第二种失败模式更难发现也更有欺骗性。agent生成的代码通常能跑通日志也正常最终能输出一份报告。但只要细看实验设计就会发现很多致命问题。常见情况包括没有对照组、训练集和验证集存在信息泄露、随机种子没有固定、某个超参数只调整了一组、消融实验只做了“去掉模块”却没做“加入替代模块”。这些问题不是代码层面的bugagent自己无法判断因为代码运行成功和实验科学有效是两套完全不同的校验逻辑。更麻烦的是当代码输出一个结果后agent倾向于把这个结果当作“实验结论”。如果结果是正面的它就认为假设成立如果是负面的它就放弃这个方向。这种二元处理方式无法处理科研里常见的模糊情况结果在统计上是否有意义、波动范围是否过大、离线指标和真实效果是否匹配。2.3 资源失控没有止损机制时时间成本会明显超预期开放式研究任务不像单次推理任务几秒或几十秒就能结束。它包含大量代码执行、模型训练、数据下载和中间结果计算。一旦流程设计得不好agent会卡在某个环节不断重试或者在死胡同里反复尝试产生大量无效计算。我建议的基础止损手段是给每个任务设定明确的Token预算、时间上限和重试次数上限。不要默认agent“跑得越久结果越好”这个假设在开放式科研任务里基本不成立。时间长更多意味着它把一个低价值方向反复做完了几遍而不是它真的在做有效探索。2.4 自我矛盾长任务下agent会忽略早期结论上下文窗口是目前的硬限制。即使模型能支持很长的上下文agent在长任务里也会出现“一开始定义好的研究假设到后面执行步骤里完全没有被引用”的情况。更有意思的是当你询问它某一步为什么这么做时它会基于当前上下文重新生成一个合理理由而不是引用最初的设计文档。这让“可追溯性”成为最严重的问题之一。在做研究工作落地时每一个实验决策、参数选择、放弃的方向都应该有记录。但agent默认情况下只追求“完成当前这一步”不会自发维护一份研究日志也不会有意识地区分“当时的判断”和“事后的解释”。3. 这些失败不是模型单点能力弱而是整个执行循环有硬限制如果把失败原因简单归结为“模型不够聪明”那就没法找到正确的解法。真正要理解的是agent在执行开放式任务时的完整循环接收目标、拆解任务、调用工具、接收反馈、更新策略、继续执行。这个循环在开放式研究中存在结构性缺陷。3.1 上下文和记忆开放式研究的信息量远超出单个窗口真实研究过程要消耗多少信息开题前要看几十篇论文每篇论文可能有几十页实验过程中要反复对比参数、中间结果和日志实验之间还有大量分支状态需要保留。这是一张庞大的信息网络而不是一段线性文本。当前agent的记忆方式本质上还是“把上下文塞进窗口”或“把信息写入向量库后再检索”。前者会不断挤掉早期结论后者在检索时又会丢失关键关联。研究中真正重要的不是“我记得有个实验结果”而是“我还记得这个实验和当前假设之间的因果关联”。这种结构化记忆agent目前做得非常差。3.2 反馈回路真实科研不是每一步都有即时可判定的反馈普通编程任务里的反馈是即时的测试用例通过/不通过代码运行成功/报错。agent可以在这种强反馈信号下快速调整。但科研里的反馈常常是延迟的、模糊的甚至是相互矛盾的。训练一个模型可能要花一小时训练完才发现数据预处理阶段就已经引入了偏差。这时agent面对的不是一个干净的“成功/失败”信号而是一个需要从根因开始排查的复杂问题。你问agent“这个结果为什么不理想”它会尽力解释但它缺少科研人员那种“能够想到多个潜在因素并设计实验逐一排除”的思维习惯。3.3 知识可信度判断agent还很难区分可靠结论、弱结论和错误结论开放式AI研究需要大量查阅文献、调研现状、判断哪些方法是已被验证的哪些还在争议中。这需要agent对“知识的可信度”有稳定判断。现在的问题是agent更容易把所有检索到的内容放在同一层级导致两种典型症状AI幻觉把检索到的不完整信息直接补充成结论。来源混用把官方文档、个人博客、过时论文、低质量技术文章混在一起引用不加区分。如果只是辅助写代码这个问题影响不大。但做研究时信息可信度直接决定研究立场和实验设计。用错误前提做出来的实验链条后续每一步都会被污染。3.4 工具链与环境自主研究任务里环境问题会被无限放大研究型任务的环境复杂度远高于写个脚本。要跑模型训练、要装CUDA版本匹配的依赖、要处理不同论文代码仓库之间的版本冲突、要下载大型数据集、要管理多个任务的并发资源。这些在真实科研里通常是由人来盯的因为环境问题往往需要领域知识才能判断“是该换版本还是该改代码”。agent不是完全不能处理环境问题它能跑通很多自动安装和重试流程。但一旦遇到“安装成功但运行结果错误”这类环境隐性问题agent就很容易卡住因为它看到的日志是正常的它缺少判断“正常日志下隐藏了什么异常语义”的能力。4. 现在AI agents能用在科研的哪些位置边界在哪里断言“AI agents还做不了开放式科研研究”不等于说agent在科研领域没有价值。它其实能做大量辅助工作。关键在于把任务切到合适的颗粒度并接受“agent是执行力工具不是科研决策者”这个定位。4.1 适合agent辅助的科研任务我常用的agent科研辅助场景基本都是这些类型代码实现根据明确的算法描述、公式或论文段落生成PyTorch或其他框架的代码。数据整理把CSV、JSON、日志文件转换成模型训练或统计需要的格式。代码仓库复现给定一个开源项目自动安装依赖、处理环境问题、跑通最小示例。文献初筛按关键词和范围从文献库中提取候选论文并抽取方法名称、数据集、核心指标。实验脚本生成生成指定模型、指定数据集、指定参数量下的训练和评估脚本。代码审计检查已有代码中的多进程bug、显存管理、数据加载路径等问题。文档格式化把实验结果整理成论文表格、日志摘要或过程记录。这些任务有一个共同点尽管可能复杂但是验收标准相对明确。比如代码能跑通、结果文件格式正确、指标计算准确、复现流程稳定。它们更像“工程实现”而不是“研究设计”。4.2 不适合agent独立完成的科研任务以下是我不建议让agent独立承担的任务判断研究方向是否有价值。提出一个全新的科研假设。设计一组完整且科学的对照实验。判断实验结果是否支持某个结论。评估一篇论文的贡献点和创新点。选择下一步该往哪个方向探索。判断一个指标差异是噪声、波动还是真实提升。这些任务需要对领域有深层理解、对已有工作有全局认知、对实验结果有“统计之外”的判断。当前agent不具备这种能力让它们独立做这些任务产出很容易看起来合理但实际不可信。4.3 判断任务边界的一个核心标准能不能自动验收我在实际操作中判断一个任务能不能交给agent只看一条标准任务完成后验收是否可以通过代码、脚本或确定性规则自动完成。如果验收不需要人来主观判断比如“输出表格是否包含预期的字段”“代码是否能无错跑完”“指标计算是否与官方脚本一致”那么agent可以承担。如果验收必须依赖人的经验判断比如“这一版实验设计是否控制住了变量”“这个结论是否值得写进论文”那么agent就不能独立完成必须由人来做决策agent只能提供辅助材料。这其实把agent的角色从“研究人员”变成了“研究执行器”。执行器的价值不在于做决策而在于用最低成本把决策者指定的动作做完并且给出规范化的结果。科研任务和普通任务在验证方式的差异可以用下面这个表格快速对照任务类型典型例子验证方式适合agent程度代码缺陷修复修复一个报错测试是否通过高数据处理清洗一份数据字段和格式检查高代码仓库复现跑通开源项目是否正常启动并输出结果中高文献初筛找到与主题相关的候选论文人工检查召回质量中实验设计设计对照组和消融实验需要专家判断低研究路径选择判断下一步探索方向需要专家判断低完整研究闭环从选题到结论输出需要学术共同体评审很低5. 怎么判断一个问题适不适合交给agent用三个维度先过一遍很多人并不需要判断“agent能不能做所有开放式研究”他们只需要知道“手头这个具体任务能不能交出去”。我总结了一个三个维度的筛选方法可以在任务开始前快速判断。5.1 维度一反馈能否自动判定先问自己如果agent做到一半我怎么知道它做对了没有如果答案是可以写一个检查脚本、跑一组测试用例、检查输出格式就能判定那这个任务适合agent。如果需要人工阅读实验结果、判断趋势合理性、衡量创新程度那不适合独立交给agent。如果答案是“等它做完我再看”那基本属于放手式研究风险很高。5.2 维度二路径空间是否足够小再问这个任务从开始到结束可能的分支路径多不多如果每个阶段只有几种选择或者可选方案都能预先写在任务文档里agent的表现会稳定很多。如果分支很多并且分支之间没有明确优先级agent很容易在执行中“选错路”。它不会像人类研究者那样因为品味、经验或直觉而避开某些错误方向。路径空间大的任务正确的做法不是让agent自由探索而是由人先定义好搜索边界、候选方案、失败条件和备选路径。5.3 维度三是否需要长记忆才能维持主线再评估这个任务持续多久完成中间步骤时是否需要持续参考最初的假设如果任务在几十分钟内能结束每一步的结果都即时可见agent可以处理。如果任务需要连续推进几天并且后一步的实验设计取决于前几步的结论就要特别小心。长链路任务必须拆成带检查点的短任务。每次检查点都由人来确认“当前结果是否可信、下一步是否继续”。一旦确认后再让agent往下执行。5.4 用一张筛选清单快速定位我在实际落地时会用这样一套快速筛查流程这个任务的最终产物是什么可执行代码、数据文件、报告文档还是研究结论成功标准是什么能用脚本判断还是需要专业评审有没有现成可参考的样例或baseline如果agent运行失败我能通过哪些日志定位问题任务持续时间和预算上限是多少中间输出是否需要人工审核agent产生错误结论时我有没有办法发现如果前三个问题很模糊尤其成功标准不清晰那么这个任务不应该以开放式方式交给agent。我一般会先自己把任务分解成“需要人做判断”和“可以由agent执行”两部分。判断部分人工完成执行部分交给agent。6. 如果你想用agent辅助研究我建议先按这套可控流程搭如果你已经接受“agent不能做开放式研究”的结论但又想让agent真正在科研流程里发挥作用那可以从下面这个可控的半开放流程开始。6.1 把研究目标拆成原子任务而不是交给agent整包执行先把研究目标拆成足够小的原子任务。每个原子任务只做一件事并且这件事能在一个较短的执行周期内完成。例如“复现这篇论文在主数据集上的结果”不是一个原子任务它包含环境安装、数据处理、模型实现、训练配置、指标计算等多个步骤。更好的拆分方式任务一安装这篇文章代码仓库的依赖跑通默认示例。任务二把原始数据集转换为代码仓库要求的输入格式。任务三运行训练脚本使用默认参数输出指标文件。任务四把指标文件和论文中的报告值做对比整理差异表。每个任务之间有一个明确边界。agent完成一个任务后输出结果人工确认无误后再开始下一个任务。这样可以避免agent把多个子任务纠缠在一起出现前面说的方向漂移问题。6.2 为每个任务设置独立验收标准和产物拆分出来的每个原子任务都必须同时满足两个条件有明确产物、有明确验收标准。任务产物可以是日志文件、代码文件、数据文件、可视化图表或指标表格。验收标准最好是代码可检查的。比如“输出CSV必须包含模型名称、种子、准确率三列”“运行脚本必须无错误退出”“训练日志里必须包含每个epoch的loss”。如果某个任务的验收标准只能靠主观感觉那说明它的颗粒度还不够小需要继续拆。把验收标准前置比任务跑完后再讨论“结果行不行”高效得多。6.3 人工检查点放在哪几个位置有些位置一定要保留人工检查点不能跳过实验方案启动前确认实验设计是否合理、对照组是否完整、代码生成方案是否匹配假设。第一轮实验完成后确认结果形态是否符合预期指标计算是否正确。中段结果分歧时如果多个实验的结果相互矛盾需要人来判断是数据问题、代码问题还是假设本身的问题。最终结论生成前不能让agent直接写出“本研究表明……”应该由人基于实验记录做判断。人工检查点的核心价值是阻断错误传导。agent犯的一个小错误如果不及时阻断会在后续任务里被当成前提继续引用最后变成一个难以排查的深层问题。这个现象和代码工程里的“错误累积”非常像。6.4 预算止损和中间产物留档研究任务真正跑起来后最容易被忽略的是预算控制。我建议在任务启动之前就设置以下上限单任务最大执行时间超时后任务自动停止并生成错误报告。单个agent实例的最大调用轮次或Token消耗上限。同一错误路径的最大重试次数超过次数后应当通知人工介入而不是继续循环。并发任务数量避免多个agent同时占用大量计算资源导致环境崩溃。中间产物留档也非常重要。每个原子任务完成后要把日志、配置、输入输出文件统一存放并且用带时间戳的目录命名。这样后续排查时能快速定位某个结果是由哪份代码、哪个参数、哪份数据产生的。没有中间产物的agent辅助科研价值会大打折扣因为你无法判断结果是否可信。做agent辅助科研时真正该盯住的不是它产出什么结论而是它把哪些中间信息变成了结论、中间信息是否可追溯。只要中间过程可控即使agent某个环节出错也能在几小时内定位到问题并修正。7. 结论它是很强的研究助手但不是独立研究人员写了这么多核心结论其实很简单AI agents在开放式AI研究上可能还做不到但在有边界的研究辅助任务上已经非常实用。关键是不要把两者的定位搞混也不要用开放式任务的失败去否定agent在封闭任务上的价值更不要因为封闭任务的成功就去幻想它能独立做研究。7.1 什么时候可以试试半开放式agent任务如果你的任务满足这些条件可以考虑让agent承担更大范围的工作研究目标和成功标准已经由人写清楚。路径空间可以被压缩到有限的候选方案里。每一步都有可验证的中间产物。有人工的定期检查和止损机制。预算和时间有明确上限。这种情况最适合当agent作为“科研加速器”来用。它能帮你快速完成代码实现、实验脚本生成、数据清洗和指标统计把人从琐碎执行中解放出来让你把精力放在真正需要判断力的事情上。7.2 什么时候不要碰开放式任务如果任务描述是“你去研究一下这个问题看看有什么新发现”而且没有人先定义清楚具体要验证什么假设、用什么指标判断进展、哪些方向可以接受那么这个任务现在还不适合交给agent独立做。你应该先自己把研究问题定义得足够窄把“预期发现什么”改成“验证哪两个方案在哪些数据上有什么区别”再考虑让agent介入。不要指望agent能自动补全任务定义里缺失的科研判断它会在缺失的位置生成一个貌似合理的判断然后沿着这个判断走很远最后给你一份无法回溯的结论。7.3 我对研究型agent的实用态度踩过这些坑之后我现在对agent辅助科研的态度早就不是“能不能替代研究者”而是“怎么把研究过程中适合自动化的部分做得足够稳”。我在实际任务中已经习惯了这样的分工我负责定义问题和判断结果agent负责执行和实现。每个实验开始前我会把目标拆成原子任务明确产出和验收标准然后让agent去做。每个任务完成后我会盯着它的日志和中间产物做检查确定没有隐性错误后再进入下一环。整个过程看起来不像“agent在做研究”更像“agent在帮我做实验”。这恰恰是正确的使用姿态。把agent当成一个有耐心、能快速写代码、能持续执行十几个子任务的实习生但永远保留“最终判断权”。至少在现在这个阶段所有看起来由agent独立完成的开放式研究背后几乎都有人在做方向选择、结果判断和错误兜底。那些真正能把agent用起来的人不是让agent替自己做研究而是用agent把自己从重复劳动里解放出来去做更有价值的判断和探索。