QA Agent：用 VLM + System 1/2 把自主测试做到生产级
LinkedIn 把「数字测试员」做到了 350 测试 / 30 分钟节奏，跨 iOS / Android / Web 持续跑。这篇拆它的运行时模型、多模型分工、golden dataset 评测基建——以及哪些数字被雇主品牌叙事回避了。
它实际在哪跑、谁调谁
别停在「它是个 agent」。大脑是远端 LLM，手脚是本地设备驱动，两者用一个 decision loop 串起来——System 1 旁路是整套架构的成本命门。
调用链：设备驱动（截图 + view tree）→ Planner 模型（出自然语言指令）→ Grounding 模型（指令 → 像素坐标）→ 设备驱动（执行）→ Analytical Reasoner（评估变化 + 错误）→ 回到第一步。
三个 LLM 在云端
Planner（决策）/ Analytical Reasoner（慢思考）/ Fine-tuned Grounding（定位），按认知任务分工，不在端上跑。
本地设备驱动
截图、view tree 抓取、点击/滚动/输入——iOS/Android/Web 各一套，真机或模拟器。
System 1 旁路
稳定 case 走「记忆 signature → 本地比对 → 直接执行」，全程零 LLM 调用。只有 UI 变了才唤起重链。
核心架构拆解
所有工程细节都围绕「让重链尽量少跑」展开。下表是每个部件在做什么、关键权衡是什么。
| 部件 | 实际在做什么 | 关键设计权衡 |
|---|---|---|
| System 1 确定性回放 | 历史成功动作存成 signature（元素类型 + 一个 text 字段精确匹配）；命中即本地执行 | 严格匹配防误命中；只匹配一个 text 字段抗 i18n / A-B 变化 |
| System 2 视觉规划 | 截图 + view tree + 动作历史喂 Planner，输出自然语言指令，Grounding 落坐标 | 多模型分工而非单模型，每步可独立 swap / 实验 |
| Planner | 接收状态，输出结构化计划（主动作 + fallback + 完成判断 + 是否回溯） | 喂「最近 20 条成功指令」做 in-context bias |
| Analytical Reasoner | 错误检测、view tree 评估、bug 报告——逐步分析 | 和 Planner 分离：分析用更强模型，决策用更快模型 |
| Grounding（fine-tuned） | 截图 + 动作描述 → 像素坐标 | 自研 fine-tuned，最大复制壁垒 |
| 4 个 Evaluator | View Tree（有无变化）/ Tracking Log（埋点）/ Action History（走错路）/ Error Pipeline（两阶段过滤误报） | precision 优先于 recall，宁可漏报不可误报 |
| Golden Dataset | 录制 app state 快照；回放时拦截所有设备命令返回预录数据 | 把 agent 从「对抗 live 环境」变成「对抗录好的快照」 |
三个最值钱的机制
这三个才是你该从这篇文章带走的可复用框架，不是「VLM 能测 app」这个结论。
System 1/2 = 给 agent 加 L1 缓存
VLM 调用又慢又贵。把成功路径存成 signature 复用，只有 UI 变了才付钱。成本从 O(总动作数) 降到 O(变化量)。类比 CPU 的 L1 cache vs 主存计算。
多模型分工 = 认知任务解耦
不是一个 super model 干所有事，而是 planner（快）/ reasoner（准）/ grounding（专）三模型流水线。每步独立优化、独立评测、独立替换——agent 设计的默认模式。
Golden Dataset = agent 的单元测试
评测 agent 最大难题是环境非确定性。录制快照 + 拦截设备命令 + 动作比对 = mock/stub 在 agent 层的重生。三层粒度对应单元/集成/端到端。没有它，你不知道换 prompt 是变好还是变差。
手搓版 vs LinkedIn 版
周末 demo = Appium + GPT-4V + while 循环。能跑通，但慢贵脆且无法评测。LinkedIn 在这之上加了 6 层工程化——省的不是 AI 能力，是评测、成本、可靠性基建。
| 维度 | 手搓版（周末 demo） | LinkedIn 版 |
|---|---|---|
| 成本 | 每个 action 都调 VLM | System 1 缓存，稳定 case 零 LLM |
| 质量 | 单模型干所有事 | 三模型分工，每步用最优模型 |
| 可靠性 | 点了就点了，不管效果 | 4 个 evaluator 护栏 |
| 可评测 | 对着 live app 跑，结果飘 | golden dataset 录制-回放-比对 |
| 可迭代 | 换 prompt 靠手感 | 实验 planner shadow + golden 回放 A/B |
| 民主化 | 必须写代码 | no-code recorder + LLM 语义合成 |
选型决策框架
不是所有团队都该照搬。按你的场景判断该用全套、轻量版、还是 SaaS 替代。
| 场景 | 判断 | 理由 |
|---|---|---|
| 大型 app、多平台、UI 频繁变、有标注资源 | ✅ 用全套 | System 1 缓存收益大；grounding fine-tune 有数据支撑 |
| 小团队、稳定 UI、预算紧 | ❌ 别用 | fine-tune + golden 基建成本太高，ROI 负 |
| 只做 Web、DOM 稳定 | ⚠️ 轻量版 | 有 accessibility tree，grounding 用 DOM 定位，不必 fine-tune 视觉 |
| 强无障碍 / 合规要求 | ✅ 用 | 垂直 sub-agent 正好做 a11y 评测 |
| 需要嵌入 CI 阻断合并 | ⚠️ 先解决延迟 | 目前是 30 分钟 post-deploy，离 pre-merge gate 还有距离 |
压力测试：数字层要打问号
架构扎实，但这是雇主品牌文，选择性呈现了成功。学架构很值，别照搬「200 bugs」的规模暗示。
值得抄的（架构层）
- System 1/2 缓存思维——任何 agent 产品的成本护城河
- 多模型流水线——按认知任务分配模型，而非「我习惯用哪个」
- Golden dataset 评测——agent 工程化的分水岭
- 两阶段错误验证——precision > recall 的低成本设计
- No-code recorder + LLM 语义化——民主化的产品巧思
要打问号的（数字层）
- 200 bug 没分母——百万次 run 的命中率？valid 谁定义？
- System 1 命中率没给——成本命门，i18n/A-B 下会不会大量失配
- fine-tune 数据门槛回避——最大复制壁垒，也是 LinkedIn 最不愿讲的护城河
- 延迟没提——一个流程几分钟？能否进 CI gate？
- golden 新鲜度——app 变了 golden 就烂，维护成本谁出
这套系统真正的价值不是「VLM 能测 app」（已是行业共识），而是把评测基础设施做到了生产级。前者是 demo，后者才是工程——也是普通团队最难抄的部分。
给你的 4 个个性化洞察
QA 出身 + 做自己的 AI 产品 + 关注工具链——这套架构对你有 4 个直接落点。
缓存思维是成本护城河
做任何 agent，第一步问：哪些步骤输入稳定、可 signature 化缓存？这一步把 API 账单砍一个数量级。从 demo 到产品的必经路。
Golden dataset 是你的主场
测试金字塔是肌肉记忆——搬到 agent 上：录制-回放-比对。换 model/改 prompt 能量化好坏。这是你比纯算法创业者有优势的地方。
多模型流水线做默认
决策用便宜快的，分析用贵但准的，专精任务 fine-tune 小模型。按「认知任务类型」分配 model，不按「我习惯用哪个」。
precision > recall 铁律
bug 发现、code review、监控告警、自动化——主动报告类系统默认上两阶段过滤。一个假阳性比没系统更糟，因为侵蚀信任。
金句
慢一点可以。精度，一寸不让。
慢一点可以。但精度，一寸不让——一个报幽灵 bug 的 agent 比没用更糟，它侵蚀信任。
We optimize QA Agent for precision over recall, accepting that we might miss some issues in exchange for confidence that every reported bug is real.LLM 只在 UI 变了时才被调用。这是把推理成本从「按调用次数」变成「按变化频次」。
The LLM is only invoked when the UI has changed.评估对着捕获的状态回放，而不是 live app。这是 agent 工程化的分水岭。
Evaluations replay against this captured state, not the live app.