企业官网建设流程全解析

1. MinerU MCP Server 源码部署后，PDF 解析链路为什么要统一 Key 通道

MinerU MCP Server 是把 PDF 解析能力封装成 MCP 工具的开源项目，它本身不负责大模型推理，只负责把 PDF 转成 Markdown 这类结构化文本。真正调用它的是 Claude Code、Cline、Cursor 这类支持 MCP 协议的客户端，而这些客户端在解析完文档后，往往还要把结果交给大模型做总结、问答或代码生成。问题就出在这里：MCP 服务一套配置，大模型请求又是另一套配置，两边的 endpoint 和 Key 各管各的，时间一长就会出现「PDF 解析成功了，但模型调用 401」这种割裂感。

我试过把 MinerU MCP Server 的解析结果直接丢给本地配置的模型通道，结果发现模型侧的 Base URL 和 Key 散落在好几个配置文件里，换一次 Key 要改三四个地方。所以这篇的核心思路是：MinerU MCP Server 负责 PDF 解析，模型请求的 endpoint 与 Key 统一收敛到 TaoToken 这一条通道上。这样你只需要维护一份 Key，MCP 客户端和模型调用都指向同一个入口，排障时也能快速定位是解析层的问题还是模型层的问题。

适合谁看？如果你已经在本地跑通了 MinerU MCP Server 的源码部署，或者正准备把 PDF 解析接进自己的 Agent 工作流，但被多套 Key 管理搞得很烦，这篇就是写给你的。下面会给出可复制的 MCP 配置片段、TaoToken 统一 Key 的填写位置，以及一次完整的 PDF 解析调用验证动作，目标是在本地把 MinerU 解析链路和模型通道一起跑通。

需要先明确三个概念，避免后面配置时混淆。MCP 是模型上下文协议，负责让大模型和外部工具之间用标准化方式通信；MinerU API 是真正执行 PDF 到 Markdown 转换的后端服务；MinerU MCP Server 则是中间层，把 MinerU API 的能力包装成符合 MCP 规范的接口。大模型通过 MCP 客户端调用 MinerU MCP Server，MinerU MCP Server 再去调 MinerU API 完成实际转换。而模型本身的请求，则走 TaoToken 的统一通道。两条链路各司其职，但 Key 的管理可以合并到一处。

2. TaoToken 前置准备：统一 Key 与 endpoint 的获取和填写位置

在动手改配置之前，先把 TaoToken 这边的准备工作做完。TaoToken 的作用是给模型请求提供一个统一的 endpoint 和 Key 通道，你不需要在多个客户端里分别填不同的模型服务地址，只要把 Base URL 指向 TaoToken 的 API 地址，再用同一个 Key 就能调用背后配置好的模型。对于 MinerU MCP 这种「解析 + 模型」混合链路来说，统一 Key 能省掉大量重复配置。

第一步是拿到 Key。打开 TaoToken 的控制台，进入 API Keys 页面创建一个新的 Key。创建时建议给它起一个能识别的名字，比如mineru-mcp-local，方便后面在多个客户端里区分。创建完成后把 Key 复制出来，注意这个 Key 只会在创建时完整显示一次，后面再进页面就只能看到前缀了。如果你之前已经有 Key，也可以直接复用，但建议为 MCP 场景单独建一个，方便出问题时快速吊销而不影响其他项目。

第二步是确认 endpoint。TaoToken 的 API 地址是https://taotoken.net/api，这个地址在配置 MCP 客户端和模型请求时都会用到。注意这里不要加多余的路径后缀，很多 401 和 404 就是因为把 Base URL 写成了带/v1或其他后缀的形式。正确的做法是让客户端自己去拼接具体路径，你只填到/api这一层。

第三步是确认模型 ID。TaoToken 支持多种模型，你需要在控制台或文档里确认自己要用的模型 ID 是什么，比如claude-sonnet-4-20250514这类。这个 ID 在 MCP 客户端的模型配置里会用到，填错会导致reading choices之类的报错。如果你不确定用哪个，可以先在模型对话页面里试一下，确认能正常返回再写进配置文件。

