基于AI Agent与飞书机器人的车载HMI自动化测试平台实践

1. 为什么做这套平台：车载HMI自动化测试的痛点与目标

车载HMI自动化测试这个事儿，做过的人都知道痛在哪：一个中等规模的智能座舱项目，光蓝牙、导航、语音、仪表这几个域的回归测试，手工点下来就是好几个小时，更别提多工况组合。我们团队当时正好卡在这个节点上——测试用例不少，人不够用，反馈链路又长。后来我们决定自己搭一套：飞书机器人当入口，AI Agent当大脑，把车载HMI自动化测试平台整个串起来。这篇文章就是我落地这套平台时的一些真实记录，从架构设计到踩坑细节都放在里面，给正在做同类平台的团队一点参考。

先说痛点。车载HMI测试和普通App测试有个很大的不同——被测对象往往不是一台手机，而是一整块仪表、中控、甚至带HUD的座舱域控制器。跑一条用例可能要先上电、握手、切到特定显示模式，再操作几步，最后还要截图取证。手工测试最耗时的不是“点那一下”，而是前置准备、环境切换、结果确认这三件事。单个用例五分钟，两百条用例就是一个测试工程师一整天的量。而测试工程师真正值钱的技能是分析问题、定位根因，不是重复劳动。

另一个痛点是信息断层。测试结果往往散落在Jenkins、测试机日志、Excel报表里，研发想看结论，得去翻平台、翻邮件、翻群聊天记录。我们内部日常沟通都在飞书，每天不知道有多少个“那个XX用例过了没”的问题。如果能让测试平台主动把结果推送到群里，甚至让研发直接在群里发起一轮测试，整个反馈链路就能缩短一大截。

所以这套平台的目标很明确：把“发起测试 → 调度执行 → 结果分析 → 报告推送”这条链路，全部收口到飞书机器人这一个入口里，并用AI Agent把自然语言的测试需求翻译成可执行的测试任务。后续所有设计都是围绕这条链路展开的。

1.1 车载HMI测试到底难在哪

车载HMI测试的难，和普通Web测试完全不同。我们项目里遇到最头疼的几个问题：

第一是环境复杂。被测对象是台架上的域控制器，要模拟CAN总线信号、整车电源时序、外部音源输入，每次测试前都要确认设备状态。设备没上电、总线没唤醒、屏幕进不了主界面，这些情况经常出现，而且往往是测试失败的最大干扰源。

第二是执行不稳定。HMI测试天然依赖界面状态，当前在哪个页面、弹窗有没有挡住按钮、语音播报有没有打断操作，都会影响结果。自动化脚本写的时候好好的，第二天跑可能就挂了一半，不是脚本逻辑错了，是环境时序变了。

第三是结果判定难。一个页面显示是否正确，光靠截图不够，还要比对文字是否溢出、图标是否缺失、布局是否错位，有些还要结合CAN信号验证“显示值到底是不是真实值”。这已经不是传统的UI断言能覆盖的了。

第四是反馈链路长。测试平台跑完，结果在平台上，研发不一定看平台；就算看了平台，一堆原始日志和截图，也要花时间找重点。测试人员每天大量时间花在执行和汇报上，而不是分析质量风险。

这些痛点叠加在一起，就形成了一个很典型的场景：测试团队需要一条更智能、更自动、更接近自然交互的流水线。这也是我们决定引入AI Agent的根本原因——不是赶时髦，是真的需要用自然语言把“测什么、为什么测、怎么验”讲清楚。

1.2 为什么是飞书机器人，以及为什么需要AI Agent

选飞书，说穿了是三个字：离得近。研发、测试、项目经理日常都在飞书群里，把测试入口放在IM里，学习成本几乎为零。不需要教大家“去平台点按钮”，在群里@一下机器人就行。飞书本身也提供了完善的企业自建应用、消息卡片、事件订阅能力，技术接入成本可控。

但传统的IM机器人有个通病：只能做“命令触发”。你写死几个指令，比如/run smoke、/run regression，研发必须记指令、记参数、记格式，本质上还是把平台操作搬到了IM里，用户体验没有质变。

