1. 为什么你的 AI 助手只会“说”不会“点”很多人第一次用 Dify 搭 AI 助手时都会遇到同一个尴尬模型能写出一段漂亮的“点击登录按钮”的说明但真到页面上它连按钮在哪都不知道。原因不复杂——大模型本身没有浏览器的手它只能输出文本不能操作 DOM。想让 AI 真正打开网页、填表单、抓元素中间必须有一层“执行器”而 Chrome MCP 就是干这个的。MCP 全称 Model Context Protocol你可以把它理解成 AI 和外部工具之间的“USB 接口标准”。以前每接一个工具都要写一套私有适配现在只要工具实现了 MCP ServerDify 就能用统一方式调用。Chrome MCP 则是专门把 Chrome 浏览器包装成 MCP 工具的服务它通过 Chrome DevTools Protocol 控制页面能执行点击、输入、滚动、截图、读取元素等操作。这套组合适合谁做自动化测试的同学可以用它把自然语言用例直接跑成浏览器操作做数据采集的同学可以让 AI 按语义找元素而不是死磕 CSS 选择器做业务流程自动化的同学可以把重复表单交给 AI 助手。本文会从 Dify 工具节点配置讲到 MCP 服务地址与鉴权参数最后跑一次端到端网页操作验证中间所有配置片段都可以直接复制。需要提前说明的是Dify 调用模型和 MCP 工具时都需要稳定的 API 通道。我这边统一用 TaoToken 做 Key 和 API 管理官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 后面配置里出现的 Base URL 和 Key 都从这里取。2. TaoToken 前置准备统一 Key 与 API 通道怎么配在把 Dify 和 Chrome MCP 接起来之前先把模型通道理顺。Dify 的工作流节点在调用 LLM 时需要填 API Base 和 API Key。如果你同时用多个模型每个都单独配 Key 会很乱TaoToken 的作用就是把这些通道统一成一个入口。第一步打开 https://taotoken.net/api 对应的控制台进入 API Keys 页面创建一个新 Key。建议按用途命名比如dify-chrome-mcp方便后面排查是哪个应用在调用。创建后立刻复制保存页面刷新后完整 Key 不会再显示。第二步确认你要用的模型 ID。Dify 的模型供应商配置里需要填 Model ID常见的有claude-sonnet-4-5、gpt-4o这类。如果你不确定当前账号支持哪些可以在模型对话页面先试跑一句确认返回正常再写进 Dify。第三步把 Base URL 和 Key 填进 Dify。进入 Dify 的“设置 - 模型供应商”选择 OpenAI 兼容或 Anthropic 兼容类型Base URL 填https://taotoken.net/apiKey 填刚才创建的那串。保存后点“测试”返回 200 即通。这里有个容易踩的坑Dify 里有些供应商模板默认会拼接/v1而 TaoToken 的 API 地址已经包含版本路径重复拼接会导致 404。如果你测试时报model not found或invalid url先检查 Base URL 末尾有没有多余的/v1。配置完成后建议在 Dify 里建一个最小的“LLM 节点”工作流输入“返回 ok”确认模型通道没问题。这一步单独验证能避免后面把模型问题和 MCP 问题混在一起排查。模型通道通了再进入 Chrome MCP 的配置。3. 可复制配置Chrome MCP 服务与 Dify 工具节点这一节是全文最核心的部分所有片段都可以直接改路径后使用。先配 Chrome MCP Server再配 Dify 工具节点最后把两者用鉴权参数串起来。3.1 Chrome MCP Server 的 JSON 配置Chrome MCP 通常以 Node 服务形式运行你需要先确认本机装了 Node 18 和 Chrome。安装依赖后在项目目录创建mcp-config.json{ mcpServers: { chrome: { command: node, args: [/Users/yourname/chrome-mcp-server/dist/index.js], env: { CHROME_PATH: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome, HEADLESS: true, PORT: 8931, AUTH_TOKEN: sk-mcp-chrome-2024 } } } }三个关键点args里的路径必须指向你实际编译后的index.jsWindows 下路径要写成C:\\chrome-mcp-server\\dist\\index.jsCHROME_PATH指向本机 Chrome 可执行文件AUTH_TOKEN是自定义的鉴权串后面 Dify 调用时要带上同一个值。启动服务node /Users/yourname/chrome-mcp-server/dist/index.js --config ./mcp-config.json看到MCP server listening on 8931就说明起来了。此时可以用 curl 探活curl -X POST http://127.0.0.1:8931/mcp \ -H Authorization: Bearer sk-mcp-chrome-2024 \ -H Content-Type: application/json \ -d {jsonrpc:2.0,method:tools/list,id:1}返回里应该能看到navigate、click、type、extract等工具名。如果返回 401说明 AUTH_TOKEN 没对上如果连接被拒检查 PORT 是否被占用。3.2 Dify 工具节点配置片段进入 Dify 工作流添加一个“自定义工具”节点类型选 MCP。配置如下{ name: chrome_mcp, transport: http, url: http://127.0.0.1:8931/mcp, headers: { Authorization: Bearer sk-mcp-chrome-2024, Content-Type: application/json }, timeout: 30000, tools: [navigate, click, type, extract, screenshot] }注意url必须是 MCP 服务的完整路径不要只写http://127.0.0.1:8931。timeout建议不低于 30000因为页面加载和元素等待可能超过默认的 10 秒。tools列表按需勾选勾多了会增加模型选择工具的负担。如果你用的是 Claude Code 或 Cline 这类客户端配置结构类似但字段名可能是baseUrl和apiKey。三件套永远是Base URL、Key、Model ID。在 Dify 里对应的是 MCP URL、AUTH_TOKEN、以及 LLM 节点的模型 ID三者缺一不可。3.3 工作流串联从用户输入到浏览器动作在 Dify 里建一个 Chatflow节点顺序是开始 → LLM意图解析→ 工具节点chrome_mcp→ LLM结果整理→ 结束。LLM 节点的系统提示词里要明确告诉模型可用工具例如你可以调用 chrome_mcp 的 navigate、click、type、extract 工具。用户要求操作网页时先 navigate 到目标 URL再根据页面结构选择 click 或 type最后用 extract 读取结果。工具节点的参数映射用变量引用比如url绑定{{start.query}}里解析出的地址。这样一条“打开某网站搜索关键词并读取第一条结果”的链路就搭好了。4. 验证请求跑一次端到端网页操作配置写完必须验证否则你不知道是模型没选对工具还是 MCP 没执行。下面用一个最小场景让 AI 打开一个公开的示例页面输入关键词读取结果文本。4.1 构造测试输入在 Dify 预览窗口输入打开 https://example.com 找到页面主标题把标题文本返回给我。预期链路LLM 解析出需要 navigate 和 extract 两个动作工具节点依次执行最后 LLM 把 extract 的结果整理成自然语言。4.2 观察 MCP 服务日志服务端会打印类似[tool] navigate urlhttps://example.com status200 [tool] extract selectorh1 textExample Domain如果只看到 navigate 没有 extract说明模型没选对第二个工具回去检查系统提示词里有没有把 extract 的用途写清楚。如果两个都没打印说明 Dify 根本没调到 MCP检查工具节点的 URL 和鉴权头。4.3 成功结果的判断标准一次成功的端到端验证要满足三点MCP 日志里出现完整的工具调用序列Dify 工作流追踪里工具节点状态是成功最终输出里包含页面上真实存在的文本而不是模型编造的。我实测下来最容易出问题的是第三步——模型有时会“脑补”结果所以 extract 的返回值一定要在日志里核对。再进阶一点可以测表单填写让 AI 打开一个带输入框的测试页输入“hello”点击提交读取提交后的提示。这个场景会同时用到 type 和 click能验证参数传递是否正确。如果 type 报element not found多半是选择器没匹配上需要在提示词里让模型先用 extract 读取页面结构再决定选择器。5. 本篇常见错排查401、local proxy failed、reading choices这一节按真实报错来每个都给出定位路径。401 Unauthorized出现在 Dify 工具节点或 curl 探活时。原因通常是 AUTH_TOKEN 不一致或者请求头里Bearer后面多了空格。检查 MCP 配置里的AUTH_TOKEN和 Dify headers 里的值是否逐字符相同。如果用了 TaoToken 的 Key 调模型401 则要检查 Key 是否过期或额度用尽去控制台重新生成即可。local proxy failed / connection refusedDify 报这个说明它连不上127.0.0.1:8931。先确认 MCP 服务进程还在再确认 Dify 是跑在本地还是容器里。如果 Dify 在 Docker 里127.0.0.1指向的是容器本身要改成宿主机的局域网 IP比如http://192.168.1.10:8931/mcp。这是最容易被忽略的一点。reading choices of undefined这个报错来自 LLM 节点通常是模型返回结构不符合预期。检查 Dify 模型供应商的 Base URL 是否写成了https://taotoken.net/api以及 Model ID 是否拼写正确。如果返回体里没有choices字段说明请求根本没到模型服务或者被中间层拦截了。OAuth 相关报错如果你在 Claude Code 或 Codex 里配置 MCP可能会遇到 OAuth token 失效。这类客户端需要在auth.json里配置 Base URL、Key、Model ID 三件套。以 Codex 为例~/.codex/auth.json里要有{ baseUrl: https://taotoken.net/api, apiKey: sk-your-key, model: claude-sonnet-4-5 }改完重启客户端再跑一次codex auth status确认。CC Switch 或 Cline MCP 的配置逻辑一样都是这三项只是字段名不同。元素找不到 / 超时MCP 日志报element not found或timeout。先确认页面是否真的加载完可以在 navigate 后加一个等待或者让模型先 extract 页面结构再操作。选择器尽量用文本或 role不要用易变的 class 名。6. 把通道固定下来让网页操作可复用跑通一次之后建议把配置固化成模板。MCP 服务用 systemd 或 pm2 托管避免每次手动启动Dify 工作流导出成 DSL 备份TaoToken 的 Key 按应用分账号方便审计调用量。这样下次换一个网页任务只需要改提示词和 URL不用重配通道。如果你还想验证不同模型对工具调用的支持程度可以去模型对话页面直接试跑同样的提示词对比哪个模型选工具更准。长期做编码或 Agent 类任务的话Coding Plan 的额度模型更适合高频调用。接入文档里有完整的参数说明和示例遇到配置问题先查文档再排查能省不少时间。最后留一个实用技巧在 Dify 工具节点后面加一个“代码节点”把 MCP 返回的 JSON 做一次清洗只保留text和status字段再交给 LLM。这样模型不会被冗余字段干扰输出稳定性会明显提升。