如果你关注 AI 圈最近会有一个很强烈的体感大模型不再只停留在聊天框里而是开始主动规划任务、调用工具、修改代码、完成多步操作。但问题也随之而来——当 AI 从数字世界走进物理世界它还能不能像处理文本那样稳定可靠中国科大最近的研究正好把这个问题推到了台前AI 智能体在真实实验室场景下能不能扛住一次货真价实的“压力测试”先把结论放在前面以目前的技术水平AI 离“全面接管实验室”还有距离但它已经能在真实物理世界中跑通一部分“假设—实验—观测—修正”的闭环。真正值得关注的不是某个模型又提升了多少准确率而是这类测试暴露出的系统性问题任务的稳定性、设备的可控性、失败时的恢复能力以及工程上怎么评测一套“AI实验”系统到底行不行。这篇文章我会做三件事第一解释“AI 接管实验室”到底意味着什么它和普通对话、代码生成有什么本质区别第二把“压力测试”这个概念从软件工程搬过来说清楚真实物理世界的压测为什么更残酷第三给出一套可运行的最小压力测试框架包含完整代码你可以用自己的模型 API 跑一遍理解 AI Agent 在物理任务中的规划、执行和评测闭环。1. 这篇文章真正要解决的问题很多人看到“AI 科学家”“AI 化学家”这类表述第一反应是以后是不是不需要人做实验了这个理解过于简化。AI 在实验室里的角色目前并不是取代人而是把“人的一部分决策过程”自动化。真正的问题不是“模型会不会做实验”而是“模型在连续多轮交互中能不能保持稳定”。做实验和写文章不一样。写文章写错一个词最多是语句不通做实验调错一个参数轻则浪费样品重则损坏设备甚至引发安全问题。所以实验室场景下的 AI Agent必须经过比普通应用严格得多的测试。我在看这类研究时最关心的不是论文里那张漂亮的“成功率对比图”而是三个细节实验任务是在模拟器里做的还是在真实设备上做的如果失败Agent 是会自己纠错还是靠人工介入拉回来整个流程有没有记录完整的决策轨迹能不能回溯每一步操作这三个问题也是这篇文章想帮你建立的评测视角。如果你正在做 AI 应用开发、Agent 工程、实验室自动化或者只是被“AI 科学家”的新闻刷屏你可以用这套框架去判断一个 AI 系统在真实世界里到底能不能用而不是只看演示视频。2. AI 接管实验室的含义从辅助工具到自主 Agent要讨论“接管”必须先拆解实验室工作的层次。我习惯把 AI 在实验场景中的能力分成三个层次层次能力范围当前成熟度判断第一层读文献、写方案、推荐实验条件比较成熟适合当 Copilot第二层控制仪器、读取数据、执行标准流程正在成熟需要严格封装和校验第三层自主提出假设、设计实验、根据结果修正方案仍处于探索阶段很少能完全无人化第一层本质上是“AI 辅助”和日常用大模型写文档没有本质区别。第三层才是真正意义上的“AI 科学家”但它的难度不在于模型聪明不聪明而在于“科学实验”本身是一个闭环提出假设、设计实验、操作设备、采集数据、分析结果、修正假设然后再来一轮。在这个闭环里最容易出问题的不是“提出假设”这一步而是“操作设备”和“根据真实反馈修正”这两步。设备有噪声环境有误差反应结果可能和理论预期不一致甚至同一个实验重复做三次得到三个不同的结果。AI Agent 如果不能处理这种不确定性它就只能活在演示视频里。所以我们讨论“AI 接管实验室”本质上是在讨论一个多步骤决策系统在物理世界中的工程可靠性而不只是在讨论大模型的推理能力。这也解释了为什么需要“压力测试”——不是考它会不会而是考它在各种边界条件下能不能持续稳定地会。3. 为什么真实物理世界需要“压力测试”做过后端开发的人对“压力测试”这个词不会陌生。用 JMeter、ab、Apifox 对接口做压测核心是看系统在并发升高、响应变慢、资源受限时是否仍然能满足预期。比如一条常见的压测命令ab -n 10000 -c 200 https://your-service.test/api这条命令用 200 个并发请求打 10000 次请求看服务会不会崩、响应时间会不会劣化。软件压力测试的核心逻辑是在极限状态下找系统的瓶颈。真实物理世界里的 AI Agent 压力测试逻辑完全一致但条件更残酷。差异主要体现在四个方面3.1 状态不可重置软件压测里请求失败了大不了重试数据库可以回滚服务可以重启。但物理实验不一样。试剂用完了就没了温度冲过头了样品可能就废了设备卡住了不是重启就能恢复。每次实验都有不可逆成本这是实验室 Agent 和线上 API 最大的区别。3.2 反馈有噪声和延迟后端接口返回的是结构化 JSON快就是快慢就是慢。但实验室里的传感器数据可能波动仪器响应可能延迟同一个动作在不同环境条件下会产生不同结果。AI Agent 必须学会在模糊反馈中做判断而不是期待精确的 reward。3.3 动作空间必须严格受限软件 Agent 可以调用任意 API但物理设备不行。你不能让 AI 随意把加热功率调到 1000%也不能让它同时执行两个互相冲突的命令。物理设备要求动作白名单、参数范围校验和人工确认机制否则一次幻觉操作就可能造成事故。3.4 评估指标更复杂软件压测主要看吞吐量、错误率、延迟。实验室 Agent 要看的指标更多任务成功率、平均步数、成本消耗、人工干预次数、失败后的恢复率、安全违规次数等。一个模型可能成功率很高但每次成功都消耗了 10 倍资源这在真实实验室里依然不可用。一句话总结真实物理世界的压力测试考验的不是 Agent 的“上限能力”而是它的“下限稳定性”。4. 中国科大最新研究到底测了什么回到中国科大这个最新研究上。从公开信息看这类工作关心的不是“AI 能不能理解实验原理”而是“AI 能不能在一个真实、不完美、有噪声的环境里完成一个闭环实验任务”。这其实就是一次针对 AI Agent 的工程压测。我不打算在这里复述论文里的具体数字因为单看数字很容易被误导。更有价值的是它的测试设计思路。通常这类研究会围绕以下几个问题展开4.1 任务设计把大目标拆成可验证的小任务实验室任务不能直接扔给模型一句“帮我做个催化剂”而是需要拆成温度控制、加液顺序、反应时间、产物检测等子任务。压力测试的第一步就是看 Agent 能不能把一个模糊目标转换成一系列可执行、可检查的具体动作。4.2 环境设计模拟器先行真机小规模验证完全的物理实验成本太高也不适合做重复测试。所以常见的做法是先在模拟环境里做大规模压测把明显失败的策略过滤掉再挑选少量任务到真实设备上验证。模拟器的价值不是替代真机而是能低成本重复暴露边界问题。4.3 失败注入故意制造异常真实实验一定会遇到异常温度传感器漂移、设备返回超时、试剂余量不足。压力测试会故意注入这些异常看 Agent 是能识别并调整策略还是直接忽略错误继续执行。这一步最能看出系统是否具备“知道自己不知道”的能力。4.4 评价维度不只关心成功还关心怎么成功如果 Agent 每次都靠随机尝试碰巧成功那么它并不具备可复用性。所以研究人员会关注行动轨迹是否合理、是否违反安全约束、是否过度依赖人工干预。这也是为什么“过程指标”和“结果指标”一样重要。所以答案不是简单的“能”或“不能”而是AI 能接管哪些层不能接管哪些层。从这类压力测试暴露的问题来看语言理解和基础规划已经不是最大瓶颈物理世界里的感知、控制与安全校验才是。5. 自己动手搭建最小 Agent 压力测试框架光看概念容易飘我建议你亲手跑一个最小版本。下面这个框架不需要真实设备只用一个模拟环境替代物理实验室然后把一个大模型接进去让它通过“观察状态—选择动作—读取反馈”的方式完成任务。这样做有两个好处一是帮你看清楚 Agent 决策循环的骨架二是让你快速体验“为什么物理世界任务没有对话任务那么稳定”。5.1 环境准备本示例使用 Python 3.9核心依赖只有两个requests python-dotenv安装依赖pip install -r requirements.txt在项目目录下创建一个.env文件填入你的模型 API 配置。这里用的是 OpenAI 兼容接口国内云厂商的兼容端点同样适用只需要把LLM_BASE_URL换成服务商提供的地址LLM_API_KEYsk-xxx LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你只是本地体验也可以换成其他兼容接口。本文示例不依赖具体模型重点演示 Agent 循环和压测逻辑。5.2 整体结构我们做一个“温度控制任务”反应体系需要达到某个目标温度Agent 可以执行加热、冷却、等待等动作环境会返回当前温度。Agent 需要根据当前状态不断调整动作直到达到目标温度。这个任务虽然简单但已经具备了物理任务的核心要素连续状态、带噪声反馈、动作受限、需要多步决策。6. 完整示例与代码实现下面是完整代码我已经拆成三个文件方便你理解每一层职责。6.1 定义模拟实验环境文件路径env_sim.py# env_sim.py import time class ReactionEnv: 一个最小化的实验环境模拟器。 模拟一个加热/冷却体系目标是让 current_temp 接近 target_temp。 action 只支持 set_power 和 wait。 def __init__(self, target_temp60.0, max_cycles10): self.target_temp target_temp self.current_temp 25.0 self.max_cycles max_cycles self.cycle 0 def get_state(self): return { current_temp: round(self.current_temp, 1), target_temp: self.target_temp, cycle: self.cycle, success: abs(self.current_temp - self.target_temp) 1.0, } def execute(self, action: str, value: float): if self.cycle self.max_cycles: return {error: max_cycles reached} if action set_power: # value 是功率百分比正数加热负数冷却 # 加入少量随机扰动模拟真实设备噪声 self.current_temp (value / 100.0) * 2.0 - 0.2 self.current_temp (self.target_temp - self.current_temp) * 0.01 elif action wait: # 等待一会温度会略微向目标靠拢 self.current_temp (self.target_temp - self.current_temp) * 0.05 else: return {error: funknown action: {action}} self.current_temp max(15.0, min(100.0, self.current_temp)) self.cycle 1 time.sleep(0.2) return self.get_state()这段代码模拟了物理实验最重要的三个特征当前状态会变化、动作有滞后效应、结果带有噪声。set_power不是瞬间让温度变成目标值而是逐渐逼近这更接近真实设备的惯性。6.2 定义 Agent 的决策循环文件路径agent.py# agent.py import json import os import requests SYSTEM_PROMPT 你是一个实验控制智能体。你的任务是通过合理动作让反应体系达到目标温度。 你可以使用以下动作 - set_power(value): value 是功率百分比正数加热负数冷却 - wait(): 等待一段时间温度会略微变化 你必须严格按以下 JSON 格式返回动作不要输出任何额外文本 {action: set_power, value: 60} 或者 {action: wait, value: 0} 每次执行完动作后你会收到环境返回的当前状态。如果已经达到目标温度返回 {finish: true} def chat_once(messages): 调用 OpenAI 兼容的 /chat/completions 接口。 resp requests.post( os.getenv(LLM_BASE_URL, https://api.openai.com/v1/chat/completions), headers{Authorization: fBearer {os.getenv(LLM_API_KEY)}}, json{ model: os.getenv(LLM_MODEL, gpt-4o-mini), messages: messages, temperature: 0.2, }, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] def parse_action(text): 解析模型返回的 JSON 动作。 try: data json.loads(text) if data.get(finish): return {finish: True} return data except json.JSONDecodeError: return None def run_agent(env, max_steps8): 运行一个 Agent直到成功或超过最大步数。 messages [ {role: system, content: SYSTEM_PROMPT}, { role: user, content: ( f请让反应体系达到目标温度 {env.target_temp}°C。 f当前状态{json.dumps(env.get_state(), ensure_asciiFalse)} ), }, ] history [] for step in range(max_steps): raw chat_once(messages) action parse_action(raw) # 如果模型没有按 JSON 返回默认等待一次避免直接崩溃 if action is None: action {action: wait, value: 0} if action.get(finish): state env.get_state() history.append({step: step, action: finish, state: state}) if state[success]: return {ok: True, steps: step 1, history: history} # 没达到目标温度就提前结束视为失败 return {ok: False, error: finish called before reaching target, history: history} result env.execute(action.get(action), float(action.get(value, 0))) history.append({step: step, action: action, state: result}) messages.append({role: assistant, content: raw}) messages.append({role: user, content: f执行结果{json.dumps(result, ensure_asciiFalse)}请继续。}) if result.get(error): return {ok: False, error: result[error], history: history} if result.get(success): return {ok: True, steps: step 1, history: history} return {ok: False, error: max_steps exceeded, history: history}这个循环很关键。它做的事情是让模型根据当前状态生成一个动作执行动作再把执行结果作为新的上下文传给模型如此往复。每一步都有完整的轨迹记录这为后续分析“失败原因”提供了基础。注意这里对模型的输出做了两层保护如果模型没有返回 JSON默认执行等待不能让它把非法动作传给环境如果模型提前宣告结束但实际没达标也视为失败。这就是动作白名单和成功条件校验的雏形。6.3 压力测试脚本文件路径stress_test.py# stress_test.py import argparse import json import random import time from env_sim import ReactionEnv from agent import run_agent def single_task(target_temp, max_steps): env ReactionEnv(target_temptarget_temp) start time.time() result run_agent(env, max_stepsmax_steps) elapsed time.time() - start return { target_temp: target_temp, ok: result[ok], steps: result.get(steps, max_steps), elapsed: round(elapsed, 2), error: result.get(error), } def main(): parser argparse.ArgumentParser() parser.add_argument(--tasks, typeint, default10) parser.add_argument(--max-steps, typeint, default8) parser.add_argument(--output, defaultresult.jsonl) args parser.parse_args() results [] for i in range(args.tasks): # 每次随机选一个目标温度模拟不同的实验条件 target random.choice([45, 50, 60, 70, 80]) res single_task(target, args.max_steps) results.append(res) print(json.dumps(res, ensure_asciiFalse)) ok_count sum(1 for r in results if r[ok]) print(\nsuccess rate: {}/{}.format(ok_count, len(results))) print(avg steps: {:.1f}.format(sum(r[steps] for r in results) / len(results))) with open(args.output, w, encodingutf-8) as f: for r in results: f.write(json.dumps(r, ensure_asciiFalse) \n) if __name__ __main__: main()这个脚本的思路和 JMeter 压测类似不跑一次而是跑多次不固定条件而是每次随机变化目标温度最后统计成功率、平均步数和失败原因。这套思路放到真实实验里同样适用。6.4 接入真实设备时怎么扩展如果你的目标是接真实设备不需要改动 Agent 循环只需要把ReactionEnv.execute替换成真实设备的操作函数。比如一个串口控制设备的封装可能是这样# device_adapter.py # 真实设备请以厂商协议为准这里只演示结构 from serial import Serial ser Serial(/dev/ttyUSB0, 9600, timeout2) def set_power(value): # 发送厂商定义的指令 cmd fSET POWER {value}\r\n.encode() ser.write(cmd) resp ser.readline().decode().strip() return {ack: resp} def read_temperature(): ser.write(bGET TEMP\r\n) resp ser.readline().decode().strip() return {current_temp: float(resp)}真实设备接入的核心不是把数据读出来而是把设备操作封装成“安全、可回滚、可校验”的函数。每个动作执行后必须有明确的返回值每个设备的边界参数必须在代码里限制一旦出现异常必须支持紧急停止。这些工程约束比模型本身更重要。7. 运行结果与效果验证运行压力测试脚本python stress_test.py --tasks 5 --max-steps 8预期输出大致如下{target_temp: 60, ok: true, steps: 3, elapsed: 4.21, error: null} {target_temp: 45, ok: true, steps: 5, elapsed: 6.13, error: null} {target_temp: 80, ok: false, steps: 8, elapsed: 9.02, error: max_steps exceeded} {target_temp: 70, ok: true, steps: 4, elapsed: 5.55, error: null} {target_temp: 50, ok: true, steps: 2, elapsed: 3.98, error: null} success rate: 4/5 avg steps: 4.4你需要关注的不是第一次跑出来的具体数字而是几个问题成功率是不是稳定多跑几次会发现在不同目标温度下成功率波动明显。失败任务是不是集中在某些边界条件比如目标温度距离初始温度越远越容易失败。Agent 是否存在“提前宣布成功”的情况这通常说明模型对“成功”的理解不够准确。平均步数是多少如果成功率高但步数非常多说明模型在“试错”而不是“推理”。如果调用接口失败先看.env里的LLM_API_KEY和LLM_BASE_URL是否正确再看控制台是否打印 HTTP 错误状态码。这个框架本身不复杂问题大概率出在模型接口配置上。8. 常见问题与排查思路问题现象可能原因排查方式解决方案模型返回的不是 JSON解析失败输出格式不稳定打印原始返回内容在 system prompt 中强调“只返回 JSON”降低 temperature增加解析容错Agent 一直重复同一个动作环境反馈信息不足或模型陷入循环查看 history 里的状态变化把关键指标显式写进反馈增加“反思”步骤让模型先总结再决策调用 API 超时或限流并发过高或额度不足查看 HTTP 状态码和错误信息增加重试与退避降低并发限制 max_steps使用更快的模型模拟器成功但真机失败模拟器过度简化没有模拟噪声和设备惯性对比真机和模拟器的轨迹在模拟器中加入随机扰动先小规模真机验证Agent 提前 finish但温度没达标模型误解了成功条件检查 finish 分支前后的状态在返回结果中强制校验 success 条件不让模型自行判断结束这里最容易被忽视的是表格最后两行。真实物理世界的 Agent 失败往往不是“模型不会”而是“模型以为自己会了”。所以工程上必须把成功判断从模型手里拿回来交给环境或人工去校验。9. 最佳实践与工程建议如果你要把这套思路用在真实项目中下面的建议可以帮你少踩很多坑。它们不只是针对 AI Agent也适用于任何“大模型控制真实设备”的工程实践。9.1 安全边界高于一切物理设备必须加急停开关动作参数必须在代码层做上下界限制用户权限要最小化。绝对不能依赖“模型一定不会乱来”这个假设。AI 幻觉是概率问题不是能不能的问题。只要概率不是零安全设计就必须兜底。9.2 动作白名单加参数校验不要让模型直接拼接指令。无论是调用 API 还是操作设备都要把动作抽象成有限集合。模型的输出只负责选择动作和参数真正执行前还要经过一个校验层。比如set_power的参数超出 0-100 范围就直接拒绝并给模型一个明确反馈。9.3 可观测性必须内置每个 Agent 的决策轨迹都要记录下来模型输入、原始输出、解析后的动作、环境返回、延迟、消耗的 token。建议使用 JSON Lines 存储方便后续分析失败原因。没有轨迹记录的压力测试等于没有做。9.4 评测不要只看成功率成功率只是一个结果指标。你还要看成功率背后的成本平均步数、API 调用次数、人工干预次数、安全违规次数。一个系统可能成功率很高但每次实验都需要人盯着这就不叫“接管实验室”而叫“人机协同”。9.5 模拟器不能太干净模拟器越干净测试结果越没有参考价值。建议在模拟器里加随机噪声、设备延迟、偶发故障、传感器漂移。真实世界是多变的压力测试的目的就是尽早暴露这些多变因素带来的影响。9.6 模型选择要匹配任务复杂度不是模型越大越好。对于温度控制这类任务一个响应快、输出格式稳定的小模型往往比一个“想太多”的大模型更可靠。Agent 工程更看重的是可控性和成本而不是单一能力上限。9.7 从“人机协同”开始而不是追求全自动最稳妥的落地路径不是一上来就全自动而是先让 AI 给出建议由人确认后执行再逐步扩大到“标准流程自动执行、异常情况转人工”最后才是在低风险任务上尝试完全自主。这个递进策略既能控制风险也能积累真实数据。回到开头的问题AI 能接管实验室了吗答案不是“能”或“不能”而是“能接管一部分但必须被严格约束和评测”。中国科大这项研究的价值不在于证明 AI 已经可以替代科学家而在于给了我们一套看待 AI 与物理世界交互的测试方法。下次再看到“XX 模型接管实验室”的新闻你可以直接问三个问题它到底接管了哪一层有没有做过超过 10 次的重复实验失败时是自动恢复还是靠人兜底这三个问题足够过滤掉一半标题党。