chrome mcp server 自动化

你大概遇到过这种情况：想让 Agent 自己去点网页、填表单、抓数据，教程上来就是一堆 npm 安装命令，装完却不知道浏览器那边到底要开什么、连不上从哪查。这篇按落地顺序讲三件事——环境怎么备、第一个动作怎么跑通、跑起来之后超时和并发怎么定。不深挖协议原理，只给能照着做的步骤和排查顺序。

想让 Agent 自己去点网页、填表单、抓数据，最容易卡住的不是代码写不出来，而是浏览器那头没接上。你装完一堆依赖、注册完服务，一跑就报连不上，然后开始到处翻日志，其实问题往往出在环境没备干净。这篇按落地顺序讲三件事：环境怎么备、第一个动作怎么跑通、跑起来之后超时和并发怎么定。不深挖协议，只给能照着做的步骤和排查顺序。

先给个预期：这套东西第一次跑通大概要花掉你半小时到一小时，其中一半时间会花在浏览器侧的准备工作上。别急着写复杂的多步任务，先用一个最简单的动作验证链路通了，再往上叠。链路没通时写的任何自动化逻辑，都是白写。

先备好这三样，再谈自动化

环境准备分三块：浏览器侧、服务侧、Agent 侧。三块都对齐了再谈自动化，否则你会在「到底是哪一层没通」上浪费大量时间。下面这张对照表可以当开工前的检查清单用，每一项都要能明确回答「是」或「否」。

• 独立用户数据目录：新建一个专门给自动化用的目录，别复用你平时登录各种账号的那个 profile，通知弹窗和登录态都会干扰
• 绝对路径：启动命令、Server 入口文件、工作目录全部写绝对路径，相对路径在不同工作目录下启动时行为不一样
• 最小工具集：第一次只暴露「打开页面」和「读标题」两个能力，通了再加点击和输入
• 版本可查：把浏览器和运行环境的版本号记在配置文件里，升级后出问题能快速对比
• 参考实现：MCP Server 条目的字段写法可以直接到 /mcp 看现成的例子，照抄改路径比从零写快

第一个动作跑通：打开、定位、回读

单个动作的执行顺序是固定的：打开目标页、等待可交互、定位元素、执行动作、回读结果。这五步里最容易偷懒跳过的是「等待可交互」和「回读结果」。前者跳过，你会在页面还没渲染完时去找元素；后者跳过，你根本不知道动作到底成没成。

1. 打开目标页让 Agent 访问一个结构简单、不需要登录的公开页面作为起点。验证方式：返回的当前 URL 和你传入的一致。
2. 等待可交互设一个元素出现的等待条件，而不是死等固定秒数。验证方式：日志里能看到等待耗时，正常情况下应该是几百毫秒级而不是顶到上限。
3. 定位元素优先用稳定的选择器或可访问性角色，别用带随机后缀的样式类名。验证方式：先查命中数量，确认是 1 个而不是 0 个或多个。
4. 执行动作点击或输入后立刻回读关键状态，比如按钮文案变了、列表多了一行。验证方式：回读结果里带成功标志和关键文本。
5. 回读结果让 Agent 返回结构化结果：成功与否、当前 URL、抓到的关键文本。验证方式：你能在日志里判断它走到了哪一步。

选择器不要硬编码在提示词里，放进配置文件。硬编码在提示词里的选择器改起来要动提示词，改配置只要动一行，而且能让多个动作复用同一份定位规则。定位规则本身也会随页面改版失效，集中管理才好维护。

卡住时按固定顺序查，别跳步：先看进程起没起，再看端口或通道通不通，然后确认页面是不是真到了目标地址，最后看选择器命中几个。这个顺序能覆盖大部分问题。传输方式和命令路径这类具体报错，站内 mcp-connection-troubleshoot 那篇有更细的排查步骤，可以对着走一遍。

超时、并发与失败重试怎么定

超时不要用一个总上限兜底，要拆成三档：元素出现、页面加载完成、整体动作结束。三档分别设上限，哪一档先触发，你就知道问题出在渲染慢、网络慢还是逻辑卡住。用一个总超时的话，报错信息永远只有一句「超时了」，没法定位。

元素超时

等某个元素出现的最长时间，设短一点，触发通常意味着选择器错了或页面结构变了

加载超时

等页面进入可交互状态的最长时间，触发通常是网络或第三方脚本拖慢

动作超时

单次完整动作的总上限，设成前两档的合理倍数，触发说明逻辑本身有问题

幂等标识

给填表提交类动作加一个唯一标记，重试时先查这个标记，避免重复写入

• 单实例串行：一个浏览器实例建议串行跑动作，先别急着开多个标签页并行
• 先问站点：要并发之前先确认目标站点是否允许，很多站点对高频访问有风控
• 重试范围：只在读取、打开这类幂等动作上重试，填表和提交要配合去重标识
• 崩的是浏览器：并发拉高时最先出问题的往往不是模型推理，而是浏览器实例本身
• 指标三件套：失败率、平均单步耗时、重试次数，比只看一个成功率有用得多

延迟基线建议先量一遍再定阈值，别凭感觉设。你可以拿 /tools/speed-test 对目标页面测一轮，拿到当前网络和渲染下的正常耗时区间，再把超时上限设成这个区间的合理倍数。之后每次出问题，先跟这个基线比，是整体变慢了还是某个动作单独变慢了，一眼能分出来。

日志与回归：怎么知道它变差了

自动化跑起来之后，最大的问题不是它失败，而是它悄悄变差了你没发现。今天能过、明天要重试三次才过，这种缓慢退化不会报警。解决办法是把高频动作固化成小用例，定期跑一遍，跟上次的结果对比。

每次动作至少记这几样：时间、目标 URL、实际用的定位器、结果、耗时。定位器要记实际用的那个，因为配置改了之后你得能回看是哪次改动引入了问题。字段怎么设计可以参看站内 api-log-fields-replay 的思路，那里对回放需要的字段讲得比较细。

• 固化用例：挑十个左右高频页面动作，写成能一键跑的小用例
• 改配置必跑：升级 Server 或改定位器之后跑一遍，比人工点一遍快也准
• 看两件事：原本能过的现在过不过、原本几步现在几步
• 步数异常：步数突然变多，通常意味着某个定位器开始不稳，及早换掉
• 别追全部：不是所有动作都值得进用例，挑影响面大的那几个就够

这套流程的边界要说清楚：它适合结构相对稳定、访问频率可控的页面。如果目标页面每次加载结构都在变、或者站点明确限制自动化访问，那再怎么调超时和重试也不划算，该考虑换数据来源或走官方接口。这种情况不适合硬扛，早点换方案比优化参数省事。