企业官网建设流程全解析

车载HMI测试这两年越来越难做了。我刚入行时，一个中控屏、几个菜单层级、几十条用例，手工点一点就完事；现在座舱智能化卷上来，中控屏、仪表屏、HUD、后排娱乐屏多屏联动，语音、手势、方向盘按键多种交互并存，测试用例从几百条一路涨到几千条，而测试工程师还是那么几个人。这种压力下，我们在团队里落地了一套“飞书机器人 × AI Agent”的车载HMI自动化测试平台，把“人盯屏幕、人翻日志、人写结论”这最后一公里真正自动化掉。简单说，测试人员在飞书群里发一句自然语言，机器人转给AI Agent做意图识别和任务拆解，Agent再调度台架或实车执行器跑测试，跑完把结构化报告、截图、失败归因一起推回群里。这篇文章不打算写成产品宣传稿，我想把架构设计思路、三层关键工程的细节、以及上线后踩到的一堆坑原原本本分享一下。如果你是做车载测试、座舱交付，或者正在琢磨怎么把LLM能力接进测试工具链，这篇应该对你有用。

1. 聊点真实的：车载HMI测试的乱象，才是这套平台的真正起点

1.1 车载HMI测试到底难在哪

很多从移动互联网转过来的测试同学，一开始都低估了车载HMI测试的复杂度。表面看都是屏幕、都是交互，但这里面的差异几乎是代际级的。普通App测试，页面结构相对固定，控件层级清晰，出了Bug好定位；车载HMI不一样，几个硬伤绕不开：

• 多屏联动：一个操作可能同时影响中控、仪表、HUD。空调温度调高两度，中控弹窗显示详情，仪表上的状态图标同步变化，HUD里的提示文字也可能跟着切换。每一块屏上的显示逻辑都得验证到位，少一块都不行。
• 交互方式复杂：触摸只是最基础的一路。旋钮、方向盘按键、语音指令、手势控制，甚至眼球追踪，同一个功能在不同入口下的行为可能都不一样。测试用例的覆盖面必须把这些交互路径都包含进去。
• 强关联整车状态：HMI不是独立的App，它得实时反映车速、挡位、电量SOC、车门状态、充电状态这些整车信号。所以测试不能只盯着屏幕看，还得同步对着总线日志核对信号值，否则显示对了但信号错了一样是缺陷。
• 场景组合爆炸：光线、车速、温度、电源模式排列组合，UI策略全不一样。夜间自动亮度、倒车时360影像切换、充电中的SOC刷新，每个组合都是独立测试场景，数量级直接起飞。

这些特性决定了，如果测试还停留在“人工看屏幕 + 手工记录”的阶段，效率一定会崩。我们高峰期一次大版本回归要两周，其中一多半时间不是花在点屏幕上，而是花在“人工核对预期显示结果”和“整理失败用例证据链”这两件事上。后来我们算过一笔账，一个测试工程师一天能真正有效执行的用例数大概只有60到80条，剩下的时间全被截图整理、日志翻找、缺陷描述这些琐事吃掉了。

1.2 传统自动化的“最后一公里”为什么一直走不完

既然人力扛不住，那上自动化啊。我们最开始确实也搭过一套相对传统的自动化测试框架，屏幕截图、坐标点击、图像比对、CANoe仿真信号注入，该有的东西都有。但跑了一段时间，暴露出来几个很实际的问题。

第一是脚本维护成本高。HMI的需求变更太频繁了，UI文案调整、布局微调、交互细节改动，几乎每个迭代都有。一个小改动就可能让几十条用例的视觉断言失效，自动化工程师天天在修脚本而不是在写新用例，投入产出比非常难看。

第二是断言逻辑太死板。传统自动化最喜欢的像素级比对，在HMI场景里经常失灵。倒计时、进度条、随音乐跳动的动画，这些内容是“动态合理”的，没法用一张静态模板去比。放宽阈值吧，又容易把真缺陷漏过去。规则写死了不灵活，写松了不可靠，两头堵。

第三，也是最要命的：结果证据链碎片化。跑完几千条用例，生成几百张截图、几十万行日志，然后把测试工程师叫过来逐条确认失败原因。这个失败是已知缺陷？环境抖动？还是真回归？全靠人去翻日志做判断。这个环节人力消耗最大，却恰恰是规则引擎和传统脚本覆盖不到的地方——因为它需要的不是单帧画面的判断，而是对系统上下文、历史记录、日志线索的综合理解。这“最后一公里”走不完，自动化就永远只是“半自动”，前面省的时间全在后面补回去了。

