企业官网建设流程全解析

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 实例，用 CDP（Chrome 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 运行，低版本会报语法错误。
• 本机已安装 Chrome：MCP 服务默认调用系统 Chrome，没装会启动失败。
• 一个可用的模型 API Key：Dify 里要配模型供应商，否则工作流无法推理。

如果你还没决定用哪家模型，可以先用 TaoToken 的模型对话快速验证一下模型连通性，确认 Key 能用再往 Dify 里填，省得在 Dify 配置页反复试错。地址是 https://taotoken.net/api ，模型对话入口在 https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。

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_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite API Keys 管理： https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite

3. 可复制配置：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-chrome

3.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 服务实际协议选）
• URL：http://localhost:9999

点验证，出现绿色成功提示即接入完成。如果 Dify 跑在 Docker 里，localhost指向容器自身，要改成宿主机的可达地址，比如http://host.docker.internal:9999（Mac/Windows）或宿主机内网 IP（Linux）。

3.5 编排一个最小工作流

在 Dify 里新建“工作流”应用，加一个“Agent”节点，把 Chrome-Automation 这个 MCP 工具挂上去。系统提示词写清楚职责，比如：“你可以调用浏览器工具完成网页操作。每次操作前先确认当前页面状态，操作后读取结果再决定下一步。”然后接一个“开始”节点接收用户输入，再接“结束”节点输出结果。保存后就能在预览里测试。

4. 验证请求：让助手真的操控网页

4.1 场景一：自动搜索并读取结果

在 Dify 预览框输入：“打开百度首页，在搜索框输入‘Dify 工作流’，点击搜索，告诉我第一条结果的标题。”观察 Chrome 窗口是否自动打开、输入、点击。如果一切正常，Dify 会返回类似“第一条结果是《Dify 工作流入门》”的文本。这一步验证的是“打开 + 输入 + 点击 + 读取”四个基础动作的串联。

4.2 场景二：表单填写与提交

换一个带表单的测试页，输入：“打开 https://example.com/contact，姓名填‘张三’，邮箱填‘zhangsan@example.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_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite

接入文档里有完整的 MCP 工具定义和参数说明，建议在编排复杂工作流前先过一遍，尤其是工具返回值的结构，这决定了你在 Dify 里怎么写条件分支。文档地址： https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

最后给一个实操建议：先用 headless=false 把流程跑通，肉眼确认每一步动作都对，再切 headless=true 上量。调试阶段把 MCP 服务的日志级别调高，出错时能看到具体的 CDP 命令和响应，比在 Dify 界面猜要快得多。