飞书机器人 × AI Agent：一套车载 HMI 自动化测试平台的架构设计与落地
在飞书群里 @ 一下机器人，说一句\”跑一轮发版冒烟\”，30 分钟后一份带完整证据链的发版测试报告就私聊发回来了——这不是畅想，是我们目前正在运行的日常。本文分享这套\”飞书机器人 + AI Agent\”自动化测试平台的架构设计、核心模块实现，以及我们在落地过程中踩过的坑。
前言：车载 HMI 测试到底难在哪
车载 HMI（人机交互界面）项目的测试，有几个很\”拧巴\”的特点：
传统做法的两个极端都有问题：
| 全人工执行 | 灵活、能兜底 | 一轮 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 * as lark from \’@larksuiteoapi/node-sdk\’;
const wsClient = new lark.WSClient({
appId: process.env.FEISHU_APP_ID,
appSecret
