车载HMI自动化测试这件事做了的人都知道难点其实不在UI自动化技术本身而在“如何让测试能力被整个团队真正用起来”。过去我们组里跑的自动化脚本不少控件树识别、图像匹配、模拟器回放都有但测试同学想跑一轮回归还是得自己找设备、敲命令、翻日志跑完的结果散落在各个报告里连个统一出口都没有。我接手这块平台建设时定了两条硬规矩入口必须离使用者足够近近到在IM里发一句话就能调度测试结果必须自动回来回来之后还能让人一眼看懂。抱着这个目标我们最后落成了一套“飞书机器人 × AI Agent × 车载HMI自动化执行器”的平台。这篇文章就来讲讲这套平台的架构设计、实现细节、落地过程里踩过的坑以及我个人的一些复盘。1. 为什么做这件事痛点分析与方案选型1.1 车载HMI测试的日常远比想象中“脏”车载HMI和我们常见的App测试有个很大的不同它不是一个屏幕、一套操作逻辑而是中控、仪表、HUD、后排屏等多个显示单元的组合。出现一个缺陷往往和系统版本、屏幕分辨率、驾驶模式、正在运行的应用都有关系。再加上整车厂和一级供应商之间频繁的版本交付节奏HMI的回归测试量非常大。我接手时最直观的感受是团队不是在测产品而是在“伺候设备”。测试同学为了跑一个“仪表和中控联动”的用例要先确认某个台架没人占再去台架旁边手动清掉上一次残留的进程然后打开测试工具、选设备、加载用例集、点开始。中间一旦某一步弹窗卡住整个用例就废了又得重头来。这种活干到下午人已经很疲惫出错的概率反而更高。自动化也不是完全没有但零散地散落在不同同学的脚本仓库里有人用框架A有人用框架B甚至有人直接写Shell脚本加截图比对。真正想跑一个跨模块的回归需要把这些脚本挨个手动触发再把结果汇总成一份报告。等于说自动化的效益被“组织成本和门槛”吃掉了大半。1.2 选型过程为什么是“飞书机器人 AI Agent”最开始我们有三个候选方向。第一个是做一个完整的Web测试平台用例管理、设备管理、报告展示全做进去类似一整套内部CI系统加一个可视化界面。但评估下来这个投入太大对使用者的要求也很高——测试同学要学新平台、记地址、处理登录态一个平台最好用的状态是“不用专门去学习”。第二个方向是用IM机器人的“斜杠命令”。比如在群里发 /run smoke -d 101 这种固定指令由机器人解析并触发任务。这种方案开发成本低但体验有个明显瓶颈非技术背景的人记不住命令参数一旦命令变多反而比Web平台更难用。第三个方向就是现在这个方案IM机器人做入口AI Agent做“从模糊到精确”的翻译层。用户完全可以用自然语言发请求比如“帮我跑一下中控首页的回归”“在1号台架上把仪表主题的冒烟跑了”由Agent负责把这句话转成结构化的测试任务。机器人和Agent之间不是简单的字符串匹配而是真正把用户的意图和平台能力对接起来。我最终选择第三个方向还有一个原因。车载HMI测试的诉求天然是碎片化的有人要跑完整回归有人只想验证某一条用例有人报了“仪表黑屏”希望马上跑一遍开机自检链路有人深夜在群里丢一句“把昨天那个失败用例重跑一下”。这种多变、并行、且经常需要上下文关联的交互场景用对话式入口来承接匹配度非常高。方案对比看下来会更清楚方案使用门槛部署成本交互体验维护负担Web测试平台中高需要学习系统高前后端数据库主动登录、结构化操作高飞书机器人斜杠命令中需要记忆语法低固定格式、反馈生硬低飞书机器人AI Agent低自然语言即可中需接入大模型灵活、可多轮澄清中1.3 目标边界与迭代节奏做这类平台最容易犯的毛病是一上来就想把所有场景都收进来。我的建议是先把边界划清楚。我们第一版的北极星指标只有三个用户能不能在聊天框里说一句话触发测试任务任务跑完之后结果能不能自动推送回来失败的时候能不能拿到足够现场信息至少不用重新手工去复现一次。至于缺陷自动定位、用例推荐、复杂设备能力编排统统留到后面。节奏上我们从立项到第一个可用版本大概用了两周。先不做复杂调度先把“机器人收到消息 → Agent解析 → 创建一个最简单的设备任务 → 执行器跑冒烟用例 → 结果回推”这条主干打通。因为这条主干一旦通了整个平台的骨架就成立了后面所有细化都是在骨架上加肉。提示如果你也在做类似的平台第一版千万不要贪多先保证一条端到端链路是完整的让团队真的用起来然后再迭代。2. 整体架构设计与核心数据流2.1 四层架构各干各的活整套平台从逻辑上分四层交互层、智能层、服务层、执行层。分层的原则是“每一层只依赖下面一层的接口不跨层调内部逻辑”。交互层是飞书机器人网关负责接收消息事件、推送通知卡片、管理会话入口。它不关心消息内容怎么理解只做消息的接收、格式转换和回推。智能层也就是AI Agent模块是整个平台和传统自动化平台拉开差距的地方。它的职责是“把用户意图翻译成平台能执行的标准任务描述”包括意图识别、参数抽取、对话上下文管理以及必要的时候追问用户。翻译完成后它会调用一个统一的内部接口把任务交给服务层而不是直接去操作设备。服务层承载核心的业务状态任务中心、用例仓库、设备池、报告服务。它维护每一个任务从创建、排队、执行中、到终态的生命周期同时负责和外部系统做数据交互比如存储报告、绑定用例版本。执行层是直接接触车载HMI设备和被测对象的模块包括台架、模拟器、真机的驱动控制以及执行用例脚本的运行时。执行层做的是脏活累活启动环境、横竖屏切换、点击坐标、截图比对、收集日志。这四层串起来的调用关系是固定的飞书消息 → 机器人网关 → AI Agent → 任务中心 → 设备调度 → 执行器 → 结果上报 → 通知回推。每一层之间都用明文结构体相接不混在一起。2.2 一条消息走到执行器的完整链路用一个具体场景来看整条链路。测试同学在“中控仪表测试群”里机器人发了一句“帮我在1号台架上跑一下仪表主题切换的冒烟。”第一步飞书的事件订阅服务把这条消息以回调形式送到机器人网关网关先做签名校验确认消息确实来自飞书再看一下会话状态里有没有这个群的语义上下文。第二步网关把消息内容连同会话ID、发送者、群组ID包装成一个事件对象投递给AI Agent引擎。Agent先跑一轮意图分类判断这是一个“执行测试任务”的请求接着抽取关键参数设备目标“1号台架”、用例集“仪表主题切换冒烟”。第三步Agent并不会马上就创建任务而是先调用一个“查询可用设备”的工具确认1号台架当前确实在线且空闲。如果设备被占用Agent会直接回复“该设备正在跑任务大约还要十分钟”而不是硬着头皮把任务建出来。第四步Agent把完整参数整理成一份标准任务描述JSON调用任务中心接口创建任务。任务被分配一个全局唯一的任务ID进入排队队列。第五步设备调度器扫描到新任务锁定1号台架把它从设备池切成“占用”状态同时通知执行器加载对应的用例脚本。第六步执行器在1号台架上跑用例。过程中会持续上报进度和心跳任务中心负责记录状态一旦超过阈值没有心跳就会判定执行异常。第七步执行结束后执行器把结果和现场附件回传报告服务报告服务生成摘要信息由机器人网关推送到群里。整个过程用户从头到尾只做了一件事在聊天框里发了一句话。链路看起来不算复杂但每个环节都有超时、重试、异常兜底。后面我会具体讲任何一个环节没有兜底都会变成白天高高兴兴发消息、半夜胆战心惊看告警的窘境。2.3 关键设计原则失控可控平台里最需要重点把握的一个原则叫“失控可控”。AI Agent有很强的不确定性它会理解错、会编造参数、会在多轮对话中前后矛盾。但平台本身不能把这种不确定性放大到真实设备上。所以我们的设计是Agent永远只负责“生成任务建议”最终对设备的操作权全部掌握在任务中心手里。任务中心是唯一被允许创建设备任务、锁定设备、触发取消动作的服务。Agent调用它时必须遵守固定的协议格式任务中心也会做最终校验设备是否存在、用例集是否合法、优先级是否合理、当前是否有冲突任务。所有这些校验不过任务直接拒绝并返回原因Agent把原因用自然语言回复给用户。这个看似简单的原则在后来的使用中救了我们很多次。有一次模型把“中控”理解成了“仪表”生成了一个仪表相关的任务但因为任务中心做标签校验时发现用户实际选的标签和该模块用例不匹配直接拦了下来。如果当时没有这一层闸门错误任务真被跑到设备上平台在团队里的信任感一瞬间就会崩塌。注意在AI Agent参与的工程化系统里永远要把“模型生成的内容”当作不可信输入来处理在边界处用强约束收敛。3. 飞书机器人接入与AI Agent指令解析的实现细节3.1 机器人接入从开放平台到事件回调飞书机器人的接入流程本身不复杂。先在开放平台创建应用开启“机器人”能力然后给它配置事件订阅地址。我们需要订阅的主要就是“接收消息”事件覆盖私聊和群聊中机器人的场景。这里有几个容易被忽略的坑。第一是校验飞书的事件回调请求带签名和加密字段服务端必须做签名校验和解密不通过直接丢弃。很多团队本地联调时图方便先把校验关了结果一上生产就发现一堆假消息进到了业务逻辑里。第二是事件重放飞书的事件投递不是精确一次消息事件可能会重复推送多次。机器人网关在消费消息前一定要先查一条“消息ID幂等表”同一个message_id只能被处理一次。下面是网关处理回调的简化伪代码实际我们用的Java实现但逻辑可以平移到任何语言def handle_callback(event): # 1. 校验签名失败即丢弃 if not verify_signature(event): return invalid signature # 2. 解密消息体 raw decrypt_event_body(event[encrypted_content]) # 3. 幂等检查同一个消息ID不重复处理 msg_id raw[header][event_id] if redis.exists(fdedup:robot:{msg_id}): return duplicated redis.setex(fdedup:robot:{msg_id}, 300, 1) # 4. 判断是消息事件还是其他事件 event_type raw[header][event_type] if event_type im.message.receive_v1: payload raw[event][message] event_obj { chat_id: payload[chat_id], sender_id: payload[sender][sender_id][open_id], text: extract_text(payload[content]), } # 投递给Agent处理 agent_engine.handle_event(event_obj) return ok一个更隐蔽的问题飞书事件回调里拿到的sender_id是open_id它和应用是绑定的。同一个用户在不同机器人下open_id不同所以需要用一张用户映射表来串联用户的身份。不然排查问题的时候连“这条消息是谁发的”都很难追溯。3.2 定义“任务描述JSON”把话说清楚AI Agent的理解结果不能是一段自由的文字否则下游任务中心没法处理。我们在中间定义了一份标准任务描述协议所有由Agent生成的任务必须是符合这个协议的JSON对象。协议的核心结构是这样的{ intent: run_task, tenant_id: hmi_test_group, task_name: 仪表主题切换冒烟, device_selector: { device_id: bench_01, strategy: exact }, target: { module: dashboard, capability: [touch, voice], tags: [smoke, theme_switch] }, schedule: { priority: normal, max_timeout_seconds: 1800, notify_chat_id: oc_xxx } }字段不是随便定的每一项都有明确目的。intent让下游区分是执行任务、查询状态还是取消任务。device_selector决定用哪台设备strategy可以是精确匹配也可以是“找一台符合条件并且空闲的”。target描述被测对象module对应产品模块capability对应操作能力类型tags用于过滤用例集。schedule里notify_chat_id表示结果推送到哪个群。为什么把协议定义成JSON而不是直接用自然语言传给下游因为JSON有明确的schema可以校验、可以版本化、可以在以后扩展字段时保持兼容。任务中心只信任符合schema的任务不合法就拒绝这比让Agent生成自由文本、再由下游解析容错要稳妥得多。3.3 AI Agent的Prompt与工具调用设计Agent的理解能力很大程度靠提示词设计和工具定义。我们的系统提示词会明确告诉模型三件事这个平台能干什么、不能干什么、遇到模糊请求应该怎么办。平台能力清单大致是运行测试用例集、查询任务状态、查询设备状态、取消任务、查看最近报告。每个能力对应一个工具函数。模型在生成回答前会被要求优先从这些工具里查找外部事实而不是凭记忆生成。工具定义的示例{ type: function, function: { name: search_test_cases, description: 根据模块、标签、版本等信息搜索可用测试用例集, parameters: { type: object, properties: { module: {type: string, enum: [home, dashboard, hud, settings]}, tags: {type: array, items: {type: string}}, product_version: {type: string} }, required: [module] } } }为了让模型输出足够稳定我们还会在提示词里要求它在最终回答前必须经历三个步骤先确认意图再从工具拿事实最后提交任务。如果用户的请求信息不全比如只说“跑一下回归”但没说设备模型不能瞎猜而是要追问用户。追问的设计也讲究。模型不是简单问“你要跑哪个设备”而是给出可选项“目前空闲的设备有1号台架和中控模拟器A你要用哪一台”这样用户回复成本最低对话也最容易收敛。3.4 会话上下文与多轮追问对话式入口一定会遇到“上下文关联”的需求。用户发完“跑一下仪表主题切换”过了十分钟可能来一句“结果怎么样”或者第二天说“重跑一下昨天那个用例”。这就要求Agent能维护会话状态。我们会为每个群和私聊会话保存一份最近任务记录记录包括任务ID、任务名称、执行时间、结果摘要。模型在理解新请求时可以拿这份记录作为上下文参考。比如“重跑昨天那个”就能关联到最近一次任务的具体ID。但要给上下文设置有效期。默认会话记忆只保留24小时超过之后一律视为新会话开始。任务状态查询也不依赖模型记忆而是让模型调用query_task接口从任务中心实时拉取避免模型拿着过期的“印象”回答用户。实操心得让Agent“知道自己不知道什么并且会去查实时数据”比让它记住所有对话历史更能避免错误回答。4. 执行引擎与车载HMI测试任务的落地4.1 测试用例、标签与产品版本的关系平台底层承接的是测试用例资产。我们重新梳理了用例库的组织方式从原来的“脚本名即用例名”改为“描述式用例脚本绑定”。一个标准用例包含用例编号、名称、所属模块、操作步骤描述、期望结果、关联的产品版本范围、能力标签。标签体系尤其重要。因为Agent筛选用例时不是靠全文搜索脚本名而是靠标签组合。比如“仪表主题切换冒烟”对应的标签是moduledashboard、capabilityvoice、priorityP0。用户说“跑一下仪表的语音冒烟”Agent会把它映射到这套标签上从而锁定正确的用例集。用例与产品版本的绑定是为了防止自动化脚本版本和被测产品版本错位。车载HMI的版本迭代频繁UI控件树经常变脚本需要跟着同步。如果某个用例脚本已经标记为“不兼容某版本”任务中心会在派发任务时直接拒绝并提示用户相关版本已锁定避免拿到完全失效的测试结果。4.2 设备池与调度策略设备池是执行层的资源底座。我们把台架、模拟器、真机都抽象成统一设备模型每台设备有唯一ID、类型、分辨率、系统版本、连接状态、当前状态机和最近心跳时间。设备状态机定义了四个状态空闲、占用、异常、维护。任务开始时把设备从空闲切成占用结束时释放回空闲。执行器在跑任务的过程中会周期上报心跳一旦心stop超过阈值任务中心将设备标记为异常执行器触发收尾逻辑。调度策略上我们按照“同模块串行、跨模块并行”的原则来控并发。同模块的用例彼此之间可能有状态依赖比如仪表和中控存在联动跑串行能避免相互污染跨模块的用例相互隔离可以并行执行来提升吞吐。设备不够时新任务进入队列按优先级排序高优先级的任务可以插队。有一个细节很关键设备占用是“预约式”的。任务创建之后、正式执行之前设备先被标记为“预占”防止调度器在准备阶段把同一台设备分给另一个任务。过去我们没做预占出现过两个任务同时拿到同一台设备一起初始化环境直接在屏上抢焦点的“事故”。4.3 HMI执行器的实现思路三通道协同验证车载HMI执行器是让测试真正“跑起来”的模块。我们的实现采用三通道协同验证的思路控件树识别、图像识别、外设信号采集。控件树识别对应UI层级结构能精确拿到按钮、列表项的位置和状态速度快、定位准。但很多车载HMI是自研渲染引擎或者基于Qt QML的控件树不一定完整特别是在仪表盘这类图形大量自绘的场景拿不到足够审美的树。图像识别兜底就显得很重要。我们跑了图像模板匹配和YOLO等检测模型用来识别屏上的图标、异常色块、黑屏、花屏等。第三通道是信号采集这也是车载场景区别于普通App测试的地方。执行器会采集CAN总线信号、车辆状态模拟器的输出用于判断一个交互是否真的产生了对应效果。比如按下方向盘上的音量键光看屏幕不变化不够还要看总线里的音量数值是否发生了变化这更能说明链路是真的通了。执行器跑一个用例的时序大致是建立连接 → 环境清理 → 屏幕状态校准 → 按步骤执行操作 → 每个步骤后截图并做断言 → 步骤异常时记录现场 → 全域收集日志 → 结束并生成结果。如果哪一步失败执行器会立刻把截图、控件树快照、logcat日志和最近一段录屏打包成附件供后续分析。4.4 结果回传与报告聚合执行完成后结果报告要能被人快速判断。我们的报告分三层摘要层、用例层、附件层。摘要层就是几行字一共跑了几条用例、通过几条、失败几条、耗时多久、用了哪台设备、哪个产品版本。用例层列出每个用例的结果失败用例直接标红查询详情入口。附件层是完整截图、日志、录屏的下载链接。推送到飞书群的是经过裁剪的卡片不是一长串报告。卡片上最关键的内容是“结论”和“失败摘要”。失败摘要包括失败用例的名称、失败阶段、可能原因分类——是环境异常、脚本失效还是疑似产品缺陷。这个分类是执行器根据现场信息自动标注的不是手工填写。报告数据会同步存储一份到本地数据库和对象存储用于趋势分析。周维度可以看到按模块、按能力类型的通过率变化哪些脚本经常翻车需要维护哪些模块的稳定性在下滑。这些数据后续还能反哺到用例优化和开发排期上。注意结果推送的“结论自动标注”一定要保守。它只是辅助人快速判断的参考绝不能替代测试工程师的最终确认否则误标带来的信任损失远大于省下来的那点时间。5. 落地过程实录那些必须写出来的坑5.1 消息重复回调把任务创建了两次平台上线第一天就踩了一个落差很大的坑。一位同学在群里发了一条跑回归的消息十分钟后群里出现两条一样类型一样的任务在同时跑1号台架被锁死另一个任务在排队里“卡死”等待。排查下来根因就是前面提到的事件重复推送。飞书的事件回调在某种网络重试场景下会把同一条消息推送两次。我们开发时虽然写了幂等检查但只覆盖了网关层的消息接收没有在任务创建层做同样的保护。两条请求都是第一次进入任务中心各自都通过了设备预占判断于是都创建了任务。解法的本质是“双保险”。网关层继续做消息幂等任务中心再做一个按任务指纹幂等的存在约束——用“消息ID请求来源”做唯一索引重复请求直接返回已有任务而不是新建。这样就算网关被绕过任务中心也能拦截重复。教训就是任何跨网络、带副作用的操作幂等都不嫌多。5.2 Agent一本正经地“编”参数有段时间我们遇到一个很头疼的问题Agent为了完成任务会在信息不足时强行猜参数。用户明明没提到设备Agent“自作主张”选了1号台架用户说的是仪表Agent却因为工具返回的用例描述里出现了“中控”字样把模块标签一直变成了中控。这种问题的本质是模型把“生成看起来合理的答案”和“生成事实正确的答案”混在了一起。单靠提示词让模型“不要猜”是没用的要靠机制控制。我们后来强制所有任务创建前必须先调用工具查询真实数据并且把查询结果直接作为输入的一部分喂给模型。比如只有先调用list_devices拿到在线设备列表模型才能从中选择设备只有先search_test_cases拿到合法用例集模型才能创建任务。另外如果模型选择的设备不在设备池返回的列表里任务中心会直接拒绝并返回“设备不存在”的状态Agent会转述给用户并重新请求。这套“查询先行硬校验兜底”的组合基本把乱编参数的问题压了下来。实操心得在Agent工程化里别指望模型的“诚实”要用工具查询和系统校验来约束模型的可能性空间。5.3 台架死机与僵尸进程设备长期开着跑自动化一定会出现各种异常状态。最常见的现象是设备池显示“空闲”但实际屏幕已经黑屏或者系统进程已经卡死。任务派过去执行器初始化半天然后上报一个莫名其妙的“无法连接”。我们排查后发现很多是长时间运行后系统进入休眠状态或者之前某个用例留下了僵尸进程占着屏幕不释放。单纯重启执行器解决不了因为被测系统已经脏了。后面建立了一整套自愈机制。任务执行前执行器先做一次环境自检检查系统是否响应、屏幕亮度是否正常、常驻进程是否在跑自检不通过先尝试软恢复清理残留进程、重置显示服务软恢复失败再执行硬重启。同时设备维护脚本会周期性扫描设备状态发现实际连接异常立即把设备踢出空闲池不参与任务调度。自愈机制跑起来之后平台因为设备异常导致的失败率大幅下降。这个过程里我体会很深的一点是设备池管理不能只看任务相关状态机还要维护“物理世界”的实时状态两条信息要能对得上。5.4 通知轰炸与接收疲劳平台上线初期我们为了让用户有“掌控感”把每个执行阶段都推送到群里任务已创建、环境初始化中、正在执行第三条用例、正在执行第四条用例、执行完成。结果是测试群瞬间变成了流水日志群重要信息被淹没在不断刷屏的消息里。接收者真正关心的其实只有两个节点任务开始跑了吗、跑完了吗。如果中途失败了再额外补一条失败节点通知。我们重新设计了分级推送策略任务创建成功只推给发起人的私聊不推群里。 任务开始执行在群里推一条简短信息包含任务ID、设备、用例集。 任务完成群里推完整结果卡片。 任务异常/失败群里推失败摘要附件链接提醒相关人关注。调整之后群里的噪声明显降下来重要消息的触达率反而更高。这件事也提醒我做消息驱动的平台推送策略本质上是在替用户做信息过滤推送越克制平台越显专业。6. 效果复盘与AI Agent的进一步扩展6.1 平台落地后的几个直观变化平台运行一段时间后团队的工作方式发生了一些微妙的变化。最明显的是测试同学不再需要掌握一堆命令和工具只需要在聊天框里说一句话就能发起测试。本来超过一个小时的仪表模块手工回归现在只用等平台跑完大约二三十分钟就可以拿到带附件的报告中途不用守着设备。设备利用率也上来了因为平台有排队和调度机制没有设备的空转时间。另一个变化是结果透明。测试报告自动推送对应群后产品、开发、测试都能在同一时间看到结果。以前要专门约人对齐的“测试结论”现在变成了一条公开的、可回溯的记录。开发同学说这种透明度让他们更有动力在提测前自己先跑一轮因为知道失败会被记录在案面子上挂不住。从数据上看自动化触达率显著提升不是只有测试开发在跑自动化普通测试工程师甚至产品经理也会偶尔发一条任务来验证自己的判断。这个变化比任何技术指标都让我高兴。6.2 AI Agent还能做的三件事平台的主干跑通之后AI Agent的扩展空间开始变得明显。目前我们在推进三个方向。第一个方向是智能排测。根据本轮迭代涉及的产品模块和需求标签让Agent自动推荐应该跑哪些用例集而不是由人手动圈选。这需要把产品需求数据和用例标签做关联本质上是在做“变更影响面分析”。短期不追求全自动能让Agent给出推荐清单、由测试工程师确认就行。第二个方向是失败初判。把失败现场的多模态信息——截图、录屏关键帧、日志片段——喂给多模态模型让模型输出一份“类似UI改版、疑似脚本失效、可能是产品缺陷”的初步判断。这个判断会作为标签出现在报告里帮助测试同学先圈定排查范围。第三个方向是交互式巡检。Agent不再只能被动回答问题而是在每天固定时间主动发起巡检把当日代码变更相关的风险用例汇总起来在群里问“需要我现在跑一遍吗预计20分钟”。这种主动触达大大降低了测试工程师“想起要回归”的认知负担。6.3 平台化的组织协同最后想说说这套平台给组织协同带来的变化。以前设备是某个同学“自己的”用例脚本是某个脚本“作者的”测试资源私有化严重。平台出现后设备和用例都沉淀成公共资产任何人只要在聊天框里发起任务就能使用这些资源。这要求团队重新定义角色。测试开发同学不再只写脚本还要维护用例标签、设备自愈脚本、执行器稳定性。普通测试同学的角色变成“用例验收者”和“结果确认者”。设备本身由平台的维护脚本统一管理。有一个警惕点我必须提一下不要让平台变成“跑脚本出租车”。如果只是把现有的手动流程自动化而用例质量没有跟上平台就会变成一个快速产出无效报告的机器。所以一定要围绕平台建立一套用例质量反馈机制定期清理失效用例、重新评估脚本维护优先级。平台的价值取决于它肚子里用例的质量而不是它能跑多快。最后再分享几点我的个人体会这套平台做下来最让我有成就感的不是某一个大模型能力有多强而是整个团队使用测试能力的方式被改变了。过去测试同学问人“这台设备怎么跑”现在发一句自然语言就能搞定过去结果要等人工汇总现在自动进群过去失败要凭记忆重跑现在每次执行都有完整现场。如果你也想做类似的平台我真心建议从一条最窄的链路开始哪怕先不支持多设备、不支持复杂编排就先把“聊天框发一句话、跑一遍冒烟用例、结果推回来”做踏实。两周后让人用起来再根据反馈逐步加深度。让AI Agent参与进来的时候记得用确定性兜底不确定性工具查询先行、任务中心硬校验、所有结果可回溯。我在实际使用中还发现这类平台的长期价值不在于跑的用例数而在于沉淀下来的数据和它如何反哺团队的测试决策。希望对你有帮助。