在 LLM 的能力边界被一遍遍刷新的同时一个更接近科研现场的问题开始浮现如果给 AI Agent 一个开放式科研任务它能否像科研工作者一样独立完成从提出假设、设计实验、写代码、跑结果到修正结论的完整链路清华团队提出的 ASI-Bench 评测基准正是因为“AI 能不能独立做科研”这个问题而受到关注。它不再只问模型能不能答对题而是把镜头对准科研过程中最关键也最难量化的能力科学自主性。对于正在做 AI Agent 应用、垂类模型落地或 LLM 评测平台的工程师来说这个方向有很强的参考价值。科研任务几乎是长链路 Agent 的极限测试场景问题开放、步骤不定、依赖真实环境和外部工具结果还要能被验证和复现。理解 ASI-Bench 的设计逻辑不只是在追一个论文热点更是在理解如何为一类复杂 Agent 任务搭建可评测、可复现、可排查的工程体系。这篇博客会从评测难点、任务设计、工程实现、指标分析、常见排查和落地建议几个角度展开。1. 先理解“AI 独立做科研”为什么难以评测1.1 科研任务和普通任务有本质差别大多数常规评测任务可以抽象成“给定输入计算输出”的有限问题。代码题有测试用例数学题有唯一答案问答类任务有标准答案或参考答案。评测这类任务只需要判断模型输出和预期结果是否一致。科研任务不是这样。一个真实科研问题往往没有标准答案甚至问题本身的边界都不清晰。研究者需要先理解问题、拆解问题、判断哪些信息有用再决定下一步做什么。过程中会出现多种可选路径每条路径都可能通向部分成功或部分失败。更麻烦的是“失败”本身也是科研的一部分但自动化评测系统很难给失败归因。如果把这个场景交给 AI Agent它必须完成的工作链条通常包含检索和阅读相关文献确定问题背景。提出可验证的假设并把假设转成实验方案。编写代码、准备数据、运行实验。解读结果判断结果是否支持假设。根据结果修正方向或梳理成研究报告。这条链路不仅长而且每一步的结果都会影响下一步方向。评测一个 Agent 在这些环节中的表现靠“最终答对没答对”这种二元判断远远不够。1.2 传统基准无法覆盖科研自主性现有的 LLM 基准大体可以分成几类知识问答类MMLU 等、推理类GSM8K、MATH 等、代码类HumanEval、MBPP 等、Agent 类WebArena、SWE-bench 等。它们各自的贡献很大但在面向科研自主性时都有明显局限。基准类型典型代表任务特点在科研自主性上的局限知识问答MMLU单轮选出答案只考察记忆和知识覆盖不考察研究和决策过程数学推理GSM8K多步计算后给出答案路径固定不涉及真实实验环境代码生成HumanEval按函数签名补全代码不涉及问题发现、实验设计和结果验证工具调用WebArena在网页环境中完成操作任务较明确科研任务要开放得多软件工程SWE-bench修复真实 issue接近真实工程但目标仍然是既定 issue科研自主性评测需要的不是“答案判断”而是“过程判断”。一个 Agent 可能最终没有给出漂亮结论但它在过程中表现出了合理的假设提出、实验设计和失败诊断能力反过来一个 Agent 也可能看似生成了完整报告但实验代码根本跑不通结论完全来自模型幻觉。这两种情况在同一套传统评分逻辑下很难被区分。1.3 ASI-Bench 的定位ASI-Bench 面向的是“科学自主性Autonomous Scientific Intelligence”。这个命名暗示它的关注点不是模型能不能回答科学问题而是模型能否在一个开放的科研任务中自主决策、执行、验证和修正。按照公开资料中的设计思路这类基准通常不是一个简单题库而是一套包含任务样本、运行环境、评测协议和打分方法在内的完整系统。它做的核心事情是把“科研”这个模糊概念拆成可观测、可执行、可打分的任务单元再通过任务完成度和过程行为两类证据来评价 Agent 的表现。有人可能会问这类基准会不会只是把几个科研任务包进 Docker 镜像里差别在于ASI-Bench 更强调“自主性”。它的价值不只是让 Agent 跑通一个实验而是看 Agent 在没有人类逐步指令的情况下能否自己规划路线、调用工具、从环境里获取反馈并调整行为。这种设计思路对任何想要构建科研助手、实验自动化平台或长任务 Agent 的团队都有借鉴意义。2. 科研流程拆解与评测维度2.1 把科研流程拆成可以观测的环节要进行自动化评测第一步是把科研流程拆成可观测的环节。不同科研方向流程会有差异但大体可以抽象成以下阶段问题理解Agent 是否理解任务目标能否澄清不明确的信息。信息收集Agent 是否主动检索资料能否筛选出相关信息。假设提出Agent 能否基于现有信息给出可验证的假设。方案设计Agent 能否把假设转成具体实验计划包括数据来源、方法和工具。实现执行Agent 能否真正写出可运行代码并在规定环境里执行。结果分析Agent 能否正确解释输出结果判断结果是否支持假设。迭代修正Agent 能否在遇到失败时调整方案而不是原地空转。输出总结Agent 能否把过程和结论整理成清晰报告。每个阶段都可能成功也可能以不同方式失败。评测系统如果只记录最终报告就会丢失大量关于 Agent 能力结构的信息。2.2 核心评测维度在 ASI-Bench 这类基准里评测通常从多个维度展开。下表是实际搭建评测方案时比较常用的维度评测维度观测方式说明任务完成度产物是否生成、实验是否运行、报告是否提交判断 Agent 是否走完流程而不是中途退出结果正确性实验输出是否与预期接近或结论是否有数据支撑重点关注是否被验证过而不是模型直接生成过程自主性人类标注或规则判断 Agent 的决策路径看 Agent 是否自己规划了步骤而不是反复等待指令工具使用质量工具调用序列是否合理是否滥用搜索、重复运行、无效调用资源效率调用次数、运行时长、Token 消耗效果相同的情况下资源消耗更低的方案更优可复现性相同条件下重复运行是否得到一致结果排除随机性导致的虚假成功在具体评测任务里这些维度不一定全部采用需要根据任务类型确定权重。比如一个偏文献调研的任务结果正确性和过程自主性更重要一个偏代码实验的任务执行成功率和工具使用质量更重要。2.3 任务样本设计原则评测任务的设计质量决定了基准的上限。科研自主性评测的任务样本通常需要满足几个原则开放性任务不能是“填空”或“单选”要允许 Agent 走多条路径给不同水平的自主性留出区分度。可验证性虽然路径开放但结果必须存在可判断的依据。比如数据集中是否包含已知结论或者实验是否存在客观评价标准。需要真实工具任务要迫使 Agent 使用代码、数据文件或检索接口避免只靠模型记忆作答。有难度梯度同时包含短周期任务和长周期任务才能区分“能处理单步任务”和“能完成端到端研究”两种能力。环境可控每个任务最好有独立运行环境避免前一个任务影响后一个任务。注意一个常见的误区是把任务写得太“像考试题”。比如直接问“某个模型在某数据集上的准确率是多少”这仍然是在测记忆。真正测自主性的任务应该要求 Agent 自己实现、运行并验证而不是凭记忆写答案。3. 用工程方式搭建科研自主性评测管线理解设计之后如何在工程上实现一套类似的评测管线下面给出的是一套最小可运行示例用于说明思路。真实项目中需要结合 ASI-Bench 官方发布的具体任务集和评分脚本调整但核心流程是通用的。3.1 用 JSON 定义评测任务每个评测任务至少需要包含任务描述、预期产物、运行提示、资源限制和评分标准几个字段。{ task_id: asi_small_001, title: 实现一个线性回归实验并分析数据关系, description: 给定 data.csv 数据集要求完成以下工作1. 加载数据2. 选择合适特征建立线性回归模型3. 输出模型系数、R2 值4. 用 200 字以内说明系数对应的实际含义。, environment: { image: python:3.11-slim, requirements: [pandas, scikit-learn, numpy] }, expected_assets: [result.json], timeout_seconds: 1800, max_tool_calls: 100, scoring: { asset_weight: 0.3, result_correctness_weight: 0.5, process_quality_weight: 0.2 } }这个 JSON 的价值在于把任务格式标准化。Agent 评测系统可以统一读取这类描述再决定启动哪个容器、安装哪些依赖、跑哪个 Agent、最后怎么打分。任务字段中的timeout_seconds和max_tool_calls要特别重视科研任务很容易让 Agent 陷入长时间搜索或无限制迭代缺少这两个限制会导致评测成本不可控。3.2 用容器隔离运行环境Agent 要跑科研任务必须给它一个真实可执行的 Python 环境。容器隔离是当前最稳妥的方式。FROM python:3.11-slim WORKDIR /workspace RUN pip install --no-cache-dir \ pandas2.0.3 \ scikit-learn1.3.0 \ numpy1.24.3 COPY data.csv /workspace/data.csv CMD [bash]基础镜像固定版本是关键。如果每次评测都用latest标签依赖升级可能导致同一个 Agent 在不同时间得出完全不同的结果这种误差会直接污染评测报告。生产级评测系统还应该对镜像做内容哈希校验保证每次运行使用的是同一份环境。3.3 评测执行器评测执行器负责按任务定义启动容器、运行 Agent、采集结果和回收资源。下面是一个简化版 Python 驱动逻辑import docker import json import time client docker.from_env() def run_evaluation(task_definition: dict, agent_script: str): image task_definition[environment][image] timeout task_definition[timeout_seconds] container client.containers.run( imageimage, command[python, agent_script], working_dir/workspace, detachTrue, mem_limit4g, cpu_period100000, cpu_quota200000, volumes{/local/data: {bind: /workspace, mode: rw}} ) try: result container.wait(timeouttimeout) logs container.logs().decode(utf-8) return { exit_code: result[StatusCode], logs: logs, } finally: container.remove(forceTrue)执行器的职责不只是把容器跑起来。它还要处理几类异常Agent 进程超时、容器内存超限、日志量过大、进程挂死。任何一个异常没有处理整个评测批次就会被卡住。生产环境建议增加超时看门狗由主进程而不是容器内的 Agent 进程来控制终止逻辑。3.4 记录完整轨迹评测不只是看结果文件还要记录 Agent 在运行过程中的完整轨迹。轨迹记录通常包含每次模型调用输入的 prompt 和模型输出。每次工具调用的参数、返回结果和执行耗时。Agent 当前可观察的上下文窗口状态。文件系统变化比如生成了哪个中间文件。关键指标快照比如 Token 消耗和工具调用次数。{ timeline: [ { t: 0.0, type: model_call, input_preview: 给定 data.csv 数据集..., output_preview: 我需要先查看数据结构, token_count: 1200 }, { t: 1.2, type: tool_call, tool_name: python_execute, code_preview: import pandas as pd; df pd.read_csv(data.csv), return_value: shape: (100, 5) } ], total_tokens: 45200, total_tool_calls: 32, env_updates: [created result.json] }轨迹记录是后续分析失败模式的原始素材。没有轨迹就只能看到“Agent 失败了”有了轨迹才能说明“Agent 在第几步因为什么失败”这直接决定评测结论对 Agent 开发是否有指导价值。4. 指标计算与能力边界分析4.1 关键指标定义科研自主性评测的指标通常比普通基准更复杂因为它同时要考虑结果和过程。指标计算方式或含义适用说明Passk多次采样中至少一次成功的比例适合衡量 Agent 的真实成功率降低随机性影响任务完成率生成全部预期产物的任务占比衡量 Agent 是否具备走完流程的基本能力结果准确率产物内容与参考答案的匹配程度需要人工或规则预定义正确结果过程分人类标注者对决策路径的评分衡量规划、纠错、自主判断能力工具有效率有效工具调用次数 / 总调用次数识别重复搜索、空转执行端到端耗时从任务开始到提交产物的总时长反映 Agent 的方式是否高效在正式使用这些指标前需要先确定任务是否允许随机尝试。科研任务里 Agent 可能通过反复修改代码碰巧成功这虽然也是能力体现但和“一次设计正确”是不同的能力。建议同时报告“最终成功率”和“首次尝试成功率”不能只给一个漂亮数字。4.2 Agent 在科研任务中的典型失败模式基于常见 Agent 评测经验科研场景里问题最集中的几个失败模式如下失败模式典型现象复现原因上下文丢失前面步骤确定的方向后面又推翻重来长任务触发上下文过长关键信息被截断工具空转反复读取同一个网页或重复执行同一段代码模型没有从环境反馈中获得足够信号幻觉式完成报告写得很完整但引用的数据或结果并不存在模型直接生成结论没有验证产物是否真实生成环境盲区代码在本地不能运行但 Agent 仍然认为成功Agent 没有把环境执行结果作为决策依据过早收敛只完成最浅层操作就提交结果缺少对“任务是否真正完成”的校验机制资源失控调用次数爆炸长时间不收敛缺少工具调用上限和超时保护这些失败模式说明一个问题当前 Agent 在科研任务中的瓶颈往往不是单点能力而是“感知-决策-执行-验证”的闭环不够完整。模型能生成单段代码但它不知道代码是否真的运行成功它能总结文本但它不确定总结的结论是否得到数据支持。4.3 面向当前能力边界的判断从这类评测中能得到几条重要结论第一当前 Agent 更适合处理受限科研子任务比如“读取数据并建模”“分析实验结果”“生成某一段代码”。在完整科研流程里多数 Agent 会在某个较长的中间环节失效。第二自主性和正确性要分开看。一个自主规划路径能力很强的 Agent也可能因为验证不足而输出错误结论。反过来一个每一步都按照预设路径走的 Agent可能结果很稳但并没有体现出科研自主性。第三评测结果不能只看成功率。两个 Agent 可能成功率相同但一个平均调用 20 次工具、消耗 5 万 Token另一个平均调用 80 次工具、消耗 20 万 Token。在当前大模型推理成本敏感的生产环境里效率指标往往比单一成功率更重要。注意任何基准得出的结论都存在时间窗口。科研 Agent 的能力提升很快新模型可能在旧基准上迅速饱和。评测基准需要持续更新任务难度否则“能通过基准”和“能做科研”之间的差距会重新扩大。5. 评测中的常见问题与排查路径搭建和运维科研自主性评测系统时会出现很多表层现象不一致、实际原因复杂的问题。下面按现象到根因的顺序列出最常见的几类。5.1 同一 Agent 在不同批次评测中结果差异很大现象同一份代码、同一个模型今天通过明天失败。排查顺序先确认两个批次使用的模型服务版本是否一致。很多模型服务会灰度升级相同 prompt 的输出可能已经不同。再检查基础镜像是否变化。如果 Dockerfile 使用pip install且不带固定版本依赖可能被更新。检查评测环境中是否残留前一个任务的文件或进程。检查 Agent 本身的随机性。模型温度不为 0 时即使环境完全一致结果也会有波动。处理建议模型版本固定为某一日期快照依赖版本写死评测任务使用全新容器多次采样取通过率而不是单次结果。5.2 Agent 长时间卡住不输出看起来像“死机”现象容器还在运行日志不再刷新评测任务迟迟不结束。可能原因Agent 进入了工具调用死循环反复执行同一操作。模型上下文尾部被超长工具输出占满导致模型难以继续。Agent 等待外部外部资源比如网络请求一直没有返回。评测执行器没有设置正确超时。检查方式查看最后一次工具调用参数和返回内容判断是否有重复调用查看容器资源占用情况确认执行器超时参数是否传入。处理建议在评测执行器中设置严格超时并把超时行为明确记录为“失败原因timeout”。为工具调用增加频率限制比如相同参数的工具调用 5 分钟内最多执行 3 次。5.3 任务环境依赖不完整导致虚假失败现象Agent 代码逻辑看起来正确但一运行就报错评测结果为失败。可能原因任务 JSON 里的 requirements 和实际 Dockerfile 中的依赖不一致。数据文件路径绑错容器内访问不到。Python 版本或系统库版本不匹配。检查方式在容器内手动执行 Agent 生成的代码直接看报错信息。处理建议先把任务本身的运行环境手工验证一遍。在评测前执行一次“环境自检脚本”主要检查数据文件是否存在、关键依赖能否 import、目录是否有写权限。5.4 自动打分把正确结论误判为错误现象人工看 Agent 报告认为结论正确但自动评分给出了低分。可能原因评分规则过于依赖关键词或严格文本匹配。Agent 使用了不同的但正确的方法产物格式与预设模板不一致。评分脚本读取了错误路径下的文件。检查方式调出评分为低分的轨迹对比 Agent 实际生成的产物和评分脚本的读取位置。处理建议自动打分负责可计算的结构化检查比如文件是否存在、模型是否训练、R2 值范围是否合理开放性问题必须增加人工抽查比例。规则化打分结合人工校准是当前比较可靠的做法。问题现象常见原因检查方式处理建议评测结果不稳定依赖、模型版本或随机性变化逐项对比环境和模型版本版本固定、多次采样Agent 长时间卡住死循环或上下文溢出查看最后工具调用和日志设置超时和调用频率限制虚假失败环境依赖不完整容器内手工执行脚本增加环境自检脚本打分误判文本匹配过于严格检查轨迹和产物路径结构化打分加人工抽查6. 从 ASI-Bench 到科研 Agent 落地建议6.1 给 Agent 开发者的建议如果目标不是复现一个基准而是把科研 Agent 做成可用产品下面这些建议会更接近生产实践。第一重视验证节点。Agent 在每个关键步骤完成后都应该调用一个验证函数来确认“这一步真的完成了”。比如写代码后先运行运行成功后再进入下一步。没有验证节点的 Agent很容易把幻觉输出当成完成结果。第二给 Agent 提供环境反馈。不要让模型在“真空”里做决策。当它运行代码失败时要把完整的 traceback 返回给它并引导它根据报错修正而不是让它自己猜测失败原因。第三控制上下文窗口。长科研任务会把大量文献、代码、输出塞进上下文。建议定期把已经完成的关键结论写入独立的“工作日志”而不是把所有历史片段全部保留。第四设置资源边界。科研任务的探索空间很大如果不限制工具调用次数和总 Token成本会很快失控。很多产品适合用“预算制”给 Agent 一个明确的工具调用预算超出后它必须基于已有信息输出结论。6.2 给评测设计者的建议评测设计的目标不是让某类 Agent 得高分而是让分数能够预测 Agent 在真实场景中的表现。结果和过程并重。只看结果会放过幻觉只看过程会忽略实际产出。多次采样取分布。科研任务充满随机性单次成功不能说明问题。设置人工校准集。从评测任务中抽出一部分由人类专家打分与自动打分对比发现偏差及时调整。定期评估基准的饱和度。如果已有模型普遍接近满分说明任务难度不够需要补充更难样本。发布评测时要附带随机种子、模型版本、依赖版本和评测工具版本否则复现无从谈起。6.3 科研 Agent 上线前检查清单下面这份清单可以在把科研 Agent 从实验环境推到真实业务环境前使用。[ ] 是否固定了 Python 版本和所有依赖版本。[ ] 数据文件是否有清晰路径和权限校验。[ ] Agent 是否具备完整的验证节点不会把“生成报告”当成“完成实验”。[ ] 是否配置了工具调用上限、总 Token 上限和超时上限。[ ] 是否记录完整轨迹包括工具调用、模型输出和文件变更。[ ] 是否区分了“模型能力问题”和“环境配置问题”。[ ] 是否做了多个 Agent 方案的横向对比而不是只看单次表现。[ ] 是否包含人工抽查机制防止自动打分误判。[ ] 是否能在新依赖发布后快速重建评测环境并重新验证。6.4 扩展方向从单 Agent 到多 Agent 科研系统当前科研 Agent 评测大多围绕单个 Agent 执行任务但真实科研协作通常是多角色参与的过程。下一步可以探索的方向包括多 Agent 分工一个负责文献调研一个负责实验一个负责写作它们之间通过共享记忆协作。人和 Agent 协同评测 Agent 能否在关键时刻主动求助或者在接受人类反馈后修正研究计划。与真实实验室工具对接把评测环境从静态容器扩展到可以控制实验设备、调用实验数据的系统。这些方向都会让“科研自主性”的评测更接近真实但工程复杂度也会上升。一个可参考的路径是先在单 Agent 上建立可靠的评测闭环再把多 Agent 协作引入最后逐步接入真实环境。ASI-Bench 这类工作带来的最大价值不是给出一个“AI 已经会做科研”或“AI 完全不会做科研”的结论而是提供一套方法让社区能持续回答“AI 在科研流程中的哪个步骤真正可用哪个步骤还停留在表面”。对这个回答越清楚科研 Agent 从演示走向生产力的路就越可控。对工程师来说与其争论“AI 能不能独立做科研”不如先把评测系统搭起来用轨迹、指标和失败模式去说明它目前到底能做什么。