AI Agent解决的是这一层的问题。它让机器人从“指令执行器”变成“需求理解器”。研发在群里说一句“帮我跑一遍蓝牙电话的冒烟，然后出一份结果摘要”，Agent自己拆解出测试范围、用例筛选条件、执行策略、报告格式，再调用平台工具去执行，最后把结论推回群里。

这里有个很容易误判的点：AI Agent不是必须的。如果你们团队只有几十条固定用例，写命令就够了。但我们的用例有几千条，涉及多个测试域，不同研发关注点又不一样，纯命令式机器人根本维护不过来。引入Agent之后，测试入口从一个命令字典变成了一个可以对话的工程助手，这是质的变化。

2. 整体架构设计：从IM入口到测试执行再到结果闭环

这套平台的整体架构，我在设计时把它拆成五层：交互层、Agent层、调度层、执行层和数据层。每一层只做自己的事，层与层之间用明确的API契约通信。这个分层看起来不复杂，但每一层都踩过不少坑，后面会详细讲。

交互层就是飞书机器人，负责收发消息、渲染卡片、处理用户点击回传。Agent层是大脑，负责理解用户意图、规划步骤、调用工具。调度层负责把Agent产生的测试任务转换成真正可执行的作业，管理队列、并发和重试。执行层是落地的手脚，跑的是真正的车载HMI测试脚本，操作真实的设备或台架。数据层把用例、结果、日志、截图这些沉淀下来，供平台和Agent查询。

这个架构有几个设计原则，我觉得比选型更重要：

第一，Agent不直接碰设备。Agent的职责是“理解需求并拆分任务”，真正操作设备的是调度层和执行层。这样即使Agent偶尔幻觉乱调工具，也不会直接搞坏一台测试机。所有Agent能调用的工具，都在调度层包了一层权限控制。

第二，消息链路和任务链路分离。飞书消息走一条链路，测试任务走另一条链路。Agent发起一个测试任务后，任务在调度层排队执行，Agent不阻塞等待，而是通过回调或者主动查询拿结果。这个异步设计一开始就定了，否则飞书回调超时会让你痛不欲生。

第三，一切可追溯。Agent的每一轮思考、每一次工具调用、每个任务的执行日志，全都落库。这个在排查“为什么Agent会给出这个结论”时太重要了，AI系统的黑盒问题只能用日志来对抗。

2.1 平台分层与核心模块

具体看一下每一层的核心模块。

交互层主要是飞书自建应用机器人。我们用的是长连接模式，而不是HTTP回调，原因很简单：测试平台部署在内网，没有公网地址，用长连接可以让飞书主动连过来，省掉网关和反向代理这一堆事。权限配置上只需要机器人发消息、接收群消息、卡片回调这几项。消息进来之后，统一走一个消息管道，先做简单的消息过滤（只处理@机器人的消息、不在特定群的消息直接忽略），再进Agent层。

Agent层是整个平台的大脑，核心是一个大模型驱动的Agent运行时。我们基于Function Calling模式做了个Tool Registry，Agent能调什么工具、工具参数长什么样，全部注册在案。同时配置了一个System Prompt，把Agent的角色定义为“车载HMI测试助手”，并告诉它工具的使用规则、常见坑、以及哪些问题需要转人工。

调度层做两件事：一是把Agent的“自然语言任务”解析成具体的测试任务，比如“跑一遍蓝牙电话冒烟”会被解析成执行某几个测试套件；二是管理执行队列，控制并发，做失败重试和超时熔断。调度层不关心测试用例具体怎么写的，它只负责把作业发下去、把状态收回来。

执行层是真正跑测试的地方。我们基于Python做了一套测试执行器，管理着几台车载HMI测试台架和模拟环境，执行器启动后向调度层注册心跳，接收任务后开始跑测试脚本，实时上报状态和日志。这里最关键的是设备池管理——哪个设备空闲、哪个设备被占用、哪个设备掉线了，必须实时可见，否则任务发到一个坏设备上就是一次无效执行。

数据层比较简单，就是MySQL加对象存储。MySQL存用例元数据、任务记录、Agent的操作日志；对象存储放截图、日志文件、测试报告。Agent需要分析历史结果时，通过一个查询工具读MySQL，需要看截图时，通过工具生成一个临时链接。

2.2 核心链路：一次对话式测试请求的完整流转

我拿一个实际场景把整个链路串一遍。研发在群里发了一句：