这里要特别说明一点：MinerU MCP Server 本身不调用大模型，它只负责 PDF 解析。所以 TaoToken 的 Key 和 endpoint 是配在 MCP 客户端那一侧的，也就是 Claude Code、Cline 或 Cursor 这些工具的模型设置里。MinerU MCP Server 的.env里填的是 MinerU 自己的 API Key（如果用官方 API 的话），两者不要混在一起。很多人第一次配的时候会把 TaoToken 的 Key 填进 MinerU 的MINERU_API_KEY，结果解析请求全部失败，这个坑要避开。

如果你用的是 Claude Code 这类工具，它的配置通常放在~/.claude/settings.json或项目级的.claude/settings.json里。Cline 则是在 VSCode 的设置里找 MCP 和模型配置。Codex 的话会涉及auth.json。不管哪个客户端，核心都是三件套：Base URL 填https://taotoken.net/api，Key 填你刚创建的那个，Model ID 填你要用的模型。这三样填对，模型请求就能走通。

3. 可复制配置：MinerU MCP Server 与 TaoToken 统一 Key 的完整片段

这一节给出可以直接复制的配置片段。先处理 MinerU MCP Server 这一侧，再处理 MCP 客户端的模型侧，最后把两边串起来。

MinerU MCP Server 的配置分源码模式和包管理模式两种。源码模式下，进入 MinerU-MCP 目录后创建.env文件，内容如下：

# 使用本地 MinerU API USE_LOCAL_API=true # 本地 MinerU API 地址 LOCAL_MINERU_API_BASE=http://localhost:8888 # 转换后文件保存路径 OUTPUT_DIR=./downloads

如果你用的是 MinerU 官方 API 而不是本地服务，把USE_LOCAL_API改成false，并补上官方 API 的 Key：

USE_LOCAL_API=false MINERU_API_BASE=https://mineru.net MINERU_API_KEY=你的MinerU官方Key OUTPUT_DIR=./downloads

注意这里的MINERU_API_KEY是 MinerU 官方服务的 Key，不是 TaoToken 的 Key，两者用途不同。MinerU 的 Key 只用于 PDF 解析，TaoToken 的 Key 用于模型请求。

接下来是 MCP 客户端的配置。以 Cline 为例，MCP 服务器配置通常写在cline_mcp_settings.json里，路径在 VSCode 的全局存储目录下。配置片段如下：

{ "mcpServers": { "mineru-mcp": { "command": "uvx", "args": ["mineru-mcp"], "env": { "MINERU_API_BASE": "https://mineru.net", "MINERU_API_KEY": "你的MinerU官方Key", "OUTPUT_DIR": "./downloads", "USE_LOCAL_API": "false", "LOCAL_MINERU_API_BASE": "http://localhost:8888" } } } }

这段配置让 Cline 通过uvx自动拉起 MinerU MCP Server，不需要你手动启动 SSE 服务。如果你用的是源码模式，把command改成uv，args改成["run", "-m", "mineru.cli", "--transport", "sse"]，并确保在激活的虚拟环境里执行。

然后是模型侧的配置。Cline 的模型设置里，API Provider 选择 OpenAI Compatible 或 Anthropic 兼容模式，Base URL 填https://taotoken.net/api，API Key 填 TaoToken 的 Key，Model ID 填你要用的模型。如果你用的是 Claude Code，配置写在settings.json里：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "你的TaoToken Key", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

Codex 的话，auth.json里需要填OPENAI_BASE_URL和OPENAI_API_KEY，同样指向 TaoToken 的地址和 Key。三件套的核心就是 Base URL、Key、Model ID，缺一不可。

如果你用的是 CC Switch 来管理多个 Claude Code 配置，可以在 CC Switch 里新增一个配置项，Base URL 填https://taotoken.net/api，Key 填 TaoToken 的 Key，Model ID 填对应模型。这样切换配置时不会影响到其他项目。

配置完成后，启动顺序也有讲究。如果用的是本地 MinerU API，先启动 MinerU 的 web_api 服务：

cd /path/to/MinerU/projects/web_api pip install -r requirements.txt python app.py

服务会在http://localhost:8888启动。然后再启动 MCP 客户端，客户端会自动拉起 MinerU MCP Server。如果用的是 SSE 模式，需要手动启动：

