在日常项目里，文档翻译最麻烦的往往不是“翻一次”，而是反复在工作区、浏览器、下载目录和交付文件之间切换。文件在本地，任务状态在网页里，结果又需要回到项目目录复核。

现在可以把这段流程放到 Codex 的同一个工作区里完成：通过翻译排版大师的 MCP 服务，Codex 能查询账户与计费、创建文档翻译任务、持续查询进度，并在完成后取得结果地址。

这不是让模型绕过人工检查。它解决的是“把本地文件交给翻译服务并跟踪结果”的重复操作；扫描件、表格、公式、示意图和业务关键数字仍应在交付前复核。

这个场景为什么适合 MCP

MCP 适合处理已经位于本地工作区内的一份或几份文档。Codex 可以先检查文件是否存在，再按明确的任务边界创建异步翻译任务，并使用同一个 task_id 查询状态，避免网络等待时误建多份任务。

当前生产 MCP 支持 PDF、DOCX、PPTX、XLSX 四类文档，实际开放 4 个工具：

• translation_get_account：读取共享账户的 credits 信息。
• translation_get_pricing：读取当前每计费页价格与各格式计费单位。
• translation_create_document_task：创建异步文档翻译任务。
• translation_get_task：按任务 ID 查询进度、状态、费用与短时有效的结果地址。

这套方式特别适合开发者、产品团队和需要反复处理项目资料的人：文件仍留在工作区，任务过程也能在同一个 Codex 对话中持续追踪。

接入前的 3 个准备

1. 安装 Codex，并确认终端能够执行 codex 命令。
2. 准备 Node.js 18 或更高版本，本地 MCP 桥接依赖 Node 的运行环境。
3. 在开发者中心创建一个专用 API Key。密钥只在创建时完整展示一次，应保存在受限的本机配置中，不要放入项目仓库、提示词、截图或共享网盘。

对于 MCP，单份本地文档的生产载荷上限是 20 MB。超过这个体积时，应改用 REST API：后台系统或批量任务也更适合使用 REST API，因为它们通常需要自己控制 multipart 上传、幂等请求、重试、日志和结果归档。

建议先做只读检查

配置完成后，不建议立刻创建付费任务。先让 Codex 调用账户和计费工具，确认 MCP 注册、API Key 与当前计费规则均正常，再选择一份有代表性的文档测试。

可以这样描述需求：

本次只使用翻译排版大师 MCP 做只读检查：
1. 查询账户字段，但不要展示任何密钥；
2. 查询当前每计费页 credits，以及 PDF、DOCX、PPTX、XLSX 的计费单位；
3. 不要创建翻译任务，也不要修改本地文件。

这一小步能在真正计费前发现配置、凭据或环境问题。

第一份文档怎么下任务

一条好的指令需要把文件路径、目标语言、轮询终止条件、结果保存位置和“保留原文件”讲清楚。例如：

请使用翻译排版大师 MCP，把当前工作区的 ./manual.pdf 翻译为中文。

要求：
1. 先确认文件存在且不超过 20 MB；超过时停止并建议改用 REST API；
2. 创建任务后保存 task_id，每 3 至 5 秒查询一次，直到 SUCCESS 或 FAILED；
3. SUCCESS 后将结果保存到 ./outputs/manual-zh.pdf；
4. 告诉我预估与实际 credits，不要覆盖原文件；
5. 提醒我复核扫描识别、表格、示意图和关键业务数值。

这里最关键的是保留 task_id 并持续查询同一个任务。文档处理是异步的，看到 QUEUED 或 RUNNING 并不意味着失败；这时重复创建任务反而可能造成重复处理。

MCP 和 REST API 如何选择

生产环境里别忽略这两件事

第一，使用独立 API Key。每个客户端或自动化流程各用一个 Key，出现设备、配置或日志泄露时，可以单独撤销而不影响其他接入。

第二，把结果地址当作敏感信息。完成后的下载地址是短时有效的，应在确认结果后及时保存；原文也应保留，以便对照和交付复核。

完整安装步骤、手动配置示例和故障排查见官方教程：

https://fanyipaiban.com/developer-api/mcp-codex/

如果你的场景是把工作区里的文档交给 Codex 协作处理，MCP 能显著减少“上传、等待、下载、找文件”的来回切换；如果你在搭建业务系统或批处理，则从一开始就选择 REST API 会更稳妥。