支持的 API 覆盖所需字段、动作和权限时，优先用 API。任务需要网页上的专属控件或可视检查时，再用获准访问的浏览器。MCP 连接器可以封装任一路径。先定义最终业务状态，再选择接口。
从业务结果开始
写清记录 ID、期望状态、操作权限和事后可读取的证据。实验是把一条订单标为已审核。通过条件是目标订单正确，状态为 reviewed，版本为 2。状态提示或单个 HTTP 响应不足以验证这三项。
选择接口和权限
受支持的 API 给调用方提供请求和响应契约。浏览器使用授权会话中可见的控件。MCP 让 Agent 查找并调用有名称的工具。检查工具底层调用的是哪条路径、用的是哪个账号或服务权限。批准不可逆动作前核对记录和具体变更。
| 路径 | 适用情况 | 前提 | 独立核对 |
|---|---|---|---|
| API | 受支持的接口动作 | 账号或服务权限 | 读取记录和版本 |
| MCP | 工具覆盖所需动作 | 有名称的工具契约 · 工具许可和底层权限 | 回读底层记录 |
| Browser | 页面专属动作或可视证据 | 授权浏览器会话 | 重新加载并读可见状态 |
MCP Tools · Playwright MCP 入门 · 浏览器 Agent
用相同需求测试两条路径
API 路径读取 API-01 的版本 1 与 ETag，再发条件更新，返回 200。用同一个旧 If-Match 重试得到 412，独立回读仍是 reviewed、版本 2。UI 路径用 Tabbit 打开 UI-01，点击一次 Mark reviewed 并重新加载。页面仍显示 reviewed、版本 2。这些结果来自同一个合成系统。
| 试验 | 观察结果 |
|---|---|
| API 写入 | API-01 · HTTP 200 · reviewed · r2 |
| 旧 If-Match | API-01 · HTTP 412 · reviewed · r2 |
| Tabbit 点击并重载 | UI-01 · reviewed · r2 |
| 独立 API 回读 | UI-01 · reviewed · r2 |
RFC 9110 If-Match · 浏览器自动化 · 界面测试
混用时传递明确的记录 ID
批量读取和独立核对可用已获准的 API。浏览器只承担必须从 UI 操作的环节，把同一个记录 ID 交给下一步。本次独立 API 回读 UI-01，与重新加载的页面一致。没有获准的读接口时，用授权界面重新打开记录并回读状态。
Playwright API testing · 让 AI Agent 操作浏览器 · 接入现有浏览器
为变化和失败留出检查点
API 依赖接口契约、权限和并发规则。UI 依赖页面路径、控件和会话。遇到超时，先查动作是否已经生效。旧版本条件失败时重新读取业务状态，再决定是否重试。按钮缺失或含义变化时停止。
一位 QA 从业者描述了浏览器执行和 API 断言组合的做法。一位 n8n 用户把没有 API 的网页操作脚本封装成调用入口。封装能简化调用，页面依赖仍在。 Reddit QA · Reddit n8n
明确什么时候算完成
输出目标 ID、路径、最终状态和独立回读结果，释放会话前保存必要回执。日志不要存凭据和个人数据。若无法核对最终状态，标记待查，重要的变更交给人确认。
常见问题
什么时候优先使用 API？
API 的支持范围覆盖授权动作和状态读取时优先使用。必须通过页面完成的环节再走 UI。
MCP 连接器就是 API 吗？
MCP 把工具暴露给客户端。工具可封装服务 API、浏览器动作或其他实现。
可以混用 API 和浏览器吗？
可以。用稳定的记录 ID 衔接，最后独立回读业务状态。
只有 Web UI 的系统可以自动化吗？
可以在授权账号内操作获准控件。提前约定预期状态，遇到访问限制时停止。
HTTP 200 能证明业务完成吗？
在系统允许时，另读目标记录和最终业务状态。
条件更新失败或超时后怎么办？
先读当前状态，弄清实际变更后再判断是否需要重试写入。