cd /path/to/mineru-mcp source .venv/bin/activate uv run -m mineru.cli --transport sse

服务会在http://localhost:8001启动。stdio 模式则不需要手动启动，客户端会自己管理进程。

4. 验证请求：一次完整的 PDF 解析调用与成功结果确认

配置写完之后，必须做一次完整的验证，确认 PDF 解析链路和模型通道都通了。验证分两步：先确认 MinerU MCP Server 能被客户端识别，再确认模型能通过 TaoToken 正常返回。

第一步，在 MCP 客户端里查看工具列表。以 Cline 为例，打开 MCP 服务器面板，应该能看到mineru-mcp处于已连接状态，并且列出了parse_documents和get_ocr_languages两个工具。如果显示未连接，先检查uvx是否在 PATH 里，再检查.env或 JSON 里的环境变量有没有拼错。常见的问题是MINERU_API_KEY填成了 TaoToken 的 Key，导致 MinerU 侧认证失败。

第二步，发一条解析请求。在对话里输入：

请使用 MinerU MCP 将以下 URL 的 PDF 文档转换为 Markdown 格式：https://arxiv.org/pdf/2303.08774.pdf

模型会识别这是文档转换任务，调用parse_documents工具，参数为{"file_sources": "https://arxiv.org/pdf/2303.08774.pdf"}。如果一切正常，你会看到工具调用过程，然后返回转换后的 Markdown 内容，开头通常是论文标题和摘要部分。

第三步，确认模型请求走的是 TaoToken。这一步容易被忽略。你可以在 TaoToken 的控制台里查看调用日志，确认刚才的模型请求确实打到了 TaoToken 的 endpoint 上。如果日志里没有记录，说明模型请求还在走本地或其他通道，需要回去检查 Base URL 和 Key 的配置。

第四步，测试本地文件解析。输入：

请使用 MinerU MCP 将本地的 /Users/yourname/sample.pdf 文件转换为 Markdown 格式

模型会调用parse_documents，参数为{"file_sources": "/Users/yourname/sample.pdf"}。注意这里要用绝对路径，相对路径容易因为工作目录不同而找不到文件。如果报文件不存在，先确认路径拼写，再确认 MCP Server 进程有权限读取该文件。

第五步，测试 OCR 场景。如果你有扫描版 PDF，可以输入：

请使用 MinerU MCP 将以下 URL 的扫描版 PDF 转换为 Markdown，并启用 OCR：https://example.com/scanned.pdf

模型会调用parse_documents并带上enable_ocr: true参数。OCR 处理时间会比普通解析长，耐心等待即可。如果超时，参考下一节的排障方法。

验证成功的标志有三个：MCP 工具列表里能看到parse_documents，解析请求能返回 Markdown 内容，TaoToken 控制台里能看到对应的模型调用记录。三个都满足，说明 PDF 解析链路和统一 Key 通道都跑通了。

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

配置过程中最容易撞上的就是认证类报错。下面按真实报错逐个拆解。

401 Unauthorized。这个报错通常出现在模型请求侧，说明 TaoToken 的 Key 没填对或没生效。先检查 Key 是否完整复制，有没有多余空格。再检查 Base URL 是不是写成了https://taotoken.net/api/带尾斜杠，有些客户端会把尾斜杠拼成双斜杠导致路径错误。如果 Key 和 URL 都没问题，去 TaoToken 控制台确认这个 Key 是否被吊销或过期。还有一种情况是把 MinerU 的 Key 填到了模型配置里，两者搞混了，这个要特别注意。

local proxy failed。这个报错一般出现在客户端尝试连接本地 MCP 服务时，说明 MCP Server 进程没起来或者端口不对。先确认 MinerU MCP Server 是否在运行，SSE 模式下检查http://localhost:8001是否能访问。如果用的是 stdio 模式，检查command和args是否写对，uvx是否在 PATH 里。Windows 上还要注意路径分隔符和引号转义问题。

reading choices 报错。这个通常出现在模型返回阶段，说明请求发出去了但响应格式不对。常见原因是 Model ID 填错了，比如填了一个 TaoToken 不支持的模型名。去 TaoToken 的模型列表里确认可用的 Model ID，填一个确定能用的。另一个原因是客户端把请求发到了错误的 endpoint，比如把 Anthropic 格式的请求发到了 OpenAI 兼容接口上，这个要对照客户端的 API Provider 设置来排查。

