Playwright MCP Server 与 AI Agent 浏览器自动化测试

• MCP 概念
• Playwright MCP 核心能力
• 工具封装

Playwright MCP Server（@playwright/mcp）把 Playwright 的浏览器能力封装为 MCP（Model Context Protocol）工具，供 AI Agent 通过工具调用驱动浏览器。核心能力：浏览器导航（打开 URL、前进后退、刷新）、元素快照（snapshot 返回页面可访问性树/结构化元素，供 AI 理解页面状态）、点击/输入（点击、输入文本、按键、选择等结构化操作）、表单/滚动/切换、断言与截图（截图、检查元素属性）。封装方式：每个能力映射为一个 MCP 工具（如 browser_navigate、browser_snapshot、browser_click、browser_type），定义工具名、参数 schema（JSON Schema）与返回描述；AI Agent 通过 MCP 调用工具，MCP Server 转化为 Playwright 操作并返回结构化结果（如 snapshot 的可访问性树供 AI 决策）。关键设计：snapshot 用可访问性树（accessibility tree）而非纯 DOM，让 AI 理解"可交互控件"的可语义化结构；工具返回结构化数据（元素、状态、文本），支撑 AI 决策闭环。这样 AI 无需手写选择器，而是通过快照理解页面并用工具操作。

Playwright MCP 的核心是"把浏览器能力工具化、结果结构化"。快照/可访问性树让 AI 理解页面，导航/点击/输入等结构化工具让 AI 操作浏览器，形成"感知→决策→操作"闭环。

• AI 测试工作流
• 意图到断言闭环
• 各环节

AI Agent 通过 Playwright MCP 完成 E2E 测试的工作流是闭环：1）用户意图——用户用自然语言描述测试目标（"验证登录后能查看订单列表"）；2）行动规划——AI 将意图分解为可执行步骤（导航→登录→断言订单列表），并规划每步用哪个 MCP 工具；3）工具调用——AI 依次调用 browser_navigate/browser_snapshot/browser_click/browser_type 等工具，每步根据 snapshot 反馈调整（感知页面当前状态→决定下一步操作）；4）断言与截图——对关键状态断言（验证订单文本、元素可见），用 browser_snapshot/browser_screenshot 验证并截图留存，形成闭环。该闭环的核心是"感知-决策-操作-验证"的循环：每步用 snapshot 感知真实页面状态，决策下一步，执行工具，用断言/截图验证结果，必要时回退重试。AI 需要处理中途失败（元素未找到、超时）用快照重新定位。这样从自然语言意图到可执行、可验证、可留证的 E2E 流程闭环。

AI 测试工作流本质是"意图驱动的闭环执行"。意图分解为步骤、snapshot 感知状态、工具执行操作、断言/截图验证，形成可闭环、可留证的自动化流程。

• 覆盖率对比
• 稳定性对比
• 开发成本对比

Playwright MCP（AI 驱动）与传统代码驱动测试在覆盖率、稳定性、开发成本上各有取舍。覆盖率：传统代码驱动测试覆盖面广、可精确控制（可测边界、异常、数据驱动），覆盖率稳定且可度量；AI MCP 测试覆盖面取决于模型能力与指令，能快速覆盖"常见路径"，但对复杂/异常分支覆盖不均、难精确控制。稳定性：传统测试稳定（代码确定、可重试、可断言强），flaky 可治理；AI MCP 测试稳定性受"模型决策波动"影响（同一意图可能走不同路径），需依赖 snapshot 定位与重试，稳定性略低但正在改善。开发成本：传统测试开发成本高（手写选择器、等待、断言，维护成本高）；AI MCP 测试开发成本低（自然语言生成，无需手写选择器/等待，快速起量），但需投入"提示词/指令调优 + 结果校验"的人工成本。对比结论：AI MCP 适合"快速探索、快速生成初稿、覆盖常见路径、降低入门成本"；传统代码驱动适合"精确、稳定、可度量的长期回归"。实践中常"AI 生成初稿 + 人工精修/固化关键用例"，二者结合。

两者的取舍是"开发成本 vs 稳定性/覆盖率可控性"。AI 降开发成本、快探索，但稳定与覆盖可控性弱；传统精确稳定但成本高，宜"AI 起量 + 人工固化关键回归"结合。

• 三个 Agent 分工
• 协作修复 flaky
• 工程价值

