尧图网站建设 
飞书机器人 × AI Agent：一套车载 HMI 自动化测试平台的架构设计与落地在飞书群里 @ 一下机器人，说一句"跑一轮发版冒烟"，30 分钟后一份带完整证据链的发版测试报告就私聊发回来了——这不是畅想，是我们目前正在运行的日常。本文分享这套"飞书机器人 + AI Agent"自动化测试平台的架构设计、核心模块实现，以及我们在落地过程中踩过的坑。前言：车载 HMI 测试到底难在哪车载 HMI（人机交互界面）项目的测试，有几个很"拧巴"的特点：被测对象是 3D 渲染应用。界面跑在车机上的引擎里，“对不对"很大程度是视觉层面的——控件树断言、单点图像识别都很难回答"这帧画面看起来是否正常”，我们最终采用录屏 + 逐帧视频对比作为核心回归手段。发版节奏快，每轮都要全量冒烟。拉包 → 推包到多型车机 → 批量执行用例 → 录屏 → 视频对比 → 出报告，一轮下来人工盯守要两三个小时。需求变更频繁且"伤及无辜"。一个看似人畜无害的需求——比如新版本 UI 右下角加了一个水印——就能让全部视觉基线瞬间失效，一夜之间所有用例"集体 FAIL"。证据链要求高。每一个 FAIL 结论都要能拿得出录屏、截图、差异对比图；报告要可归档、可追溯，发版评审时经得起追问。传统做法的两个极端都有问题：方案优点死穴全人工执行灵活、能兜底一轮 2~3 小时，人被钉在设备前纯脚本/CI 流水线快、无人值守规则写死，需求一变基线全崩；FAIL 了分不清是环境问题还是真缺陷，脚本维护成本高我们的思路是：让 AI Agent 当自动化的"大脑"，让飞书机器人当"嘴和手"——人只做判断和确认，其余的交给 Agent。这里说的 AI Agent 是 Codely CLI（团结引擎推出的命令行 AI 编程助手）：它能读写本地工作区、执行 Shell 命令、调用各类内部 API，并且支持用 Markdown 文档沉淀"程序性经验"（官方叫法是 Skill 技能），每次任务开始时自行读取相关技能按流程执行。换句话说，它不是聊天机器人，是一个能真正动手干活的进程——这一点是整个平台成立的前提。一、平台总体架构先上全景图：整个平台分五层：层组成职责① 触发入口层飞书群聊 / 私聊测试、开发同学用自然语言下达任务② 接入网关层消息中台（Node.js 服务）飞书长连接接入、会话管理、卡片渲染③ AI Agent 层Codely CLI 工作区任务规划、经验调用（技能库）、工具执行④ 自动化执行层车机设备集群、测试执行平台、对象存储推包、用例执行、录屏、产物存取⑤ 数据与资产层Run 证据目录、回归基线库、报告知识库证据链留存、基线管理、报告归档1.1 三个关键架构决策决策一：WebSocket 长连接，不要公网 Webhook。飞书事件订阅有两种模式：Webhook 回调（需要公网可达的服务器）和 WebSocket 长连接（客户端主动连飞书，不需要公网）。我们选后者：测试机、车机设备全部在内网，长连接模式让整套平台完全私有化部署、零公网暴露，不用申请公网 IP、不用内网穿透，还规避了回调伪造问题。一个测试同学的工作机就能跑起整套网关。决策二：话题（Thread）内回复 + 单卡片。所有回复——群聊和私聊都一样——都收拢在话题内，而且只发一张最终结果卡片，不发"思考中"之类的中间卡片。原因很简单：一轮冒烟要几十分钟，中间刷一串"正在执行第 N 步……"没有任何信息量，只会淹没群里的正常沟通。话题化之后，“一个任务 = 一个话题”，上下文天然连贯，几天后回溯当时的执行过程也很方便。决策三：不把流程写死在代码里，把"经验"沉淀成技能文档。不同车机平台的推包方式、拉起方式、各种环境坑（哪台设备网络 ADB 要主动 connect、哪类视频段从私有目录拉取必损坏、哪台设备起前台 Service 会触发系统依赖不匹配崩溃）——这些都是经验，而且一直在变。写成 if-else 是死路：每踩一个新坑都要发版改代码。我们的做法：用结构化的**技能文档（SKILL.md）**描述"做一件事的完整流程"；用结构化**记忆（CODELY.md）**记录"长期有效的事实与教训"；Agent 每次任务前自行读取相关技能与记忆，按文档流程执行。新坑出现时，更新几行 Markdown 就完成"代码升级"。二、接入层实现：机器人怎么"接住"一句话2.1 WebSocket 长连接接入飞书官方 SDK（@larksuiteoapi/node-sdk）原生支持长连接模式，接入代码非常短（脱敏简化）：import*aslarkfrom'@larksuiteoapi/node-sdk';constwsClient=newlark.WSClient({appId:process.env.FEISHU_APP_ID,appSecret 飞书机器人 × AI Agent：一套车载 HMI 自动化测试平台的架构设计与落地
飞书机器人 × AI Agent：一套车载 HMI 自动化测试平台的架构设计与落地在飞书群里 @ 一下机器人，说一句"跑一轮发版冒烟"，30 分钟后一份带完整证据链的发版测试报告就私聊发回来了——这不是畅想，是我们目前正在运行的日常。本文分享这套"飞书机器人 + AI Agent"自动化测试平台的架构设计、核心模块实现，以及我们在落地过程中踩过的坑。前言：车载 HMI 测试到底难在哪车载 HMI（人机交互界面）项目的测试，有几个很"拧巴"的特点：被测对象是 3D 渲染应用。界面跑在车机上的引擎里，“对不对"很大程度是视觉层面的——控件树断言、单点图像识别都很难回答"这帧画面看起来是否正常”，我们最终采用录屏 + 逐帧视频对比作为核心回归手段。发版节奏快，每轮都要全量冒烟。拉包 → 推包到多型车机 → 批量执行用例 → 录屏 → 视频对比 → 出报告，一轮下来人工盯守要两三个小时。需求变更频繁且"伤及无辜"。一个看似人畜无害的需求——比如新版本 UI 右下角加了一个水印——就能让全部视觉基线瞬间失效，一夜之间所有用例"集体 FAIL"。证据链要求高。每一个 FAIL 结论都要能拿得出录屏、截图、差异对比图；报告要可归档、可追溯，发版评审时经得起追问。传统做法的两个极端都有问题：方案优点死穴全人工执行灵活、能兜底一轮 2~3 小时，人被钉在设备前纯脚本/CI 流水线快、无人值守规则写死，需求一变基线全崩；FAIL 了分不清是环境问题还是真缺陷，脚本维护成本高我们的思路是：让 AI Agent 当自动化的"大脑"，让飞书机器人当"嘴和手"——人只做判断和确认，其余的交给 Agent。这里说的 AI Agent 是 Codely CLI（团结引擎推出的命令行 AI 编程助手）：它能读写本地工作区、执行 Shell 命令、调用各类内部 API，并且支持用 Markdown 文档沉淀"程序性经验"（官方叫法是 Skill 技能），每次任务开始时自行读取相关技能按流程执行。换句话说，它不是聊天机器人，是一个能真正动手干活的进程——这一点是整个平台成立的前提。一、平台总体架构先上全景图：整个平台分五层：层组成职责① 触发入口层飞书群聊 / 私聊测试、开发同学用自然语言下达任务② 接入网关层消息中台（Node.js 服务）飞书长连接接入、会话管理、卡片渲染③ AI Agent 层Codely CLI 工作区任务规划、经验调用（技能库）、工具执行④ 自动化执行层车机设备集群、测试执行平台、对象存储推包、用例执行、录屏、产物存取⑤ 数据与资产层Run 证据目录、回归基线库、报告知识库证据链留存、基线管理、报告归档1.1 三个关键架构决策决策一：WebSocket 长连接，不要公网 Webhook。飞书事件订阅有两种模式：Webhook 回调（需要公网可达的服务器）和 WebSocket 长连接（客户端主动连飞书，不需要公网）。我们选后者：测试机、车机设备全部在内网，长连接模式让整套平台完全私有化部署、零公网暴露，不用申请公网 IP、不用内网穿透，还规避了回调伪造问题。一个测试同学的工作机就能跑起整套网关。决策二：话题（Thread）内回复 + 单卡片。所有回复——群聊和私聊都一样——都收拢在话题内，而且只发一张最终结果卡片，不发"思考中"之类的中间卡片。原因很简单：一轮冒烟要几十分钟，中间刷一串"正在执行第 N 步……"没有任何信息量，只会淹没群里的正常沟通。话题化之后，“一个任务 = 一个话题”，上下文天然连贯，几天后回溯当时的执行过程也很方便。决策三：不把流程写死在代码里，把"经验"沉淀成技能文档。不同车机平台的推包方式、拉起方式、各种环境坑（哪台设备网络 ADB 要主动 connect、哪类视频段从私有目录拉取必损坏、哪台设备起前台 Service 会触发系统依赖不匹配崩溃）——这些都是经验，而且一直在变。写成 if-else 是死路：每踩一个新坑都要发版改代码。我们的做法：用结构化的**技能文档（SKILL.md）**描述"做一件事的完整流程"；用结构化**记忆（CODELY.md）**记录"长期有效的事实与教训"；Agent 每次任务前自行读取相关技能与记忆，按文档流程执行。新坑出现时，更新几行 Markdown 就完成"代码升级"。二、接入层实现：机器人怎么"接住"一句话2.1 WebSocket 长连接接入飞书官方 SDK（@larksuiteoapi/node-sdk）原生支持长连接模式，接入代码非常短（脱敏简化）：import*aslarkfrom'@larksuiteoapi/node-sdk';constwsClient=newlark.WSClient({appId:process.env.FEISHU_APP_ID,appSecret