1.3 飞书机器人 × AI Agent是增量改进，不是颠覆重来

决定引入AI Agent的时候，团队内部其实吵过一轮。有人担心LLM会胡说八道，把测试结果带偏；有人坚持应该正经做个Web平台，把所有测试流程搬到浏览器里；还有人觉得直接让大模型生成测试脚本就行，省掉中间一堆系统。

最后我们统一了一个认知：AI Agent不是来做测试判定的最终裁判，而是来做“拆解、调度、沟通”的中间层。判定层继续保留传统自动化的严谨断言逻辑，Agent负责理解人的意图、分解任务、调用工具、汇总结果、解释失败原因。这样一来，LLM出现在它最擅长的地方，避开它不擅长的精确数值断言，属于典型的增量改进，不是推翻重来。

另一个重要决策是入口选飞书机器人。原因很朴素：团队所有人每天打开最频繁的应用就是飞书，测试任务、缺陷管理、发布群全在这里。与其让大家再记一个Web平台的地址和账号，不如把测试能力直接嵌进IM里——在群里说句话就能触发测试，收通知不用切应用，审批和结果回溯都在同一个聊天流里完成。这个“IM即工作台”的思路，落地阻力最小，用起来团队接受度也最高。

2. 平台架构拆解：谁在对话、谁在调度、谁在跑测试

2.1 四层架构总览

整个平台从逻辑上切成四层：飞书交互层、Agent调度层、测试执行层、数据与资产层。

• 飞书交互层：负责消息收发、事件订阅、卡片渲染、命令校验。这是用户能看到的全部，也是开发过程中最容易被低估的一层。
• Agent调度层：核心大脑。基于大语言模型做意图识别、任务拆解、工具选择、多轮对话管理，同时通过状态机跟踪每个任务的执行生命周期。
• 测试执行层：对接台架HIL、实车测试终端、视觉比对服务、日志采集服务。这一层执行具体动作，向Agent暴露统一的功能接口。
• 数据与资产层：测试用例库、历史报告、截图录屏、总线日志、缺陷库。所有执行证据和知识沉淀最终落到这一层。

四层之间用统一JSON协议交互，消息走MQ或HTTP异步回调，避免各层强耦合。这样的分层顺手解决了一个老问题：传统测试平台里，Web前端、调度服务、执行引擎经常揉在一个进程里，改一处就要重新发布一套，牵一发动全身。现在各层独立部署、独立扩缩容，Agent层就算是挂了，飞书机器人还能做基本的查询兜底，执行层该跑测试还在跑，不会全线瘫痪。

2.2 Agent在平台中的职责边界：不做执行，只做拆解与决策

这是整个架构里我最坚持的一点：Agent绝对不要直接操作执行器。换句话说，Agent不写脚本、不点屏幕、不发CAN信号，它只做三件事。

第一，把用户的自然语言请求理解成一个结构化的任务描述，通常是一份JSON工单，包含模块、用例集、车型配置、执行环境这些字段。第二，根据任务描述，从已注册的工具集里选择合适的工具和调用顺序，走ReAct风格的推理循环，边想边调用，调用完再根据结果想下一步。第三，在执行器返回结果之后，结合测试数据、历史报告、缺陷库做综合解释，把一堆技术指标翻译成人话结论。

当时我们调研过业界主流的Agent架构，包括ReAct、Plan-and-Execute、Multi-Agent这些路线，也参考了云厂商公开的Agent设计白皮书。第一天就排除了Multi-Agent，原因很简单：多智能体编排的调试成本太高了，几个Agent之间互相调用、互相等待，出了问题排查链路非常痛苦。我们最后选了“单Agent + 外部状态机”的组合，LLM只负责在单次决策里做工具选择和归因解释，任务生命周期交给状态机代码去管。

为什么这么设计？因为一旦让LLM直接生成底层执行指令，出错代价太高。让模型写个Python脚本去操作方向盘？语法错误、API调用不合规、执行顺序不可控，哪一环都可能崩，出了问题还难追溯。但让LLM从一个预先封装好的工具列表里做选择，工具的输入输出边界都清晰、参数有约束、行为可测试，Agent的职责就被收敛在“决策”而不是“编码”上。

提示：判断Agent架构好不好，不是看它多智能，而是看它出了错能不能快速定位、能不能安全兜底。单Agent + 明确工具边界，是我们实测下来最可控的组合。