Playwright Test Agents（v1.56+）引入三个专用 Agent 协作修复 flaky 测试。Planner：分析失败原因，规划修复方案——理解 flaky 根因（时序、选择器、等待），决定"改等待、改选择器、改断言"；Generator：生成修复代码——把 Planner 的方案落地为具体代码修改（如替换选择器、加等待、调整断言）；Healer：修复后的验证与自愈——运行修复后的测试验证是否通过，必要时迭代，实现"自愈"闭环。三者协作流程：Planner 诊断失败 → Generator 生成修复 → Healer 验证并迭代，形成"诊断-修复-验证"的自动化循环。工程价值：降低 flaky 治理的人工成本——传统需人工定位根因、手写修复、反复验证；Agents 自动完成诊断、修复、验证，把 flaky 修复从"人工苦力"变为"AI 自动迭代"，大幅提升 flaky 治理效率；让团队从"反复修 flaky"中解放，聚焦真实缺陷。注意：Agent 自动修复需人工审核（避免误修掩盖真问题），与"根因分类、趋势看板"配合治理。

三个 Agent 对应"诊断-生成-验证"的修复闭环。Planner 诊断、Generator 生成修复、Healer 验证自愈，自动化 flaky 修复流程，降低治理成本，但需人工审核防误修。

• 安全边界
• 脚本注入风险
• 可信选择器 vs CSS

Playwright MCP 让 AI 驱动浏览器，需定义安全边界。受信任浏览器上下文：MCP 应运行在受控/受信任的浏览器上下文中，限制访问敏感站点、凭据、生产环境操作，避免 AI 在非预期环境执行破坏性操作。外部脚本注入风险：AI 通过 execute_script/browser_evaluate 执行 JS 脚本，注入不可信脚本可能导致安全风险（XSS、数据泄露、恶意操作），需限制脚本来源、校验脚本内容、禁止执行不可信外部脚本。可信 DOM 选择器 vs CSS 选择器：Agent 操作时用"可信 DOM 选择器"（基于可访问性树/稳定属性/role 的定位，如 getByRole、getByText、data-testid）比"任意 CSS 选择器"更安全——CSS 选择器可被页面内容影响（如用户可控文本被拼进 CSS），且更脆弱；可信选择器基于语义结构，稳定且不易被不可信内容操纵。取舍：Agent 定位优先用可信语义选择器（安全、稳定），CSS 选择器作为补充但需谨慎（避免用不可信内容构建选择器）；限制脚本执行与外部注入。安全边界设计：白名单站点、受限凭据、可信选择器优先、脚本校验、审计操作日志。

安全边界的关键是"限制 AI 的操作范围与方式"。受控上下文 + 脚本校验 + 可信语义选择器优先，降低 AI 驱动的注入与越权风险，同时提升定位稳定性。

• 回归场景可用度
• 失败率
• 人工兜底成本

AI Agent 自动化测试在回归场景的真实可用度需理性评估。从 prompt → 决策 → 操作 → assertion 的链路中，每一环都可能失败：prompt 理解偏差（意图不清导致步骤错误）、决策错误（选错路径/操作）、操作失败（元素未找到、时序）、assertion 失败（断言太弱/错）。整条链路失败率受"页面复杂度、动态性、模型能力、指令质量"影响——简单稳定页面成功率较高，复杂异步/动态页面失败率升高。人工兜底成本：AI 失败时需人工介入——验证失败原因（AI 问题 vs 真实缺陷）、修正 prompt/指令、补充断言、可能需人工重写用例；兜底成本由此产生（人工 review 每个 AI 用例的执行与结果、处理误报、维护 prompt）。可用度判断：AI 测试适合"快速探索、生成初稿、覆盖稳定路径、辅助回归"，作为"回归初筛 + 人工复核"；对"高可信、低误报、需精确断言"的关键回归，仍需人工固化/审核。控制失败率与兜底成本：用清晰可复用的 prompt 模板、用可信语义定位、用强断言、对 AI 结果做"自动校验 + 人工抽审"，把兜底成本控制在可接受范围。

AI 回归测试的可用度取决于"失败率与兜底成本"的平衡。AI 快速覆盖但逐环有失败率，需人工兜底；宜"AI 初筛 + 人工复核"，并用模板、强断言、抽审控制成本。

• 多 MCP 编排
• 上下文压缩
• 工具选择策略