“帮我在XX车型上跑一遍蓝牙电话的冒烟用例，重点关注通话质量和连接稳定性。”

这句话发出去之后，发生了这些事：

飞书机器人通过长连接收到消息，先确认这是@机器人的消息，然后原样交给Agent服务。Agent服务把这条消息连同群聊上下文一起发给大模型，大模型通过Function Calling识别出用户意图，决定调用list_test_suites工具查询可用的蓝牙电话冒烟套件。

拿到套件列表后，Agent再调用create_test_task工具，参数是车型、测试套件ID、执行优先级。这一步不会直接执行，而是在调度层创建了一个任务记录，返回一个任务ID给Agent。

Agent得到任务ID后，在群里回复一条消息卡片：“已为你创建蓝牙电话冒烟测试任务，任务ID是TS-20240601-001，预计执行时间15分钟，完成后我会推送报告摘要。”

调度层看到新任务后，检查设备池，挑一台空闲的测试台架，把任务派发给对应的执行器。执行器启动测试脚本，跑完所有用例后，把结果、截图、日志回传给调度层，调度层更新任务状态，并触发报告生成。

报告生成后，Agent收到任务完成通知，调用query_test_result工具拿关键数据，然后生成一条摘要消息主动推送到群里。摘要里包含通过率、失败用例列表、失败截图链接，以及Agent给出的一句话质量结论。研发看到后就可以直接点进链接看详细日志了。

这条链路全程不需要任何人去打开测试平台网页，全程都在飞书群里完成。从“发起”到“拿到结论”，中间所有环节都自动化了。真正实现了“用聊天的方式做测试”。

2.3 为什么不能跳过Agent直接走机器人指令

我见过不少团队做类似的平台，第一版都是纯命令式机器人：用户发/test bluetooth_smoke，机器人触发脚本，跑完回结果。我承认这种方式简单直接，也能解决一部分问题，但它有几个硬伤：

一是命令泛滥。测试域一多，命令就爆炸。每个域、每种测试类型，甚至每个车型参数都要定义一套命令，用户根本记不住。最后变成文档写了一堆，大家还是只敢用那两三条命令。

二是参数语义混乱。同样一个“蓝牙电话冒烟”，研发嘴里说出来的可能是“帮我测一下蓝牙电话好不好使”，也可能是“跑蓝牙电话的冒烟套件”，还可能是“查一下昨天蓝牙电话的结果”。这些表述在命令式机器人里没法统一处理，但AI Agent能。

三是结果反馈太机械。命令式机器人只能把原始结果原样丢出来，用户还是得自己看、自己分析。Agent可以在分析之后给出一句人话结论——“蓝牙电话冒烟整体通过，但车机侧音频路由切换到蓝牙通道时出现一次卡顿，建议重点检查A2DP连接稳定性”，这才是研发真正想要的信息。

所以我的观点是：如果你的平台只是做“遥控器”，命令式机器人就够；如果你希望平台成为“助手”，AI Agent才值得投入。我们这个项目后者的属性和价值明显更大。

3. 飞书机器人接入与交互设计

飞书机器人这一层，看着是个小模块，实际上细节特别多。机器人接入得好不好，直接决定用户愿不愿意用这个平台。我从创建应用、消息收发、卡片交互三个维度讲讲落地的关键点。

3.1 机器人创建与消息接收：长连接模式的选择

飞书开放平台创建企业自建应用，过程不复杂，但有几个权限点要选对。我们需要的权限主要是：读取群消息、发送群消息、接收卡片回调。其中接收消息事件建议申请im:message.group_at_msg（接收群聊中@机器人消息），这样群成员只有@机器人时平台才会收到消息，不会打断正常群聊。

事件订阅有两种模式：HTTP回调或长连接。HTTP回调需要公网可达的HTTPS地址，我们内网环境没有，所以选了长连接。飞书长连接本质上是一个WebSocket订阅，SDK（feishuPython SDK）会维持连接并接收事件推送，使用上很简单。长连接模式有一个隐藏好处：不会因为回调超时被飞书重试。HTTP模式如果服务端处理超过3秒，飞书会重试推送同一事件，容易造成重复消费。我们基于长连接做幂等，压力小了很多。