另外，团队也调研过一些基于Rust实现的新兴Agent运行时，性能和并发模型确实让人眼前一亮，但考虑到团队技术栈、飞书SDK的成熟度，以及执行层大量Python脚本的集成成本，主体服务最后还是用了Python。工具选型不必追新，能和现有生态稳定集成才是第一优先级。

2.3 入口为什么选飞书机器人

选飞书做入口，除了前面说的使用习惯，还有几个工程上的实际理由。

飞书开放平台提供的是完整应用机器人能力，事件订阅、消息卡片、交互回调、API接口都齐，特别适合做“命令型机器人”。群聊天然就是工作流，一个测试任务在专门测试群里发起，执行结果自动@到负责人，其他人能看见全部历史，形成了测试审计流。卡片交互能力也强，我们可以在卡片里嵌入按钮、下拉框、状态标签，比如“开始测试”“查看日志”“确认缺陷”，这些交互回调直接驱动后续流程，用人话讲就是“不用记命令，点按钮就行”。而且飞书多端一致，Web、桌面、手机端都能收消息点卡片，测试人员不在工位上也能通过手机审批或者看进度。

团队里一开始有人说“这不就是个聊天机器人吗，能扛起核心测试调度？”实际用下来，恰恰是因为入口简单、界面统一，团队的接受度才高。任何新工具最难的永远是推广，入口做在用户每天已经泡着的地方，推广阻力直接少一半。这个决定回头看，性价比非常高。

3. 飞书机器人与Agent对接的工程细节

3.1 事件订阅、消息卡片与指令协议设计

飞书机器人接入有两种方式：自定义机器人（webhook）和应用机器人。webhook只能单向推消息，没法做交互回调，所以平台用的是应用机器人。核心链路是这样的：

• 用户在群里@机器人或者单聊发消息，飞书通过事件订阅推送消息事件到我们的服务端。
• 服务端先做消息去重与来源校验，然后提取文本内容，转成Agent的输入。

消息转指令这一步，关键是要设计一套稳定的指令协议。我把它理解成Agent和飞书消息之间的一层DSL。比如用户发“今晚帮我跑HUD夜间模式的回归”，消息解析层会提取出：意图=执行测试、目标模块=HUD、测试模式=夜间、时间偏好=今晚。结构化字段再传给意图识别模块；如果信息不全，Agent通过飞书卡片发起一轮澄清式问答：“请问具体是哪个车型配置？是否包含仪表联动验证？”这样比让模型直接猜参数要稳得多。

消息卡片我们用的是交互式卡片。卡片不是静态展示，还带按钮、勾选项和回调地址。用户点“确认执行”，飞书会回调我们的接口，服务端再激活下一步流程。这里必须做好验签和幂等处理——用户可能连点两次按钮，回调可能重发，不幂等就会出现重复调度任务。我们第一期在这里吃过亏，后来统一给每个回调加了event_id去重表，才算彻底根治。

卡片里还能嵌表格结构，我们主要用来展示失败用例清单，模块、用例名、失败原因、截图链接一列排开，比文字列表直观得多，用户直接在卡片下方的按钮里选择“复跑失败用例”还是“提单跟进”，操作路径非常短。

3.2 意图识别与多轮对话的状态管理

我们在这里踩过最大的一个坑，就是图省事把所有意图识别全交给LLM。一开始确实爽，随便一句话模型都能理解个七八成，但到生产环境就发现不稳定。同一种表达换个说法，模型理解可能就偏了；座舱项目代号、测试环境名这类专有名词，模型识别尤其差。

后来改成“规则 + LLM”的混合意图识别。第一道先走规则模板，把高频指令抽象成模板，比如“跑一下XX的用例”“查一下XX环境的状态”“复跑失败的用例”。模板命中就直接转结构化工单，不走LLM，速度快、零成本、100%稳定。模板没命中、语义模糊的，才交给LLM做开放式意图理解，同时要求LLM输出JSON格式的结构化意图和置信度，置信度低于阈值就主动触发澄清对话。

多轮对话的状态管理同样重要。你以为Agent对话是问一句就结束？真实测试任务里往往要反复确认。我们在Agent层维护了一个会话状态KV，每个会话关联当前待确认的任务参数、已收集的用户偏好、本次确认状态。机器人收到新消息，先查这个会话有没有未完成状态，有就走“补齐参数”分支，没有再走“新意图识别”分支。这样LLM的对话能力被框在一个可控的状态流转里，不会出现模型回复内容和任务状态错位的现象。

