内容中心 › 选型
Agent 不是不会翻译。给它 300 字的摘要，译文质量可能比任何翻译网站都好。
但它翻不完一份 100 页的标书，也交不出一份能直接投稿的 Word。这不是模型强弱的问题，是三件结构上的事：
所以翻译 MCP 有没有必要，答案不在「谁翻得更准」，在这一个问题：这份文档翻完之后，用户还要不要再花两小时收拾。
要，就必须有 MCP。不要，Agent 直翻就够了。
先把边界划清，否则后面的论证就是自说自话。
这四种情况，Agent 直翻明显更好：
这四类占了日常使用的绝大多数次数。如果按「调用次数」算，MCP 是少数派；按「文档页数」算，MCP 是多数派。两个口径经常被混着说，结论就打架。
拿一份 15 页的真实论文（NeurIPS 模板，双栏，含公式与图）逐页解析，再折算到 100 页：
| 指标 | 15 页实测 | 折算 100 页 |
|---|---|---|
| 字符数 | 17,831 | 约 12 万字符 |
| 字体种数 | 24（含 8 种 Computer Modern 数学字体） | 层级更复杂 |
| 矢量绘图元素 | 2,710 个 | 约 1.8 万个 |
| 图片块 | 13 个 | 约 87 个 |
| 公式编号 | 7 处 | 约 47 处 |
| 希腊字母与数学符号 | 21 个 | 约 140 个 |
12 万字符英文译成中文，约 18 万 token。而单次输出上限普遍在 8K 到 64K token 之间——这个上限由解码过程决定，不是工程优化能绕开的。
所以任何声称「一句话翻完 100 页」的 Agent 工作流，底下一定有分块、拼接和重试，只是没写在介绍里。
这里要区分两个容易混淆的数：上下文窗口管「读进去多少」，这些年涨得很快，20 万、40 万都有；输出上限管「一次吐多少」，涨得慢得多。很多「长文档 AI 翻译」的宣传，拿输入窗口当卖点，回避了输出。
分块本身不难，难在块与块之间保持一致。
我们做过一个统计：一篇讲注意力机制的论文，attention 在全文出现 97 次，一份分块翻译的译文里出现了三种说法——注意力、关注、注意力机制。读者会以为是三个不同概念。
同类问题还有三种，都是分块的直接后果：
这四类错误的共同点是：译文本身读得通顺，错在你对不上原文。所以它们不会在阅读时暴露，只在交付后暴露。
服务端管线解决这件事的办法很笨：全文先扫一遍，建术语表，再逐块翻，每块都带着同一份术语表和编号映射。MCP 调用触发的是这条管线，Agent 直翻触发不了。
这一堵最容易被低估。模型输出的是文字流，排版是另一套东西。
还是那份 15 页论文：24 种字体、2,710 个矢量绘图元素、13 个图片块、7 处公式编号。这些不是「文字」，是坐标、字号、基线、字体子集。
要还原成能投稿的 Word 或 PDF，得回答一串具体问题：
| 问题 | Agent 直翻的答案 | 需要什么 |
|---|---|---|
| 公式是字符还是图片 | 输出成文本，上下标塌成一行 | 字体映射 + 位置重排 |
| 表格错行怎么办 | 输出成 markdown 表格，合并单元格丢失 | 单元格坐标还原 |
| 图注跟着图走吗 | 不知道图和图注的关系 | 版面块结构分析 |
| 页眉页脚页码 | 混进正文一起翻 | 区域识别 + 排除 |
| 双栏顺序 | 按文本流读，左右栏串行 | 分栏检测 |
每一行都是独立的工程问题。加起来的结论只有一句：Agent 直翻拿到的是译文，不是文档。用户还得把它贴回原文件、重新对齐、逐个修公式——那两小时就花在这里。
很多人默认「自己调模型更便宜」。按 100 页算一遍：
所以「便宜」这件事只在用廉价模型时成立，而廉价模型恰恰最需要专业管线兜底——它更不擅长术语一致性和公式识别。
真正的成本差不在模型费，在返工：一份 100 页的译文，如果术语要人工统一、公式要逐个修、表格要重排，两小时是保守估计。按人力成本算，这两小时远贵于 5 元。
既然必要性在于「接住」，那衡量厂商 MCP 的尺子也只有这一把。分档不看品牌大小，看四条：能不能收文件、能不能回文件、能不能报页数与进度、本机要不要装东西。
| 档位 | 代表 | 形态与本机要求 | 能否翻文档 |
|---|---|---|---|
| 远程全流程 | DeepL、翻呗 | 一个 URL + 凭证，本机零依赖 | 能 |
| 本地阉割 | PDFMathTranslate | 装 Python 3.11~3.12 + 依赖 | 能，但翻译服务写死 Google |
| 挂名不翻译 | 福昕 PDF365、Doc2X | 远程或 stdio | 不能：前者是 PDF 工具集，后者是解析导出 |
| 无 MCP 入口 | 翻译狗、沉浸式翻译、百度、有道、阿里、谷歌、Wordvice 等 12 家 | — | — |
几个值得记的细节：
DeepL 是目前做得最完整的：29 个工具（按套餐裁剪），OAuth 2.1，术语表和风格规则能在对话里增删改，文件字节走带外通道、不进模型上下文。它已经进了 Claude、ChatGPT、Copilot 三家的连接器目录。
PDFMathTranslate 是开源里最能打的，公式排版确实保得住，但它的 translate_pdf 工具把翻译服务硬编码成了 Google——命令行里用 -s 换成 DeepL 或 OpenAI，走 MCP 时依然走 Google。对本机的要求也最高。
福昕和 Doc2X 各有 30 多个和 13 个工具，都是真东西，但都不是翻译：福昕做的是转换、OCR、合并、压缩、电子签，Doc2X 做的是解析、导出、下载。它们的 MCP 让 Agent 能把文档处理干净，翻译那一步还得回网页。
翻译狗和沉浸式翻译没有检索到公开的 MCP 入口。这不一定说明它们不重视，可能只是判断 MCP 还没到值得投入的时候。
翻呗的 MCP 有 7 个工具，远程托管，Bearer 令牌由账号密码换取。设计上有三个取舍值得说，因为它们直接对应上面三堵墙：
只读工具先行。7 个工具里，账户余额、可选引擎、翻译报价三个是只读的，下单前先报价。原因是扣积分不可逆——让 Agent 在花钱之前先把总价算出来，比事后解释为什么贵更有用。
文件三种入口。本地路径（stdio 场景）、公网 URL、50MB 以内 base64。不是为了炫技，是因为不同客户端的能力差得很远：桌面端能读本地文件，网页端只能给 URL 或内联数据，少一种入口就少一批用户。
令牌可吊销。令牌不落库，用密码哈希做签盐，改密码即全量失效。代价是没有令牌列表可管理，好处是不会出现「离职员工的令牌还活着」这种事故。
代价也得说清楚。DeepL 用 OAuth 2.1，我们用的是 Bearer——简单、能立刻用，但进不了 Claude 的连接器目录，那个目录硬性要求 OAuth。这是要补的课，不是可以绕过的选项。
工具数量也不在一个量级：它 29 个，我们 7 个。多出来的那些是术语表 CRUD、改写、纠错、多语言批量。我们需要不需要，取决于用户会不会在对话里改术语表——这件事还没验证。
回到那个判据：翻完之后还要不要收拾。
一段话、一封邮件——不用收拾，Agent 直翻更快更省。这类场景不需要 MCP，也不该为了「有 MCP」去用 MCP。
一份 100 页的标书、一篇要投稿的论文——必然要收拾，而收拾的每一件事（术语、公式、表格、编号）都在 Agent 的能力边界之外。这类场景没有 MCP，就只能人肉补。
所以翻译 MCP 的必要性不在「翻得更准」，在它接住了 Agent 结构上做不到的那一段：装不下的量、对不齐的术语、还原不了的排版。