一个智能体要回答你的问题，往往得先读懂你喂给它的文档：PDF 合同、网页、表格、扫描件。可「把文档变成模型能用的文本」这一步，看着普通，实则藏着一堆坑——版式一变就错位、表格一乱就丢列、不同模型解析出的结构还不一致。10 月 7 日，LlamaIndex 上线 OpenDocRouter，想把这个被很多人当碎活打发的环节，做成一次 API 调用：统一的文档转 Markdown 接口，底层接一组开源模型，用版本化的解析配方来管理。
智能体最常被忽视的 bottleneck：文档解析
做 RAG 的团队习惯把注意力放在检索与生成，解析常被当成「前面顺手接一下」的预处理。可现实是，解析质量直接决定下游能召回什么。同一份带复杂表头的 PDF，解析得稳，模型才能拿到对的行列；解析得飘，召回就跟着漂，后面再强的模型也救不回。更要命的是，解析往往是个长期债：模型要升级、格式要兼容、异常要兜底，团队一旦自己养一条解析流水线，就得长期有人盯着。OpenDocRouter 的卖点正落在这里——它不宣称解析更强，而是宣称解析更省心：一次调用接好，版本化配方保证可复现。
三层设计：模型、配方、接口
它的结构可以拆成三层来理解。底层是模型层：接一组开源模型来做版面理解、表格识别、OCR 这类活，团队不绑死某一家闭源服务。中间是配方层：每个解析任务对应一个版本化的配方，规定用哪些模型、走什么后处理、怎么还原结构；配方有版本，意味着今天解析出的 Markdown 和三个月后解析同一份文档，结果应当一致、可审计。最上面是接口层：对外只暴露一个统一的解析 API，调用方不用关心底下换了哪个模型、配方怎么演进。对应用开发者，这等于把「文档长什么样」和「我的 agent 拿到什么」之间那段不稳定的转换，封装成了一个有版本的黑盒服务。
版本化配方为什么重要
很多团队自己写解析，最痛的不是写不出初版，而是初版之后：模型一升级，老文档解析结果变了；临时改了段后处理，新文档好了、旧文档却坏了。版本化配方把「这次用什么逻辑解析」钉成可回放的记录，出问题能追到是哪个配方版本、哪次变更。对要对外服务的 agent，这种可复现、可审计的解析，往往比单次解析更漂亮更有价值——因为它让上游稳定，下游才敢放心依赖。当然，配方再版本化也救不了源文档本身的质量问题，扫描件模糊、版式极端畸变，该丢的还是可能丢，这是配方之外的硬限制。
对 RAG 类 agent 的影响
把视角拉到 RAG 整体，OpenDocRouter 这样的托管解析等于把「文档理解」从团队的维护负担里挪出去，变成按需付费的能力。取舍很清楚：自建管线前期便宜、可控、能针对自己的文档深度定制，但要长期养；托管 API 一次接好、按量付费、免运维，代价是依赖外部服务、对极端格式的定制空间受限。对多数不想被解析流水线拖住的中小团队，托管是更划算的默认；对已有一套深度定制、文档格式高度固定的大团队，自建仍可能更贴合。它不替代检索与生成里的任何一环，只是把那道最容易被低估的上游，做成了一个可被版本管理、可被审计的接口。目前官方及行业暂未披露它对各类型文档的解析准确率基准，实际效果仍要看在真实语料上的表现。对已经跑着一套 RAG 的团队，把它当解析层的替补而非整套重写，是更稳妥的切入方式。
一句话收尾：OpenDocRouter 把文档解析从自维护的碎活，升级成带版本配方的统一 API，稳的是上游、省的是运维。