多 MCP Server 编排（Playwright + Filesystem + Sentry + DB 等）让 AI Agent 触达浏览器、文件、错误监控、数据库等多类能力，但需处理上下文与工具选择。上下文压缩：多 MCP 会产生大量上下文（snapshot、日志、数据），需压缩以避免上下文膨胀——只保留任务相关上下文（按需取 snapshot、聚合日志、用摘要/结构化数据而非全量）；用"按需加载"（工具返回精简结果、查询时再取详情）、会话管理（分阶段上下文）压缩。工具选择策略：面对多个 MCP 的工具，AI 需选择正确的工具——用"工具描述 + 能力清单"让 AI 理解各工具用途；设计"工具路由"（按任务类型选对应 MCP：测 UI 用 Playwright、查错误用 Sentry、查数据用 DB）；用"最小工具集"减少选择冲突（按需注册工具，不暴露全部）。关键设计：工具 schema 描述清晰、上下文按需压缩、工具按需注册/路由，避免"上下文爆炸"与"工具选择混乱"。实践中可为特定测试任务创建"专用 MCP 组合 + 精简工具集"，平衡能力与成本。

多 MCP 编排的核心是"能力丰富 vs 上下文/选择成本"的平衡。按需压缩上下文、清晰工具描述 + 按需路由，让 AI 在触达多能力的同时不失控。

• Playwright MCP vs 通用 Agent
• 测试场景取舍
• 确定性/可断言性与通用性的权衡

Playwright MCP 与 Browser Use / computer-use 类通用 Agent 在测试场景的取舍不同。Playwright MCP：面向浏览器自动化的专门工具，提供结构化能力（snapshot 可访问性树、导航、点击、输入、断言、截图），操作基于浏览器上下文（DOM/可访问性树），稳定、可控、可断言、可留证，适合"精确的浏览器测试"。Browser Use / computer-use 类通用 Agent：面向"通用 GUI 操作"（浏览器、桌面、跨应用），基于屏幕/视觉理解操作（computer-use），不限于浏览器，更通用但粒度粗、依赖视觉、稳定性与可断言性弱。工程取舍：测试场景看重"确定性、可断言、可复现、可集成 CI"——Playwright MCP 结构化、可断言、可集成，更契合测试；通用 Agent 更适合"跨应用/桌面自动化、非结构化探索、视觉类操作"，但测试断言与复现弱。取舍结论：核心浏览器测试用 Playwright MCP（结构化、可断言、可集成）；需跨应用/桌面/视觉理解时用 computer-use 类 Agent；两者可结合（Playwright MCP 做主流程，computer-use 补跨应用跳转）。测试工程优先确定性、可断言性，故 Playwright MCP 更主流。

取舍的核心是"确定性 vs 通用性"。测试需要可断言、可复现、可集成，Playwright MCP 的浏览器结构化能力更契合；通用 computer-use 偏通用但断言/复现弱，适合跨应用补充。

• 沙箱化
• headless/临时 profile/凭据隔离
• 成本时长控制

CI/CD 中运行 Playwright MCP 需沙箱化与成本/时长控制。沙箱化：headless——CI 用无头模式运行（无界面、省资源、安全）；临时 profile——用临时浏览器 profile/context，用完即弃，隔离测试状态，避免污染与残留；凭据隔离——测试凭据（登录态、token）用环境变量/密钥管理（secret）注入，不硬编码、不落到日志，不同环境隔离凭据。成本/时长控制：Playwright MCP 的 AI 调用有 token/API 成本，需控制——限制 AI 调用次数（每用例最大步骤/重试）、控制 snapshot 频率（避免无限快照）、用缓存/复用登录态降低调用；时长控制——设超时（用例超时、步骤超时、AI 决策超时），分片并行控制总时长，避免单用例无限循环。综合：CI 中用 headless + 临时 profile + 凭据隔离保证安全，用调用次数/超时/分片/复用控制成本与时长，让 AI 测试在 CI 中可控、可预测、可审计。

CI 中 AI 测试的关键是"安全 + 可控成本"。headless/临时 profile/凭据隔离保安全，调用次数/超时/分片/复用控成本时长，让 AI 测试在 CI 中稳定可预测。

• 同类工具
• 差异
• 定位与能力层（控制/观测/测试）的差异

