Quality Assurance Agent：用 AI 驱动的自主测试重塑软件质量
完整翻译
在 LinkedIn，保障移动端和 Web 应用的质量不只是技术挑战，更是对依赖我们平台的 13 亿会员的承诺。随着我们的生态扩展到覆盖 iOS、Android 和 Web、支持 36+ 种语言，再加上 agentic coding 工具带来的更高频变更，传统的质量保证（QA）方法开始触及天花板。
LinkedIn 的用户界面（UI）不是一个 app，而是成千上万种排列组合——用户类型、语言、会员等级、会员画像、活跃实验——每一种组合都创造一种不同的体验。这种复杂度是有代价的：如果没有持续的监控和调整，功能可能在不知不觉中退化（regress）。
我们通过员工测试和反馈抓住了其中一部分 bug。任何 LinkedIn 员工都可以摇一摇手机，从我们的 beta app 提交一份「Shaky」bug 报告。但靠人手动探索 app 是无法规模化的。我们需要一个能持续、自主做这件事的系统。
于是我们构建了一个 Quality Assurance (QA) Agent。我们没有做一个更好的脚本执行器，而是做了一个数字测试员。通过将生成式 AI 的推理能力与 Vision-Language Models（VLM，视觉语言模型）结合，我们创造了一个能够导航我们的 app、像人一样感知 UI、并在 iOS/Android/Web 应用上执行复杂端到端流程的自主 agent。
早期成果令人鼓舞。QA Agent 已经识别出超过 200 个有效 bug，并在影响营收的关键流程中抓住了回归。更重要的是，它为产品和工程团队的任何成员打开了用自然语言编写测试的大门，把质量从「只属于开发者的责任」转变为「共享的纪律」。
在这篇博客里，我们将分享 QA Agent 的构建方式、背后的架构决策，以及在 LinkedIn 移动和 Web 平台上规模化时学到的教训。
超越脚本：视觉语言模型
传统的测试自动化依赖僵硬的 selector 和隐藏的代码标识符，一旦底层实现变化就会失效。为了解决这个问题，我们转向了 Vision-Language Models。
与标准脚本不同，VLM「看」屏幕的方式和用户完全一样。它们能读文本、识别图标、理解页面的视觉层级。这让 QA Agent 把测试从实现细节中解耦出来。如果一个「Submit」按钮改了 ID 但看起来还是个「Submit」按钮，agent 会找到它并点击。这种能力把我们的测试从「僵硬的代码执行问题」转变成「灵活的规划和导航问题」。
然而，「用一个 VLM」低估了实际发生的事。QA Agent 不依赖单一模型。不同的认知任务需要不同的强项，所以我们在每个动作周期里组合多个模型：
- 一个模型负责高层规划。给定当前截图、动作历史和任务目标，它决定下一步做什么：「点 Apply 按钮」「下滑找到薪资字段」或「任务完成」。
- 另一个模型负责分析推理。错误检测、view tree 评估、bug 报告生成，以及 planner 内的导航决策都跑在这个模型上——在这里，仔细的逐步分析比速度更重要。
- 最后，我们有一个 fine-tuned 模型做视觉 grounding。当 planner 说「点 Apply 按钮」时，需要把这个指令解析成实际的屏幕坐标。这个 fine-tuned 模型接收一张截图和一个动作描述，返回点击的像素坐标。
这些在一个动作周期里是这样组合的：
- agent 捕获一张截图和当前的 view tree（屏幕内容的文本表示）。
- planner 检查这个状态以及动作历史和目标，输出一条自然语言指令，比如「点 ‘Easy Apply’ 按钮」。
- fine-tuned 模型接收这条指令和截图，在视觉上定位元素，返回坐标。
- 设备驱动执行点击。
- 执行后，分析推理模型评估这个动作是否产生了有意义的变化、检查错误，循环重复。
这种多模型方法让我们能独立优化每个认知步骤。我们可以换一个更好的 planner 而不动 grounding 层，或者改进错误检测而不影响导航。这也意味着我们可以针对同一个测试套件做实验、对比不同模型配置——这一点后面很重要。
Agent 架构：两全其美
为了在 AI 的成本和延迟与对速度和可靠性的需求之间取得平衡，我们设计了一个受人类认知启发的混合架构，特别是「System 1」（快、直觉）和「System 2」（慢、深思）思维的概念。这一节会深入实现，因为架构才是大多数有趣工程所在之处。
System 1：确定性回放
System 1 是快速、反射式的模式。它从历史成功运行中回放动作。如果一个测试之前成功跑过且 UI 没变，QA Agent 就走已知路径。它可预测、便宜、基于记忆。
每个成功的动作被存为一个 signature（签名）。可以把这些 signature 想成 UI 元素的指纹。下一次运行时，agent 从存储的记忆里取出第一个动作，检查那些坐标上的元素是否仍然匹配 signature。匹配是严格但有针对性的：元素类型必须匹配，且至少一个文本字段（渲染文本或 accessibility 文本）必须精确匹配。如果匹配，agent 确定性地执行动作，不调用任何 LLM。
结果是稳定的测试流程执行得又快又便宜。LLM 只在 UI 变化时才被调用——这就引出了 System 2。
System 2：基于视觉的规划
当 agent 遇到一个新屏幕、变化的布局，或 System 1 匹配失败时，它切换到 System 2。这时 VLM 接管。
planner 接收当前截图、最近动作历史窗口和任务目标。它输出一个结构化的计划，包含：作为自然语言指令的下一步最优动作、可能的 fallback 动作、任务是否完成、agent 是否需要回溯。fine-tuned 模型然后把选定的动作 grounding 到坐标以执行。
为了提高 planner 在选择下一步最优动作（自然语言指令）时的准确率，我们建了一个简单的学习反馈循环：来自成功测试的指令会被记住，用来在未来的测试运行中偏向（bias）动作。每次运行、每个任务，我们都会保存传给 grounding 模型的自然语言指令。在 prompt planner 时，我们提供它之前对同一任务给出的最近 20 条成功的自然语言指令。这让 planner 偏向之前成功的指令。
Evaluator 作为护栏
即使有这种混合方法，agent 仍可能卡住或幻觉出动作。我们实现了几个在执行期间作为护栏运行的 evaluator。
View Tree Evaluator 比较每个动作前后的 UI 结构。它接收 view tree 的扁平表示、任务描述和动作历史，用模型判断是否真的发生了有意义的变化。如果 agent 点了一个按钮但什么都没发生，这个 evaluator 会抓住它。
Tracking Log Evaluator 验证预期的分析事件是否真的触发。LinkedIn 的 app 在用户交互时发出 tracking 事件，我们的许多测试用例包含「哪些事件应该出现、以什么顺序」的断言。这个 evaluator 对照实际的日志流验证这些，检查事件内容和顺序约束。
Action History Evaluator 检查到目前为止采取的动作序列是否与高层测试意图一致。这能抓住 agent 成功导航到某处但到错了地方，或走了条迂回路径暗示困惑而非进展的情况。
Error Detection Pipeline 是一个多阶段系统，用于在提交 bug 报告前过滤误报。当 agent 怀疑有错误时，pipeline 跑两个阶段：
- detect error 阶段分析截图寻找崩溃、错误页面或 UI 异常。
- verification 阶段做第二次 LLM 调用来验证初始检测，检查错误评估是否正确。
只有两个阶段都同意，pipeline 才进入报告阶段，生成包含复现步骤、截图和相关日志的详细报告。这个两阶段验证显著减少了误报，这对于维护接收这些报告的工程团队的信任至关重要。
决策循环
把这一切拼起来，一次测试执行是这样的：agent 收到一个任务，比如「保存一个职位发布」。它检查 System 1 记忆里是否有已知路径。如果找到，就确定性回放，把每个动作的 signature 对照当前 UI 验证。如果 signature 不匹配，或没有记忆，就切换到 System 2。planner 检查当前屏幕，基于应用当前状态决定下一步动作（点击、滚动、输入文本）。动作然后被 grounding 到坐标并执行。执行后，evaluator 检查错误、验证 UI 变化、校验 tracking 事件。agent 然后捕获新状态并重复。如果任务成功完成，动作序列被存回记忆，为下一次运行播种 System 1。
民主化质量：一种新的运营模式
QA Agent 带来的最重大转变也许是文化上的。通过把测试的复杂性抽象到 AI 接口背后，我们为非工程师拥有和参与产品质量打开了门。
我们不要求人们写代码或复杂的脚本，而是允许他们直接使用应用，发出点击、滚动、输入事件来构造测试流程。我们的 recorder 捕获这些交互，但关键的是，它不只是把它们存成一个脆弱的宏。我们用 LLM 把这些原始事件合成成高层的、语义化的自然语言指令。在坐标 (234, 567) 的一次点击变成「点 ‘Easy Apply’ 按钮」，因为 LLM 能解读截图、理解用户实际在做什么，而不只是手指落在哪里。
然后我们提供一个专门的 Web 界面让用户审查这些合成的计划。这个 Human-in-the-Loop（人在环中）流程让创建者验证 agent 对任务的理解，确保它在上线生产前抓住了测试的真实意图。
一旦批准，这个过程实际上「播种」了 agent 的记忆。agent 从这个测试的已知正确路径开始，使它能从第一天起快速、确定性地执行，同时仍保留在应用演进或 UI 变化时切换到 System 2 的能力。
这个工作流在 LinkedIn 民主化了质量，创造了一种非技术利益相关者也能编写弹性、agent 驱动测试的纪律。
严格的评估
一个报告幽灵 bug 的自主 agent 比没用更糟——它侵蚀信任。我们把 QA Agent 优化为precision 优先于 recall，接受我们可能错过一些问题，以换取对每个报告的 bug 都为真的信心。
构建严格的评估框架是我们解决过的更难的问题之一，也是更重要的问题之一。
Golden Dataset 框架
早些时候，我们意识到不能对着 live app 评估 agent。真实环境不断变化：新部署落地、实验开关切换、服务端内容漂移。跑同一个测试两次可能因为与 agent 行为完全无关的原因产生不同结果。这让评估结果充满噪音、不可复现。
所以我们建了一个 golden dataset 框架。工作流是这样的：一个人工审查者标注一次 agent 运行，标记哪些动作正确、哪些任务成功完成。这个反馈被捕获并存为 golden dataset——应用状态在每一步的冻结快照，包括截图、view tree 和每一步的预期动作。
关键洞察是：评估对着这个捕获的状态回放，而不是 live app。当我们跑一次评估时，agent 正常执行，但每个设备命令都被拦截。截图请求返回预录的图像。view tree 请求返回预录的层级。当 agent 采取一个动作时，我们不在真实设备上执行，而是对照录制的动作 signature 比较。agent 是否点在了正确元素的包围盒内？是否朝正确方向滚动？是否输入了正确文本？
这给了我们确定性、可复现的评估。我们可以把同一个 golden dataset 跑 100 次得到一致结果——这对于衡量一个改动是真的改进了 agent 还是只是运气好至关重要。
我们在三个层级测量准确率：action-level（每个单独动作是否匹配）、task-level（一个任务内所有动作是否匹配）、replay-level（整个测试是否通过）。golden dataset 可以被打标和过滤，这样我们可以对着特定子集评估：负例、feed 相关失败、或平台特定的 case。
实验框架
golden dataset 框架与我们的实验系统结合时变得真正强大。
在生产运行期间，实验与生产 planner 并行执行。agent 使用生产动作，但实验动作被记录在旁边。我们比较实验 planner 是否会点同一个元素、朝同一方向滚动、或达成相同的完成判断。这些比较带着完整的可观测性被记录，包括带标注的截图显示每个 planner 会点在哪里。
当我们想更严格地评估一个新方法时，我们对着 golden dataset 回放它。因为 golden dataset 捕获了完整的应用状态，我们可以在不需要设备、不需要 live app、且结果完全可复现的情况下，对着几十个真实测试场景测试一个新的 planner 变体。
这就是我们在提升 planner 变更前验证它们的方式。我们对着与生产 planner 相同的 golden dataset 跑候选，测量动作准确率和任务完成率，并排比较结果。没有猜测，没有「手动测试时似乎更好」。量化的提升，或量化的回归。
当测试在生产中失败时，我们 triage（分诊）它们以理解哪里出了问题。agent 是导航错了？幻觉出 bug？错过了真实问题？这些失败成为负例，我们纳入回 golden dataset，持续提升准确率。今天这个 triage 是手动的；未来，我们希望能自动化它。
QA Agent 实战
我们见过 QA Agent 做出标准自动化框架不可能做到的事。
穿越大规模迁移的自愈
任何一天，都有数百个变更落入 LinkedIn 主代码库。Test ID 变了。UI 处理被修改了。View 层级被重构了。传统测试自动化需要持续的维护和对齐才能跟上。
QA Agent 在整个迁移过程中持续执行核心流程。因为它视觉导航而非依赖实现细节，只要面向用户的体验仍然可识别，它就能适应。按钮仍然写着「Apply」；agent 找到它并点击，不管底下变了什么。当 UI 变化大到足以破坏 System 1 路径时，agent 回退到 System 2，推理新的布局，并为下一次运行更新记忆。
App 崩溃和意外错误页
当 QA Agent 遇到 app 崩溃或意外错误页时，它不只是让测试失败。它捕获诊断所需的一切。agent 录制会话视频，收集崩溃日志和设备日志，并把崩溃跑过多阶段错误验证 pipeline 后才提交。这意味着以前会被忽视或需要冗长来回复现的崩溃，到达时已经带上了完整上下文和复现步骤。
业务指标保护
QA Agent 在测试执行期间监控 tracking 事件，不只是 UI 行为。这意味着分析埋点的回归——损坏的漏斗、误触发的事件、不一致的 payload——会与功能 bug 一起自动浮现，保护团队用于决策的业务指标。例如，当 profile 团队在调查无法解释的会话丢失时，QA Agent 已经标记了一个 profile 流程在发出不正确的 tracking 事件且触发不一致，给了他们 root-cause 这个问题的关键拼图。
接下来是什么？
今天，QA Agent 通过定时作业运行在一个专门的员工集群上。我们以 30 分钟节奏跨 iOS、Android 和 Web 执行 350+ 测试，在不阻塞主开发流程的情况下持续在真实环境中监控。
自最初部署以来，我们交付了几个重要能力。golden dataset 评估框架给了我们可复现的度量。实验系统让我们在推出前定量验证变更。这些不是我们计划的特性，而是我们正在其上构建的基础设施。
除此之外，我们正在投资四个方向：
- 左移到开发：今天 QA Agent 在部署后运行。我们正在把它作为 skill 暴露给编码 agent 在代码编写时调用，这样我们可以在一个提议的变更合并前触发一次验证运行。这把质量反馈从「我们在生产中抓住了它」移到「我们写代码时就抓住了它」。
- 自动化 triage：今天我们手动审查失败来理解哪里出了问题。我们正在建设一个 agent 能自己诊断问题、回答后续问题、或用更深埋点重跑测试片段的系统。
- 垂直化 sub-agent：QA Agent 已经产生丰富的产物：截图、view tree、动作历史。我们正在构建专门的 sub-agent 分析这些数据来评估无障碍、国际化和性能，而无需重跑测试。
- 探索性测试：不是结构化的测试用例，而是给 agent 一个高层指令，比如「找出 Jobs 里所有的 i18n 问题」，让它自主导航、探索边界情况、浮现我们没想到要测的问题。
结论
QA Agent 起初是一个实验：一个 AI 系统能导航我们的 app、抓住真实 bug、并在传统自动化不能的地方规模化吗？答案是肯定的——超过 200 个 bug 被发现，关键回归被抓住，核心流程在一次重大平台迁移中得到保护。
但更大的胜利是文化上的。质量不再被锁在工程内部。任何能用 app 的人现在都能编写测试。随着我们向部署门控、自动化 triage 和探索性测试扩展，QA Agent 正在成为基础性基础设施——不只是为抓住 bug，而是为 LinkedIn 构建软件的方式。
深度解读
这篇文章回答的问题： 怎样用 VLM + 多模型混合架构，把"自主测试 app"这件事从演示做到生产级 350 测试/30 分钟的规模。
这篇文章应该回答但没回答的问题： 这套系统到底花多少钱、跑多慢、漏了多少关键 bug——以及一个普通团队复制它的真实门槛在哪。
Part 1 · 工程级解读
这套系统实际在哪跑、谁调谁
先把运行时模型画清楚，别停在「它是个 agent」：
- 跑在哪：LinkedIn 内部员工集群，定时作业驱动，30 分钟一轮，iOS / Android / Web 三端各一套设备驱动（device driver，真机或模拟器）。
- 进程内 vs 跨进程：agent 的大脑（planner / reasoner / grounding 三个模型）是远端 LLM API 调用；手脚（截图、view tree 抓取、点击/滚动执行）是本地设备驱动。两者通过一个 decision loop 串起来——截图→云端推理→本地执行→评估→再截图。
- 调用链：
Device Driver（截图+view tree）→ Planner 模型（出自然语言指令）→ Grounding 模型（指令→像素坐标）→ Device Driver（执行点击）→ Analytical Reasoner（评估变化+错误）→ 回到第一步。一个端到端流程几十个 action，就是这条链跑几十轮。 - System 1 旁路：上面那条重链只在 UI 变了时才跑。稳定 case 走「记忆 signature → 本地比对 → 直接执行」，全程零 LLM 调用。这是整套架构的成本命门。
记住这张图，下面所有工程细节都是围绕「让重链尽量少跑」展开的。
核心架构拆解
| 部件 | 职责 | 工程上实际在做什么 | 关键设计权衡 |
|---|---|---|---|
| System 1（确定性回放） | 吃掉稳定 case，砍成本 | 把历史成功动作存成 signature（元素类型 + 一个 text 字段精确匹配）；命中就本地执行，不调 LLM | 严格匹配防误命中；只匹配一个 text 字段是为了抗 i18n/A-B 变化 |
| System 2（视觉规划） | 处理 UI 变化与新屏幕 | 截图 + view tree + 动作历史喂 planner，输出自然语言指令，fine-tuned 模型 grounding 到坐标 | 多模型分工而非单模型，每步可独立 swap 和实验 |
| Planner 模型 | 决策「下一步做什么」 | 接收截图+历史+目标，输出结构化计划（主动作+fallback+完成判断+是否回溯） | 偏向快和决策，喂「最近 20 条成功指令」做 in-context bias |
| Analytical Reasoner | 慢思考：错误检测、view tree 评估、bug 报告 | 逐步分析，准确率优先于速度 | 和 planner 分离——分析任务用更强的模型，决策用更快的 |
| Fine-tuned Grounding 模型 | 自然语言指令 → 像素坐标 | 截图 + 动作描述 → 坐标 | 自研 fine-tuned，是整套系统最大的复制壁垒 |
| View Tree Evaluator | 检测「动作有没有产生变化」 | 动作前后 view tree 扁平化比对 | 抓「点了但没反应」的无效动作 |
| Tracking Log Evaluator | 校验埋点事件 | 对照日志流检查事件内容和顺序 | 保护业务指标，不只 UI 正确性 |
| Action History Evaluator | 检测「走错路」 | 动作序列 vs 高层意图 | 抓迂回路径和到错地方 |
| Error Detection Pipeline | 过滤误报 bug | 两阶段：detect（初检）→ verify（二次 LLM 复核），都同意才上报 | precision 优先于 recall 的铁律 |
| Golden Dataset | 评测基础设施 | 录制 app state 快照；回放时拦截所有设备命令返回预录数据；动作对照 signature 比对 | 把 agent 从「对抗 live 环境」变成「对抗录好的快照」 |
| Experiment Framework | 安全迭代 planner | 实验 planner 与生产 planner 并行跑，shadow 比对；golden dataset 回放做 A/B | 量化提升或量化回归，没有「感觉更好」 |
三个最值钱的内部机制
1. System 1/2 混合 = 把「缓存」思维搬上 agent
直觉上大家以为 VLM agent 的难点是「看得懂屏幕」。其实 GPT-4V / Claude 这代模型已经基本看懂了。真正的工程难点是：VLM 调用又慢又贵。一个端到端流程几十个 action，每个 action 都调三四个模型，一轮测试几分钟、几美金，跑 350 个测试 × 每天 48 轮 = 成本爆炸。
LinkedIn 的解法是给 agent 加了一层「L1 缓存」：把历史成功的动作路径存成 signature，稳定 case 直接本地比对执行，零 LLM 调用。只有 UI 变了才唤起 System 2 这个「主存计算」。这是把 LLM 成本从 O(总动作数) 降到 O(变化量) 的关键一跳。
类比 CPU：System 1 = L1 cache（快、便宜、命中率优先），System 2 = 主存计算（慢、贵、处理 cache miss）。这个类比能帮你记住整个架构的成本逻辑。
2. 多模型分工 = 认知任务解耦
反直觉点：LinkedIn 没有用一个 super model 干所有事，而是拆成三个专精模型——planner（快、决策）、analytical reasoner（慢、分析）、grounding（专、定位）。
为什么不用一个？三个原因：①不同认知任务的最优模型不同（决策要快、分析要准、定位要专）；②每个 step 可以独立 swap 和 A/B 实验，改 planner 不影响 grounding；③fine-tuned grounding 用小模型，成本可控。
这是 agent 设计的默认模式应该是「多模型流水线」而非「单模型万能」的工程证据。每个 cognitive step 单独优化、单独评测、单独替换。
3. Golden Dataset = Agent 的单元测试
评测自主 agent 的最大难题：环境非确定性。live app 一直在变（部署、A/B、服务端内容），跑两次同一测试结果可能不同，你根本不知道换了个 prompt 是变好还是变坏。
LinkedIn 的解法是把测试里成熟的 mock/stub 模式搬上 agent 层：录制 app state 快照（截图 + view tree + 预期动作），回放时拦截所有设备命令返回预录数据，动作对照 signature 比对。这把 agent 从「对抗真实环境」变成「对抗录好的快照」，于是可以跑 100 次得到一致结果。
三层粒度对应经典测试金字塔：action-level（单元）/ task-level（集成）/ replay-level（端到端）。任何自主 agent 上线前，你必须有一套「录制-回放-比对」的 golden dataset，否则你根本无法判断改动的好坏。这是 agent 工程化的分水岭。
手搓版 vs LinkedIn 版（省的到底是什么）
如果你周末想搓一个 QA agent，大概长这样：Appium + GPT-4V + 一个 while 循环。每次截图 → VLM 决策 → 执行 → 再截图。能跑通，但慢、贵、脆、且无法评测。
LinkedIn 在这之上加了 6 层工程化：
| 维度 | 手搓版（周末 demo） | LinkedIn 版 | 省的是什么 |
|---|---|---|---|
| 成本 | 每个 action 都调 VLM | System 1 signature 缓存，稳定 case 零 LLM | 把成本从 O(n) 降到 O(变化量) |
| 质量 | 单模型干所有事 | planner/reasoner/grounding 三模型分工 | 每步用最优模型，避免短板 |
| 可靠性 | 点了就点了，不管有没有效果 | 4 个 evaluator 护栏 | 抓无效动作、走错路、误报 bug |
| 可评测 | 对着 live app 跑，结果飘 | golden dataset 录制-回放-比对 | 确定性、可复现的评测 |
| 可迭代 | 换 prompt 靠手感 | 实验 planner shadow + golden 回放 A/B | 量化提升/回归，没有猜测 |
| 民主化 | 必须写代码 | no-code recorder + LLM 语义合成 | 非工程师也能写测试 |
省的不是「AI 能力」——VLM 大家都能调。省的是把一个能 demo 的 agent 变成生产系统所需的评测、成本、可靠性基础设施。
选型决策框架
| 场景 | 该不该用这套思路 | 理由 |
|---|---|---|
| 大型 app、多平台、UI 频繁变、有标注资源 | ✅ 用 | System 1 缓存收益大；grounding fine-tune 有数据支撑 |
| 小团队、稳定 UI、预算紧 | ❌ 别用全套 | fine-tune + golden dataset 基建成本太高，ROI 负 |
| 只做 Web、DOM 稳定 | ⚠️ 轻量版即可 | Web 有 accessibility tree，grounding 可用 DOM 定位，不必 fine-tune 视觉模型 |
| 强无障碍/合规要求 | ✅ 用 | 垂直 sub-agent 正好做 a11y 评测 |
| 需要嵌入 CI 阻断合并 | ⚠️ 先解决延迟 | 这套系统目前是 30 分钟节奏 post-deploy，离 pre-merge gate 还有距离 |
替代方案：Mabl / Applitools（视觉+DOM 混合 SaaS，不必自建）、Appium + AI selector 插件（轻量）、纯自研（按本文思路但只取 System 1/2 + evaluator，跳过 golden dataset 先跑起来）。
诚实限制 + 压力测试质疑
这套架构扎实，但博客是雇主品牌文，选择性呈现了成功。几个必须打问号的地方：
- 「200 个有效 bug」没有分母。350 测试 × 每天 48 轮，假设跑了 3 个月 = 数百万次 run。200 bug 的命中率到底多少？「valid」由 LinkedIn 自己定义，没有第三方验证。一个精度优先的系统，漏报的关键 bug 有多少？
- System 1 命中率没给。这是整套架构的成本命门——如果 i18n（36 语言）和 A/B 实验让 signature 大量失配，大部分 case fallback 到 System 2，成本护城河就垮了。这个数字 LinkedIn 一定有，但没披露。
- fine-tuning 数据门槛被回避。grounding 模型怎么 fine-tune 的？需要多少标注的「截图+动作→坐标」数据？这是外部团队复制的最大壁垒，也是 LinkedIn 最不愿讲的护城河。
- 延迟没提。一个端到端流程要几分钟？30 分钟一轮跑 350 测试，并行度多少？这些直接影响能不能进 CI gate。
- golden dataset 的新鲜度问题。app 变了，golden dataset 就过时，维护成本谁出？博客只说「失败转成负例」，没说 golden 本身的腐烂率。
- 利益相关：LinkedIn Engineering Blog 本质是招聘 + 技术品牌建设。作者会选择性呈现成功（「promising」「significant」密集出现），弱化成本与失败。学架构思路很值，但别照搬「200 bugs」的规模暗示。
一个真骨感的判断：这套系统的真正价值不是「VLM 能测 app」（这已经是行业共识），而是把**评测基础设施（golden dataset + experiment framework）**做到了生产级。前者是 demo，后者才是工程。这也是普通团队最难抄的部分。
Part 2 · 苏格拉底对话
学生（尾巴）：我做了这么多年 QA，一看到「VLM 自主导航 app 测试」第一反应是——这不就是花更多钱、换一种脆法吗？视觉理解能比 selector 稳？
老师：好问题。先想：传统 selector 为什么脆？
学生：因为实现细节一变（test ID 改了、层级重构了），selector 就断，哪怕用户看到的界面没变。
老师：那 VLM 解了哪一层的耦？
学生：解了「测试」和「实现细节」的耦。它看的是用户看到的东西——按钮上写着 Apply，它就找 Apply，不管底下 ID 叫什么。
老师：所以「脆」的根源转移了——从「实现细节变化」转移到「视觉变化」。对吧？
学生：对……这意味着只要 UI 视觉不变，测试就稳。可是这又引出新问题：VLM 调用又慢又贵，每个 action 都调，一个流程几十个 action，成本怎么扛？
老师：这就是 LinkedIn 架构的命门。你想，一个测试跑过一次成功了，下一次 99% 的屏幕其实没变——
学生：——那我干嘛还调 VLM？把上次成功的路径存下来，下次直接照着走，只有走不通了再喊 VLM。
老师：完全正确。这就是 System 1。它本质是什么？
学生：……缓存。把「成功的动作路径」当成 LLM 推理结果的缓存，命中就直接用，miss 了才算。
老师：那成本从 O(总动作数) 变成了——
学生：O(变化量)。只有 UI 真变了的那部分才付 VLM 的钱。这是把 LLM 成本从「按调用次数」变成「按变化频次」。
老师：现在第二个问题：你怎么知道换了个 prompt、换了个模型，agent 是变好还是变差了？
学生：跑测试看通过率？但 app 一直在变，今天挂了可能是 agent 的问题，也可能是线上环境变了……测不准。
老师：所以评测的敌人是什么？
学生：非确定性。live 环境的噪音盖过了 agent 本身的变化。
老师：LinkedIn 怎么把噪音干掉的？
学生：把环境冻住——录制成快照，回放时拦截所有设备命令返回预录数据。这样 agent 是在对着「录好的世界」测试，跑 100 次都一样。
老师：这让你想到什么？
学生：单元测试的 mock 和 fixture……只不过这里 mock 的是整个 app 界面。agent 的单元测试 = 静态 fixture + 动作比对。
老师：最后一个开放问题留给你：这套系统目前是 post-deploy 跑，30 分钟一轮。LinkedIn 说要「左移到写代码时」。你觉得从「30 分钟后报」到「提交前阻断」，中间最难的那一跳是什么？
学生：……（留给你想）。
Part 3 · 给你的个性化洞察
你 QA 出身、做自己的 AI 产品、关注 AI 工具链，这套架构对你有 4 个直接落点：
「缓存思维」是你做任何 AI agent 产品的成本护城河。LinkedIn 的 System 1/2 本质是「把 LLM 稳定输出存下来复用，只对变化部分付费」。你做任何 agent（不管是知识库、自动化、还是 QA 类），第一步先问：哪些步骤的输入是稳定的？那些步骤的 LLM 输出可以 signature 化缓存？这一步能把你的 API 账单砍掉一个数量级，是从 demo 到产品的必经路。
「golden dataset」是你给 AI 产品做质量评估的框架。你做 QA 这么多年，测试金字塔是肌肉记忆。现在把它搬到 agent 上：你的 agent 产品有没有一套「录制-回放-比对」的 golden set？换 model / 改 prompt 时，你能不能量化地说出是变好还是变差？没有这个，你的迭代就是在凭手感。这是你比纯算法出身的创业者有优势的地方——评测基础设施是 QA 的主场。
「多模型流水线」是 agent 设计的默认模式。别用一个 super model 干所有事。LinkedIn 的 planner（快）/ reasoner（准）/ grounding（专）分工值得照抄：决策用便宜快的，分析用贵但准的，专精任务 fine-tune 小模型。你在选 model 时，按「认知任务类型」分配，而不是按「我习惯用哪个」。
「precision > recall」是你做任何「主动报告」类 AI 系统的铁律。不管是 bug 发现、code review、监控告警、还是你自己的日记/知识库自动化——一个报假阳性的系统比没系统更糟，因为它侵蚀信任。LinkedIn 的两阶段验证（detect + verify）是低成本高收益的设计：宁可漏几个，不可误报一个。你做产品时，主动干预类功能默认上两阶段过滤。
一个反向提醒：别被「200 bugs」「自主测试」带着走。这套系统的真正壁垒不是 AI 能力，是评测基建（golden dataset + experiment framework）和 grounding 模型的 fine-tune 数据。如果你要借鉴，先抄评测框架，再抄架构——没有评测，架构好坏你根本不知道。
金句
慢一点可以。但精度，一寸不让——一个报幽灵 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.
质量不再锁在工程内部。任何能用 app 的人现在都能写测试。
Quality is no longer locked inside engineering. Anyone who can use the app can now author a test.