企业官网建设流程全解析

1. WSL 里 Codex 接 Playwright MCP 到底解决什么问题

OpenAI Codex 在 WSL 里跑起来之后，很多人第一反应是让它帮忙写代码、改脚本，但真正卡住的地方往往不是模型能力，而是它没法直接操作浏览器。比如你想让 Codex 打开一个本地页面、点按钮、抓 DOM、截图、跑一遍端到端流程，默认状态下它只能“说”，不能“做”。Playwright MCP 就是补上这块能力的东西：它把浏览器自动化封装成 MCP 工具，Codex 通过 MCP 协议调用它，就能在 WSL 里驱动 Chromium 完成真实页面操作。

这个组合适合谁？一类是前端/测试同学，想在 WSL 里让 Codex 帮忙跑 Playwright 脚本、定位选择器、复现 UI bug；另一类是做 Agent 的开发者，需要给 Codex 挂一个能操作浏览器的工具链。核心检索词就是 WSL、OpenAI Codex、Playwright、MCP，这四个词串起来就是本文要落地的场景。

真正麻烦的点有两个。第一是 Codex 的auth.json指向问题：默认它连的是官方端点，如果你要用 TaoToken 这类兼容端点，就得把 Base URL 和 Key 改对，否则 MCP 还没启动，模型请求就先 401 了。第二是 MCP 启动链路：WSL 下npx拉包慢、交互式确认会卡死、超时默认值太短，导致 Codex 里/mcp列表里根本看不到 playwright。我试过把这两件事分开排查，先保证模型请求通，再保证 MCP 进程能起来，顺序反了会浪费很多时间。

下面按“先配 Codex 认证 → 再注册 MCP → 再验证浏览器任务”的顺序走，每一步都给可复制的片段。你不需要先理解 MCP 协议细节，照着改文件、跑命令、看输出就行。

2. TaoToken 前置：把 Codex 的 auth.json 指向兼容端点

Codex 的认证信息默认放在~/.codex/auth.json，在 WSL 里就是/home/你的用户名/.codex/auth.json。这个文件里最关键的是 API Key 和端点地址。如果你直接用官方端点，MCP 配好了也可能因为额度或网络问题跑不通；换成 TaoToken 的兼容端点，请求路径更可控，配合 MCP 做浏览器任务时排障也简单。

先确认 Codex 已经装好。在 WSL 终端里执行：

codex --version

如果提示找不到命令，先按 Codex 官方方式安装。装好之后创建配置目录：

mkdir -p ~/.codex

然后编辑auth.json。注意这个文件是 JSON 格式，字段名要和 Codex 实际读取的一致。下面是一个可复制的结构，把sk-开头的 Key 换成你在 TaoToken 控制台生成的：

{ "OPENAI_API_KEY": "sk-你的TaoToken密钥", "OPENAI_BASE_URL": "https://taotoken.net/api" }

这里有个坑：不同版本的 Codex 对字段名大小写敏感，有的读OPENAI_API_KEY，有的读openai_api_key。最稳的办法是先看官方文档里 auth.json 的字段说明，再对照改。TaoToken 的 API 地址是https://taotoken.net/api，注意不要多加 UTM 参数，认证端点带参数容易出问题。

改完之后验证模型请求能不能通。可以用一个最小请求测试：

curl -s https://taotoken.net/api/v1/models \ -H "Authorization: Bearer sk-你的TaoToken密钥" | head -c 300

如果返回模型列表的 JSON，说明 Key 和端点没问题。如果返回 401，先检查 Key 有没有复制错、有没有多余空格。这一步过了，再动 MCP 配置，否则后面报错你分不清是认证问题还是 MCP 问题。

另外提醒一句：auth.json里不要写注释，JSON 不支持注释，写了会导致解析失败。权限也建议收紧：

chmod 600 ~/.codex/auth.json

WSL 和 Windows 文件系统互通，如果你在 Windows 侧也装了 Codex，注意别让两边配置互相覆盖。建议 WSL 里单独维护一份。

3. 可复制配置：config.toml 注册 Playwright MCP

Codex 的 MCP 服务注册写在~/.codex/config.toml。这个文件是 TOML 格式，和 auth.json 分开。先安装 Playwright MCP 包，再写配置。

在 WSL 里全局安装：

npm install -g @playwright/mcp

如果 npm 全局目录没在 PATH 里，可以用npx方式，不依赖全局安装。验证包能不能跑：

npx -y @playwright/mcp@latest --help

-y很关键，它跳过 npx 的交互式确认。WSL 下如果不加-y，npx 会停下来等你按 y，Codex 启动 MCP 时就会卡住直到超时。

然后编辑config.toml：

nano ~/.codex/config.toml

写入下面这段。路径和字段名保持和原文一致，startup_timeout_sec必须给够：

[mcp_servers.playwright] command = "npx" args = ["-y", "@playwright/mcp@latest"] startup_timeout_sec = 60

三个字段解释一下。command是启动命令，这里用npx；args是参数数组，-y跳过确认，@playwright/mcp@latest指定包；startup_timeout_sec是启动超时，WSL 下 npx 首次拉包和文件 IO 慢，60 秒是实测比较稳的值，设 10 秒或 30 秒都容易在首次启动时被判超时。

如果你同时用多个 MCP，可以并列写多个[mcp_servers.xxx]段。比如再加一个文件系统 MCP：

