1. 为什么要在 Dify 里接 Chrome MCP如果你已经用 Dify 搭过聊天助手会发现它有个天然短板只能“说”不能“做”。你问它今天某网站头条是什么它要么凭训练数据瞎猜要么告诉你“我无法访问实时网页”。而 Chrome MCP 正好补上这块——它把真实 Chrome 浏览器包装成一组可调用的工具打开页面、点击、输入、抓取 DOM让大模型从“嘴替”变成“手替”。这套组合适合谁三类人最划算一是做数据采集但不想写爬虫的开发者页面结构一变就改选择器太痛苦二是做自动化测试或运营流程的团队想让 AI 按自然语言跑一遍注册、填表、下单三是做 Agent 产品的同学需要一个能落地“网页操控”能力的执行层。Dify 负责编排和对话管理Chrome MCP 负责真实浏览器动作中间用 MCP 协议打通分工干净。我实测下来整条链路最容易被卡住的不是模型而是 MCP 服务的接入参数和 Dify 里的工具描述。下面按“先跑通、再调优”的顺序走一遍每一步都给可复制的配置。2. 前置准备Dify 与 Chrome MCP 环境2.1 两个服务的角色划分先把架构说清楚后面排障才有方向。Dify 是编排层它把用户的一句话拆成“打开页面 → 定位输入框 → 输入关键词 → 点击搜索 → 读取结果”这样的步骤序列然后通过 MCP 协议把每个步骤发给 Chrome MCP 服务。Chrome MCP 是执行层它启动一个真实的 Chrome 实例用 CDPChrome DevTools Protocol驱动浏览器完成动作再把结果页面文本、元素状态、截图回传给 Dify。这里有个关键点Dify 本身不直接控制浏览器它只是 MCP Client。所以 Chrome MCP 服务必须独立运行并且 Dify 能通过网络访问到它。本地开发时两者都在 localhost 没问题一旦 Dify 跑在 Docker 里就要注意容器网络和宿主机端口的映射关系这是后面“连接失败”排查的核心。2.2 环境清单与版本要求动手前确认这几样Docker 与 Docker Compose用于跑 Dify官方 compose 文件最省事。Node.js 18 或更高Chrome MCP 服务基于 Node 运行低版本会报语法错误。本机已安装 ChromeMCP 服务默认调用系统 Chrome没装会启动失败。一个可用的模型 API KeyDify 里要配模型供应商否则工作流无法推理。如果你还没决定用哪家模型可以先用 TaoToken 的模型对话快速验证一下模型连通性确认 Key 能用再往 Dify 里填省得在 Dify 配置页反复试错。地址是 https://taotoken.net/api 模型对话入口在 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。2.3 获取模型 Key 与接入信息在 TaoToken 控制台创建 API Key拿到形如sk-xxxx的字符串。接入文档里会给出 base_url通常是https://taotoken.net/api这样的 OpenAI 兼容端点。Dify 的模型供应商配置里选“OpenAI-API-compatible”把 base_url 和 Key 填进去即可。这一步别急着在 Dify 里点“保存”先确认 Key 在模型对话里能正常返回避免后面把模型报错误判成 MCP 问题。控制台入口 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite3. 可复制配置Dify 工作流 Chrome MCP 接入3.1 启动 Dify 服务用官方 compose 最快。新建目录后拉取配置并启动mkdir dify-chrome-mcp cd dify-chrome-mcp curl -o docker-compose.yml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yml docker compose up -d等一两分钟访问http://localhost:80首次进入要创建管理员账号。如果你本机 80 端口被占用改 compose 里的端口映射比如8080:80后面所有地址相应换成 8080。3.2 安装并启动 Chrome MCP 服务另开一个终端安装 MCP 服务并启动npm install -g modelcontextprotocol/server-chrome server-chrome启动成功后终端会打印监听地址和 Chrome 连接状态类似Server running on http://localhost:9999。如果 Chrome 没自动弹出检查系统是否装了 Chrome或用环境变量指定路径CHROME_PATH/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome server-chrome3.3 settings.json 骨架与参数说明Chrome MCP 支持用配置文件管理启动参数放在项目根目录或用户目录下均可。下面是一份可直接改的骨架{ mcpServers: { chrome-automation: { command: server-chrome, args: [--port, 9999, --timeout, 60000], env: { CHROME_PATH: /usr/bin/google-chrome, HEADLESS: false, USER_DATA_DIR: ./chrome-profile } } } }几个参数值得单独说--timeout控制单次操作等待上限复杂页面建议 60000 毫秒起HEADLESS设为 false 方便你肉眼观察 AI 的操作过程调试完再改 true 提速USER_DATA_DIR指定用户数据目录能保留登录态做需要登录的自动化时非常关键。改完配置重启服务生效。3.4 在 Dify 中注册 MCP 服务器回到 Dify 管理界面进入“设置 → 模型供应商 → MCP 服务器”点添加。填写名称Chrome-Automation类型SSE 或 HTTP按你的 MCP 服务实际协议选URLhttp://localhost:9999点验证出现绿色成功提示即接入完成。如果 Dify 跑在 Docker 里localhost指向容器自身要改成宿主机的可达地址比如http://host.docker.internal:9999Mac/Windows或宿主机内网 IPLinux。3.5 编排一个最小工作流在 Dify 里新建“工作流”应用加一个“Agent”节点把 Chrome-Automation 这个 MCP 工具挂上去。系统提示词写清楚职责比如“你可以调用浏览器工具完成网页操作。每次操作前先确认当前页面状态操作后读取结果再决定下一步。”然后接一个“开始”节点接收用户输入再接“结束”节点输出结果。保存后就能在预览里测试。4. 验证请求让助手真的操控网页4.1 场景一自动搜索并读取结果在 Dify 预览框输入“打开百度首页在搜索框输入‘Dify 工作流’点击搜索告诉我第一条结果的标题。”观察 Chrome 窗口是否自动打开、输入、点击。如果一切正常Dify 会返回类似“第一条结果是《Dify 工作流入门》”的文本。这一步验证的是“打开 输入 点击 读取”四个基础动作的串联。4.2 场景二表单填写与提交换一个带表单的测试页输入“打开 https://example.com/contact姓名填‘张三’邮箱填‘zhangsanexample.com’留言填‘咨询产品’点击提交。”重点看输入框定位是否准确。如果 AI 填错字段多半是工具描述里对元素定位的说明不够需要在提示词里补充“优先用 label 文本或 placeholder 定位”。4.3 场景三抓取列表并做简单分析输入“打开某新闻列表页抓取所有标题和发布时间按时间倒序排列总结今天最热的话题。”这个场景考验的是 DOM 读取和结果回传的完整性。如果返回内容被截断检查 MCP 服务的响应大小限制或在提示词里要求“分批读取每批不超过 20 条”。4.4 用 curl 直接验证 MCP 服务不想每次都开 Dify 的话可以直接打 MCP 服务的健康检查或工具列表接口curl -s http://localhost:9999/health curl -s http://localhost:9999/tools | head -c 500能返回工具清单说明服务本身没问题问题就缩小到 Dify 的接入配置或模型推理环节。5. 本篇常见错排查5.1 Chrome 启动失败报错通常是Chrome executable not found。先确认系统装了 Chrome再用CHROME_PATH显式指定。Linux 服务器没图形界面时要装xvfb并配合 headless 模式否则 Chrome 起不来。5.2 Dify 连接 MCP 失败分两种情况Dify 和 MCP 都在宿主机检查 9999 端口是否被防火墙拦Dify 在 Docker 里localhost不通换成host.docker.internal或宿主机 IP。另外确认 MCP 服务监听的是0.0.0.0而不是仅127.0.0.1否则容器访问不到。5.3 操作超时页面加载慢或元素还没渲染出来就操作会报 timeout。把--timeout调到 60000 以上并在提示词里要求 AI“等待页面加载完成后再操作”。有些 SPA 页面需要额外等待可以在工作流里加一个延时节点。5.4 元素定位不准AI 点错按钮或填错框是网页操控最常见的坑。解决办法有两个一是在提示词里给出更明确的定位策略比如“用按钮文本‘提交’定位”二是让 MCP 先返回页面可交互元素列表AI 从中选择而不是凭猜测直接操作。5.5 登录态丢失每次启动都是全新会话需要登录的站点会卡在登录页。用USER_DATA_DIR指定持久化目录手动登录一次后后续启动复用该目录即可保留 Cookie。注意这个目录不要提交到版本库里面有敏感凭证。6. 长期编码与 Agent 场景的接入建议如果你打算把“Dify Chrome MCP”做成长期跑的自动化 Agent比如每天定时抓数据、监控页面变化那模型调用的稳定性和成本就要认真考虑。频繁的网页操作会产生大量多轮推理按量计费的模式下成本不好控。这种场景更适合用 Coding Plan 这类面向长期编码和 Agent 的套餐把预算固定下来同时保证调用不中断。Coding Plan 入口 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入文档里有完整的 MCP 工具定义和参数说明建议在编排复杂工作流前先过一遍尤其是工具返回值的结构这决定了你在 Dify 里怎么写条件分支。文档地址 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后给一个实操建议先用 headlessfalse 把流程跑通肉眼确认每一步动作都对再切 headlesstrue 上量。调试阶段把 MCP 服务的日志级别调高出错时能看到具体的 CDP 命令和响应比在 Dify 界面猜要快得多。