做文档翻译时，很多人第一反应是“能不能调用接口”。真正开始接入后，通常还要考虑文件从哪里来、任务是否需要排队、结果怎样交付，以及失败后如何继续处理。

如果只是想在 Codex 工作区里处理一两份 PDF 或 Office 文档，MCP 更适合快速验证。如果要把翻译能力接入 SaaS、RPA、内容管理系统或后台队列，REST API 通常更容易纳入现有架构。

一、先看文件处理场景

1. 工作区中的单份文档

MCP 更适合当前对话或工作区里的单文件任务。开发者可以让 Codex 查询账户状态和计费规则，创建翻译任务，再查询任务进度和结果。

这种方式的价值不是把模型变成一个简单的文本翻译器，而是把“文件提交、任务查询、结果取回”放进同一条工作流里。对于需要先验证效果的场景，可以选择一份有代表性的样本，而不是只用几行纯文本测试。

2. 后台批量或长期任务

如果文件来自业务系统，且需要批量处理、排队、重试、归档或记录任务状态，REST API 更合适。服务端可以保存任务标识，把状态轮询和结果存储纳入已有的后台流程。

MCP 和 REST API 不是谁替代谁的关系。前者偏向工作区协作，后者偏向系统集成，选择时应先看任务的归属位置。

二、按任务状态设计接入流程

无论使用哪种方式，都建议把文档翻译当成异步任务处理：

1. 准备并提交文档。
2. 保存返回的任务标识。
3. 查询任务状态，区分处理中、成功和失败。
4. 任务成功后再取得结果地址。
5. 对译文、格式、表格、图片和专业术语做交付前检查。

不要把“提交成功”直接当成“文件已经翻译完成”。异步任务的好处是可以明确知道当前处于哪个阶段，也方便在页面关闭或网络短暂中断后继续查询。

三、MCP 和 REST API 的选择清单

适合优先选择 MCP 的情况

• 主要在 Codex 工作区处理本地文档。
• 当前先验证一份代表性 PDF、Word、Excel 或 PPT。
• 希望在同一个协作界面里查询任务和处理结果。
• 暂时不需要批量队列、归档和复杂权限管理。

当前线上 MCP 面向单文件工作区场景，单份本地文档载荷上限为 20 MB。这个边界适合样本验证和日常单文件处理，超过该场景后应重新评估接入方式。

适合优先选择 REST API 的情况

• 文件由业务系统自动产生。
• 需要批量提交、任务队列和结果归档。
• 需要由服务端统一保存 API Key。
• 需要把重试、幂等、权限和审计接入现有系统。
• 需要将翻译结果交给其他业务模块继续处理。

四、文档格式不同，检查重点也不同

PDF 翻译后要重点查看页面结构、扫描质量、表格和图片中的文字。Word 和 PPT 更适合在结果文件中继续编辑，并检查标题层级、文本框和换行。Excel 则要复核表格结构、公式、型号和单位。

无论入口是什么，正式交付前都建议使用一份真实样本进行抽样检查。机器翻译或自动化任务可以减少重复操作，但不能替代对关键内容的人工复核。

结语

选择 MCP 还是 REST API，关键不在于哪个名词更新，而在于任务属于“工作区内的单文件协作”，还是“业务系统中的批量处理”。先明确任务边界，再设计状态查询和结果交付，接入过程会更容易维护。

如果要查看 MCP 的安装、连接验证、任务流程和故障排查，可以参考Codex MCP 文档翻译教程。