做车载HMI测试这些年我最深的体会是测试真正难的从来不是跑用例本身而是怎么让一堆跑不完的用例、改不完的需求、复现不了的偶发缺陷在有限的人和时间内有序收场。当飞书机器人和AI Agent这两个词开始频繁出现在行业群里时我第一反应是——它们能不能把我从每天早上挨个问用例结果、下班前整理报告发群的琐事里捞出来答案是能。这篇文章记录的是我基于飞书机器人 × AI Agent从零搭建的一套车载HMI自动化测试平台涵盖整体架构、飞书机器人接入、Agent核心实现、测试执行器联动以及落地过程中被真实环境逼着改出来的几轮优化。适合正在做车载HMI/智能座舱测试自动化、或者想给现有测试平台加一个智能入口的工程师参考。我会尽量把踩过的坑和最终方案一起讲清楚尤其是那些官方文档不会写的东西飞书事件回调超时怎么处理、Agent的Token上下文怎么控制、大模型判断测试结果时怎么防止幻觉这些都是真金白银换来的教训。1. 车载HMI测试的真实痛点我为什么非要把飞书机器人和AI Agent请进来1.1 传统HMI自动化测试卡在哪几个环节先说说背景。车载HMI的测试对象这几年膨胀得很厉害仪表盘、中控大屏、HUD、副驾娱乐屏一套车机里可能同时跑着QNX、Linux、Android Automotive三套系统。UI迭代又特别快几乎每个版本都有布局调整、文案修改、深色模式适配。传统自动化平台在这个场景下其实能做的不少但实际用起来总有几座大山入口分散测试任务在JIRA里用例在测试管理平台上执行脚本散落在各台工控机报告最后要人手工汇总。任何一次版本回归光是把这些信息凑齐就要半天。编排靠人跑哪些用例、要不要注入车速信号、导航软件要不要先切到后台这些依赖人肉判断。用例执行顺序一旦出错整批结果全部作废。结果割裂截图、日志、CAN信号记录、覆盖率数据各存各的出了问题很难把时间轴对齐定位一个偶现黑屏可能要翻好几个小时的日志。反馈链路长测试执行完不是终点还要整理报告、对应开发、跟踪修复状态。这一步纯靠人工重复劳动也是最容易漏的环节。典型场景是这样的测试工程师小A要验证某个版本的导航应用他得先去JIRA看任务再打开自动化平台选用例集等跑完后翻日志和截图找问题最后把结果整理成PPT发到群里再挨个人确认。整条链路里人承担了大量信息搬运工作真正的分析判断反而被压缩了。1.2 AI Agent在测试链路里到底扮演什么角色很多人一听说AI Agent做测试第一反应是让大模型去执行用例。这个理解其实偏了。Agent在测试平台里的核心价值不是智能执行用例而是把测试需求转成可执行的规划再把结果组织成人能直接理解的信息。举个例子你给Agent发一句验证夜间模式下仪表盘导航转弯箭头显示是否正常。传统平台听到这句话是懵的因为它需要的是一个明确的用例ID。Agent会把这个需求拆成一系列动作切换到夜间模式、通过CAN信号把车速拉到巡航状态、启动导航并设定路线、在转弯点截图、和基准图比对、输出差异分析。每一步对应一个工具调用工具执行完的结果再汇总成结构化报告。并且Agent还有个传统框架给不了的能力失败原因解释。脚本断言失败只会告诉你截图不匹配Agent可以结合截图、日志、当前HMI状态做一个综合分析给出截图差异集中在左上角区域疑似路况卡片遮挡建议检查导航SDK的布局适配。这种输出对开发定位问题的帮助是碾压级的。1.3 飞书机器人为什么是天然的第一入口入口放在IM里不是拍脑袋决定的。车载测试团队的人员分布决定了这件事硬件台架在实验室软件团队在办公区项目管理在飞书群里测试报告和缺陷跟踪最终也要回到飞书。IM是所有人日常停留的地方把测试平台接进去用户不需要再打开一套新系统在群里发一条消息或者点一个卡片按钮就能发起/查看一个任务。飞书开放平台的成熟度也正好够用机器人事件订阅、消息卡片、上传文件、多维表格API、获取用户身份。这些能力组合起来足够支撑一个双向交互的测试入口——不仅能发消息给你还能听你指令、识别你是谁、给你可点击的交互界面。自定义webhook机器人只能单向发消息做不了这个闭环所以平台最终选择了企业自建应用的方式接入。这条路在授权审核上多花了一点时间但后面用起来极度顺畅。2. 平台整体架构接入层、编排层、执行层是怎么做到解耦的2.1 分层架构的总设计思路整套平台跑起来之后我习惯把架构描述成四个逻辑层接入层、编排层、执行层、数据层。接入层只有飞书机器人这个角色负责接收群消息、卡片按钮回调、任务状态查询请求并做最基础的意图判断和权限校验。编排层是AI Agent加任务状态机的组合负责把一句话拆成多个步骤、选择工具、维护上下文、判断结果是否满足预期。执行层是各种测试执行器ADB/SSH操作器、CAN信号模拟器、截图和视觉比对引擎。数据层存测试结果、Agent会话记录、报告文件和任务状态。这个结构和很多人想象的Agent直接调工具不同中间被刻意加了一层状态机。Agent负责规划和解释状态机负责保证流程不会乱走路。举个例子Agent规划出5个步骤状态机会按顺序分发第2步超时或失败时状态机会中断并触发补偿逻辑而不是把异常丢给大模型现场发挥。测试平台需要的是稳定可复现的执行这一层隔离非常值得做。2.2 为什么消息接入要独立于Agent编排这是我最早踩的一个大坑差点让整个项目翻车。飞书对事件回调有一个硬性要求服务器必须在3秒内返回应答否则飞书会判定回调失败并不停重试。如果我把飞书消息直接同步抛给Agent去编排执行一个稍微复杂的规划动作就要调用大模型接口光等LLM返回通常就要好几秒回调必然超时。最终方案是在接入层和编排层之间加了一个事件队列。飞书事件到达后机器人服务立刻返回一个空JSON确认同时把事件内容写进队列后台Worker消费队列后再交给Agent编排。用户看到的是已收到任务正在编排执行结果通过异步消息推回到群里。这套机制把飞书回调的时效性要求和Agent处理的耗时彻底解耦后面再遇到任何长任务都没慌过。2.3 执行层抽象把操作HMI变成一套标准工具如果Agent要直接操作不同设备代码会很快变成一团乱麻。我做的第一件事是定义执行器接口所有工具统一提供名称、描述、参数Schema和一个invoke方法输入输出都是JSON结构。Agent只和这套接口打交道不关心底层是ADB还是SSH还是CAN设备。trait HmiTool { fn name(self) - str; fn description(self) - str; fn parameters(self) - Value; // JSON Schema async fn invoke(self, params: Value) - ResultToolResult, ToolError; } struct ToolResult { status: ToolStatus, // Success | Failed | Skipped summary: String, // 喂给大模型看的精简摘要 data: Value, // 完整结构化数据用于报告 }这里的summary字段是为Token省钱设计的后面在Agent上下文管理里会细讲。执行器抽象好之后新增一种设备支持只需要实现一个traitAgent编排逻辑一行不用改。3. 飞书机器人模块从群聊消息到可追踪的测试工单3.1 接入选型企业自建应用比自定义机器人强在哪飞书机器人有两条路一条是群里的自定义机器人配置一个webhook地址就能发消息五秒钟就能跑通。另一条是企业自建应用要建应用、配权限、申请审核麻烦得多。我刚开始也图省事试过自定义机器人但很快发现它致命的问题只能发、不能收。用户想发起测试任务、查状态、点按钮交互全走不了webhook。自定义机器人拿不到人的身份信息更做不了基于用户角色的权限控制。企业自建应用虽然开通麻烦但是把能力补全了可以订阅机器人消息事件能拿到用户ID和群ID可以发送消息卡片并接收按钮回调还能调用云文档接口上传文件、创建多维表格。对测试平台来说这些能力每一项都是刚需。我的建议是如果做demo可以先用自定义机器人正式平台直接选自建应用不要走弯路。3.2 消息意图识别规则优先大模型兜底飞书机器人收到的消息大致分两类一类是格式明确的指令比如/run nav_regression_suite或卡片按钮回调另一类是自然语言描述比如帮我查一下昨天深色模式那批用例为啥挂了。我在这块用了很务实的策略能走规则的绝不动大模型。固定格式指令直接用字符串解析和参数匹配耗时几毫秒不消耗Token。自然语言才交给AI Agent做意图识别和任务编排。这么做的原因很直接测试平台的指令重复率极高每次都让大模型处理纯粹是浪费而且规则解析的稳定性远高于模型。实测下来平台里大约70%的请求走了规则路径只有剩下30%真正需要Agent的理解能力。3.3 测试报告如何变成飞书表格和消息卡片报告推送是用户感知最直观的部分也是我花心思最多的部分。最初我只是把文本结果拼成一条普通消息发出去用起来很痛苦几十个用例的结果堆成一大段手机上根本看不下去想定位失败项还得翻半天。后面改成组合方案一条消息卡片加一个文件附件。卡片上只放汇总信息——通过率、失败数、阻塞数、总耗时、失败用例Top5列表每个失败项后面带一个查看详情按钮。点击按钮回调触发查询返回这条用例的截图、日志、Agent分析结论。明细数据则单独整理成Excel文件上传到会话里用飞书的云文档能力直接在线预览。这里有个细节Excel文件的表头我用的是项目组已有的模板格式用例编号、模块、预期结果、实际结果、缺陷关联、截图链接每个字段都对齐了飞书文档表格的列类型。这样测试经理可以直接把表格导入已有的管理文档不用二次加工。真正做到报告即数据。4. AI Agent核心设计用Rust把任务编排、工具调用和Token管理落地4.1 为什么Agent运行时选Rust而不是Python先回答一个绕不开的问题为什么用Rust写Agent运行时而不是生态更成熟的Python。一是部署体验Rust一个静态二进制扔到台架工控机上就能跑不装Python环境、没有依赖冲突对于长期驻场的测试设备来说太重要了。二是并发稳定性Agent运行时本质是大量异步任务同时在飞书接入、工具调用、LLM请求之间流转Rust的async/await和所有权模型让这块代码写起来很踏实不用担心共享状态的野问题。当然Rust的短板也很明显AI生态库少、模型SDK不全、写业务逻辑比Python慢。我的解法是核心运行时用Rust间接执行的算子脚本仍旧用Python子进程。两边通过JSON over stdio通信Rust负责调度和生命周期Python负责算子里那些生态依赖重的逻辑比如视觉模型推理、CAN协议解析。这个混合架构实际跑下来是最顺的两边各取所长。4.2 我用的是Plan-and-Execute而不是单体ReActAI Agent的主流架构里ReAct模式和Plan-and-Execute是我实际对比过两条路线。ReAct的思路是让模型在每一轮都观察当前状态、决定下一步动作灵活但有两个问题Token消耗高每步决策都要把历史搬给模型行为不稳定模型偶尔会反复尝试同一个失败动作。对测试场景来说这两个问题都很致命因为用例执行的路径应该是确定性和可解释的。最终我选了Plan-and-Execute的变体大模型只负责把用户需求翻译成一个有序的任务计划后续步骤的执行由状态机驱动每一步的工具选择在规划时就固定下来。Agent在单步骤遇到失败时允许把失败信息和重试建议反馈给模型让模型决定是重试、跳过还是终止。这样既保留了对异常情况的智能处理能力又保证了正常路径的稳定执行。从效果看平台上线三个多月正常路径零随机乱跳。4.3 Token管理搞懂Agent的短期记忆才能控住成本先说Token是什么。Token是LLM处理文本的最小单位中文场景下大约一个字对应1到2个Token。模型有上下文窗口限制超了就要截断或者报错。Agent对话过程中每轮规划、每次工具返回结果都会累积进历史上下文越滚越大很快把窗口撑爆。我在这里吃的教训最深。第一版实现里我天真地把所有工具执行完整输出都塞给模型结果跑了三十个用例之后上下文窗口直接爆掉平台报错瘫痪。后面做了三件事来管住Token历史截断只保留最近N轮对话更早的消息自动丢弃。对测试平台来说Agent和用户的交互轮次不会很多保留最近五轮基本够用。工具结果压缩就是前面说的summary字段。工具执行完先由代码自动生成一段精简摘要完整数据存数据库只有摘要进上下文。比如截图比对工具返回的是相似度97.2%差异区域2处位于左上角这一句而不是整个Base64图片或几百行像素数据。会话隔离每个测试任务单独建一个Agent会话任务结束后上下文归档避免不同任务的上下文互相污染也避免历史累积导致Token失控。这三板斧下来单任务Token消耗降低了差不多80%平台响应速度和费用都健康了。5. 工具执行层Agent怎么真正驱动车载HMI和执行器5.1 工具注册表与参数校验Agent能调的工具不是硬编码在编排逻辑里的而是维护在一张工具注册表里。每个工具包含四件套名称、描述、参数Schema、执行器实现。Agent在规划时会把用户需求、可用工具列表、工具描述一起丢给大模型让模型挑合适的工具并输出JSON参数。Rust端用serde做参数反序列化Schema不符的请求直接拒绝不给模型瞎编的机会。这里有一条经验工具描述要写人话。同样一个截图工具描述写成截图当前HMI界面并返回图像文件路径和get_screenshot对模型理解能力的影响完全不同。描述越具体模型选错工具的概率越低。平台里每个工具的描述都经过了几轮措辞优化这是0成本但收益极其明显的优化点。5.2 通过SSH/ADB操作目标设备车载HMI的操作执行器基本跑两条协议Android Automotive设备走ADBQNX/Linux设备走SSH。我在执行器里封装的几个核心动作包括启动/停止应用、注入触摸和按键事件、读取当前焦点窗口、设置系统参数、执行shell命令、截屏。每个动作的底层都对应一串指令但Agent看到的只是一些语义化动作。这里很容易忽略的一个点是命令超时。车载设备的性能参差不齐冷启动导航应用有时候能卡到几十秒但如果设置无限期等待一旦设备异常挂起Agent就会卡死在那里。我的做法是所有远程命令统一加一个可配置超时默认30秒超时后自动杀掉命令并返回超时错误。错误信息会喂给Agent做重试判断但执行框架本身不会无限等下去。5.3 CAN信号模拟与HMI状态联动HMI测试有大量场景依赖车辆信号。比如要验证仪表盘的车速显示就得让整车的CAN网络把车速信号喂给仪表要验证转向灯指示就得模拟转向灯开关的状态。平台里集成了一个CAN信号模拟器通过CAN卡和自研信号发生器在测试环境里广播刹车、油门、挡位、转向灯、车速这些关键信号。Agent侧的工具集于是多了set_speed、set_gear、set_turn_signal这类动作。执行器内部做一层状态同步设置CAN信号的同时会主动等待HMI端的状态刷新再触发后续截图或操作确保测试时序正确。这一层等待逻辑很关键因为CAN信号到UI渲染天然有延迟如果不等待直接截图经常会捕获到过渡帧造成假失败。5.4 视觉验证截图比对那部分如何防误判视觉验证是车载HMI测试的核心也是AI最容易帮倒忙的地方。平台里的视觉引擎分了三层第一层用OpenCV做模板匹配和感知哈希粗比对快速筛出明显一致的截图第二层对差异区域做像素级定位输出差异框和差异率第三层才轮到AI介入——把差异区域的局部截图、相似度数值、预期描述一起给大模型让模型判断差异是缺陷、是预期变化还是测试环境干扰。这里要特别强调一点不要让大模型直接看全图做判断。全图分辨率高、细节多既费Token又容易让模型被背景干扰最后给出一个泛泛的看起来不太对。局部裁剪加结构化指标的设计非常实用模型看到的是差异率3.2%差异集中在左上角一个图标区域预期该区域显示箭头图标这种输入下模型输出准确率会高得多。6. 落地过程中被真实环境教育的三件事6.1 飞书回调3秒超时先应答后异步是底线前面提过事件队列的做法这里展开说一下当时的排查过程。第一版联调时群里发消息经常出现消息已读但没有反应飞书后台能看到大量回调重试记录。顺着链路一步步查才定位到问题出在Agent规划调用了LLM接口单次响应就要3到5秒整条飞书回调必然超时。修复方案就是在接入层加队列先响应后处理。这里想提醒后来者一点飞书回调的3秒限制任何人都绕不过去任何同步处理逻辑放进回调里都是定时炸弹。6.2 长测试任务的会话保持与超时控制一个完整的回归任务可能要跑三十分钟中间会经历多次Agent规划、工具调用、结果汇总。这个过程中如果某个环节花了太长时间用户会以为平台挂了。我们平台的做法是给长任务设计了一个进度反馈机制Agent每完成一个步骤就往飞书群推一条轻量进度消息比如计划5步已完成2步CAN信号注入完成正在启动导航。用户可以随时打断说跳过这步Agent会重新规划后续路径。这个机制同时解决了会话保持问题。因为每条进度消息都携带Task ID用户回复时可以通过Task ID直接追加指令不需要重新描述一遍完整需求。6.3 大模型幻觉导致的假失败是最难调的一类问题平台刚上线那两周出现过几次特别迷惑的情况测试结果明明都通过了Agent在总结里却写注意导航界面疑似显示异常。开发一看截图界面完全正常。这就是典型的模型幻觉——它看到差异区域的局部截图结合上下文自己脑补了一个异常。我的解决方案分三步第一给Agent的判定通道增加置信度门槛低于门槛统一标成Review不直接下PASS或FAIL的结论第二结构化数据优先于模型描述工具返回里已有的数值指标相似度、差异框坐标直接透出在报告里模型只负责解释不负责创造指标第三所有Review状态的结论必须人工复核后才能关闭AI结论永远只是辅助意见。这套机制之后AI误判从会改错结论降级成了只会多标记一条等人工看一眼完全在可控范围。6.4 消息风暴与并发限流车载测试团队人数不多但一个项目群里可能有几十个自动化任务同时在跑。每个任务每完成一步推一条进度消息再加上报告推送和按钮回调量积累起来也不小。更要命的是如果某个Agent实例卡住LLM API持续重试会对大模型接口方的限流策略造成压力。平台做了两件事。一是会话级锁同一个测试项目群同时只允许一个任务在演化状态后面提交的任务排队等待避免多个Agent同时操作同一台台架设备导致命令打架。二是全局限流器对LLM API调用做令牌桶限流超出额度时任务降级为重试队列并主动通知用户当前负载高任务已排队。这两层保护上线后再没出现过消息风暴把整个平台拖垮的情况。写在最后这套平台上线之后我最大的感受是自动化测试终于不再只是跑用例而是一个能对话、能解释、能把人的注意力引导到最值得看的地方的助手。中间踩过的坑——尤其是Token管理、回调超时、模型幻觉这三块——如果重新来一遍我会在设计阶段就把消息链路和Agent状态机画清楚而不是先跑通Demo再回来补课。最后分享一个小技巧在设计AI Agent驱动的测试平台时别让大模型做真正的断言把硬性判定留给确定性算法坐标、阈值、状态码、异常日志让大模型专注于描述异常、组织步骤、解释结果。这样既能保住准确性又能享受大模型带来的灵活交互两全其美。
做车载HMI测试这些年我最深的体会是测试真正难的从来不是跑用例本身而是怎么让一堆跑不完的用例、改不完的需求、复现不了的偶发缺陷在有限的人和时间内有序收场。当飞书机器人和AI Agent这两个词开始频繁出现在行业群里时我第一反应是——它们能不能把我从每天早上挨个问用例结果、下班前整理报告发群的琐事里捞出来答案是能。这篇文章记录的是我基于飞书机器人 × AI Agent从零搭建的一套车载HMI自动化测试平台涵盖整体架构、飞书机器人接入、Agent核心实现、测试执行器联动以及落地过程中被真实环境逼着改出来的几轮优化。适合正在做车载HMI/智能座舱测试自动化、或者想给现有测试平台加一个智能入口的工程师参考。我会尽量把踩过的坑和最终方案一起讲清楚尤其是那些官方文档不会写的东西飞书事件回调超时怎么处理、Agent的Token上下文怎么控制、大模型判断测试结果时怎么防止幻觉这些都是真金白银换来的教训。1. 车载HMI测试的真实痛点我为什么非要把飞书机器人和AI Agent请进来1.1 传统HMI自动化测试卡在哪几个环节先说说背景。车载HMI的测试对象这几年膨胀得很厉害仪表盘、中控大屏、HUD、副驾娱乐屏一套车机里可能同时跑着QNX、Linux、Android Automotive三套系统。UI迭代又特别快几乎每个版本都有布局调整、文案修改、深色模式适配。传统自动化平台在这个场景下其实能做的不少但实际用起来总有几座大山入口分散测试任务在JIRA里用例在测试管理平台上执行脚本散落在各台工控机报告最后要人手工汇总。任何一次版本回归光是把这些信息凑齐就要半天。编排靠人跑哪些用例、要不要注入车速信号、导航软件要不要先切到后台这些依赖人肉判断。用例执行顺序一旦出错整批结果全部作废。结果割裂截图、日志、CAN信号记录、覆盖率数据各存各的出了问题很难把时间轴对齐定位一个偶现黑屏可能要翻好几个小时的日志。反馈链路长测试执行完不是终点还要整理报告、对应开发、跟踪修复状态。这一步纯靠人工重复劳动也是最容易漏的环节。典型场景是这样的测试工程师小A要验证某个版本的导航应用他得先去JIRA看任务再打开自动化平台选用例集等跑完后翻日志和截图找问题最后把结果整理成PPT发到群里再挨个人确认。整条链路里人承担了大量信息搬运工作真正的分析判断反而被压缩了。1.2 AI Agent在测试链路里到底扮演什么角色很多人一听说AI Agent做测试第一反应是让大模型去执行用例。这个理解其实偏了。Agent在测试平台里的核心价值不是智能执行用例而是把测试需求转成可执行的规划再把结果组织成人能直接理解的信息。举个例子你给Agent发一句验证夜间模式下仪表盘导航转弯箭头显示是否正常。传统平台听到这句话是懵的因为它需要的是一个明确的用例ID。Agent会把这个需求拆成一系列动作切换到夜间模式、通过CAN信号把车速拉到巡航状态、启动导航并设定路线、在转弯点截图、和基准图比对、输出差异分析。每一步对应一个工具调用工具执行完的结果再汇总成结构化报告。并且Agent还有个传统框架给不了的能力失败原因解释。脚本断言失败只会告诉你截图不匹配Agent可以结合截图、日志、当前HMI状态做一个综合分析给出截图差异集中在左上角区域疑似路况卡片遮挡建议检查导航SDK的布局适配。这种输出对开发定位问题的帮助是碾压级的。1.3 飞书机器人为什么是天然的第一入口入口放在IM里不是拍脑袋决定的。车载测试团队的人员分布决定了这件事硬件台架在实验室软件团队在办公区项目管理在飞书群里测试报告和缺陷跟踪最终也要回到飞书。IM是所有人日常停留的地方把测试平台接进去用户不需要再打开一套新系统在群里发一条消息或者点一个卡片按钮就能发起/查看一个任务。飞书开放平台的成熟度也正好够用机器人事件订阅、消息卡片、上传文件、多维表格API、获取用户身份。这些能力组合起来足够支撑一个双向交互的测试入口——不仅能发消息给你还能听你指令、识别你是谁、给你可点击的交互界面。自定义webhook机器人只能单向发消息做不了这个闭环所以平台最终选择了企业自建应用的方式接入。这条路在授权审核上多花了一点时间但后面用起来极度顺畅。2. 平台整体架构接入层、编排层、执行层是怎么做到解耦的2.1 分层架构的总设计思路整套平台跑起来之后我习惯把架构描述成四个逻辑层接入层、编排层、执行层、数据层。接入层只有飞书机器人这个角色负责接收群消息、卡片按钮回调、任务状态查询请求并做最基础的意图判断和权限校验。编排层是AI Agent加任务状态机的组合负责把一句话拆成多个步骤、选择工具、维护上下文、判断结果是否满足预期。执行层是各种测试执行器ADB/SSH操作器、CAN信号模拟器、截图和视觉比对引擎。数据层存测试结果、Agent会话记录、报告文件和任务状态。这个结构和很多人想象的Agent直接调工具不同中间被刻意加了一层状态机。Agent负责规划和解释状态机负责保证流程不会乱走路。举个例子Agent规划出5个步骤状态机会按顺序分发第2步超时或失败时状态机会中断并触发补偿逻辑而不是把异常丢给大模型现场发挥。测试平台需要的是稳定可复现的执行这一层隔离非常值得做。2.2 为什么消息接入要独立于Agent编排这是我最早踩的一个大坑差点让整个项目翻车。飞书对事件回调有一个硬性要求服务器必须在3秒内返回应答否则飞书会判定回调失败并不停重试。如果我把飞书消息直接同步抛给Agent去编排执行一个稍微复杂的规划动作就要调用大模型接口光等LLM返回通常就要好几秒回调必然超时。最终方案是在接入层和编排层之间加了一个事件队列。飞书事件到达后机器人服务立刻返回一个空JSON确认同时把事件内容写进队列后台Worker消费队列后再交给Agent编排。用户看到的是已收到任务正在编排执行结果通过异步消息推回到群里。这套机制把飞书回调的时效性要求和Agent处理的耗时彻底解耦后面再遇到任何长任务都没慌过。2.3 执行层抽象把操作HMI变成一套标准工具如果Agent要直接操作不同设备代码会很快变成一团乱麻。我做的第一件事是定义执行器接口所有工具统一提供名称、描述、参数Schema和一个invoke方法输入输出都是JSON结构。Agent只和这套接口打交道不关心底层是ADB还是SSH还是CAN设备。trait HmiTool { fn name(self) - str; fn description(self) - str; fn parameters(self) - Value; // JSON Schema async fn invoke(self, params: Value) - ResultToolResult, ToolError; } struct ToolResult { status: ToolStatus, // Success | Failed | Skipped summary: String, // 喂给大模型看的精简摘要 data: Value, // 完整结构化数据用于报告 }这里的summary字段是为Token省钱设计的后面在Agent上下文管理里会细讲。执行器抽象好之后新增一种设备支持只需要实现一个traitAgent编排逻辑一行不用改。3. 飞书机器人模块从群聊消息到可追踪的测试工单3.1 接入选型企业自建应用比自定义机器人强在哪飞书机器人有两条路一条是群里的自定义机器人配置一个webhook地址就能发消息五秒钟就能跑通。另一条是企业自建应用要建应用、配权限、申请审核麻烦得多。我刚开始也图省事试过自定义机器人但很快发现它致命的问题只能发、不能收。用户想发起测试任务、查状态、点按钮交互全走不了webhook。自定义机器人拿不到人的身份信息更做不了基于用户角色的权限控制。企业自建应用虽然开通麻烦但是把能力补全了可以订阅机器人消息事件能拿到用户ID和群ID可以发送消息卡片并接收按钮回调还能调用云文档接口上传文件、创建多维表格。对测试平台来说这些能力每一项都是刚需。我的建议是如果做demo可以先用自定义机器人正式平台直接选自建应用不要走弯路。3.2 消息意图识别规则优先大模型兜底飞书机器人收到的消息大致分两类一类是格式明确的指令比如/run nav_regression_suite或卡片按钮回调另一类是自然语言描述比如帮我查一下昨天深色模式那批用例为啥挂了。我在这块用了很务实的策略能走规则的绝不动大模型。固定格式指令直接用字符串解析和参数匹配耗时几毫秒不消耗Token。自然语言才交给AI Agent做意图识别和任务编排。这么做的原因很直接测试平台的指令重复率极高每次都让大模型处理纯粹是浪费而且规则解析的稳定性远高于模型。实测下来平台里大约70%的请求走了规则路径只有剩下30%真正需要Agent的理解能力。3.3 测试报告如何变成飞书表格和消息卡片报告推送是用户感知最直观的部分也是我花心思最多的部分。最初我只是把文本结果拼成一条普通消息发出去用起来很痛苦几十个用例的结果堆成一大段手机上根本看不下去想定位失败项还得翻半天。后面改成组合方案一条消息卡片加一个文件附件。卡片上只放汇总信息——通过率、失败数、阻塞数、总耗时、失败用例Top5列表每个失败项后面带一个查看详情按钮。点击按钮回调触发查询返回这条用例的截图、日志、Agent分析结论。明细数据则单独整理成Excel文件上传到会话里用飞书的云文档能力直接在线预览。这里有个细节Excel文件的表头我用的是项目组已有的模板格式用例编号、模块、预期结果、实际结果、缺陷关联、截图链接每个字段都对齐了飞书文档表格的列类型。这样测试经理可以直接把表格导入已有的管理文档不用二次加工。真正做到报告即数据。4. AI Agent核心设计用Rust把任务编排、工具调用和Token管理落地4.1 为什么Agent运行时选Rust而不是Python先回答一个绕不开的问题为什么用Rust写Agent运行时而不是生态更成熟的Python。一是部署体验Rust一个静态二进制扔到台架工控机上就能跑不装Python环境、没有依赖冲突对于长期驻场的测试设备来说太重要了。二是并发稳定性Agent运行时本质是大量异步任务同时在飞书接入、工具调用、LLM请求之间流转Rust的async/await和所有权模型让这块代码写起来很踏实不用担心共享状态的野问题。当然Rust的短板也很明显AI生态库少、模型SDK不全、写业务逻辑比Python慢。我的解法是核心运行时用Rust间接执行的算子脚本仍旧用Python子进程。两边通过JSON over stdio通信Rust负责调度和生命周期Python负责算子里那些生态依赖重的逻辑比如视觉模型推理、CAN协议解析。这个混合架构实际跑下来是最顺的两边各取所长。4.2 我用的是Plan-and-Execute而不是单体ReActAI Agent的主流架构里ReAct模式和Plan-and-Execute是我实际对比过两条路线。ReAct的思路是让模型在每一轮都观察当前状态、决定下一步动作灵活但有两个问题Token消耗高每步决策都要把历史搬给模型行为不稳定模型偶尔会反复尝试同一个失败动作。对测试场景来说这两个问题都很致命因为用例执行的路径应该是确定性和可解释的。最终我选了Plan-and-Execute的变体大模型只负责把用户需求翻译成一个有序的任务计划后续步骤的执行由状态机驱动每一步的工具选择在规划时就固定下来。Agent在单步骤遇到失败时允许把失败信息和重试建议反馈给模型让模型决定是重试、跳过还是终止。这样既保留了对异常情况的智能处理能力又保证了正常路径的稳定执行。从效果看平台上线三个多月正常路径零随机乱跳。4.3 Token管理搞懂Agent的短期记忆才能控住成本先说Token是什么。Token是LLM处理文本的最小单位中文场景下大约一个字对应1到2个Token。模型有上下文窗口限制超了就要截断或者报错。Agent对话过程中每轮规划、每次工具返回结果都会累积进历史上下文越滚越大很快把窗口撑爆。我在这里吃的教训最深。第一版实现里我天真地把所有工具执行完整输出都塞给模型结果跑了三十个用例之后上下文窗口直接爆掉平台报错瘫痪。后面做了三件事来管住Token历史截断只保留最近N轮对话更早的消息自动丢弃。对测试平台来说Agent和用户的交互轮次不会很多保留最近五轮基本够用。工具结果压缩就是前面说的summary字段。工具执行完先由代码自动生成一段精简摘要完整数据存数据库只有摘要进上下文。比如截图比对工具返回的是相似度97.2%差异区域2处位于左上角这一句而不是整个Base64图片或几百行像素数据。会话隔离每个测试任务单独建一个Agent会话任务结束后上下文归档避免不同任务的上下文互相污染也避免历史累积导致Token失控。这三板斧下来单任务Token消耗降低了差不多80%平台响应速度和费用都健康了。5. 工具执行层Agent怎么真正驱动车载HMI和执行器5.1 工具注册表与参数校验Agent能调的工具不是硬编码在编排逻辑里的而是维护在一张工具注册表里。每个工具包含四件套名称、描述、参数Schema、执行器实现。Agent在规划时会把用户需求、可用工具列表、工具描述一起丢给大模型让模型挑合适的工具并输出JSON参数。Rust端用serde做参数反序列化Schema不符的请求直接拒绝不给模型瞎编的机会。这里有一条经验工具描述要写人话。同样一个截图工具描述写成截图当前HMI界面并返回图像文件路径和get_screenshot对模型理解能力的影响完全不同。描述越具体模型选错工具的概率越低。平台里每个工具的描述都经过了几轮措辞优化这是0成本但收益极其明显的优化点。5.2 通过SSH/ADB操作目标设备车载HMI的操作执行器基本跑两条协议Android Automotive设备走ADBQNX/Linux设备走SSH。我在执行器里封装的几个核心动作包括启动/停止应用、注入触摸和按键事件、读取当前焦点窗口、设置系统参数、执行shell命令、截屏。每个动作的底层都对应一串指令但Agent看到的只是一些语义化动作。这里很容易忽略的一个点是命令超时。车载设备的性能参差不齐冷启动导航应用有时候能卡到几十秒但如果设置无限期等待一旦设备异常挂起Agent就会卡死在那里。我的做法是所有远程命令统一加一个可配置超时默认30秒超时后自动杀掉命令并返回超时错误。错误信息会喂给Agent做重试判断但执行框架本身不会无限等下去。5.3 CAN信号模拟与HMI状态联动HMI测试有大量场景依赖车辆信号。比如要验证仪表盘的车速显示就得让整车的CAN网络把车速信号喂给仪表要验证转向灯指示就得模拟转向灯开关的状态。平台里集成了一个CAN信号模拟器通过CAN卡和自研信号发生器在测试环境里广播刹车、油门、挡位、转向灯、车速这些关键信号。Agent侧的工具集于是多了set_speed、set_gear、set_turn_signal这类动作。执行器内部做一层状态同步设置CAN信号的同时会主动等待HMI端的状态刷新再触发后续截图或操作确保测试时序正确。这一层等待逻辑很关键因为CAN信号到UI渲染天然有延迟如果不等待直接截图经常会捕获到过渡帧造成假失败。5.4 视觉验证截图比对那部分如何防误判视觉验证是车载HMI测试的核心也是AI最容易帮倒忙的地方。平台里的视觉引擎分了三层第一层用OpenCV做模板匹配和感知哈希粗比对快速筛出明显一致的截图第二层对差异区域做像素级定位输出差异框和差异率第三层才轮到AI介入——把差异区域的局部截图、相似度数值、预期描述一起给大模型让模型判断差异是缺陷、是预期变化还是测试环境干扰。这里要特别强调一点不要让大模型直接看全图做判断。全图分辨率高、细节多既费Token又容易让模型被背景干扰最后给出一个泛泛的看起来不太对。局部裁剪加结构化指标的设计非常实用模型看到的是差异率3.2%差异集中在左上角一个图标区域预期该区域显示箭头图标这种输入下模型输出准确率会高得多。6. 落地过程中被真实环境教育的三件事6.1 飞书回调3秒超时先应答后异步是底线前面提过事件队列的做法这里展开说一下当时的排查过程。第一版联调时群里发消息经常出现消息已读但没有反应飞书后台能看到大量回调重试记录。顺着链路一步步查才定位到问题出在Agent规划调用了LLM接口单次响应就要3到5秒整条飞书回调必然超时。修复方案就是在接入层加队列先响应后处理。这里想提醒后来者一点飞书回调的3秒限制任何人都绕不过去任何同步处理逻辑放进回调里都是定时炸弹。6.2 长测试任务的会话保持与超时控制一个完整的回归任务可能要跑三十分钟中间会经历多次Agent规划、工具调用、结果汇总。这个过程中如果某个环节花了太长时间用户会以为平台挂了。我们平台的做法是给长任务设计了一个进度反馈机制Agent每完成一个步骤就往飞书群推一条轻量进度消息比如计划5步已完成2步CAN信号注入完成正在启动导航。用户可以随时打断说跳过这步Agent会重新规划后续路径。这个机制同时解决了会话保持问题。因为每条进度消息都携带Task ID用户回复时可以通过Task ID直接追加指令不需要重新描述一遍完整需求。6.3 大模型幻觉导致的假失败是最难调的一类问题平台刚上线那两周出现过几次特别迷惑的情况测试结果明明都通过了Agent在总结里却写注意导航界面疑似显示异常。开发一看截图界面完全正常。这就是典型的模型幻觉——它看到差异区域的局部截图结合上下文自己脑补了一个异常。我的解决方案分三步第一给Agent的判定通道增加置信度门槛低于门槛统一标成Review不直接下PASS或FAIL的结论第二结构化数据优先于模型描述工具返回里已有的数值指标相似度、差异框坐标直接透出在报告里模型只负责解释不负责创造指标第三所有Review状态的结论必须人工复核后才能关闭AI结论永远只是辅助意见。这套机制之后AI误判从会改错结论降级成了只会多标记一条等人工看一眼完全在可控范围。6.4 消息风暴与并发限流车载测试团队人数不多但一个项目群里可能有几十个自动化任务同时在跑。每个任务每完成一步推一条进度消息再加上报告推送和按钮回调量积累起来也不小。更要命的是如果某个Agent实例卡住LLM API持续重试会对大模型接口方的限流策略造成压力。平台做了两件事。一是会话级锁同一个测试项目群同时只允许一个任务在演化状态后面提交的任务排队等待避免多个Agent同时操作同一台台架设备导致命令打架。二是全局限流器对LLM API调用做令牌桶限流超出额度时任务降级为重试队列并主动通知用户当前负载高任务已排队。这两层保护上线后再没出现过消息风暴把整个平台拖垮的情况。写在最后这套平台上线之后我最大的感受是自动化测试终于不再只是跑用例而是一个能对话、能解释、能把人的注意力引导到最值得看的地方的助手。中间踩过的坑——尤其是Token管理、回调超时、模型幻觉这三块——如果重新来一遍我会在设计阶段就把消息链路和Agent状态机画清楚而不是先跑通Demo再回来补课。最后分享一个小技巧在设计AI Agent驱动的测试平台时别让大模型做真正的断言把硬性判定留给确定性算法坐标、阈值、状态码、异常日志让大模型专注于描述异常、组织步骤、解释结果。这样既能保住准确性又能享受大模型带来的灵活交互两全其美。