3.3 Function Calling工具集设计：从“执行用例”到“查询车况”

Agent要真正动手做事，靠的是工具调用。我们把后端能力统一封装成工具，每个工具等于一个可被Agent调用的函数，有名字、描述、输入参数Schema、输出参数Schema。常见工具分成几类：

关键是工具的输入输出Schema一定要严格。Agent调用工具前，必须先对齐参数到Schema，类型错了就拒绝调用，不能让参数在模型那里自由发挥。我们额外加了一层参数校验器，进入执行层之前再做一次校验，确保边界条件全部由代码控制。

工具数量也不是越多越好。工具太多，模型选错的概率跟着涨。我们第一期只暴露了12个工具，覆盖最高频的测试请求，其余的需求宁可通过澄清对话引导用户简化需求。这个取舍在Function Calling场景里非常关键。现在很多团队在做Agent时总想一口气把所有能力都暴露出去，结果模型经常选错工具，调试起来头大。少而精，永远比多而杂好用。

3.4 长任务异步化：秒级响应与小时级执行如何共存

车载HMI测试，一组回归用例跑下来动辄半小时，整车场景甚至要几小时。如果Agent同步等着执行完，用户早就以为机器人死了。所以整个任务链路从一开始就是异步的。

具体流程：飞书收到请求，Agent先返回“任务已受理”的即时回执，秒级响应，同时把任务写入MQ；执行器消费任务，逐步回传进度事件（开始、用例A通过、用例B失败）；进度事件推给Agent，Agent更新状态机，再选择性推送给用户——不是每次进度都刷屏，而是关键节点推送，比如出现失败、任务完成、环境异常时。任务最终完成后，Agent拉取结构化报告，生成结论，@任务发起人。

异步链路带来的新问题是进度查询。用户会问“跑到哪了？”，所以每个任务都必须有task_id。Agent会把task_id以卡片摘要的形式固定在会话上下文里，用户任何关于进度的提问，都先经过task_id关联到具体任务，再去查状态机，而不是让模型基于对话记忆瞎猜。这个细节一开始没做，结果模型经常一本正经地编进度，后来把task_id硬关联加上，才算彻底解决。

4. 执行层的真实落地：台架、实车、视觉AI三合一

4.1 执行层工具链：从CANoe到Python视觉框架

执行层是这套平台里“最不AI”的一层，却也是最关键的一层。我们不会让AI Agent在一个不靠谱的执行层上做决策，所以执行层的稳定性和可控性，优先级比Agent的智能程度还要高。

台架侧用的是CANoe作为总线仿真与信号注入核心，配合vTESTstudio做测试序列，加载被测座舱域控制器。台架的好处是环境可控、能24小时运行、可以做总线级的信号验证。执行器通过CANoe的TCP Server API接收指令，动态下发测试序列，实时回传测试结果。

实车侧的环境要复杂得多。车在地下室或者户外停车场，网络随时可能断开，车机系统状态不可控因素多。我们在每台测试车上装了一个边缘执行网关，一台工控机，负责四件事：通过ADB连接车机、通过以太网采集多路屏幕画面、通过串口和以太网采集CAN日志、与云端Agent服务保持心跳。异常情况下，网关要能断网续跑，执行完再补传结果。

视觉与交互验证层是Python + OpenCV + OCR的组合。OpenCV做模板匹配和区域定位，OCR做文字提取，验证车机屏幕上的显示内容。语音交互场景单独接语音识别引擎，验证唤醒词、指令理解、TTS播报内容。这套组合选型基于一个朴素的判断：车载HMI测试里，最可靠的断言是总线信号级断言，信号值、报文周期、错误帧，都是确定的；第二可靠的是语义级视觉断言，屏幕上是否出现了正确的文字内容；最不可靠的是像素级视觉比对，受亮度、动画、时间戳影响太大。所以我们的自动化用例优先用信号断言，视觉断言只做辅助和兜底。

4.2 画面采集、OCR、模板匹配：哪些点适合传统算法

视觉判断这部分是车载HMI测试和普通App自动化差异最大的地方，值得单独说说。

画面采集在实车上是个性能挑战。多路屏幕画面通过视频采集卡或ADB截屏获取，直接截全屏PNG做模板匹配，一帧可能要几百毫秒，几块屏轮询一次就是好几秒，对需要毫秒级验证的动画场景完全不够用。我们的优化方式是，采集到原始帧后先做兴趣区裁剪。比如仪表上只关心左上角的挡位显示、中间的时速数字、右侧的告警图标区域，裁剪到ROI再做识别，单区域OCR耗时能压到几十毫秒。