事件处理上有一个容易踩坑的点：飞书推送的消息事件是加密的。配置里设置了Encrypt Key之后，所有回调payload都需要先解密才能拿到实际内容。SDK里提供了封装，但如果你是自己实现协议解析，别把加密数据当正文处理，我见过不止一个人在这个地方被卡住半天。

收到消息后，优先级最高的一件事是“过滤”。群里可能同时有大量消息，但我们只关心两种：@机器人的、以及用户在机器人对话窗口发来的。其他消息直接丢弃，不进入Agent，避免无关信息污染Agent的上下文。

3.2 表格消息怎么发：三种方案对比

“飞书机器人发送表格”这个话题，网上讨论度很高，因为实际使用中确实高频。用户说“给我一份昨天的蓝牙测试结果”，Agent要回复的就不应只是一段文字，而是一张清晰的表格。表格数据落地到飞书，我用下来有三种可行方案。

方案一是消息卡片里的Markdown表格。飞书卡片支持Markdown语法，但表格渲染效果一般，列多的时候会挤成一团，手机上阅读体验很差，只适合少量几行的简单表格。

方案二是上传文件后发送文件消息。用openpyxl生成.xlsx文件，调用飞书上传文件接口拿到file_key，然后发送文件消息。优点是可以带格式、带颜色、带统计行，用户在飞书里点开就能看，还可以直接下载。缺点是看数据要一步“打开文件”的操作，不如直接在消息流里直观。

方案三是把表格渲染成图片，发送图片消息。我们实际大量用的是这个方式。用matplotlib或plotly把表格画出来，调整好列宽和字号，生成PNG，上传后发送。飞书消息流里直接展示，手机和PC都能看，视觉效果比卡片好得多。缺点是图片里的文本不能复制，所以我们的做法是：结论文字走文本消息，明细数据走图片或文件，两者搭配发送。

给Agent增加一个“发送表格”工具时，实际包含一个上传动作。飞书的图片消息需要先上传图片拿到image_key，再走发送接口。这里要注意上传大小限制，飞书图片上限是10MB，表格截图一般不会超，但如果你把整个月的测试详情渲染成一张大图，记得先做压缩和分页。

3.3 交互闭环：卡片回调与人工确认

机器人不只是“发消息”，还要能“收操作”。比如Agent准备跑一轮全量回归测试，这个操作比较重，会影响其他团队正在用的测试设备，应该让用户在点“确认执行”之后才真正开始。

飞书卡片支持按钮交互。我们在消息卡片上放两个按钮：“确认执行”和“取消”。用户点击后，飞书会触发card.action.trigger回调事件，事件里携带了卡片上设置的value。这个回调我们同样处理成Agent的输入——Agent看到“确认执行”这个动作，才真正调用调度层工具。

设计这里的核心是两套消息要分清楚：普通消息和卡片回调。卡片回调不经过群消息事件，而走独立的回调入口。长连接模式下，飞书SDK会自动把卡片回调和普通的im.message.receive_v1事件分开，我们分别注册处理函数就行。

还有一个小坑：卡片按钮的value是字符串形式的结构化数据，用JSON序列化后塞进去的。回调回来时要反序列化并做容错处理，否则一个格式错误就会让整个回调处理崩溃。另外，卡片回调一定超时限制，需要在消息里带上任务ID，幂等处理，否则用户手快点了两次，任务就被创建了两遍。

4. AI Agent 核心设计与实现

AI Agent是这套平台的大脑，也是我们投入精力最多、踩坑最深的一部分。从架构选型到工具设计，再到Prompt编排和成本控制，里面值得记录的东西非常多。

4.1 Agent 架构选型：主流方案怎么选，我们最终用了什么

“AI Agent主流架构”这个话题，我讲一下我们在项目里做选型的真实思考。

当前Agent的架构，比较主流的有三类。第一类是ReAct模式，让模型循环思考“Thought → Action → Observation”，自己决定下一步做什么。第二类是Function Calling模式，模型根据工具描述直接产出结构化的调用请求，平台负责执行并返回结果，交替进行。第三类是Plan-and-Execute模式，模型先生成完整计划，再逐项执行。

我们最终选了Function Calling为主、ReAct思想为辅的混合方案。为什么？因为测试平台的工具调用是相对固定的，就那十来个工具，函数签名清晰，Function Calling有很高的工具选择准确率。同时我们在System Prompt里引导模型“先确认环境再执行、拿不到结果要重试、最终给出结论”，这实际上是ReAct的思考逻辑，但具体动作由Function Calling完成。

