脚本明明执行了，Trace 里也看到了点击，日志最后却只剩一个 timeout。

很多人在 MCP 调浏览器失败后，会第一时间盯着报错看：

timeout
target closed
locator not found
navigation failed

然后开始加等待、改选择器、加重试。

但这类问题很多时候不是脚本单点报错，而是三份信息没对齐：

日志记录的是“代码做了什么”；
Trace 记录的是“页面上发生了什么”；
环境快照记录的是“这次任务到底跑在什么环境里”。

只看其中一份，很容易把环境问题误判成普通 Chrome 调试问题。

先看故障现象，不要先改脚本

遇到 MCP 浏览器任务失败，我一般会先看是不是下面几类现象：

同一段脚本本地能跑，接到 Agent 或 MCP 后偶发失败；
Trace 里能看到页面打开和点击，但日志显示超时；
同一个 task 在不同重试里跳到了不同账号、不同语言、不同代理出口；
明明复用了登录态，任务却又回到了登录页。

如果出现这些现象，问题可能不在“动作有没有执行”，而在“动作执行时绑定的是哪个环境、哪个会话、哪个浏览器实例”。

这里没分清，后面继续改 selector、加 retry、加 wait，通常只是在放大噪音。

环境快照、Trace、日志分别看什么

这三类信息不要混着看。

信息类型	主要回答的问题	应该包含什么	单独看时的局限
日志	代码执行到了哪一步	task_id、action、url、locator、result、trace_id	看不到页面真实状态
Trace	页面和动作实际发生了什么	点击、输入、网络等待、DOM 变化、截图时间线	不知道这次运行绑定了哪个环境
环境快照	任务跑在什么上下文	profile_id、代理出口、时区、语言、浏览器实例、会话标识	不一定能反映具体失败动作

最常见的误判，是看到 Trace 里的点击失败，就直接认为 selector 有问题。

但真实原因可能是：这次任务跑进了错误 profile，或者 MCP 连接到的根本不是你以为的浏览器上下文。

推荐排查顺序

我建议固定按这个顺序查，不要一会儿看日志，一会儿改脚本。

1. 先确认自动化入口是不是唯一

先确认这次任务到底是通过 MCP 调用，还是 Playwright 直连，或者 CDP 附着到已有浏览器实例。

如果入口不唯一，日志和 Trace 可能根本不是同一次运行。

这时你看到的“点击失败”，可能只是另一个浏览器上下文里的动作结果。

2. 再核对环境边界

确认同一个 task_id 对应的这些信息是否一致：

profile_id
代理出口
语言
时区
浏览器实例 ID
会话标识
Trace ID

这里就是环境快照要解决的问题。

如果 task 重试后 profile 变了，或者代理出口变了，后面看到的 Trace 再完整，也只能说明“另一个环境里发生了什么”。

3. 再看会话边界

不要只盯 Cookie。

很多站点的登录态还依赖 LocalStorage、IndexedDB、设备状态、浏览器指纹、语言时区和网络出口。

所以你要确认的是：当前登录态是不是属于当前 profile，而不是上一次运行残留，或者另一个账号环境里的状态。

4. 最后再看动作层

到了这一步，才看 Trace 里的 selector、等待条件、页面跳转和网络请求。

也就是说，先确认任务跑在正确环境里，再判断动作是不是写错了。

否则你很可能会在错误环境里调一个正确脚本。

最少要记录哪些字段

如果现在还没有 task_id 贯穿日志、Trace、截图和环境快照，建议先补这个。

最小记录粒度可以类似这样：

recordStep({
  taskId,
  profileId,
  browserInstanceId,
  proxyId,
  action,
  url,
  locator,
  result,
  traceId,
  timestamp
})

这里的重点不是字段多，而是每一步都能回答三个问题：

这是谁的任务？
它跑在哪个浏览器环境里？
它对应哪一份 Trace 和截图？

只要这三件事串不起来，后面的复盘都会很痛苦。

MCP 调浏览器的最小验证步骤

不要一上来跑完整业务流程。
先做最小验证。

步骤	验证目标	通过标准
1	固定一个 profile 和一个代理出口	同一 task 重试后环境 ID 不变
2	打开 IP 检测页或固定测试页	页面表现与预期出口、语言时区一致
3	只执行打开页面、读取标题、点击稳定元素	日志、Trace、截图时间线能一一对应
4	再加入登录态复用或复杂流程	失败时能明确落到 environment、state 或 selector

这里有个实用判断点：

如果最小动作稳定，但一接入多账号环境、任务恢复或 Agent 接管就开始漂移，那么问题更像环境编排，而不是 Playwright 本身。

这时选型重点就不该只看脚本框架，而要看浏览器环境、Profile、代理和任务记录能不能稳定绑定。

MCP + Trace 复盘时最容易踩的坑

把 timeout 当成根因

timeout 通常只是结果，不是根因。

真正的问题可能是环境切错、登录态失效、网络等待条件不成立，也可能是 Agent 在错误页面上继续规划动作。

只看日志，不看环境快照

日志会告诉你“点了登录按钮”。

但它不会告诉你，这个按钮是在中文环境、英文环境，还是另一个账号上下文里被点的。

只看 Trace，不看会话

Trace 很容易让人误以为页面流程没问题。

但如果当前 profile 已经漂移，你看到的每一步都可能是错上下文里的“正确动作”。

一上来就改 selector

selector 当然可能有问题。

但如果环境、会话、入口都没确认，先改 selector 很容易越改越乱。

尤其是 AI Agent 接浏览器时，失败不一定发生在动作层，也可能发生在环境绑定层。

修复建议

如果已经确认问题来自边界不清，修复顺序也应该按层来。

先固定自动化入口。
再固定浏览器实例和 profile 绑定。
再把登录态维护从 prompt 层移到环境层。
最后才优化 selector、等待策略和重试逻辑。

长期看，团队最好把失败归因统一分成几类：

network
auth
selector
state drift
agent planning
environment mismatch

这样下次再遇到“脚本像是执行了，但结果不对”，就不会继续把所有问题都归到 Chrome 调试或前端页面波动上。

MCP 调浏览器失败后，最重要的不是马上多加几行 wait。

而是先把日志、Trace 和环境快照对齐。

只要能回答清楚这三个问题：代码做了什么、页面发生了什么、任务跑在哪个环境里，大多数浏览器自动化问题都会变得好查很多。