识别算法的分工也有讲究。模板匹配适合“固定图标”判断，告警灯是否点亮、功能图标是否切换；但不同分辨率、不同主题下模板要维护多套，阈值也不能拍脑袋定。我们的原则是宁可漏报不可误报，漏报可以靠AI复核兜住，误报会直接浪费人工精力。

OCR适合“文字内容”验证，“充电中”“已连接”、温度数值、车速数字这类。但车机屏幕的OCR难点在于：字体多半是定制字体，背景有渐变和动效，显示区域还可能被中控台光照反射干扰。我们针对这一块自建了一批字体训练数据，效果明显比通用OCR好。动画类内容就别走图像匹配了，直接检测视频流关键帧里目标区域的颜色或亮度变化更稳，比如验证进度条动画在不在动，连续几帧算像素差异就行。

4.3 结果判定策略：用例断言与AI复核的混合模式

执行层的用例断言依然走传统脚本逻辑：信号值比对、OCR结果断言、模板匹配结果断言，全部是确定性逻辑，不走LLM。那AI Agent在哪里介入结果判定？

答案是“失败原因分析”和“失败聚簇”。一个用例失败，传统脚本只知道“断言失败”，不知道“为什么失败”：是环境问题（截图全黑、车机重启）？是系统问题（某个服务崩溃）？是需求变更（UI文案改了导致OCR不匹配）？还是真缺陷？

我们让Agent在用例失败后自动拉取失败截图、最近30秒日志、当前总线状态、最近一次同类用例的历史结果，做一次失败归因。Agent会输出可能原因、置信度、建议动作（重试/提单/忽略）。工程师不用自己翻日志，直接看Agent的归因结果再决定下一步。实测下来，归因的初步准确率大约七成，剩下三成由工程师修正归因标签，这个反馈又会作为样本沉淀下来，持续优化Agent的归因能力。

这个“确定性断言 + AI归因”的混合模式，既保住了测试判定的严谨性，又解决了人力成本最高的“看数理解”环节。整套架构里，我最愿意推荐给同行的就是这一点。

5. 权限、Token与稳定性：上线后最难啃的三件事

5.1 权限设计：测试命令的审批与执行链

在飞书群里挂一个能操作台架和实车的机器人，权限不控制好真要出事。比如误触发了固件刷写或车辆上下电，轻则打乱测试计划，重则影响正在进行的实验。

我们的权限模型分三层。用户层按飞书用户和群身份判断，普通成员只能发查询和只读命令；核心测试人员可以发起用例执行；测试负责人才能触发固件刷写、环境重置这类高危操作。环境层把台架执行和实车执行分开授权，实车操作默认比台架高一级审批要求。指令层对高危指令单独配置审批链：用户在群里发起高危操作，机器人不直接执行，而是发一个审批卡片给负责人，负责人点“批准”后任务才真正进入执行队列。审批人和指令内容全部记录在日志里。

这块一开始我们都觉得没必要，团队里都是自己人。直到有一次有人误在生产台架上触发了一条全量用例执行，把正在跑另一组实验的台架挤掉了，才意识到权限和审批链的刚性需求。现在这套三层权限模型是平台不可动摇的底线。

5.2 Token消耗测算与上下文裁剪策略

先说个基础概念，LLM计费和处理的基本单位是token，可以粗略理解成模型读写内容的字符碎片，1个汉字大约对应1到2个token。一次把几万字的报告原文塞进Prompt，就是几万token，成本自然暴涨。Token控制不是省不省的问题，而是决定这套平台能不能规模化铺到多台架多车型的问题。

我们的优化手段总结下来四点。第一，能不走LLM就不走，规则模板命中的直接处理，数据库查询直接走API，只有真正需要语义理解的请求才调模型。第二，长文档剪进带外数据。最初设计里我们把完整测试报告原文直接塞进Prompt让模型总结，效果是真好，但一份报告几万字，Token消耗吓人。后来改成先做结构化摘要，统计信息、失败列表、关键字段进Prompt，完整报告作为链接让用户自己点。Token消耗直接降了八成以上，总结质量几乎没有下降。第三，历史对话缓存，同一天同一会话只保留最近几轮完整对话入上下文，更早的转成摘要缓存。第四，用便宜模型做普通意图识别，用强模型做复杂归因。规则模板接住七成请求后，剩余请求里大部分用小型模型就能识别；只有失败归因这种需要多源综合判断的任务才调用强模型。