另外要说的一个趋势是：现在很多Agent框架（LangGraph、AutoGen、MetaGPT）都在往多Agent方向发展，但我们的结论是——在工程任务场景，单Agent加工具集往往比多Agent更稳。多Agent的好处是角色分离，但代价是上下文膨胀、通信成本高、整体延迟变大。测试平台上，一个任务链路并不复杂，单Agent串起来完全够用，出错面还更小。

Rust写Agent这个话题，我们也关注过。Rust的高性能和低资源占用确实是优势，适合做Agent运行时层面，但Agent本质上是大模型调用的编排，性能瓶颈在模型响应而不在代码语言。我们的Agent服务用Python写的，迭代速度快。如果未来需要做高并发的Agent网关，用Rust包一层会是不错的方向，现阶段没必要为了语言特性增加团队维护成本。

4.2 工具集设计：Agent 到底能调用什么

Agent的能力边界，完全由工具集决定。设计工具集时我有一条原则：工具要少而精，粒度要适中。粒度太粗，Agent没有灵活性；粒度太细，调用链太长，出错概率上升。

我们最终给Agent暴露了这几个工具：

• list_device_status：查询当前测试设备状态，返回各台设备的在线、空闲、占用信息。
• list_test_suites：按测试域/车型/关键字查询测试套件，返回套件ID、名称、预估时长。
• get_suite_detail：查看某个测试套件的用例列表、前置条件、是否适配当前车型。
• create_test_task：创建测试任务，参数包括套件ID、设备偏好、优先级、超时时间。
• cancel_test_task：取消排队中或执行中的任务。
• query_test_result：按任务ID查询执行结果，返回通过率、失败用例、耗时分布。
• get_failure_detail：获取失败用例的日志、截图链接、断言信息。
• search_test_history：按时间范围和关键字查询历史测试记录，供Agent做对比分析。
• send_report_to_group：生成报告摘要消息推送到指定群。

每个工具在实现时都定义好JSON Schema的入参和出参。出参有一个注意点——返回给模型的内容不要太长。比如query_test_result如果返回500行原始测试日志，模型上下文很快就爆了。我们的做法是做摘要：返回前端展示用的统计信息，再通过get_failure_detail按需取详细日志。

工具调用的容错也很重要。Agent可能传入一个不存在的套件ID，也可能在测试设备全部被占用时要求立即执行。每个工具都要在异常时返回一条明确的错误信息，告诉Agent“为什么失败，怎么修正”。这一步直接决定了Agent的鲁棒性。我们经常看到一些Agent项目，工具调用一次失败后，模型就开始一本正经地编造结果，就是因为错误信息不够结构化。

4.3 Prompt 编排与上下文管理

Agent的Prompt设计，我把它分成三个部分：系统提示词、工具描述、对话历史管理。

系统提示词定义Agent的角色、能力边界和输出规范。我们的System Prompt包含这些关键信息：Agent是车载HMI测试助手，必须基于工具结果说话；不编造测试结论；创建任务前要确认设备状态；任务完成后必须主动推送消息；如果用户请求超越能力范围，明确告知并推荐人工介入。

工具描述不要只写“这个工具的用途”，要写清楚使用时机和常见坑。比如create_test_task的描述里我们会写：“创建测试任务之前，建议先调用list_device_status或list_test_suites确认设备可用性和套件编号；如果用户未指定车型，默认使用上次使用的车型。”

对话历史管理是另一个关键点。飞书群里消息很多，如果全部塞给Agent，一是token很快爆掉，二是无关消息会影响Agent判断。我们的做法是：只保留与Agent相关的消息（@机器人的、机器人的回复、以及用户明确的追问），并按时间窗口裁剪；超过上下文窗口时，优先丢弃旧消息，只保留最近几轮对话。对于需要长期记忆的信息（比如用户关注的测试域、常用车型），单独存到一个KV存储里，每次构造上下文时回填，不依赖大模型上下文窗口。

还有一个小技巧：在对话历史里标注消息来源和消息时间。比如群聊里的消息，加上“[群聊 17:04]”；Agent自己的回复，加上“[Bot]”。这样模型在理解对话时，不会把两个不同角色的消息混在一起。

