用 Codex + MCP 翻译 PDF、Word、Excel、PPT：一次接入跑通本地文档工作流

在日常项目里文档翻译最麻烦的往往不是“翻一次”而是反复在工作区、浏览器、下载目录和交付文件之间切换。文件在本地任务状态在网页里结果又需要回到项目目录复核。现在可以把这段流程放到 Codex 的同一个工作区里完成通过翻译排版大师的 MCP 服务Codex 能查询账户与计费、创建文档翻译任务、持续查询进度并在完成后取得结果地址。这不是让模型绕过人工检查。它解决的是“把本地文件交给翻译服务并跟踪结果”的重复操作扫描件、表格、公式、示意图和业务关键数字仍应在交付前复核。这个场景为什么适合 MCPMCP 适合处理已经位于本地工作区内的一份或几份文档。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 个准备安装 Codex并确认终端能够执行codex命令。准备 Node.js 18 或更高版本本地 MCP 桥接依赖 Node 的运行环境。在开发者中心创建一个专用 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 如何选择场景推荐方式原因在 Codex 中处理本地的一份或几份文件MCP工作区文件、任务创建和结果查询能在同一条协作流程中完成。后台系统、RPA、队列或批量翻译REST API系统可自行管理上传、幂等键、重试、日志和结果归档。单份文件超过 20 MBREST API当前生产 MCP 的单份文档载荷上限为 20 MB。首次验证翻译效果网页工作台先用代表性样例检查译文与排版再决定是否自动化。生产环境里别忽略这两件事第一使用独立 API Key。每个客户端或自动化流程各用一个 Key出现设备、配置或日志泄露时可以单独撤销而不影响其他接入。第二把结果地址当作敏感信息。完成后的下载地址是短时有效的应在确认结果后及时保存原文也应保留以便对照和交付复核。完整安装步骤、手动配置示例和故障排查见官方教程https://fanyipaiban.com/developer-api/mcp-codex/如果你的场景是把工作区里的文档交给 Codex 协作处理MCP 能显著减少“上传、等待、下载、找文件”的来回切换如果你在搭建业务系统或批处理则从一开始就选择 REST API 会更稳妥。