实测下来，一套台架、每天二三十次任务交互、每周一次全量回归的规模，单台架月均LLM成本在个位数到两位数之间，完全可接受。

5.3 稳定性治理：断网重连、飞书限频、执行器探活

这套平台有三个高频稳定性坑，一个个说。

实车环境断网。地下室、户外停车场、强干扰条件下，车端网络随时可能断。我们的处理是边缘网关本地续跑：任务下发到网关后，网关先把任务和依赖参数持久化到本地，执行过程中即便断网也照常跑完，结果先存本地，重连后补传。云端Agent只负责调度和结果回收，不实时控制执行器的每一个动作。架构目标从“云端控制”调整为“云端调度、边缘自治”。

飞书消息限频。飞书开放平台对消息发送频率有限制，大量执行时一次性推几十上百条消息会被限流。我们的策略是进度消息合并推送，每10分钟汇总一次进度，或者一个阶段完成推一条摘要卡片，而不是每条用例推一条。顺便也解决了刷屏问题，群里刷屏太多，用户会直接屏蔽机器人，那就彻底失去意义了。

执行器探活。台架可能被人占用，实车可能不在线。Agent在调度任务前必须先探活，检查执行器在线状态、资源占用、是否已有任务在跑。我们把探活做成工具注册在Agent工具集里，Agent在任务受理阶段就自动调用探活工具，执行器忙就返回“当前不可用，预计X点释放”，让用户重新安排，而不是让任务进队列傻等。

5.4 踩坑：Agent幻觉导致误判的真实案例

这是我最想分享的部分。有一次，一条用例明明在日志里清楚写着“镜像文件加载失败，测试未执行”，Agent归因时却生成“胎压监测界面显示异常”的结论。我们查了很久才发现根因：Agent在归因时过度依赖截图视觉内容，忽略了日志里的关键错误行。截图显示的是上一次测试留下的残留画面，日志才是真实执行证据。之后我们给Agent的归因Prompt加了硬约束：日志优先级高于截图，信息矛盾时以日志为准，归因结论里必须引用日志原文。这个约束上线后，归因准确率明显上来了。

另一个教训是不要让Agent直接定“问题等级”。有一次Agent把一条自动化设备故障强行归因为“HMI显示缺陷”，等级标了P0，差点全员响应。现在等级判定必须有“缺陷库关键字匹配 + 人工确认”作为前置，Agent只能给建议，不能独立定级。

这两条经验合起来就是一句话：AI Agent在生产系统里一定要设计安全网，硬规则兜底、置信度阈值、人工确认回调，别让模型直接做最后的决定。

6. 一些复盘和后续想做的事

6.1 复盘：这套平台最值钱的不是算法，是工具化和流程化

整套平台从立项到稳定运行，大概花了三四个月。回过头看，最耗时间的不是Agent部分的代码，而是执行层的稳定性和工具边界整理。Agent的代码量可能只占整个系统的三成，但它在架构里起的是穿针引线的作用，真正的价值在于把飞书交互、测试执行、数据闭环这些原本分散的系统串成了一个整体。

6.2 后续计划：从任务执行走向测试知识沉淀

我们已经开始尝试把历史失败归因数据做进一步挖掘：同一模块的失败原因占比、不同车型配置下的用例稳定性差异、环境问题与真缺陷的比例趋势。这些统计以前靠人肉整理，现在有了结构化数据和Agent归因标签，做出来成本很低。计划是做成自动化的“测试健康周报”，每周推送到团队群。另外一个方向是把Agent能力进一步开放给更多角色，产品经理可以在群里问“这周的测试通过率怎么样”，质量经理可以问“HUD相关用例最近有没有趋势性失败”，这些查询类交互已经在灰度测试里了。

6.3 给同行的一句话建议

如果让我给正准备做类似平台的朋友一句话：先把执行层做扎实，再让Agent上场。一个稳定可控的执行层，加上一个边界清晰的Agent调度层，这套组合的价值会远远大于“塞一个大模型进去做全自动测试”的幻想。测试行业的核心永远是可控、可信、可追溯，AI是放大器，不是替代品。

最后说个小技巧：我们的飞书机器人在每个任务完成后，都会附带一句“本结论由AI辅助生成，请结合日志复核”。这既是对工程师的提醒，也是我们对Agent责任边界的一种诚实表达。说实话，加上这句话之后，团队反而更信任这套系统了。