4.4 Token 是什么，以及怎么控成本

“AI Agent token是什么意思”这个问题，团队里不少人都问过。Token是大模型处理文本的最小单位，简单理解就是模型计费的“字数”。中文场景下一个Token大概对应一个字，英文大概是半个到一个单词。一次Agent对话，系统提示词、工具描述、对话历史、模型输出，每一个部分都要消耗Token，加在一起就是一次请求的总Token数。

Token成本是Agent项目上线后最先暴露的问题。我们第一版上线时没有做任何控流，结果一个完整的测试请求流程，从接收消息到输出最终结论，可能消耗3万到5万Token。如果每天跑几十个请求还能接受，一旦团队用得频繁，账单增长非常快。而且Token不只是钱，还决定了响应延迟——上下文越长，模型首字延迟越大。

控成本我从几个方向做。第一，精简System Prompt，只保留必要信息；第二，工具描述压缩，用一句话讲清楚功能，不要冗长；第三，对话历史按窗口裁剪，绝不能无限累积；第四，结果摘要化，给模型的结果数据尽量短，必要时分步取；第五，按群按用户设置频率限制，避免一个用户反复刷接口。

还有一个点：模型用量要做分级路由。简单意图（比如查历史结果）走便宜的小模型，复杂意图（比如跨域综合分析）走大模型。用一套轻量意图识别先行分类，可以明显降低整体成本。这是我们上线第二个月做的优化，效果非常直接。

5. 车载HMI自动化测试平台的落地细节

AI Agent把“自然语言”翻译成了“测试任务”，但任务最终要落到真实的被测设备上跑起来，这些才是整个平台真正“硬”的地方。Agent再聪明，如果执行层不稳定，整个平台就是个花架子。

5.1 设备管理与测试框架改造

车载HMI的测试对象，在我们项目里主要是两种：一种是台架环境，由域控制器、屏幕、CAN盒、电源模拟器组成；另一种是仿真环境，用模拟器或者硬件在环（HIL）跑测试。真机和台架的高度差异，决定了不能一套测试脚本通吃。

我们做设备管理层时，给每个设备定义了一个虚拟“插槽”，至少包含：设备ID、设备类型、当前状态（在线/离线/空闲/占用中）、支持的测试域（蓝牙/导航/语音等）、分辨率参数、连接方式。执行器启动时向调度层注册插槽，每隔10秒上报心跳。调度层下发任务时，先根据任务要求的测试域匹配设备，再进行锁定，任务结束后释放。

测试框架选型上，我们基于pytest包装了一层车载HMI通用的执行器。为什么不用现成的UI测试框架直接跑？因为车载HMI场景有很多领域特定操作：电源时序控制、CAN信号模拟、音源切换、HUD亮度测试，这些都需要通过底层接口去驱动，而不是简单的坐标点击。执行器里封装了一整套vehicle_adapter接口，统一了不同设备的操作方式，测试用例面向接口写，不关心底层是台架还是仿真环境。

执行器还有一个重要职责是“恢复现场”。每条用例跑完后，自动复位到主界面，清掉弹窗和临时状态，保证下一条用例的初始条件干净。这个看起来不起眼，实际是稳定性的最大功臣。很多自动化平台挂用例，挂的不是用例逻辑，是上一条用例遗留的脏状态。

5.2 任务调度：并发、排队和资源锁定

调度层需要考虑的问题，用一个字概括是“锁”。

同一个测试设备在同一时间只能跑一个任务，这是硬约束。如果并发控制没做好，两个任务同时操作一台设备，结果一定是双双失败，而且失败原因最难排查。我们实现了一个带优先级的任务队列：调度层不直接下发任务到执行器，而是先入队，由调度进程根据设备可用情况和任务优先级决定下一步。高优先级的冒烟测试可以插队，但全量回归这种长任务不能一直被插队，所以在队列里设置了“最大等待时长”，超时后就禁止再被插队。

任务超时处理也很关键。一个测试任务跑挂了，执行器可能一直卡在某条用例上，整个设备就被占死。我们给每个任务设置了执行超时时间，超时后调度层会下发“中断”指令，执行器杀掉子进程，复位设备状态，并把任务标记为失败。虽然丢失了一次执行机会，但保住了设备的可用性，比硬等要好得多。

