1. 为什么车载HMI自动化测试需要引入AI Agent和飞书机器人一年多前我们团队被一个问题反复折磨中控屏、仪表盘、HUD的测试用例越堆越多自动化脚本覆盖率看起来很高但一线的测试工程师和项目经理依然习惯在群里喊话——“导航界面卡顿复现了你们快来看”“这个版本的高温工况下倒车影像延迟超标了能不能今晚跑一遍”。这些需求本身不难难的是它们几乎全是模糊的、口语化的、需要人脑二次翻译的。传统自动化测试平台的入口是JIRA、禅道、Jenkins页面要么是预先配置好的定时任务要么是半固定的用例模板。一个测试员想临时跑一个“模拟胎压报警后在仪表盘和中控屏同时弹窗”的组合场景得先打开设备管理页找空闲台架再翻用例库确认有没有现成脚本没有就得提需求让开发排期。这套流程走下来快则半天慢则两三天等结果出来缺陷早被下一个版本覆盖了。我们决定做一个新的东西把车载HMI自动化测试平台的入口从“网页后台”搬到飞书群里让测试员像跟同事聊天一样下指令再把指令背后的意图理解、任务编排、失败分析交给AI Agent处理。平台不再只是一堆脚本的集合而是一个能听懂人话、能调动台架设备、能自己判断结果有没有问题的数字同事。这篇文章就是把这套系统的架构设计、关键模块的落地思路、以及我们踩过的坑完整梳理一遍。适合正在做车载测试平台、或者想在协作平台上搭建AI测试入口的团队参考。2. 平台整体架构消息入口、智能决策、物理执行三层如何咬合2.1 整体分层逻辑这套平台本质上解决的是三件事怎么接需求、怎么理解需求、怎么执行需求。对应到架构上就是三个层次。接入层负责对接飞书机器人处理用户发到群里的消息、卡片交互、指令开关智能层是核心由AI Agent承担意图解析、用例匹配、任务编排、结果研判执行层则管理真实的测试资源——座舱台架、总线仿真工具、视觉采集设备、日志服务器。三层之间通过消息队列和REST接口串联不强行做成一个大单体。原因很简单执行层的设备经常因为硬件故障、线束松动、系统死机而不可用如果把接入层和智能层跟执行层耦合在一起某台设备挂了会导致整个对话服务不可用这在日常使用中是不可接受的。2.2 核心链路的数据流向一条完整的指令从用户在飞书群里发出到最终收到测试报告大致经过七个节点用户发消息到群 → 机器人Webhook接收 → AI Agent解析意图并补充必要信息 → 任务编排器检查设备状态和用例可用性 → 下发执行任务到指定台架 → 执行完成后回传截图、日志、信号数据 → AI Agent生成结论并推送消息卡片。这里有个容易被忽略的细节AI Agent不是传统意义上的“聊天机器人”它不做开放式的自由对话而是围绕预先定义好的测试能力边界做“约束式理解”。我们会把可调用的工具、可执行的用例、可用的设备全部注册成结构化清单Agent只能在这些清单里做选择和组合。这样既保留了自然语言交互的灵活性又避免了模型胡说八道。2.3 为什么选飞书作为入口而不是自建Web页面团队内部讨论过要不要做独立的Web操作台。后来一致认为对一线测试员来说多一个网址、多一套账号密码、多一次登录跳转都是使用的隐形门槛。飞书群里每天已经有大量的工作流在跑——缺陷通报、值班交接、发布通知把测试入口放在同一个IM群里学习成本约等于零。飞书机器人除了支持文本消息还提供了非常实用的消息卡片交互能力。任务执行中、执行完成、异常中断都可以通过不同颜色的卡片实时展示用户还能在卡片上点按钮来“重跑”“只看失败项”“导出日志”。这种交互方式比传统Web页面里的刷新按钮直观得多也更适合测试这种“发起后等待结果”的场景。3. 飞书机器人端的落地细节从收消息到发卡片3.1 机器人接入与权限模型平台采用的是飞书自建应用方式接入。机器人需要开通的能力包括接收群消息、读取用户基本信息、发送消息卡片、接收卡片回调。权限模型上我们做了分级控制群里的普通成员只能发起常规测试任务管理员可以在群里执行“设备自检”“强制重启台架”这类运维操作防止有人误触发危险指令。权限控制是技术上容易做、设计上容易出疏漏的环节。最开始的版本里只要在群里的用户都能发设备重启指令某个加了机器人但不懂硬件的同事不小心发了一条“重启仪表屏”结果正在跑的车机测试直接中断测试数据全部丢失。从那之后我们把所有涉及设备电源、系统级操作的指令统统加上了管理员校验。3.2 消息解析与指令前缀飞书机器人实现文本指令的方式很多可以直接订阅消息事件也可以配置自定义slash命令。我们做的是两者结合低频、强语义的指令比如“跑全套回归”用自然语言解析由AI Agent处理高频、固定格式的运维指令比如“/status”“/reboot”用slash命令直达不经过大模型响应速度更快、更稳定。这个设计思路值得说一下不是所有请求都需要AI介入。大模型推理有延迟有概率性错误对稳定的平台来说能用规则解决的场景就不要上模型。我们把设备查询、任务状态查询这类确定性需求全部用规则引擎处理AI Agent只负责真正需要语义理解的部分——组合场景创造、模糊条件补全、异常结果判断。3.3 消息卡片的设计与状态机卡片是用户感知平台质量的主要载体。我们不只做简单的“任务开始”“任务完成”两张卡片而是设计了一套带状态机的卡片流任务创建成功后卡片显示用例数量、预计耗时、目标设备执行过程中卡片实时刷新当前进度和已通过的用例数执行结束后卡片分为总览区和详情区总览区用颜色标识通过率详情区列出失败用例的摘要信息以及AI给出的初步原因分析。用户点“查看完整报告”会跳转到HTML报告页面点“重新执行失败项”会触发一个新的补测任务。卡片回调这里有个坑飞书卡片交互回调的签名校验和消息事件的校验方式不一样而且回调地址必须公网可达。开发时容易忽略这个细节导致本地调试一直收不到按钮事件。现在我们把回调统一走内网网关中转同时在回调处理逻辑里做了幂等处理防止用户手抖连点两次导致重复触发任务。4. AI Agent的架构设计意图解析、任务编排与失败研判4.1 意图解析把自然语言变成结构化测试计划整个平台里AI含量最高的就是这一层。用户发来的指令五花八门“帮我检查一下仪表电量显示跟BMS发过来的值是否一致”“在高温箱里跑一遍导航压力测试”“今天凌晨能不能跑一下蓝牙连接稳定性”。要让大模型输出可靠的结构化结果我们采用了两阶段方案。第一段是“意图粗分类”通过少量示例的few-shot提示让模型判断指令类型——是回归测试、专项验证、还是问题复现第二段是“参数补全”针对用户没说清楚的字段比如设备编号、测试时长、工况温度模型根据对话上下文和默认值进行填充。关键经验不要指望大模型一次性准确生成完整的测试计划。我们最初试过让模型直接输出包含所有参数的JSON结果发现它在用例名称拼写、设备编号格式上经常出错。后来改为“模型出意图规则出参数”——模型只负责判断测试类型和关键条件具体的用例ID、设备ID、信号类型都由规则引擎从数据库里按条件检索。准确率从不到80%提升到了97%以上。4.2 任务编排工具注册表与白名单机制编排层有一张核心的“能力注册表”记录平台上可以调用的所有测试能力包括自动化用例、信号注入命令、数据采集接口、环境控制指令。每个能力有三个属性能力名称、参数Schema、依赖条件。AI Agent根据用户意图在注册表里选择能力并进行组合组合结果交给调度器去执行。为了防止模型把能力组合成不合理的流程所有能力都会先经过合法性校验。举个具体例子用户说“跑一下高速工况下的能耗页面刷新率测试”Agent可能会组合出“车速信号模拟 中控屏能耗页面图像采集 帧率统计”三个能力。但如果用户只说了“刷新率测试”而没提车速调度器会使用默认工况。如果用户说“在怠速工况下跑车速120的信号模拟”这种明显矛盾的条件会被直接拦下来并提示用户确认。这套白名单机制是我们对AI输出做兜底的重要手段。4.3 失败研判让Agent先做一轮“电子眼”排查自动化测试最耗费人力的不是跑用例而是分析失败原因。一个用例挂了工程师往往要打开截图、检查串口日志、对比信号曲线才能判断是软件缺陷、环境波动还是脚本自身问题。现在这个环节AI Agent也能承担部分工作了。执行完成后Agent会收到该用例的截图、日志、相关信号序列然后按三个维度做初步判断画面层面检查是否有明显异常卡死、白屏、弹窗覆盖日志层面检查是否有崩溃堆栈或错误关键字信号层面检查数据是否在预期范围内。Agent分析之后会给出一个判断标签疑似软件缺陷、环境异常、脚本问题、结果正常。标签后面附带一句话理由例如“中控屏画面在切换导航时出现超过3秒的黑屏日志中发现渲染进程重启记录”。这一轮自动研判能把一线测试员的排查时间平均减少六七成让他们把精力集中在真正需要人工判断的疑难问题上。4.4 模型选型与部署方式模型我们最终选择了中等参数量的开源模型配合Lora微调部署在公司内部GPU服务器。相比调用公有云大模型API内部部署的好处是数据完全不出内网而且可以针对测试领域的专有名词做定向优化。车载测试里有很多缩写——BMS、VCU、ADAS、DMS——通用模型经常理解错微调后准确率提升非常明显。5. 车载HMI执行层的三个核心适配视觉、信号与实时日志5.1 视觉识别屏幕状态的唯一裁判HMI测试跟后端接口测试最大的区别在于结果是否正确最终都要回到“屏幕上看起来对不对”。我们用视觉识别作为主要的断言手段方案是“模板匹配 目标检测 像素差异分析”三种组合使用。模板匹配用于检测固定位置的图标或文字是否出现比如电池电量图标、蓝牙连接标识。这类元素位置相对固定、外观变化小模板匹配速度快、误检率低。目标检测用于处理动态区域比如导航地图上的道路名称、弹窗按钮的位置。像素差异分析则用于回归场景将当前画面和基准画面做区域对比找出异常变化的区域。这里必须吐槽一下实际落地的复杂度。车载屏幕普遍存在反光、角度偏转、亮度自动调节的问题同一张截图在不同时间段的亮度差异可能超过30%。如果直接用原始像素做对比误报率高得没法用。处理方案是在执行用例前先对当前屏幕做一次亮度和色温校准所有图像都在统一的白平衡基准下进行比较。另外屏幕区域需要在配置阶段手动框定一次把仪表盘、中控屏、HUD投影区域分别保存为独立的感兴趣区域避免跨区域误判。5.2 信号注入让测试场景“可编程”车载HMI测试很大一部分场景是信号驱动的。比如测试仪表盘的电量显示需要模拟BMS发送的电量百分比信号测试胎压报警弹出则需要模拟胎压异常信号。信号注入模块通过总线仿真工具实现平台在用例脚本里定义了标准化的信号操作接口上层不需要关心底层走的是CAN、LIN还是以太网。信号注入这块有一个非常重要的原则注入前必须确认当前台架处于仿真模式而不是实车模式。不同模式下的信号路由完全不一样仿真模式下信号从总线仿真工具发出实车模式下信号来自真实的控制器。曾经出现过一次因为切换不到位仿真信号被真实控制器当成外部干扰处理导致台架断连的情况。所以我们在任务编排层加了环境自检步骤每次执行任务之前都会先发送一组探针信号做回路验证通过后才开始正式用例。5.3 实时日志与信号数据的时序对齐第三块核心能力是日志与时序数据的对齐。车载HMI测试中视觉截图、系统日志、总线信号是三个不同来源的数据流时间戳如果不做对齐失败分析就无从谈起。我们实现了一个名为“时间轴聚合器”的模块统一接收来自执行机的屏幕截图事件、来自设备端的系统日志流、来自仿真工具的总线信号记录。聚合器以毫秒级精度把三类数据按时间轴排列形成一条完整的测试记录流。回放时可以看到在某个具体时间点屏幕上显示了什么、系统里打了什么日志、总线上的信号值是多少。这个能力在分析“偶现卡顿”“显示延迟”这类问题时极其有用——没有时间轴对齐工程师只能靠肉眼去软硬件两边来回对效率极低。6. 联调期真实踩过的坑AI幻觉、权限失控、屏幕误判6.1 AI把用例ID凭空编出来了白名单拦住了它联调阶段的第一个严重事故来自模型幻觉。当时测试执行器已经接好自动跑通了一个冒烟用例。大家兴奋之余有人突发奇想在群里发了一句“跑一下今天的全量冒烟重点看语音助手”。模型解析后居然生成了一串数据库里根本不存在的用例ID推送到了执行层。幸好任务校验环节发现用例ID不合法消息卡片的执行计划会展示待执行的用例列表边上标着“待确认”字样。加上用户点击确认才算数否则任务直接终止。教训就是永远不要信任模型生成的ID、编号、命名这类硬性字段。所有经过Agent生成的数据凡是能在数据库里校验的一律先校验、后执行。我们的规则是“模型出意图系统出ID”意图方向错了人可以修ID错了系统根本跑不起来白名单校验绝不能省。6.2 多设备并发调度时发现的资源锁问题平台接入的真实台架有四套每套台架包含仪表、中控、HUD三块屏幕。最初调度器只做了“设备忙闲标记”没做真正的资源锁。一次联调时三条指令几乎同时到达一条跑仪表显示测试一条跑中控屏压力测试一条跑HUD导航测试。调度器把三条任务都下发给了同一套台架结果三个进程抢屏幕、抢信号通道现场画面直接乱成一锅粥。修复方案是多层资源锁设备级锁一个台架同时只能跑一个任务、模组级锁同一块屏幕同时只能被一个用例占用、信号级锁同一个信号通道同时只能有一个注入任务。资源锁申请全部走调度器统一管理排队任务在卡片上可以看见“前序任务剩余数量”用户按需决定继续等待还是换台架。6.3 屏幕亮度造成的视觉误判差点漏掉一个真Bug视觉识别模块上线后第一次正式使用测试的是夜间模式下中控屏背景色渐变是否平滑。结果平台判定“通过”但人工复核时发现画面边缘有一块明显的色斑。原因是执行任务时台架处于明亮环境屏幕自动亮度拉满色斑在强光下被肉眼难以察觉像素差异分析也因为对比度过强而没有报出异常。这个案例让我们意识到视觉采集的鲁棒性不是靠算法单一维度解决的。现在平台上执行涉及外观检查的用例都会先检查当前环境光照条件并强制将屏幕亮度锁定为固定档位确保判定基准一致。另外视觉分析的结果无论是否通过所有原始截图都会保存归档方便人工抽查复核。系统允许不通过但绝不出现“机器说通过、人眼说不对”的乌龙。6.4 长时间任务的连接超时问题车载测试里有些场景耗时很长比如导航路测模拟要跑几个小时高温耐久测试甚至要跑一整夜。最初飞书机器人往调度器推任务后就不管了结果发现超过一定时间没有回调任务会被误判为超时失败。排查下来是长连接保活和回调超时配置的问题。后来我们把机器人和执行层之间的数据通路改成了双通道模型通道A是即时消息用于短耗时任务的实时状态推送通道B是异步任务执执行器启动后立即返回“任务已接收”的确认信号之后通过心跳机制定期上报“运行中”状态彻底完成后由调度器主动拉取最终结果。这样即使一次消息通道抖动丢失了数据也不会影响整体任务生命周期。7. 这套平台在团队里实际用起来的感受平台上线到现在大概有三个月了最直观的变化是测试任务的发起速度完全不是一个量级。以前跑一次专项验证从提需求到拿结果平均要半天现在在群里说一句话十分钟内就能收到首批结果和AI的初步研判。项目例会上的同步方式也变了不再是挨个汇报“跑了什么用例、结果如何”而是直接展示飞书群里的测试卡片记录整个过程都有迹可循。对一线测试工程师来说最大的红利是省去了大量重复性的“陪跑时间”。以前执行用例时必须有人在旁边盯着现在只要在群里发出指令任务跑完卡片会主动推送。工程师可以同时跟两三个测试任务并行推进每个任务的结果都自带AI标签和原始数据排查问题的起点从“看全部日志”缩小到“看AI标注的可疑片段”。当然也走了一些弯路。最初我们想让AI Agent直接生成新用例脚本后来发现以目前模型的能力生成的脚本质量离可执行还有距离硬接上线就是事故。现在这个能力只作为“用例编写辅助”使用模型生成脚本框架由自动化开发审核修改后才会纳入用例库。建议想复刻这套架构的团队一开始就把AI的能力边界画清楚从“理解已有能力并调度”起步比直接让AI“创造新能力”稳妥得多。最后分享一个非常实用的小技巧给机器人起一个好听的名字。我们内部叫它“台架管家”命名这件事看似小但对团队成员的心理接受度影响很大。一个新工具如果能让人觉得“这是团队的新同事”而不是“又一套要学的新系统”推行的阻力会小很多。