Chrome DevTools MCP、browser-tools 等与 Playwright MCP 都是"浏览器能力 MCP 化"，但差异明显。Chrome DevTools MCP：基于 Chrome DevTools Protocol（CDP），暴露浏览器底层能力（导航、DOM、网络、性能、控制台、调试），偏"浏览器调试/控制"视角，与 Chrome 深度绑定，细粒度但偏底层。browser-tools 类：提供浏览器控制/性能/网络采集工具，偏"观测与诊断"（如收集性能指标、切换 tab、控制台日志），能力较聚焦。Playwright MCP：基于 Playwright，提供结构化浏览器自动化（snapshot 可访问性树、导航、点击、输入、断言、截图、多浏览器），面向"自动化测试"场景，能力更完整、结构化、可断言、跨浏览器（Chrome/Firefox/WebKit）。差异总结：DevTools MCP 偏底层调试/CDP 能力、Chrome 绑定；browser-tools 偏观测/诊断；Playwright MCP 偏完整自动化测试（结构化、可断言、跨浏览器）。选型：做深度调试/CDP 控制用 DevTools MCP；做性能/网络观测用 browser-tools；做结构化 E2E 测试用 Playwright MCP。三者可结合（观测 + 测试）。

差异源于"定位与能力层"。DevTools MCP 偏底层调试、browser-tools 偏观测诊断、Playwright MCP 偏结构化自动化测试，按"控制/观测/测试"场景选择。

• 登录态/验证码
• WebAuthn/passkey
• 强加密 cookie

AI Agent 测试在登录态、验证码、WebAuthn、passkey、强加密 cookie 场景有明确的工程边界。登录态：AI 测试可复用登录态（storageState/测试账号），但避免在敏感登录流程上做破坏性操作；用测试账号而非真实账号。验证码：图形/短信验证码是人机验证，AI 无法可靠自动识别，工程上应"绕过"——测试环境关闭验证码、用可注入的测试验证码、用 API 预置登录态，而非让 AI 硬解验证码。WebAuthn/passkey：生物/密钥认证（硬件密钥、指纹）无法纯软件模拟，AI 测试边界是"用测试环境模拟/禁用 WebAuthn、用测试凭据注入、在独立环境验证"；真实 WebAuthn 流程需专门的浏览器模拟或硬件。强加密 cookie：AI 无法读取/篡改强加密 cookie（如 HttpOnly、签名），工程上不依赖 AI 解读 cookie，而是通过 API/存储态管理登录，避免在测试中解析加密 cookie。总体边界：AI 测试"绕过"而非"破解"——验证码、WebAuthn、加密 cookie 用测试环境注入/预置/模拟，聚焦业务逻辑，而非物理破解人机验证或密钥。这些"安全边界"场景需测试环境配合（测试开关、测试凭据、取消真实验证）。

这些场景的边界是"AI 应绕过而非破解"。验证码/WebAuthn/加密 cookie 属人机与安全机制，工程上用测试环境注入、预置登录态、模拟凭据，聚焦业务逻辑而非攻破安全机制。

• 内网部署
• 域账号/SSO 登录
• 凭据管理

Playwright MCP 在企业内网（无外网、域账号、内网 SSO）部署需处理网络与凭据。部署：内网无外网，需把 Playwright MCP Server 部署在内网机器/容器，浏览器与依赖需内网可访问（镜像预置、内网 npm 源）；MCP 客户端与 Server 走内网连接；若内网需代理访问外网，需配置代理。登录域账号/内网 SSO：内网 SSO（单点登录）常需登录域账号、证书、认证，Playwright MCP 需支持——用 storageState 预置已登录态（先人工登录生成 storageState 供复用）、或在测试环境配置 SSO 测试账号、处理证书/域认证；对强认证（多因素）用测试环境豁免或预置。凭据管理：域账号/SSO 凭据不能硬编码，用密钥管理（环境变量、secret 服务、内网凭据库）注入；区分"测试凭据"与"生产凭据"，内网环境用专用测试账号；凭据隔离（不同环境不同凭据）、审计凭据使用。要点：内网部署用预置镜像 + 内网依赖源 + storageState 预置登录态，凭据用密钥管理注入并隔离，聚焦业务逻辑而非处理内网认证细节。

内网部署的关键是"网络可达 + 认证与凭据"。预置镜像/依赖源解决内网，storageState 预置登录态、密钥管理注入凭据解决域账号与 SSO，避免在内网环境反复处理认证。

