做没做过做过而且这两年都快做成“军备竞赛”了。但你要是追着问一句“测得到底准不准”我估计十个人里有八个要沉默。别误会我这里说的“机器人/AI 工作者”不是那种在流水线上拧螺丝的机械臂而是更广义的一类东西能自己感知环境、做决策、执行任务的软件硬件综合体。往小了说是跑着 ROS2 的移动底盘往大了说是接了 GPT-4V 视觉接口还能自己调工具的机械臂工作站。最近总有人问我这种“AI 打工人”到底靠不靠谱、怎么验收、有没有一套标准能测一测。今天就把我这些年踩过的坑、跑过的测试、总结出的方法论一次性聊透。这个内容适合谁看如果你正在做机器人选型或者自己开发 AI Agent、机器人导航算法又或者老板突然丢给你一句“给咱们的机器人做个评估”那这篇文章能帮你省下至少两周的调研时间。我会从机器人和大模型 Agent 两个方向分别拆最后给出一套可以直接抄作业的混合基准测试方案。1. 先搞清楚机器人/AI“工作者”到底测什么1.1 为什么大家都在测却总觉得“测不准”先说个扎心的事实到目前为止并没有一个像“考驾照”一样全国统一、行行通用的机器人/AI 基准测试标准。这不是行业懒而是这东西确实难统一。你看手机跑分跑个安兔兔就能比个高下因为手机干的事基本固定就是那些。但机器人呢有人拿它送快递有人拿它焊接有人拿它写代码有人拿它做客服。同一个底盘、同一个大模型放到不同场景里需求的指标完全不一样。送快递的关心导航不撞墙写代码的关心生成代码能不能编译通过做客服的关心回答有没有胡编乱造——你没法用一把尺子量所有东西。但“没有统一标准”不代表“不能测”。行业里已经沉淀出了很多有用的测试方法和基准数据集只是比较碎片化。我自己的经验是与其等一个“全能标准”不如自己搭建一套“组合测试体系”把能用的工具都拼起来针对自己的场景做定制化验收。这就像招聘一样没有哪个考试能测出一个人全面的能力但你通过笔试面试试用期组合起来基本上能筛个八九不离十。1.2 拆解机器人/AI 评估的四个核心维度做了这么多年评估方案我倾向于把所有测试归结为四个维度不管测的是机械臂还是大模型 Agent都能套进去第一个是能力维度就是“能不能做到”。给机器人一条路径规划指令它能不能在 30 秒内给出可行路径给 Agent 一个编程需求它能不能写出能跑的代码。这是最基础的测试但很多人容易忽略的是能力测试必须限定范围比如“在 100 平米无遮挡环境内”、“在仓库地图已完成构建的前提下”否则测试结果根本无法对比。第二个是鲁棒性维度就是“会不会翻车”。能力是理想环境下的表现鲁棒性才是真实落地的关键。比如导航机器人在走廊里遇到突然窜出的人会不会急停Agent 在用户输入带错别字、带口语化表达的指令时还能不能正确理解。我见过太多在演示环境里神勇无比、一到现场就失灵的系统问题基本都出在鲁棒性测试做得太少。第三个是效率维度就是“花多少成本”。机器人跑完一个任务用了多长时间、消耗了多少电量大模型 Agent 回答一个问题消耗了多少 Token、调用了几次工具、延迟是几秒。效率指标往往被新手忽略但它在实际落地时非常要命。一个任务完成率 95% 但平均耗时是人工两倍的 Agent老板是不会买单的。第四个是安全合规维度就是“出事了怎么办”。机器人有没有碰撞检测、紧急制动Agent 在用户提出危险请求时会不会拒绝涉及数据隐私的指令有没有做脱敏。说实话这个维度在行业讨论里最容易被提到但真正被量化执行的反而最少。我在后面会专门讲这块怎么落地。1.3 我自己踩过的最大的坑只测功能不测环境早期我给一个工厂做 AGV 选型评估当时测了十来款机器人的导航精度、避障响应时间、续航能力单项数据都挺漂亮。结果呢到了客户现场地面有几道减速带仓库货架区光线忽明忽暗所有机器人的表现全部崩了——有的定位漂移有的直接停摆。从那以后我定了个死规矩基准测试必须分层禁止只测“理想环境”。后来我设计的测试体系里环境因素单独算一个大类至少要覆盖光照变化、地面材质、动态障碍物密度、网络信号强度这几种典型变量。这个教训放在 AI Agent 上也一样成立你拿标准数据集测出来的高分换到真实用户那蹩脚的提问方式上可能连及格都难。2. 机器人方向从导航、SLAM 到机械臂的硬核测试2.1 ROS2 导航与 SLAM 的基准测试怎么做先说移动机器人最核心的两块导航和 SLAM。SLAM 解决“我在哪、周围长什么样”的问题导航解决“我怎么过去”的问题。这两个是机器人自主移动能力的基石也是基准测试做得相对成熟的领域。SLAM 评估主要用两个指标ATE绝对轨迹误差和RPE相对位姿误差。通俗讲ATE 是机器人估计出来的轨迹和真实轨迹之间差了多少RPE 是相邻两帧之间位姿变化的误差。工具方面我强烈推荐 evo一个 Python 写的评估工具支持 TUM 和 KITTI 数据集的格式几行命令就能画出轨迹对比图并算出均方根误差。# 安装 evo pip install evo # 评估单目/双目 SLAM 结果TUM 格式 evo_ape tum groundtruth.txt trajectory.txt -a -p # 评估 RPE固定间隔 1 帧 evo_rpe tum groundtruth.txt trajectory.txt -d 1 -a -p导航测试在 ROS2 里相对复杂一些。我的做法是先用 Nav2 自带的nav2_simple_commanderAPI 写一个批量巡逻脚本让机器人依次去地图上的 10 个目标点记录每次的路径长度、耗时、与全局规划路径的偏差、是否触发碰撞。这里的关键是目标点的选择必须有讲究不能全选直道。一定要包含几个带拐角的、靠近障碍物的、需要穿过窄门的点才能测出规划器的真实水平。ROS2 开发绕不开的那本书《ROS2机器人开发从入门到实践》里的导航案例可以当基础参考。不过要提醒一句书上给的参数比如代价地图膨胀半径、规划频率都是通用值实际跑的时候必须根据机器人的物理尺寸和传感器布局调我后面会详细说参数怎么调。2.2 导航参数调优的实操心得做导航基准测试的时候最影响测试结果的就是代价地图的几个参数很多新手在这里翻车。我直接给一组我常用的调试起点机器人半径robot_radius不要直接抄底盘规格书的尺寸要把外壳、悬挂凸起都算进去否则会出现“规划路径没撞实际开过去刮了”的情况。宁可多留 2-3 厘米的余量。膨胀层半径inflation_radius默认值通常是 0.55 米但如果你的场景有窄通道比如货架间距只有 1.2 米必须调小到 0.3-0.4 米否则机器人会觉得“所有路都走不通”频繁重新规划。代价比例因子cost_scaling_factor默认 3.0。调高会让路径更贴障碍物走调低会更保守。我一般先从 2.5 开始然后根据实际绕障效果微调。这些参数不是拍脑袋定的核心逻辑是代价地图在机器人周围建立了一个“虚拟排斥场”膨胀半径就是排斥场的范围代价比例因子决定了排斥力衰减的速度。范围越大、衰减越慢机器人越安全但路径越绕反过来就越激进。你要做的就是在安全和效率之间找一个平衡点而这个平衡点和你的物理环境强相关别人给的参数只能当参考。测试的时候一定要用一个固定的评测脚本把地图、起始点、目标点、速度参数全部固定住然后在同一条件下跑 10 次取中位数不要取平均值。为什么因为导航带有随机性偶尔一次碰撞会让平均值剧烈波动中位数更能反映典型表现。2.3 工业机器人与人机协作场景的评估重点说完移动机器人再看固定工位的工业机械臂。如果你关注宇树、法奥、埃夫特这类机器人厂商会发现一个趋势机械臂越来越便宜越来越多人想把它做成“能自己看、自己决定怎么干”的智能工作站。这就对基准测试提出了新要求。传统工业机器人测试走 ISO 9283 标准主要测定位精度和重复定位精度。专业做法是用激光干涉仪测但普通开发团队没这个条件我实测下来用百分表加标准尖点也能做一个粗糙版本让机器人以固定姿态反复触碰一个标准锥形尖点记录每次的偏差。精度不是看单次偏差而是看多次重复的标准差。比如同一个点碰 30 次X/Y/Z 三个方向的偏差都落在 ±0.05mm 内说明重复定位精度很好。但对于“机器人AI”的复合体光测运动精度不够你还要测视觉引导的端到端精度。比如用 3D 相机识别工件位置再引导机械臂去抓取这时候测的不是机械本身的精度而是“视觉识别误差坐标变换误差运动误差”的叠加结果。工业上常叫“手眼标定精度”典型的评价方式是在相机视野内放 10 个已知坐标的标记点让系统视觉定位后机械臂实际去指然后计算指定点和实际点之间的偏差。关于机械臂的终端执行器很多人测的时候只关注关节电机忽略了末端。实际上像音圈电机驱动的末端执行器常用于高精度力控打磨、柔性抓取它的响应带宽和力控稳定性直接决定了整个工作站的上限。测试方法也不复杂给末端执行器一个阶跃力信号用示波器或者数据采集卡记录它的响应曲线看超调量、稳定时间。超调超过 15% 的末端做精密装配基本没戏。2.4 VDA5050 与多机调度场景怎么验收如果机器人不止一台而是几十台在仓库里跑就涉及多机调度这就绕不开 VDA5050 协议。VDA5050 是德国汽车工业协会定义的 AGV 通信接口标准现在国内很多机器人厂商也都在对接。VDA5050 测试通常是这么做的用厂商的调度系统或者自己搭一个主控通过 MQTT 下发任务给机器人然后持续监听机器人的状态消息。关键的验证点有三个状态上报是否及时准确机器人从 IDLE 到 RUNNING 的状态切换延迟应该在毫秒级这个比较容易达到。指令执行的可中断性中途下pause指令机器人能否在安全距离内停下来恢复后又能否回到规划路径上。异常处理机制报文超时、通信断开时机器人会不会自动进入保护性停止。我见过不止一次测试翻车原因都出在“通信断开重连”这个环节。很多机器人的 MQTT 重连逻辑做得很粗糙网络抖动几次之后就不再上报状态了但小车还在跑这就是非常大的安全隐患。VDA5050 兼容性测试一定要把网络故障注入加进去用工具定期断网 3-5 秒观察机器人的反应。2.5 仿真测试怎么搭才靠谱这两年做机器人都流行两件事仿真、数字孪生。但我不建议一上来就上复杂的仿真平台不然你会发现大部分时间都在调仿真环境而不是测机器人。我推荐的路线是分步走第一步用 Gazebo 或 Webots 做传感器仿真主要验证算法逻辑比如导航规划在理想模型下能不能跑通。这里注意仿真里的激光雷达和相机都是理想化的测出来的性能数值不能当作真实指标只能当“逻辑是否走通”的依据。第二步用 ROS2 的 rosbag 记录真实传感器数据然后离线回放给算法跑。这一步非常关键它用真实数据验证算法的“输入输出合理性”但完全不受硬件和控制延迟影响便于纯算法层面的优化对比。第三步才是虚实结合的半物理测试。让算法跑在真实的机器人控制器上但让虚拟障碍物投影到真实环境里这样可以在不担心真实碰撞的前提下测避障。这套搞下来成本不低但对于严肃的机器人开发团队这一套流程是必须的如果跳过电磁干扰、传感器刷新不稳这些现实问题后面现场返工的成本会让你崩溃的。3. AI 工作者Agent 与大模型的基准测试方法完全不一样3.1 先分清你测的是模型、是 Agent、还是工作流与机器人不同AI“工作者”的基准测试更虚但也更快迭代。一个很常见的误区是很多人直接把大模型跑几个榜单MMLU、GSM8K 这类就当做过评测了。但这里有个本质区别你在测“模型”还是在测“Agent”。模型评测是喂一条 prompt 看回复Agent 评测是让它完成一个多步骤任务这中间差了十万八千里。一个模型在 MMLU 上考了 90 分不代表它接上工具之后能稳定完成 30 分钟的长任务——后者不仅依赖模型的推理生成能力还依赖规划能力、工具调用准确率、错误恢复能力甚至“耐心”。如果你只是评估“选哪个大模型做底座”那直接跑学术基准就行简单快捷。比如MMLU测通用知识从高中到专业领域的多选题目。GSM8K测数学推理小学到初中应用题。HumanEval测代码生成用 passk 指标k 表示采样次数官方标准是 pass1也就是一次生成就能跑通所有测试用例的概率。SWE-bench测真实代码修 bug 的能力拿 GitHub 上的真实 issue 让模型修。这些基准跑出来可以作为“选底座”的参考但记住它们只测“模型脑力”不测“Agent 行动力”。3.2 Agent 评测的真实打开方式任务完成率、指令遵循度与成本Agent 的评测我认为需要三个层次结果对不对、过程好不好、成本值不值。结果层面的核心指标是任务完成率Task Success Rate这个最简单、也最硬核。给 Agent 布置 100 个真实任务看它独立完整地完成了多少个。比如给它一个“从飞书机器人接口里读取表格并整理发送”的任务最后表格内容和格式是否正确。注意这里一定要区分“部分完成”和“完全正确”有时候 Agent 干到一半开始胡编看起来完成了实际数据是错的这必须算失败。过程层面要看指令遵循度Instruction Following和工具调用准确率。指令遵循度怎么量化我给你一个笨但有效的方法把任务写成带明确约束条件的 prompt比如“必须使用 Python 3.10必须输出 JSON 格式必须在 10 秒内返回结果”然后检查 Agent 的最终输出有多少条每条违反了约束。工具调用准确率是多智能体系统里很关键的指标记录 Agent 调了哪几个工具、传参格式对不对、返回值有没有被正确处理。大量 Agent 翻车就翻在参数格式上比如把字符串当整数传给工具报错了又不知道重试。成本层面我每次必看两个值单任务平均 Token 消耗和单任务平均 API 调用次数。这两个指标能帮你发现“隐形烧钱”的问题。有的 Agent 框架喜欢在一个任务里反复循环调用模型一次简单问答搞了五六轮Token 成本直接翻倍。很多团队团队只盯着准确率上线后账单爆炸才来找原因其实都是评测时没把成本列为硬指标。3.3 RAG 和工具调用的专项评估怎么做现在做 AI 工作者百分之七八十都会上 RAG检索增强生成——从私有知识库里检索资料再生成回答。RAG 的评测有个麻烦最终回答的质量受“检索”和“生成”两个环节双重影响你得拆开测。检索环节看召回率Recall和排名质量。最简单的方法准备 50 道带标准答案的测试题每道题对应知识库里的特定文档片段。把 Agent 的检索接口拉出来单独调用看它返回的前 5 条结果里有没有包含正确答案对应的文档。如果知识库里明明有答案但每次都检索不到那问题不在 AI 生成能力而在 embedding 选型、分块策略或向量数据库配置上。生成环节看忠实度Faithfulness和答案相关度Relevance。忠实度是检查回答内容有没有忠实于检索到的资料有没有自己编造。这个指标在 RAGAS 这个评估库里做得比较好我常用的命令是from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy result evaluate( dataset, # 包含 question, answer, contexts, ground_truth metrics[faithfulness, answer_relevancy] )关于 embedding 的选型其实很容易被低估。我实测下来领域术语较多的知识库比如医药、法律、机器人论文通用 embedding 的效果一般有条件的先用 BGE-M3 或自定义微调后的 embedding 模型对比一下检索召回率。如果前后端已经定了 OpenAI 的生态也别偷懒直接接默认 embedding至少拿 50 条领域样本做一次人工相关性评测再定。至于 Agent 接外部工具查天气、订会议、读数据库的测试核心是“工具契约测试”。给每个工具定义一个严格的输入输出 schema然后构造 20 组正常输入、10 组边界输入、10 组恶意输入看 Agent 能否正确解析、正确传参、优雅地处理工具报错。这块不能偷懒把 Agent 和工具放一起端到端测不然出了问题你根本定位不到是工具 bug 还是 Agent 的问题。3.4 用 ROS2 大模型做机器人任务的评估指令遵循与任务分解把机器人和大模型 AI 结合起来的“机器人大脑”这两年非常火。做法基本是用大模型做任务理解与规划把自然语言指令翻译成机器人的动作序列。这类系统的评测市面上标准很少我分享一套自己在用的方案。我给每个任务准备三类测试用例单步显式指令比如“前进 1 米”、“原地旋转 90 度”。测的是大模型能不能把自然语言准确翻译成运动控制指令考察数值提取和单位换算能力。多步隐式任务比如“绕开障碍物到达 A 点”、“先去充电桩再回到工位”。测的是任务分解能力看大模型能不能拆出合理的动作序列。异常恢复指令比如“你在执行途中传感器没检测到前方障碍请重新规划”。测的是大模型能否根据实时反馈调整计划而不是傻傻执行原计划。这套测试跑下来最有意思的是多步隐式任务往往会暴露大模型“自说自话”的问题它在语义上规划得头头是道但生成的规划根本不符合物理约束比如让四驱差速底盘完成原地横移这在硬件上根本不可能。所以测试报告里一定要加一条“物理可行性评分”把规划方案交给机器人工程师人工审核这比任何自动指标都靠谱。顺便说一句如果你遇到的是“青少年机器人技术等级考试”这类场景那考的其实是固定的知识点和标准动作属于另一种形式的基准测试。它的价值不在难度而在于“评判标准的可复现性”。这也印证了一件事标准越是明确学习者和评判者的沟通成本就越低这个逻辑在行业评测里同样适用。4. 实操经验我落地的一套混合基准测试方案4.1 测试设计前先想清楚的三个问题真正开始跑测试之前我最喜欢问自己三个问题也建议你每次测试前都先自问一遍第一“测出来的结果要支撑什么决策”如果你是想在 A 和 B 两个机器人方案之间做选型那测试要侧重于横向对比如果你是想验证自研算法是否有改进那测试要侧重于纵向对比用同一套基线每次改完只跑回归。决策场景不一样测试设计的细节就会完全不同。这个问题如果没想清楚测评很容易变成“为了测而测”最后得出一堆数据却不知道该怎么用。第二“基线是什么”很多团队测试的最大问题就是没有基线。你说 Agent 的任务完成率是 70%那 70% 是相对什么的相对人工完成的标准相对上一个版本相对竞品没有基线的测试报告在技术评审会上就是一张废纸。我自己的习惯是每个项目评测之前先定义三条基线人类表现基线如果任务人类能完成的话、旧系统基线、理论最优基线。第三“需要多少样本量才可信”大模型输出有随机性5 次测试和 50 次测试的结果可能天差地别。对于 Agent 任务我个人的最低样本线是一次评测至少 30 条测试用例对于涉及随机采样的任务同一个样本要重复跑 5 次以上。说白了评测结果不是点估计你至少要能算出方差和置信区间。4.2 三层测试模型覆盖从开发到验收全流程我在实际项目中用的是“三层测试模型”整个体系分三层每层解决的问题不一样第一层是单元能力测试目标是“确认每个零件没坏”。比如大模型的意图识别准确率、SLAM 的轨迹误差、机械臂的重复定位精度。这些测试可以频繁跑每次代码变更后都可以跑一遍相当于日常体检。第二层是场景集成测试目标是“确认组合起来能干活”。比如“识别货架二维码 导航到目标货位 机械臂抓取指定商品”这个完整动作。测试脚本必须完全模拟真实任务流程不能裁剪环节否则集成问题很难暴露。这里的测试用例要包含正常路径也包含异常分支比如二维码被部分遮挡、商品被错放位置等情况。第三层是长时间稳定性测试目标是“确认连续工作不趴窝”。机器人连续运行 8 小时以上、Agent 连续处理 500 条请求看有没有内存泄漏、死锁、响应退化。很多系统在新环境里惊艳全场、三十小时后原形毕露都是这一层没做够导致的。4.3 数据采集与自动化测试脚本骨架不要手工做测试一定要自动化。我给你一个我常用的 Python 测试脚本骨架做 Agent 类测试时改改就能用import json import time from typing import Any class BenchmarkRunner: def __init__(self, agent, tasks_path: str, repeat_times: int 5): self.agent agent self.tasks json.load(open(tasks_path, encodingutf-8)) self.repeat_times repeat_times def run_task(self, task: dict) - dict: 执行单个任务记录性能指标 start time.time() try: result self.agent.run(task[instruction]) success self.check_success(result, task.get(expected)) return { task_id: task[id], success: success, latency: time.time() - start, token_used: result.get(token_usage, 0), error: None } except Exception as e: return { task_id: task[id], success: False, latency: time.time() - start, token_used: 0, error: str(e) } def run_all(self) - dict: 批量执行所有任务重复多次取统计值 results [] for task in self.tasks: for _ in range(self.repeat_times): results.append(self.run_task(task)) return self.aggregate(results) staticmethod def aggregate(results: list) - dict: 聚合统计数据成功率、平均时延、P95 时延等 successes [r for r in results if r[success]] latencies sorted(r[latency] for r in results) p95 latencies[int(len(latencies) * 0.95) - 1] return { total: len(results), success_rate: len(successes) / len(results), avg_latency: sum(r[latency] for r in results) / len(results), p95_latency: p95, avg_token: sum(r.get(token_used, 0) for r in results) / len(results) }机器人端的自动化类似核心是固定一个“任务描述文件”加一个“结果采集器”。任务描述文件里面写目标点列表、验收条件结果采集器接 ROS2 的 topic记录 /odom、/amcl_pose、/cmd_vel 等关键数据最后统一算指标。4.4 测试报告怎么解读才不会被忽悠我见过太多团队测试报告做得漂亮极了图表一大堆实际上问题重重。解读测试报告我有三条“防忽悠”原则第一看指标定义不看指标名称。比如“准确率”是一步到位答对才叫准确还是只要包含关键信息就算准确定义不同数字能相差 20 个百分点。我要求所有报告必须附上“指标计算伪代码”否则直接打回重写。第二看测试集构成。一个全是简单任务的“高成功率”没有任何意义。我习惯把测试集按难度分层报告里必须同时展示简单层、中等层、困难层各自的成功率。如果困难层成功率远低于简单层说明系统上限有限如果各层差别不大反而说明测试集设计不够有区分度。第三看方差和失败模式。平均数没有意义要看最差情况。所有 Agent 都会在某些特定任务上系统性失败比如长文本理解差、日期计算容易错、多轮对话后忘记上下文。这些系统性失败不会体现在平均分里必须逐个看失败样例做归因。每轮测试报告我要求附一页“典型失败模式列表”这个列表对于后面优化系统的价值比正确率数字重要十倍。5. 常见问题与排查技巧实录5.1 测试集污染为什么模型分数虚高这几年我见的 AI 评测翻车事故里至少三成是“测试集污染”导致的。所谓测试集污染就是你用的测试题已经在模型的训练集里出现过了模型记住的不是“推理能力”而是“标准答案”。典型表现是模型在新出的题上表现平平但在老数据集上分数奇高。排查方法其实很简单——拿掉几个样本改个数字、换个说法再做一遍如果分数掉得离谱就说明模型在“背答案”而不是“会做题”。应对措施也不复杂优先用新构建的私有测试集不要只依赖公开基准。公开基准适合做“行业横向对比”但私有测试集才是你评估自己系统的真正标尺。5.2 仿真和实机测试结果对不上这是机器人测试最常见的问题没有之一。仿真里导航成功率 95%实机跑起来 60% 不到。原因基本出在三个地方第一是传感器差异仿真激光雷达是理想化的实机的激光雷达有噪声、有极限距离和盲区。解决办法是给仿真模型加入噪声参数匹配实机传感器的噪声水平。第二是执行差异仿真模型的底盘是完美运动学实机有轮胎打滑、电机响应延迟。解决的关键是要在仿真里加入“执行噪声”比如给速度指令加一个随机延迟 50-100ms这样仿真结果更接近实机。第三是环境差异仿真地图是静态的实机场景随时可能有人路过、有门开关。这只能靠增加动态障碍物测试用例来逼近真实。我的个人经验是不要试图让仿真完全等于实机这不现实要让仿真环境的不确定性略大于实机。这样如果仿真测试能通过实机表现虽然打折扣但不至于崩盘。5.3 机器人测试的随机性问题与重复性处理机器人测试天然带有随机性同一个任务每次跑的数据都不一样这和代码单测是完全不同的逻辑。你没法像断言一个函数返回值那样断言一个机器人“必须成功”。我的处理方式是引入“统计化验收”的思维不确定用单次结果做判断而是用多次结果的成功率做判断。我常用的验收标准是导航类任务同一场景跑 10 次成功率 ≥ 8 次且失败时不能有危险动作比如高速碰撞。SLAM 类任务同一数据集跑 5 次轨迹误差方差不超过均值的 30%。Agent 类任务同一 prompt 跑 5 次结果必须达到“语义一致性”要求结果全对或全错不算随机最担心的是一会儿对一会儿错。如果明明可以稳定正确却出现了随机失败不用想肯定有隐藏的并发问题或状态污染。这种情况我建议直接加日志排查重点对 Agent 的上下文缓存机制开刀。你会发现很多“随机性”实际上是缓存击穿或者一个被多线程改写的全局状态导致的。5.4 基准测试速查表我常用的核心指标测试对象核心指标关键工具/方法推荐最低样本量SLAM 定位ATE / RPE 均方根误差evo 工具3 组数据集ROS2 导航到达成功率、路径偏差、平均速度nav2_simple_commander 批量脚本同一地图 10 次工业机械臂重复定位精度、路径精度ISO 9283、激光干涉仪/百分表30 次重复VDA5050 调度断线恢复时间、状态上报延迟MQTT 模拟器 故障注入100 条消息大模型底座MMLU / GSM8K / HumanEval pass1学术基准库官方测试集Agent 任务任务完成率、工具调用准确率、单任务 Token自建任务集 RAGAS30 条任务RAG 检索召回率、MRRRAGAS / 人工判分50 条知识库样本端到端视觉抓取指点点位误差、抓取成功率标定板 轨迹录制20 次抓取5.5 关于“机器人认证”这类事的看法聊到最后想说一下“机器人认证”。这个领域现在的认证体系参差不齐有的是行业联盟出的有的是厂商出的有的是第三方机构出的。我的看法是认证可以参考但不能替代自己的基准测试。道理很简单认证考试考的是通用场景你的场景大概率是特殊场景。就好比拿了驾照不代表你就能开好救护车。真正决定系统能不能落地的是你自己的验收测试是你在自己场景下的长跑测试。认证顶多算个“及格线”而及格线以上的竞争只能靠你自己测出来。最后分享一点个人杂感说实话干这行越久我越觉得“基准测试”这件事本质上是给“不确定性”建立一个可比较的标尺。不管是机器人面对的真实物理世界还是大模型面对的语言世界到处都是噪声、例外和边界情况。所谓测试其实就是把“我觉得它行”变成“数据显示它行”的过程。做基准测试这么多年我最大的体会是四个字别怕吃亏。别嫌设计测试场景麻烦别嫌跑一百遍任务枯燥别嫌分析失败模式耗时。你在测试阶段偷的每一次懒都会在系统上线之后以更难看的方式还回来。可能是在客户现场机器人在众目睽睽之下撞了墙也可能是 Agent 报出一个完全错误的数字还一本正经地给出解释步骤。而是反过来坚持“先测透、再上线”这个死规矩你的系统在真实运行时会给你远超预期的底气。做测试这事稳赚不亏。 机器人/AI基准测试实战：从ROS2导航到Agent评估
做没做过做过而且这两年都快做成“军备竞赛”了。但你要是追着问一句“测得到底准不准”我估计十个人里有八个要沉默。别误会我这里说的“机器人/AI 工作者”不是那种在流水线上拧螺丝的机械臂而是更广义的一类东西能自己感知环境、做决策、执行任务的软件硬件综合体。往小了说是跑着 ROS2 的移动底盘往大了说是接了 GPT-4V 视觉接口还能自己调工具的机械臂工作站。最近总有人问我这种“AI 打工人”到底靠不靠谱、怎么验收、有没有一套标准能测一测。今天就把我这些年踩过的坑、跑过的测试、总结出的方法论一次性聊透。这个内容适合谁看如果你正在做机器人选型或者自己开发 AI Agent、机器人导航算法又或者老板突然丢给你一句“给咱们的机器人做个评估”那这篇文章能帮你省下至少两周的调研时间。我会从机器人和大模型 Agent 两个方向分别拆最后给出一套可以直接抄作业的混合基准测试方案。1. 先搞清楚机器人/AI“工作者”到底测什么1.1 为什么大家都在测却总觉得“测不准”先说个扎心的事实到目前为止并没有一个像“考驾照”一样全国统一、行行通用的机器人/AI 基准测试标准。这不是行业懒而是这东西确实难统一。你看手机跑分跑个安兔兔就能比个高下因为手机干的事基本固定就是那些。但机器人呢有人拿它送快递有人拿它焊接有人拿它写代码有人拿它做客服。同一个底盘、同一个大模型放到不同场景里需求的指标完全不一样。送快递的关心导航不撞墙写代码的关心生成代码能不能编译通过做客服的关心回答有没有胡编乱造——你没法用一把尺子量所有东西。但“没有统一标准”不代表“不能测”。行业里已经沉淀出了很多有用的测试方法和基准数据集只是比较碎片化。我自己的经验是与其等一个“全能标准”不如自己搭建一套“组合测试体系”把能用的工具都拼起来针对自己的场景做定制化验收。这就像招聘一样没有哪个考试能测出一个人全面的能力但你通过笔试面试试用期组合起来基本上能筛个八九不离十。1.2 拆解机器人/AI 评估的四个核心维度做了这么多年评估方案我倾向于把所有测试归结为四个维度不管测的是机械臂还是大模型 Agent都能套进去第一个是能力维度就是“能不能做到”。给机器人一条路径规划指令它能不能在 30 秒内给出可行路径给 Agent 一个编程需求它能不能写出能跑的代码。这是最基础的测试但很多人容易忽略的是能力测试必须限定范围比如“在 100 平米无遮挡环境内”、“在仓库地图已完成构建的前提下”否则测试结果根本无法对比。第二个是鲁棒性维度就是“会不会翻车”。能力是理想环境下的表现鲁棒性才是真实落地的关键。比如导航机器人在走廊里遇到突然窜出的人会不会急停Agent 在用户输入带错别字、带口语化表达的指令时还能不能正确理解。我见过太多在演示环境里神勇无比、一到现场就失灵的系统问题基本都出在鲁棒性测试做得太少。第三个是效率维度就是“花多少成本”。机器人跑完一个任务用了多长时间、消耗了多少电量大模型 Agent 回答一个问题消耗了多少 Token、调用了几次工具、延迟是几秒。效率指标往往被新手忽略但它在实际落地时非常要命。一个任务完成率 95% 但平均耗时是人工两倍的 Agent老板是不会买单的。第四个是安全合规维度就是“出事了怎么办”。机器人有没有碰撞检测、紧急制动Agent 在用户提出危险请求时会不会拒绝涉及数据隐私的指令有没有做脱敏。说实话这个维度在行业讨论里最容易被提到但真正被量化执行的反而最少。我在后面会专门讲这块怎么落地。1.3 我自己踩过的最大的坑只测功能不测环境早期我给一个工厂做 AGV 选型评估当时测了十来款机器人的导航精度、避障响应时间、续航能力单项数据都挺漂亮。结果呢到了客户现场地面有几道减速带仓库货架区光线忽明忽暗所有机器人的表现全部崩了——有的定位漂移有的直接停摆。从那以后我定了个死规矩基准测试必须分层禁止只测“理想环境”。后来我设计的测试体系里环境因素单独算一个大类至少要覆盖光照变化、地面材质、动态障碍物密度、网络信号强度这几种典型变量。这个教训放在 AI Agent 上也一样成立你拿标准数据集测出来的高分换到真实用户那蹩脚的提问方式上可能连及格都难。2. 机器人方向从导航、SLAM 到机械臂的硬核测试2.1 ROS2 导航与 SLAM 的基准测试怎么做先说移动机器人最核心的两块导航和 SLAM。SLAM 解决“我在哪、周围长什么样”的问题导航解决“我怎么过去”的问题。这两个是机器人自主移动能力的基石也是基准测试做得相对成熟的领域。SLAM 评估主要用两个指标ATE绝对轨迹误差和RPE相对位姿误差。通俗讲ATE 是机器人估计出来的轨迹和真实轨迹之间差了多少RPE 是相邻两帧之间位姿变化的误差。工具方面我强烈推荐 evo一个 Python 写的评估工具支持 TUM 和 KITTI 数据集的格式几行命令就能画出轨迹对比图并算出均方根误差。# 安装 evo pip install evo # 评估单目/双目 SLAM 结果TUM 格式 evo_ape tum groundtruth.txt trajectory.txt -a -p # 评估 RPE固定间隔 1 帧 evo_rpe tum groundtruth.txt trajectory.txt -d 1 -a -p导航测试在 ROS2 里相对复杂一些。我的做法是先用 Nav2 自带的nav2_simple_commanderAPI 写一个批量巡逻脚本让机器人依次去地图上的 10 个目标点记录每次的路径长度、耗时、与全局规划路径的偏差、是否触发碰撞。这里的关键是目标点的选择必须有讲究不能全选直道。一定要包含几个带拐角的、靠近障碍物的、需要穿过窄门的点才能测出规划器的真实水平。ROS2 开发绕不开的那本书《ROS2机器人开发从入门到实践》里的导航案例可以当基础参考。不过要提醒一句书上给的参数比如代价地图膨胀半径、规划频率都是通用值实际跑的时候必须根据机器人的物理尺寸和传感器布局调我后面会详细说参数怎么调。2.2 导航参数调优的实操心得做导航基准测试的时候最影响测试结果的就是代价地图的几个参数很多新手在这里翻车。我直接给一组我常用的调试起点机器人半径robot_radius不要直接抄底盘规格书的尺寸要把外壳、悬挂凸起都算进去否则会出现“规划路径没撞实际开过去刮了”的情况。宁可多留 2-3 厘米的余量。膨胀层半径inflation_radius默认值通常是 0.55 米但如果你的场景有窄通道比如货架间距只有 1.2 米必须调小到 0.3-0.4 米否则机器人会觉得“所有路都走不通”频繁重新规划。代价比例因子cost_scaling_factor默认 3.0。调高会让路径更贴障碍物走调低会更保守。我一般先从 2.5 开始然后根据实际绕障效果微调。这些参数不是拍脑袋定的核心逻辑是代价地图在机器人周围建立了一个“虚拟排斥场”膨胀半径就是排斥场的范围代价比例因子决定了排斥力衰减的速度。范围越大、衰减越慢机器人越安全但路径越绕反过来就越激进。你要做的就是在安全和效率之间找一个平衡点而这个平衡点和你的物理环境强相关别人给的参数只能当参考。测试的时候一定要用一个固定的评测脚本把地图、起始点、目标点、速度参数全部固定住然后在同一条件下跑 10 次取中位数不要取平均值。为什么因为导航带有随机性偶尔一次碰撞会让平均值剧烈波动中位数更能反映典型表现。2.3 工业机器人与人机协作场景的评估重点说完移动机器人再看固定工位的工业机械臂。如果你关注宇树、法奥、埃夫特这类机器人厂商会发现一个趋势机械臂越来越便宜越来越多人想把它做成“能自己看、自己决定怎么干”的智能工作站。这就对基准测试提出了新要求。传统工业机器人测试走 ISO 9283 标准主要测定位精度和重复定位精度。专业做法是用激光干涉仪测但普通开发团队没这个条件我实测下来用百分表加标准尖点也能做一个粗糙版本让机器人以固定姿态反复触碰一个标准锥形尖点记录每次的偏差。精度不是看单次偏差而是看多次重复的标准差。比如同一个点碰 30 次X/Y/Z 三个方向的偏差都落在 ±0.05mm 内说明重复定位精度很好。但对于“机器人AI”的复合体光测运动精度不够你还要测视觉引导的端到端精度。比如用 3D 相机识别工件位置再引导机械臂去抓取这时候测的不是机械本身的精度而是“视觉识别误差坐标变换误差运动误差”的叠加结果。工业上常叫“手眼标定精度”典型的评价方式是在相机视野内放 10 个已知坐标的标记点让系统视觉定位后机械臂实际去指然后计算指定点和实际点之间的偏差。关于机械臂的终端执行器很多人测的时候只关注关节电机忽略了末端。实际上像音圈电机驱动的末端执行器常用于高精度力控打磨、柔性抓取它的响应带宽和力控稳定性直接决定了整个工作站的上限。测试方法也不复杂给末端执行器一个阶跃力信号用示波器或者数据采集卡记录它的响应曲线看超调量、稳定时间。超调超过 15% 的末端做精密装配基本没戏。2.4 VDA5050 与多机调度场景怎么验收如果机器人不止一台而是几十台在仓库里跑就涉及多机调度这就绕不开 VDA5050 协议。VDA5050 是德国汽车工业协会定义的 AGV 通信接口标准现在国内很多机器人厂商也都在对接。VDA5050 测试通常是这么做的用厂商的调度系统或者自己搭一个主控通过 MQTT 下发任务给机器人然后持续监听机器人的状态消息。关键的验证点有三个状态上报是否及时准确机器人从 IDLE 到 RUNNING 的状态切换延迟应该在毫秒级这个比较容易达到。指令执行的可中断性中途下pause指令机器人能否在安全距离内停下来恢复后又能否回到规划路径上。异常处理机制报文超时、通信断开时机器人会不会自动进入保护性停止。我见过不止一次测试翻车原因都出在“通信断开重连”这个环节。很多机器人的 MQTT 重连逻辑做得很粗糙网络抖动几次之后就不再上报状态了但小车还在跑这就是非常大的安全隐患。VDA5050 兼容性测试一定要把网络故障注入加进去用工具定期断网 3-5 秒观察机器人的反应。2.5 仿真测试怎么搭才靠谱这两年做机器人都流行两件事仿真、数字孪生。但我不建议一上来就上复杂的仿真平台不然你会发现大部分时间都在调仿真环境而不是测机器人。我推荐的路线是分步走第一步用 Gazebo 或 Webots 做传感器仿真主要验证算法逻辑比如导航规划在理想模型下能不能跑通。这里注意仿真里的激光雷达和相机都是理想化的测出来的性能数值不能当作真实指标只能当“逻辑是否走通”的依据。第二步用 ROS2 的 rosbag 记录真实传感器数据然后离线回放给算法跑。这一步非常关键它用真实数据验证算法的“输入输出合理性”但完全不受硬件和控制延迟影响便于纯算法层面的优化对比。第三步才是虚实结合的半物理测试。让算法跑在真实的机器人控制器上但让虚拟障碍物投影到真实环境里这样可以在不担心真实碰撞的前提下测避障。这套搞下来成本不低但对于严肃的机器人开发团队这一套流程是必须的如果跳过电磁干扰、传感器刷新不稳这些现实问题后面现场返工的成本会让你崩溃的。3. AI 工作者Agent 与大模型的基准测试方法完全不一样3.1 先分清你测的是模型、是 Agent、还是工作流与机器人不同AI“工作者”的基准测试更虚但也更快迭代。一个很常见的误区是很多人直接把大模型跑几个榜单MMLU、GSM8K 这类就当做过评测了。但这里有个本质区别你在测“模型”还是在测“Agent”。模型评测是喂一条 prompt 看回复Agent 评测是让它完成一个多步骤任务这中间差了十万八千里。一个模型在 MMLU 上考了 90 分不代表它接上工具之后能稳定完成 30 分钟的长任务——后者不仅依赖模型的推理生成能力还依赖规划能力、工具调用准确率、错误恢复能力甚至“耐心”。如果你只是评估“选哪个大模型做底座”那直接跑学术基准就行简单快捷。比如MMLU测通用知识从高中到专业领域的多选题目。GSM8K测数学推理小学到初中应用题。HumanEval测代码生成用 passk 指标k 表示采样次数官方标准是 pass1也就是一次生成就能跑通所有测试用例的概率。SWE-bench测真实代码修 bug 的能力拿 GitHub 上的真实 issue 让模型修。这些基准跑出来可以作为“选底座”的参考但记住它们只测“模型脑力”不测“Agent 行动力”。3.2 Agent 评测的真实打开方式任务完成率、指令遵循度与成本Agent 的评测我认为需要三个层次结果对不对、过程好不好、成本值不值。结果层面的核心指标是任务完成率Task Success Rate这个最简单、也最硬核。给 Agent 布置 100 个真实任务看它独立完整地完成了多少个。比如给它一个“从飞书机器人接口里读取表格并整理发送”的任务最后表格内容和格式是否正确。注意这里一定要区分“部分完成”和“完全正确”有时候 Agent 干到一半开始胡编看起来完成了实际数据是错的这必须算失败。过程层面要看指令遵循度Instruction Following和工具调用准确率。指令遵循度怎么量化我给你一个笨但有效的方法把任务写成带明确约束条件的 prompt比如“必须使用 Python 3.10必须输出 JSON 格式必须在 10 秒内返回结果”然后检查 Agent 的最终输出有多少条每条违反了约束。工具调用准确率是多智能体系统里很关键的指标记录 Agent 调了哪几个工具、传参格式对不对、返回值有没有被正确处理。大量 Agent 翻车就翻在参数格式上比如把字符串当整数传给工具报错了又不知道重试。成本层面我每次必看两个值单任务平均 Token 消耗和单任务平均 API 调用次数。这两个指标能帮你发现“隐形烧钱”的问题。有的 Agent 框架喜欢在一个任务里反复循环调用模型一次简单问答搞了五六轮Token 成本直接翻倍。很多团队团队只盯着准确率上线后账单爆炸才来找原因其实都是评测时没把成本列为硬指标。3.3 RAG 和工具调用的专项评估怎么做现在做 AI 工作者百分之七八十都会上 RAG检索增强生成——从私有知识库里检索资料再生成回答。RAG 的评测有个麻烦最终回答的质量受“检索”和“生成”两个环节双重影响你得拆开测。检索环节看召回率Recall和排名质量。最简单的方法准备 50 道带标准答案的测试题每道题对应知识库里的特定文档片段。把 Agent 的检索接口拉出来单独调用看它返回的前 5 条结果里有没有包含正确答案对应的文档。如果知识库里明明有答案但每次都检索不到那问题不在 AI 生成能力而在 embedding 选型、分块策略或向量数据库配置上。生成环节看忠实度Faithfulness和答案相关度Relevance。忠实度是检查回答内容有没有忠实于检索到的资料有没有自己编造。这个指标在 RAGAS 这个评估库里做得比较好我常用的命令是from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy result evaluate( dataset, # 包含 question, answer, contexts, ground_truth metrics[faithfulness, answer_relevancy] )关于 embedding 的选型其实很容易被低估。我实测下来领域术语较多的知识库比如医药、法律、机器人论文通用 embedding 的效果一般有条件的先用 BGE-M3 或自定义微调后的 embedding 模型对比一下检索召回率。如果前后端已经定了 OpenAI 的生态也别偷懒直接接默认 embedding至少拿 50 条领域样本做一次人工相关性评测再定。至于 Agent 接外部工具查天气、订会议、读数据库的测试核心是“工具契约测试”。给每个工具定义一个严格的输入输出 schema然后构造 20 组正常输入、10 组边界输入、10 组恶意输入看 Agent 能否正确解析、正确传参、优雅地处理工具报错。这块不能偷懒把 Agent 和工具放一起端到端测不然出了问题你根本定位不到是工具 bug 还是 Agent 的问题。3.4 用 ROS2 大模型做机器人任务的评估指令遵循与任务分解把机器人和大模型 AI 结合起来的“机器人大脑”这两年非常火。做法基本是用大模型做任务理解与规划把自然语言指令翻译成机器人的动作序列。这类系统的评测市面上标准很少我分享一套自己在用的方案。我给每个任务准备三类测试用例单步显式指令比如“前进 1 米”、“原地旋转 90 度”。测的是大模型能不能把自然语言准确翻译成运动控制指令考察数值提取和单位换算能力。多步隐式任务比如“绕开障碍物到达 A 点”、“先去充电桩再回到工位”。测的是任务分解能力看大模型能不能拆出合理的动作序列。异常恢复指令比如“你在执行途中传感器没检测到前方障碍请重新规划”。测的是大模型能否根据实时反馈调整计划而不是傻傻执行原计划。这套测试跑下来最有意思的是多步隐式任务往往会暴露大模型“自说自话”的问题它在语义上规划得头头是道但生成的规划根本不符合物理约束比如让四驱差速底盘完成原地横移这在硬件上根本不可能。所以测试报告里一定要加一条“物理可行性评分”把规划方案交给机器人工程师人工审核这比任何自动指标都靠谱。顺便说一句如果你遇到的是“青少年机器人技术等级考试”这类场景那考的其实是固定的知识点和标准动作属于另一种形式的基准测试。它的价值不在难度而在于“评判标准的可复现性”。这也印证了一件事标准越是明确学习者和评判者的沟通成本就越低这个逻辑在行业评测里同样适用。4. 实操经验我落地的一套混合基准测试方案4.1 测试设计前先想清楚的三个问题真正开始跑测试之前我最喜欢问自己三个问题也建议你每次测试前都先自问一遍第一“测出来的结果要支撑什么决策”如果你是想在 A 和 B 两个机器人方案之间做选型那测试要侧重于横向对比如果你是想验证自研算法是否有改进那测试要侧重于纵向对比用同一套基线每次改完只跑回归。决策场景不一样测试设计的细节就会完全不同。这个问题如果没想清楚测评很容易变成“为了测而测”最后得出一堆数据却不知道该怎么用。第二“基线是什么”很多团队测试的最大问题就是没有基线。你说 Agent 的任务完成率是 70%那 70% 是相对什么的相对人工完成的标准相对上一个版本相对竞品没有基线的测试报告在技术评审会上就是一张废纸。我自己的习惯是每个项目评测之前先定义三条基线人类表现基线如果任务人类能完成的话、旧系统基线、理论最优基线。第三“需要多少样本量才可信”大模型输出有随机性5 次测试和 50 次测试的结果可能天差地别。对于 Agent 任务我个人的最低样本线是一次评测至少 30 条测试用例对于涉及随机采样的任务同一个样本要重复跑 5 次以上。说白了评测结果不是点估计你至少要能算出方差和置信区间。4.2 三层测试模型覆盖从开发到验收全流程我在实际项目中用的是“三层测试模型”整个体系分三层每层解决的问题不一样第一层是单元能力测试目标是“确认每个零件没坏”。比如大模型的意图识别准确率、SLAM 的轨迹误差、机械臂的重复定位精度。这些测试可以频繁跑每次代码变更后都可以跑一遍相当于日常体检。第二层是场景集成测试目标是“确认组合起来能干活”。比如“识别货架二维码 导航到目标货位 机械臂抓取指定商品”这个完整动作。测试脚本必须完全模拟真实任务流程不能裁剪环节否则集成问题很难暴露。这里的测试用例要包含正常路径也包含异常分支比如二维码被部分遮挡、商品被错放位置等情况。第三层是长时间稳定性测试目标是“确认连续工作不趴窝”。机器人连续运行 8 小时以上、Agent 连续处理 500 条请求看有没有内存泄漏、死锁、响应退化。很多系统在新环境里惊艳全场、三十小时后原形毕露都是这一层没做够导致的。4.3 数据采集与自动化测试脚本骨架不要手工做测试一定要自动化。我给你一个我常用的 Python 测试脚本骨架做 Agent 类测试时改改就能用import json import time from typing import Any class BenchmarkRunner: def __init__(self, agent, tasks_path: str, repeat_times: int 5): self.agent agent self.tasks json.load(open(tasks_path, encodingutf-8)) self.repeat_times repeat_times def run_task(self, task: dict) - dict: 执行单个任务记录性能指标 start time.time() try: result self.agent.run(task[instruction]) success self.check_success(result, task.get(expected)) return { task_id: task[id], success: success, latency: time.time() - start, token_used: result.get(token_usage, 0), error: None } except Exception as e: return { task_id: task[id], success: False, latency: time.time() - start, token_used: 0, error: str(e) } def run_all(self) - dict: 批量执行所有任务重复多次取统计值 results [] for task in self.tasks: for _ in range(self.repeat_times): results.append(self.run_task(task)) return self.aggregate(results) staticmethod def aggregate(results: list) - dict: 聚合统计数据成功率、平均时延、P95 时延等 successes [r for r in results if r[success]] latencies sorted(r[latency] for r in results) p95 latencies[int(len(latencies) * 0.95) - 1] return { total: len(results), success_rate: len(successes) / len(results), avg_latency: sum(r[latency] for r in results) / len(results), p95_latency: p95, avg_token: sum(r.get(token_used, 0) for r in results) / len(results) }机器人端的自动化类似核心是固定一个“任务描述文件”加一个“结果采集器”。任务描述文件里面写目标点列表、验收条件结果采集器接 ROS2 的 topic记录 /odom、/amcl_pose、/cmd_vel 等关键数据最后统一算指标。4.4 测试报告怎么解读才不会被忽悠我见过太多团队测试报告做得漂亮极了图表一大堆实际上问题重重。解读测试报告我有三条“防忽悠”原则第一看指标定义不看指标名称。比如“准确率”是一步到位答对才叫准确还是只要包含关键信息就算准确定义不同数字能相差 20 个百分点。我要求所有报告必须附上“指标计算伪代码”否则直接打回重写。第二看测试集构成。一个全是简单任务的“高成功率”没有任何意义。我习惯把测试集按难度分层报告里必须同时展示简单层、中等层、困难层各自的成功率。如果困难层成功率远低于简单层说明系统上限有限如果各层差别不大反而说明测试集设计不够有区分度。第三看方差和失败模式。平均数没有意义要看最差情况。所有 Agent 都会在某些特定任务上系统性失败比如长文本理解差、日期计算容易错、多轮对话后忘记上下文。这些系统性失败不会体现在平均分里必须逐个看失败样例做归因。每轮测试报告我要求附一页“典型失败模式列表”这个列表对于后面优化系统的价值比正确率数字重要十倍。5. 常见问题与排查技巧实录5.1 测试集污染为什么模型分数虚高这几年我见的 AI 评测翻车事故里至少三成是“测试集污染”导致的。所谓测试集污染就是你用的测试题已经在模型的训练集里出现过了模型记住的不是“推理能力”而是“标准答案”。典型表现是模型在新出的题上表现平平但在老数据集上分数奇高。排查方法其实很简单——拿掉几个样本改个数字、换个说法再做一遍如果分数掉得离谱就说明模型在“背答案”而不是“会做题”。应对措施也不复杂优先用新构建的私有测试集不要只依赖公开基准。公开基准适合做“行业横向对比”但私有测试集才是你评估自己系统的真正标尺。5.2 仿真和实机测试结果对不上这是机器人测试最常见的问题没有之一。仿真里导航成功率 95%实机跑起来 60% 不到。原因基本出在三个地方第一是传感器差异仿真激光雷达是理想化的实机的激光雷达有噪声、有极限距离和盲区。解决办法是给仿真模型加入噪声参数匹配实机传感器的噪声水平。第二是执行差异仿真模型的底盘是完美运动学实机有轮胎打滑、电机响应延迟。解决的关键是要在仿真里加入“执行噪声”比如给速度指令加一个随机延迟 50-100ms这样仿真结果更接近实机。第三是环境差异仿真地图是静态的实机场景随时可能有人路过、有门开关。这只能靠增加动态障碍物测试用例来逼近真实。我的个人经验是不要试图让仿真完全等于实机这不现实要让仿真环境的不确定性略大于实机。这样如果仿真测试能通过实机表现虽然打折扣但不至于崩盘。5.3 机器人测试的随机性问题与重复性处理机器人测试天然带有随机性同一个任务每次跑的数据都不一样这和代码单测是完全不同的逻辑。你没法像断言一个函数返回值那样断言一个机器人“必须成功”。我的处理方式是引入“统计化验收”的思维不确定用单次结果做判断而是用多次结果的成功率做判断。我常用的验收标准是导航类任务同一场景跑 10 次成功率 ≥ 8 次且失败时不能有危险动作比如高速碰撞。SLAM 类任务同一数据集跑 5 次轨迹误差方差不超过均值的 30%。Agent 类任务同一 prompt 跑 5 次结果必须达到“语义一致性”要求结果全对或全错不算随机最担心的是一会儿对一会儿错。如果明明可以稳定正确却出现了随机失败不用想肯定有隐藏的并发问题或状态污染。这种情况我建议直接加日志排查重点对 Agent 的上下文缓存机制开刀。你会发现很多“随机性”实际上是缓存击穿或者一个被多线程改写的全局状态导致的。5.4 基准测试速查表我常用的核心指标测试对象核心指标关键工具/方法推荐最低样本量SLAM 定位ATE / RPE 均方根误差evo 工具3 组数据集ROS2 导航到达成功率、路径偏差、平均速度nav2_simple_commander 批量脚本同一地图 10 次工业机械臂重复定位精度、路径精度ISO 9283、激光干涉仪/百分表30 次重复VDA5050 调度断线恢复时间、状态上报延迟MQTT 模拟器 故障注入100 条消息大模型底座MMLU / GSM8K / HumanEval pass1学术基准库官方测试集Agent 任务任务完成率、工具调用准确率、单任务 Token自建任务集 RAGAS30 条任务RAG 检索召回率、MRRRAGAS / 人工判分50 条知识库样本端到端视觉抓取指点点位误差、抓取成功率标定板 轨迹录制20 次抓取5.5 关于“机器人认证”这类事的看法聊到最后想说一下“机器人认证”。这个领域现在的认证体系参差不齐有的是行业联盟出的有的是厂商出的有的是第三方机构出的。我的看法是认证可以参考但不能替代自己的基准测试。道理很简单认证考试考的是通用场景你的场景大概率是特殊场景。就好比拿了驾照不代表你就能开好救护车。真正决定系统能不能落地的是你自己的验收测试是你在自己场景下的长跑测试。认证顶多算个“及格线”而及格线以上的竞争只能靠你自己测出来。最后分享一点个人杂感说实话干这行越久我越觉得“基准测试”这件事本质上是给“不确定性”建立一个可比较的标尺。不管是机器人面对的真实物理世界还是大模型面对的语言世界到处都是噪声、例外和边界情况。所谓测试其实就是把“我觉得它行”变成“数据显示它行”的过程。做基准测试这么多年我最大的体会是四个字别怕吃亏。别嫌设计测试场景麻烦别嫌跑一百遍任务枯燥别嫌分析失败模式耗时。你在测试阶段偷的每一次懒都会在系统上线之后以更难看的方式还回来。可能是在客户现场机器人在众目睽睽之下撞了墙也可能是 Agent 报出一个完全错误的数字还一本正经地给出解释步骤。而是反过来坚持“先测透、再上线”这个死规矩你的系统在真实运行时会给你远超预期的底气。做测试这事稳赚不亏。