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“创造新能力”稳妥得多。
最后分享一个非常实用的小技巧：给机器人起一个好听的名字。我们内部叫它“台架管家”，命名这件事看似小，但对团队成员的心理接受度影响很大。一个新工具如果能让人觉得“这是团队的新同事”，而不是“又一套要学的新系统”，推行的阻力会小很多。