• AI 测试定位
• 自然语言用例生成
• 从需求到可执行脚本的生成链路

AI Agent 测试的定位是"自然语言驱动的用例生成与辅助执行"，而非"完全替代人工测试"。定位：AI 作为"测试助手"——用自然语言描述需求，AI 生成用例/测试脚本初稿、辅助探索、辅助回归，人工负责评审、精修、固化关键用例；AI 解决"写测试成本高、覆盖慢"的痛点，但"精度、稳定性、业务判断"仍需人工。自然语言用例生成：把自然语言需求（如"验证登录后能修改密码"）转化为测试用例——AI 解析需求得出测试步骤（导航、输入、断言）、生成可执行测试脚本（Playwright 代码或 MCP 操作序列）、生成立即断言与数据；通过"需求→步骤→脚本→断言"的生成链路。实现要点：清晰的 prompt 模板（描述需求、前置条件、预期、边界）、AI 生成初稿、人工 review 与修正、生成用例纳入现有测试体系（复用 fixture/选择器/断言）；用"生成 + 校验"保证质量（AI 生成后自动运行验证）。定位是"AI 辅助生成、人工把关"，把自然语言需求快速转化为可执行用例，降低编写门槛、提升覆盖速度。

AI 测试的定位是"辅助生成 + 人工把关"。自然语言用例生成把需求快速转为可执行脚本，但需人工评审固化为稳定回归，AI 是"提质增效的助手"而非"替代者"。

• 审计与追溯
• 操作日志/决策依据/截图
• 合规要求

AI Agent 测试结果需审计与追溯，尤其涉及敏感操作与合规。留存内容：操作日志——AI 执行的每一步工具调用（导航、点击、输入）时序记录，含参数与结果；决策依据——AI 的决策过程（为何选择某操作、基于什么 snapshot/观察），记录"决策上下文"；截图证据——关键步骤/断言/失败时的截图，作为视觉证据。留存实现：MCP Server 记录每次工具调用的日志（工具名、参数、结果、时间、浏览器上下文）；AI Agent 记录决策轨迹（prompt、中间推理、选择）；把截图/瀑布流与操作日志关联，形成"时间线证据链"。审计与追溯：把操作日志、决策依据、截图保存到可审计的存储（CI artifact、报告、审计系统），关联用例/提交/环境元数据；支持"回放"（trace 重放 AI 操作）与"追溯"（定位到具体步骤、决策、证据）。合规要求：涉及敏感数据（凭据、PII）时，日志脱敏（不落 token/密码）；操作留痕（谁/AI 在何时对什么做了操作）；满足审计合规（可查、可证明、可追溯）。设计：全链路留痕 + 决策可见 + 证据可回放 + 敏感脱敏，形成满足质量追溯与合规的审计体系。

AI 测试更需审计，因"决策不可见"。操作日志、决策依据、截图证据三者结合形成可回放、可追溯的证据链，配合脱敏与留痕满足质量与合规要求。

• MCP 集成
• 工具注册
• 调用链

MCP 与测试工具的集成通过"工具注册 + 标准化调用链"实现。工具注册：测试工具（如 Playwright MCP、Selenium 封装、自定义断言工具）以 MCP 工具形式注册到 MCP Server——每个工具定义名称、描述、参数 schema（JSON Schema）、返回格式；MCP Server 维护工具清单并向 AI 客户端暴露（工具列表、能力描述）。调用链：AI 客户端调用 MCP 工具 → MCP Server 验证参数 → 转发到测试工具执行（如 Playwright 操作）→ 返回结构化结果 → AI 解析结果并继续决策；形成"AI → MCP Server → 测试工具 → 浏览器"的调用链。集成要点：工具描述清晰（让 AI 理解何时用）、参数 schema 完整（约束输入）、返回结构化（支撑决策）、错误处理（返回错误信息供 AI 调整）；用统一的 MCP 协议接入（任意语言/框架的测试工具都可注册）。分层：工具层（测试能力）→ MCP 层（协议/注册）→ Agent 层（AI 决策），形成可扩展的集成体系。这样测试工具能力"暴露给 AI"，AI 通过 MCP 调用链编排测试。

集成的本质是"把测试能力注册为 AI 可调用的工具"。工具注册让 AI 知晓能力，标准调用链让 AI 无感调用测试工具，形成可扩展的 AI 驱动测试体系。

