1. 为什么你的 AI 助手只会“动嘴”，不会“动手”
很多人用 Dify 搭出来的聊天助手，本质上还是个“问答机器”：你问它答，它没法帮你打开网页、填表单、点按钮。想让 AI 真正操作浏览器，需要给它配一双“手”——这就是 Chrome MCP 的价值。MCP（Model Context Protocol）是一套让大模型调用外部工具的协议，Chrome MCP 服务器把浏览器的打开页面、点击元素、输入文本、抓取内容这些动作封装成标准工具，Dify 里的 Agent 就能按需调用。
但真正动手时，卡点往往不在 MCP 本身，而在 Key 的管理。Dify 要调大模型，Chrome MCP 背后规划动作的 Agent 也要调大模型，如果你同时接了三四个供应商，settings.json、config.toml、Dify 模型供应商里各塞一套 Key，改一次配置要翻三个文件，排查一次 401 要来回切换控制台。这篇就按“统一 Key”的思路，把 Dify + Chrome MCP 一次跑通，重点交付可直接复制的 settings.json 与 config.toml 骨架、Dify 模型供应商配置步骤，以及 Chrome MCP 的连通性验证动作。
适合谁看：已经在本地跑过 Dify、想给它加网页操作能力的开发者；被多套 API Key 折腾过、想收敛成一个入口的人；以及准备做网页自动化 Agent 但不想从零写工具调用的同学。下面所有配置都以 TaoToken 作为统一接入点，你只需要维护一份 Key。
2. 前置准备：TaoToken 统一 Key 与本地环境
先说清楚 TaoToken 在这里扮演什么角色。它是一个兼容 OpenAI 接口规范的模型接入层，你申请一个 Key，就能在 Dify、Chrome MCP 的 Agent 配置、以及各种 CLI 工具里复用同一套凭证。对多工具场景来说，最大的好处是：换模型、加模型只改一处，不用每个工具单独配。
你需要提前准备三样东西：
第一，一个可用的 TaoToken API Key。到控制台的 API Keys 页面创建，复制出来先存到环境变量里，别硬编码进配置文件：
export TAOTOKEN_API_KEY="sk-你的key"第二，本地环境。Dify 用 Docker 部署最省事，Chrome MCP 服务器需要 Node.js 18+，另外确认本机装了 Chrome。版本检查命令：
docker --version docker compose version node -v第三，网络与端口。Dify 默认占 80，Chrome MCP 服务器我们让它监听 9999，两个端口别冲突。如果你之前跑过别的服务占了 80，改 Dify 的映射端口即可。
注意：所有 Key 都通过环境变量注入，配置文件里用占位符引用。这样你把配置分享给别人时不会泄露凭证，也方便在不同机器上切换。
TaoToken 的接口地址是https://taotoken.net/api，兼容 OpenAI 的/v1/chat/completions路径。后面 Dify 的模型供应商、Chrome MCP 的 Agent 配置都指向这个地址。
3. 可复制配置：settings.json 与 config.toml 骨架
这一节是全文的核心，直接给你两份能用的配置骨架。先明确分工：settings.json给 Chrome MCP 服务器用，声明它调用哪个模型来规划浏览器动作；config.toml给 Dify 的模型供应商用（Dify 部分版本支持通过配置文件或环境变量注入自定义供应商），两者都指向 TaoToken，共用同一个 Key。
先看 Chrome MCP 的settings.json。放在项目根目录，或者通过--config参数指定路径：
{ "mcpServers": { "chrome": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-chrome"], "env": { "CHROME_MCP_PORT": "9999", "CHROME_PATH": "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" } } }, "llm": { "provider": "openai-compatible", "base_url": "https://taotoken.net/api", "api_key": "${TAOTOKEN_API_KEY}", "model": "gpt-4o-mini", "timeout": 60000 }, "browser": { "headless": false, "action_timeout": 30000, "max_tabs": 5 } }几个关键字段说明。base_url指向 TaoToken 的 API 地址，api_key用${TAOTOKEN_API_KEY}引用环境变量，避免明文。model填你在 TaoToken 控制台里可用的模型名，这里以gpt-4o-mini举例，你按实际可用列表替换。headless设成 false 是为了调试时能看见浏览器动作，跑稳定了再改 true。
再看 Dify 侧的config.toml骨架。Dify 的模型供应商配置在不同版本里位置略有差异，如果你用的是支持配置文件注入的版本，可以参考下面结构；如果走界面配置，就对照着在“模型供应商”里填同样的值：
[model_providers.taotoken] name = "TaoToken" provider = "openai" api_base = "https://taotoken.net/api" api_key = "${TAOTOKEN_API_KEY}" model = "gpt-4o-mini" max_tokens = 4096 temperature = 0.3 [model_providers.taotoken.parameters] top_p = 0.9 frequency_penalty = 0 presence_penalty = 0temperature给 0.3 是因为网页操作类任务需要稳定输出，太高容易让 Agent 规划出多余步骤。max_tokens给 4096 足够描述多步操作。
两份配置的共同点：都只引用一个${TAOTOKEN_API_KEY}。这就是“统一 Key”的落地方式——你换模型时，只改model字段，Key 不动。
提示：如果你的 Dify 版本界面里没有直接填
api_base的地方，选择“OpenAI”类型供应商，在 API Base 里填https://taotoken.net/api，Key 填 TaoToken 的 Key，模型名手动输入即可。
4. 部署 Dify 并配置模型供应商
配置骨架有了，接下来把 Dify 跑起来。用 Docker 部署最快，先建目录再拉配置：
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，首次进入创建管理员账号并完成初始化。这一步没什么坑，按提示走就行。
初始化完成后，进入模型供应商配置。路径是：右上角头像 → 设置 → 模型供应商 → 添加模型供应商。选 OpenAI 类型（因为 TaoToken 兼容 OpenAI 接口），然后填三个值：
| 字段 | 填写内容 |
|---|---|
| API Base | https://taotoken.net/api |
| API Key | 你的 TaoToken Key |
| 模型名称 | 与 settings.json 里一致的模型名 |
填完点保存，Dify 会做一次连通性测试。如果显示绿色成功，说明 Dify 已经能通过 TaoToken 调模型了。如果报错，先看第 5 节的排查表。
接着创建一个 Agent 应用。在 Dify 里新建应用，选“Agent”类型，模型选刚才配的 TaoToken 供应商。Agent 的提示词里要明确告诉它“你可以调用浏览器工具操作网页”，否则它可能只做文本回答。一个可用的提示词开头：
你是一个能操作浏览器的助手。当用户要求打开网页、填写表单、点击按钮或抓取内容时，调用 chrome 工具完成，不要只描述步骤。保存后，这个 Agent 就具备了调用 Chrome MCP 的前提。但此时 Chrome MCP 服务器还没接进来，下一步处理。
5. 启动 Chrome MCP 并验证连通性
Chrome MCP 服务器独立于 Dify 运行，它负责实际控制浏览器。启动命令：
npx -y @modelcontextprotocol/server-chrome --config ./settings.json如果你把配置放在默认位置，可以省略--config。启动后终端会输出监听信息，类似：
Chrome MCP server running on http://localhost:9999 Chrome browser launched and connected看到这两行，说明服务器起来了，浏览器也被拉起。接下来做连通性验证，分两步。
第一步，直接测 MCP 服务器是否响应。用 curl 打它的健康检查或工具列表接口：
curl -s http://localhost:9999/tools | head -c 500正常会返回一个 JSON，里面列出open_page、click、type_text、get_content这类工具名。如果返回空或连接拒绝，说明服务器没起来或端口被占。
第二步，在 Dify 里把 MCP 服务器注册进去。回到 Dify 设置 → 模型供应商 → MCP 服务器（部分版本在“工具”里），添加一个 MCP 服务器：
名称: Chrome-Automation URL: http://localhost:9999点验证，看到成功提示即打通。然后回到你的 Agent 应用，在工具列表里勾选 Chrome 相关工具，保存。
现在做一次端到端验证。在 Dify 的 Playground 里输入：
请打开 https://example.com，读取页面标题并告诉我。如果 Agent 返回了正确的页面标题，说明 Dify → TaoToken（模型规划）→ Chrome MCP（执行动作）→ 浏览器 这条链路全通了。这一步成功，你的网页操作型 AI 助手就算搭好了。
6. 本篇常见错排查
配置过程中最容易卡在几个地方，我按出现频率排一下。
报 401 或 invalid api key：九成是环境变量没生效。settings.json里写的是${TAOTOKEN_API_KEY}，但启动 Chrome MCP 的终端里没有这个变量。检查方法：在同一个终端执行echo $TAOTOKEN_API_KEY，有输出才说明注入成功。Docker 部署的 Dify 要注意，容器内的环境变量和宿主机是隔离的，需要在 compose 文件里通过environment传入。
Chrome MCP 启动后浏览器没弹出：CHROME_PATH填错了。macOS 默认路径是/Applications/Google Chrome.app/Contents/MacOS/Google Chrome，Linux 通常是/usr/bin/google-chrome，Windows 是C:\Program Files\Google\Chrome\Application\chrome.exe。路径里有空格的话，JSON 里正常写即可，不用转义。
Dify 验证 MCP 服务器失败：如果 Dify 跑在 Docker 容器里，而 Chrome MCP 跑在宿主机，容器内的localhost指向容器自己，不是宿主机。解决办法是把 URL 里的localhost换成host.docker.internal（Docker Desktop 支持），或者让两者在同一网络下用宿主机 IP。
操作超时：复杂页面加载慢，默认超时不够。在settings.json里把action_timeout调到 60000，llm.timeout也相应调大。另外headless: false时如果浏览器窗口被最小化，某些操作会变慢，调试时保持窗口可见。
Agent 只回答不操作：模型没被正确引导去调用工具。检查 Agent 提示词里有没有明确“调用 chrome 工具”，以及工具是否在应用里勾选启用。有时候模型能力偏弱也会导致它“忘记”调工具，换一个指令遵循更好的模型试试。
端口 9999 被占用：改CHROME_MCP_PORT和 Dify 里填的 URL 端口，两处保持一致即可。
排查顺序建议：先确认 Key 注入 → 再确认 MCP 服务器单独可访问 → 最后确认 Dify 能连到 MCP。逐层验证比一上来就端到端测要快得多。
7. 把 Key 收敛成一处，后续才好扩展
跑通之后你会发现，真正省事的地方在于：Dify 和 Chrome MCP 用的是同一个 Key、同一个 API Base。以后你想换模型，只改settings.json和 Dify 供应商里的model字段；想加一个新工具，只要它也支持 OpenAI 兼容接口，直接复用这份 Key 就行，不用再去每个工具的控制台重新生成凭证。
如果你准备长期跑编码类或 Agent 类任务，可以了解下 Coding Plan，它更适合高频调用的场景；日常调试模型输出，用模型对话页面直接测更快；需要新建或管理 Key，去 API Keys 页面；接入细节和参数说明都在接入文档里。把这几处收藏好，下次换机器或重装环境，照着这篇的配置骨架走一遍就能恢复。
最后留一个实用习惯：把settings.json和config.toml里的 Key 全部用环境变量占位，配置文件本身可以进 Git 仓库，凭证走本地.env或系统环境变量。这样你分享配置、迁移环境都不会有泄露风险，团队协作时每个人用自己的 Key，配置结构完全一致。
