如果你关注 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_KEY=sk-xxx LLM_BASE_URL=https://api.openai.com/v1 LLM_MODEL=gpt-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_temp=60.0, max_cycles=10): 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": f"unknown 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": f"Bearer {os.getenv('LLM_API_KEY')}"}, json={ "model": os.getenv("LLM_MODEL", "gpt-4o-mini"), "messages": messages, "temperature": 0.2, }, timeout=60, ) 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_steps=8): """运行一个 Agent，直到成功或超过最大步数。""" messages = [ {"role": "system", "content": SYSTEM_PROMPT}, { "role": "user", "content": ( f"请让反应体系达到目标温度 {env.target_temp}°C。" f"当前状态：{json.dumps(env.get_state(), ensure_ascii=False)}" ), }, ] 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_ascii=False)}，请继续。"}) 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_temp=target_temp) start = time.time() result = run_agent(env, max_steps=max_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", type=int, default=10) parser.add_argument("--max-steps", type=int, default=8) parser.add_argument("--output", default="result.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_ascii=False)) 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", encoding="utf-8") as f: for r in results: f.write(json.dumps(r, ensure_ascii=False) + "\n") if __name__ == "__main__": main()这个脚本的思路和 JMeter 压测类似：不跑一次，而是跑多次；不固定条件，而是每次随机变化目标温度；最后统计成功率、平均步数和失败原因。这套思路放到真实实验里同样适用。
6.4 接入真实设备时怎么扩展
如果你的目标是接真实设备，不需要改动 Agent 循环，只需要把ReactionEnv.execute替换成真实设备的操作函数。比如一个串口控制设备的封装，可能是这样：
# device_adapter.py # 真实设备请以厂商协议为准，这里只演示结构 from serial import Serial ser = Serial("/dev/ttyUSB0", 9600, timeout=2) def set_power(value): # 发送厂商定义的指令 cmd = f"SET POWER {value}\r\n".encode() ser.write(cmd) resp = ser.readline().decode().strip() return {"ack": resp} def read_temperature(): ser.write(b"GET 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 次的重复实验？失败时是自动恢复还是靠人兜底？这三个问题，足够过滤掉一半标题党。