• 断言质量验证
• 生成断言的风险
• 变异/注入验证与人工评审的结合

AI 生成的断言质量需验证，因为"弱断言"或"错误断言"会使测试失效。验证方法：一是断言强度检查——评估断言是否"捕获了关键业务结果"：是否断言了状态/结果文本/数据变化，而非只断言"元素存在/页面不报错"（弱断言）；检查断言是否覆盖"预期后果"（如提交后数据更新、状态变化）。二是断言的"阳性/阴性"验证——验证断言能捕获真缺陷（把断言放到会失败的场景验证是否能真的失败，即"有效性"）；避免"断言恒真"（永远通过，测不出 bug）。三是断言多样性——检查是否覆盖状态码、响应体、数据落库、UI 状态等多层，而非单一维度。四是运行验证——AI 生成断言后自动运行测试，验证断言在"正确路径"通过、在"注入错误"时失败（mutation 测试思想：篡改代码/数据看断言是否捕获）。五是人工评审——由测试专家 review 断言逻辑，确认其符合业务预期。综合：用"强度检查 + 有效/无效验证 + 变异测试 + 专家评审"验证 AI 断言质量，确保断言"能测、测得准、能抓缺陷"。

AI 断言的风险是"弱、错、恒真"。验证核心是"断言能否真正捕获缺陷"——强度检查判别弱，变异/注入验证判别有效性，人工评审把关业务正确性。

• AI 测试稳定性
• 选择器策略
• 等待策略

AI 测试的稳定性依赖选择器与等待策略。选择器策略：AI 定位元素应优先用"可信语义选择器"——getByRole（角色）、getByText（文本）、getByLabel（标签）、data-testid（稳定属性），而非脆弱的绝对 CSS/XPath 或依赖不可信内容的选择器；让 AI 通过 snapshot 的可访问性树选择语义定位，避免硬编码脆弱选择器；对动态元素用稳定属性/相对定位。等待策略：AI 操作前应等待元素就绪——用 Promise 的 auto-wait（Playwright 自动等待可操作）或显式等待可交互状态，避免"操作过快"（元素未就绪）；AI 操作后用 snapshot/断言确认结果，必要时重试；避免固定 sleep（AI 决策不固定时长）；对异步加载用"等待业务终态"。稳定性设计：给 AI 提供"稳定定位 + 自动等待"的约束（prompt 中要求用语义选择器、依赖 auto-wait），把 AI 的定位与等待引导到稳定路径；用重试与快照反馈兜底。综合：AI 选择器用可信语义、等待用 auto-wait/业务终态，配合重试与快照，提升 AI 测试稳定性。

AI 测试稳定性关键是"引导 AI 用稳定手段"。语义选择器（role/text/testid）+ 自动等待/业务终态 + 重试兜底，让 AI 的定位与等待可靠，减少 flaky。

• 多模态 AI 测试
• 截图理解
• 目标定位与步骤执行验证

多模态 AI Agent（视觉 + 浏览器操作）通过"看截图"驱动操作，测试要点围绕截图理解、目标定位与步骤执行。截图理解：验证 AI 是否正确理解截图——截图内容识别（元素、文本、布局、视觉状态）、能从截图判断"页面状态"（加载中/完成/错误），要点是验证"看懂了"（如识别验证码区域、识别按钮位置）；用"截图 + 可访问性树"结合（视觉理解 + 语义结构）提升准确性。目标定位：验证 AI 能否从截图/视觉定位到目标操作位置——基于视觉位置点击、避开遮挡、识别点击目标；要点是验证"点的对不对"（坐标/元素命中），用视觉定位 + 语义锚点交叉验证避免误点。步骤执行验证：验证 AI 执行的操作序列是否正确——每步结果（操作后页面变化）、最终结果（目标达成）、步骤间连续性（无多余/遗漏）；验证方法：用操作日志 + 截图对比（每步前后截图）、断言最终状态、人工/自动化复核步骤合理性。综合：多模态测试要点是"截图理解准确 + 目标定位正确 + 步骤执行可验证"，用"截图+语义+操作日志+断言"形成闭环验证，防止视觉理解偏差导致误操作。

多模态 AI 的核心风险是"视觉理解偏差"。截图理解看"懂不懂"、目标定位看"点得准不准"、步骤执行看"做得对不对"，用语义锚点、操作日志与断言交叉验证。