结果回传的一致性同样要处理。执行器跑完任务后，把结构化结果写到数据库，同时生成一份报告对象存到对象存储。调度层通过数据库状态变化感知任务完成，不依赖执行器主动回调HTTP——因为执行器可能已经被杀掉，回调不可靠。这也是我们踩过坑之后改成的方案。

5.3 报告生成与自动推送

结果报告是研发同学最关心的部分。Agent在群里推的摘要，背后是完整的报告生成链路。

我们生成报告分三个层次。第一层是执行摘要，包含任务ID、测试套件、车型、执行时间、通过/失败/阻塞用例数、总通过率。第二层是失败明细，逐条列出失败原因，关键失败附带日志片段和截图缩略图。第三层是原始数据，提供完整的日志文件和截图目录下载链接。

报告生成用pytest-html做基础模板，再定制化增加车载HMI的专属信息块，比如设备型号、车机系统版本、CAN信号状态。每一层报告生成完后，都存一份到对象存储，同时把一个短链接发给Agent，Agent在群里回复摘要时带上这个链接。

自动推送的策略是“主动说结论，按需看细节”。Agent推送到群里的内容，一定是一句话概括性结论加关键指标，从来不会把整份报告贴进群里。需要看细节的人，点链接看详细报告。这里要强调一点：推送的时机也很有讲究。执行完成后立即推送最好，但如果任务排队排了半小时，用户可能早就不在群边了。我们的做法是：任务开始前推送一条“已开始执行”的轻量通知，完成后推送正式报告，让用户对整个生命周期有预期。

6. 踩坑记录与上线建议

最后这部分，我把实际落地中遇到的高频问题整理成一张速查表，再分享几条沉淀下来的建议。这些问题个个都真实存在，如果你也在做类似平台，大概率也会遇到。

6.1 常见问题速查表

这里面最折磨人的其实是“Agent编造结论”。AI的幻觉问题在测试领域特别致命，一旦编造了一个“测试通过”的假结论，整个平台的可信度瞬间归零。我们最后的解法不只是Prompt约束，还在代码层加了硬校验：Agent在回复中引用的任务ID和结论，必须能在数据库里找到对应记录，否则不让发送。技术可以激进，质量把关必须保守。

6.2 上线路径与几条实在建议

如果你们也要做类似的平台，我给三条落地的路径建议。

第一条：先小后大，先命令后Agent。不要一上来就追求AI Agent全自动。第一阶段，先把飞书机器人和测试执行链路跑通，用几个固定命令让大家用起来，建立信任。第二阶段，引入Agent，先把Agent定位为“命令的翻译官”，它把自然语言翻译成固定的命令模板，再执行。第三阶段，才放开Agent的自主规划能力。我们当时是把这个时间线压到了三周，结果踩坑比预期多，现在回头看应该放慢一点。

第二条：Agent可观测性一定要优先做。不要只关注“Agent能不能完成任务”，更要关注“Agent是怎么完成任务的”。每一步思考、工具调用、入参出参都要有日志。否则Agent在一次测试任务里连续调用了十次工具，最后一次出来个奇怪结果，你根本不知道中间发生了什么。我们上线第一周就被研发提了一堆“Agent为什么这么判断”的问题，全靠日志才能回答。

第三条：权限和安全边界想清楚再动手。Agent能操作的测试任务，要有一个明确的“危险等级”。创建冒烟测试这种低风险任务可以自动执行；全量回归、设备固件刷写这种高风险操作，必须人工确认。实际操作中，我给Agent加了一个“危险操作”标签，命中这个标签的任务一律在飞书卡片上等待人工确认，杜绝Agent自主执行高风险动作。

回头来看，这套平台的价值不在于“用了AI”这个噱头，而在于真正把车载HMI测试的反馈链路压缩到了分钟级。研发在群里问一句就能拿到测试结论，测试人员从重复执行里解放出来去做更有价值的用例设计和问题分析，Agent在其中承担了“翻译官+调度员+报告员”的角色。我个人最大的体会是：AI Agent工程化落地，难点从来不是大模型本身，而是工程系统的稳定性、可控性和可观测性。把这些做好了，所谓“智能”才有承载的底座。