OAuth 相关报错。如果你用的是 Claude Code 或 Codex 这类带 OAuth 流程的工具，可能会遇到 OAuth 认证失败。这时候要确认settings.json或auth.json里的 Base URL 和 Key 是否覆盖了默认的 OAuth 配置。有些工具会优先走 OAuth 再走 API Key，需要在配置里显式禁用 OAuth 或把 API Key 模式设为优先。如果报错信息里提到invalid_grant或token expired，说明 OAuth token 失效了，切到 API Key 模式即可绕过。

MCP error -32001: Request timed out。这个报错在处理大型 PDF 时很常见。MinerU 解析大文档本身耗时较长，加上模型侧的超时设置，很容易触发。解决办法有几个：把大文档拆成多个小文件分批处理；改用本地 MinerU API 模式减少网络延迟；在客户端设置里调大超时时间（如果支持的话）。Cursor 有个已知问题，超时后无法再次调用 MCP 服务，需要重启客户端才能恢复。如果反复超时，优先考虑分批处理。

文件路径找不到。parse_documents处理本地文件时报找不到文件，九成是路径问题。MCP Server 进程的工作目录可能和你想的不一样，所以相对路径经常失效。统一用绝对路径，Windows 上注意用正斜杠或双反斜杠。如果文件在远程机器上，先确认 MCP Server 有权限访问该路径。

MinerU API 认证失败。如果报错指向 MinerU 侧，检查MINERU_API_KEY是否是 MinerU 官方申请的 Key，而不是 TaoToken 的 Key。如果用本地 API 模式，确认USE_LOCAL_API=true且LOCAL_MINERU_API_BASE指向正确的本地地址。本地服务没启动的话，解析请求会直接失败。

排障的核心思路是分层定位：先确认 MCP Server 是否运行，再确认 MinerU API 是否可达，最后确认模型请求是否走通 TaoToken。每一层都有对应的日志和报错，按层排查比盲目改配置高效得多。

6. 把 PDF 解析接进日常 Agent 工作流：统一 Key 之后的实用建议

链路跑通之后，真正提升效率的是把它接进日常的 Agent 工作流。统一 Key 通道之后，你可以在多个客户端之间共享同一份 TaoToken 配置，不用每个工具都重新填一遍。比如你在 Cline 里配好了 MinerU MCP 和 TaoToken，换到 Claude Code 时只需要把settings.json里的 Base URL 和 Key 复制过去，Model ID 按需调整即可。

一个实用的做法是把 MinerU MCP 的解析结果直接喂给模型做后续处理。比如解析完一篇论文后，紧接着让模型提取关键结论、生成摘要或翻译成中文。因为模型请求走的是 TaoToken 统一通道，你不需要在解析和模型调用之间切换配置，整个流程是连贯的。实测下来，这种「解析 + 处理」的组合在文献整理、合同审阅、技术文档翻译这些场景里特别省事。

对于需要长期跑的任务，建议把 MinerU MCP Server 配成 SSE 模式并常驻后台，这样多个客户端可以共享同一个 MCP 服务实例，不用每次启动都重新拉起进程。SSE 模式下服务监听在http://localhost:8001，客户端配置里填这个地址即可。stdio 模式适合临时用，每次调用都会新起进程，启动开销略大。

如果你在用 Coding Plan 做长期编码或 Agent 任务，可以把 TaoToken 的 Key 和 MinerU MCP 配置一起写进项目级的配置文件里，这样团队成员拉下代码后只需要填自己的 Key 就能跑通。注意不要把 Key 提交到版本库，用环境变量或本地配置文件的方式管理。

最后提醒一点：MinerU MCP Server 的源码在 GitHub 上持续更新，配置格式可能会有变化。升级版本后先对照官方文档确认.env的字段名有没有改，再重新跑一次验证请求。TaoToken 侧的 Key 和 endpoint 相对稳定，一般不需要频繁调整。把这两条链路的配置分开管理，出问题时能快速定位是哪一侧的问题，比混在一起排查要轻松得多。