[mcp_servers.playwright] command = "npx" args = ["-y", "@playwright/mcp@latest"] startup_timeout_sec = 60 [mcp_servers.filesystem] command = "npx" args = ["-y", "@modelcontextprotocol/server-filesystem", "/home/你的用户名/workspace"] startup_timeout_sec = 60

注意 TOML 里字符串用双引号，数组用方括号，不要用 JSON 的花括号。写错了 Codex 启动时会直接报解析错误。

预运行一次，把依赖提前下好，避免 Codex 首次启动时等太久：

npx -y @playwright/mcp@latest --help

看到帮助输出就说明包和依赖都就绪了。这一步做完，MCP 的启动链路基本就通了。

4. 验证请求：用一次浏览器任务确认调用成功

配置写完，重启 Codex。在 Codex 交互界面里输入：

/mcp

如果列表里出现playwright，说明 MCP 注册成功。如果没出现，先别急着改配置，看下一节的报错排查。

接下来做一次真实浏览器任务。在 Codex 里发一条指令，让它用 playwright 打开一个页面并抓标题。比如：

用 playwright 打开 https://example.com，返回页面标题和第一个 h1 的文本

Codex 会调用 MCP 工具，启动 Chromium，访问页面，然后把结果返回。第一次运行会下载 Chromium 二进制，WSL 下可能要等几十秒，这是正常的。如果卡在这里，检查startup_timeout_sec是否够大，以及 WSL 里有没有装 Chromium 依赖库。

如果 Chromium 启动报缺少系统库，在 WSL 里补依赖：

npx playwright install-deps chromium

这条命令会装 Linux 侧的共享库。装完再跑一次浏览器任务。

验证成功的标志有三个：/mcp列表里有 playwright；Codex 能返回页面标题；终端里能看到 Chromium 进程短暂启动。三个都满足，说明 auth.json 指向和 MCP 启动链路都通了。

如果你想更直观，可以让 Codex 截图：

用 playwright 打开 https://example.com 并截图保存到 /home/你的用户名/workspace/shot.png

然后去 WSL 里看文件是否存在：

ls -lh ~/workspace/shot.png

有文件且大小不为 0，就说明浏览器自动化真的跑起来了。

5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth

这一节按真实报错来对。你在 WSL 里配 Codex + Playwright MCP，大概率会碰到下面几类。

第一类，401。表现是 Codex 发请求直接返回未授权。原因基本在auth.json：Key 写错、字段名不对、或者 Base URL 写成了带路径的完整地址。检查OPENAI_BASE_URL是不是https://taotoken.net/api，不要写成https://taotoken.net/api/v1再加一层。Key 重新从控制台复制一次，注意前后空格。

第二类，local proxy failed。这个报错通常出现在 Codex 尝试走本地代理但代理没起来，或者环境变量里残留了HTTP_PROXY/HTTPS_PROXY。在 WSL 里检查：

env | grep -i proxy

如果有输出，先 unset 掉再重启 Codex。注意这里说的是环境变量清理，不是让你去配任何网络工具。

第三类，reading choices。这个报错一般出现在 MCP 返回结果解析阶段，Codex 读不到预期的 choices 字段。常见原因是端点返回格式和 Codex 预期不一致，或者 MCP 工具返回了非 JSON 内容。先确认模型请求本身是通的（用第 2 节的 curl 测），再确认 MCP 的--help能正常输出。如果 MCP 启动时把非 JSON 日志打到 stdout，也会干扰解析。

第四类，OAuth 相关报错。Codex 某些版本会尝试 OAuth 流程，如果你用的是 API Key 模式，需要在配置里明确走 Key 认证，避免它去走 OAuth。检查auth.json里是否只有 Key 和 Base URL，没有多余的 token 字段。如果 Codex 提示登录，按官方文档切到 API Key 模式。

还有一个 WSL 特有的坑：路径。config.toml里如果写了 Windows 路径C:\...，WSL 里的 Codex 读不到。统一用/home/你的用户名/...这种 Linux 路径。文件系统 MCP 的目录参数也一样。

最后，如果/mcp列表里 playwright 时有时无，多半是启动超时。把startup_timeout_sec从 60 再往上调，或者先手动跑一次npx -y @playwright/mcp@latest --help把包缓存热起来。

6. 配好之后怎么继续用：Key、文档与 Coding Plan

到这一步，WSL 里 Codex 接 Playwright MCP 的链路已经通了：auth.json 指向 TaoToken 的 API 端点，config.toml 注册了 playwright MCP，浏览器任务能返回真实结果。后面你要做的是把这套配置固化下来，别每次重装都重来。

如果你还没生成 Key，去 TaoToken 控制台建一个，注意权限最小化，只给需要的模型权限。地址是 https://taotoken.net/api-keys 。接入细节和字段说明看文档 https://taotoken.net/doc ，里面有 auth.json 和 config.toml 的字段对照。想先验证模型对话是否正常，可以用模型对话页 https://taotoken.net/chat 发一条消息试试。

如果你打算长期用 Codex 跑编码和 Agent 任务，尤其是需要频繁调用 MCP 工具的场景，可以看 Coding Plan https://taotoken.net/coding-plan ，它更适合这种持续调用的用法。Claude Code 相关的接入在 https://taotoken.net/claude-code ，Anthropic 兼容端点在 https://taotoken.net/anthropic 。

最后给一个实用习惯：把~/.codex/config.toml和auth.json备份到你的 dotfiles 仓库，换机器时直接拉下来改 Key 就行。WSL 重装频率不低，这一步能省很多重复配置的时间。