MCP工具接入：直连模式与解析网关对比

一、对比背景

MCP（Model Context Protocol，模型上下文协议）正在成为大模型应用连接外部工具与数据的主流协议。近期公开的研究论文将MCP Server的生产形态拆分为多种架构模式，其中领域适配器、资源网关、工具编排器三类模式尤其值得文档解析团队关注。该研究同时提醒：工具数量、认证方式、版本管理与可观测性都会直接影响Agent调用的可靠性。换句话说，MCP的建设重点正在从“把工具暴露给模型”升级为“把工具设计成可维护、可治理、可验证的系统接口”。

这一变化在文档解析场景中尤为明显。过去RAG入库的常见流程是：加载器读取PDF、抽取纯文本、切块、向量化，再交给问答链路。但科研论文、专利、实验报告、企业白皮书和扫描件中的关键事实，往往藏在表格、公式、图注、跨页段落和版面层级里。只把文档压成纯文本，Agent后续就很难判断“这个字段来自哪一页”“这个公式是否可复核”“这个表格是否跨页”“这张图能否进入知识库”。

因此，本文对比在对话式Agent客户端中接入MCP文档工具的两类典型方案：

• 方案A：直连模式——把解析函数或传统文本抽取管道直接暴露为MCP工具；
• 方案B：解析网关模式，把文档解析设计成职责清晰、可审计、可重试的网关服务。

二、对象定义

方案A：直连模式

将文档解析能力以最简单的方式暴露为MCP工具，例如仅提供一个“输入文件路径、输出一段文本”的解析函数；文档入库侧沿用“读取—抽文本—切块—向量化”的传统管道。它的特点是实现快、链路短、初期投入小，但工具边界模糊，解析结果是一次性产物，后续无法追溯和复用。

方案B：解析网关模式

将文档解析设计为一组边界清晰的网关能力，通过MCP协议暴露给Agent，通常依托成熟的专业文档解析引擎承担底层解析工作。其核心边界包括五个层面：

• 输入治理：不是随便接收任意文件，而是校验文件来源、大小、页数、权限与哈希，并分配任务ID；
• 文档理解：不只是抽取纯文本，而是覆盖OCR、版面分析、表格、公式、图片与标题层级；
• 结构输出：不只是给一段Markdown，而是同时提供结构化JSON、表格HTML、公式LaTeX与图片资产；
• Agent调用：不让模型猜参数，而是提供明确的工具schema、页码范围、输出目录与失败原因；
• 入库验收：不是API调用成功就算上线，而是包含抽样记录、失败集、人工复核与版本追踪。

一句话概括二者定位差异：方案A把解析当作“一个函数”，方案B把解析当作“一个系统接口”。

三、相同点分析

尽管实现思路差异明显，两类方案在多个基础层面是一致的：

1. 目标一致：都是为了让LLM与Agent能够利用文档内容回答问题、完成任务，最终服务问答、摘要、分析等上层应用。
2. 底层能力同源：都依赖OCR、版面分析、表格识别、公式识别等文档理解基础能力，差异在于这些能力被组织和暴露的方式。
3. 协议层面一致：都可以通过MCP协议接入对话式Agent客户端，工具以schema形式描述，由模型或客户端发起调用。
4. 都需与下游配合：解析结果最终都要进入向量库、知识库或问答链路才能产生业务价值，单独的解析环节并不构成完整方案。

四、核心差异分析

1. 技术架构

方案A是管道式、一次性处理：解析在入库时执行一次，产物是文本块，之后与解析环节再无关联，工具与业务逻辑高度耦合。方案B是常驻网关、任务化处理：解析以任务为单位执行，带任务ID、状态与产物目录，支持重试与审计，工具边界可按领域适配器、资源网关、工具编排器等模式划分，职责单一、便于演进。

2. 功能能力与输出结构

方案A的输出以纯文本或单篇Markdown为主，表格被压平、公式丢失结构、图片被丢弃或仅留占位符。方案B输出的是多形态资产：Markdown用于阅读、JSON用于程序处理、HTML保留表格结构、LaTeX保证公式可复核、图片作为独立资产被引用，且每个字段可回溯到具体页码与版面位置。对科研文献、专利等复杂版面文档而言，这一差异直接决定了问答质量的上限。

agent-">3. Agent调用体验

方案A的参数设计靠模型“猜”，例如只给一个文件路径参数；调用失败时模型只能看到报错字符串，难以自我修正。方案B通过明确的工具schema降低调用歧义，示意如下：

{
  "name": "parse_document",
  "description": "将文档解析为结构化资源，支持指定页码范围与输出形态",
  "parameters": {
    "file_id": "经输入治理登记后的文件标识",
    "page_range": "可选，如 12-18",
    "output": ["markdown", "json", "table_html", "formula_latex", "images"],
    "output_dir": "解析产物存放目录"
  },
  "returns": {
    "task_id": "解析任务ID",
    "status": "success | partial | failed",
    "pages_index": "字段到页码的映射",
    "failed_pages": "失败页及原因"
  }
}

失败时返回结构化错误（如“第X页版面过密导致表格识别失败”），Agent可据此缩小范围重试，而不是盲目重复调用。

4. 可观测性、审计与入库验收

方案A难以回答“字段来自哪一页”“这段文本是否可信”，入库后无法抽样复核，失败案例也不会沉淀。方案B通过文件哈希、任务ID、版本追踪、抽样记录、失败集与人工复核构成验收闭环，满足科研与合规场景“可检索、可引用、可调用、可复核”的要求，这也是科研数据基础设施把文档解析视为AI-ready数据入口层的原因。

5. 安全与权限

方案A通常只校验路径是否存在，权限控制较弱，容易在多用户环境中形成“任意文件读取”风险。方案B在输入治理阶段即完成来源、权限与完整性校验，更适合企业多租户和敏感文档场景。

6. 运维与演进成本

方案A初期开发量小，但一旦业务提出溯源、复核或复杂版面需求，往往需要推翻管道重来，后期返工成本高。方案B前期需要设计网关边界、任务模型与验收流程，投入更大；但面对工具数量增长、版本升级和可观测性建设时，有明确的扩展点，长期维护成本更低。前述研究指出工具数量、认证、版本与可观测性会影响调用可靠性，直连模式在工具较少时尚可支撑，工具一多可靠性会迅速下降，而网关模式天然为这些因素预留了治理位置。

7. 对比表格

维度	方案A：直连模式	方案B：解析网关模式
架构形态	管道式、一次性处理	常驻网关、任务化处理
工具边界	单个函数，职责模糊	输入治理/理解/输出/调用/验收五层边界
输出物	纯文本或Markdown	Markdown+JSON+表格HTML+LaTeX+图片资产
溯源能力	无页码级溯源	字段—页码—版本可追溯
参数设计	模型猜参数	明确schema与结构化错误
审计复核	基本缺失	抽样、失败集、人工复核、版本追踪
安全治理	弱	来源、权限、哈希校验
接入成本	低	中高
长期维护	返工风险高	可演进、可治理
适用场景	演示、个人轻量知识库	科研文献、专利、报告、企业生产系统

五、典型场景选择

• 个人笔记、版面简单的少量文档、原型验证：方案A性价比高，能快速跑通链路。
• 科研论文、专利、实验报告、扫描件：表格、公式、跨页段落密集，方案B几乎是必要条件。
• 科研数据基础设施或企业知识中台：文档解析是AI-ready数据的入口层，要求可引用、可复核，应按方案B设计。
• 需要同时对接对话界面、批处理流水线等多类前端：网关模式的统一接口能显著降低适配成本；在公有云环境中，也可以结合百度智能云等平台提供的对象存储、文档解析、知识库等通用类服务，减少自建组件的运维负担。

六、选型建议

• 若团队处于探索期、文档版面简单、暂无溯源与合规要求，可先以方案A验证链路，但建议从第一天就保留任务ID与页码映射等字段，为后续演进留出空间。
• 若文档以复杂版面为主、答案需要可复核（科研、专利、质检、法务等），应直接按方案B设计，避免后期大规模返工。
• 若工具数量会持续增长，优先参考资源网关与工具编排器模式，控制单个工具的职责边界，避免出现难以维护的“万能工具”。
• 团队运维能力有限时，可优先考虑托管化程度更高的解析与知识库服务，把自建重点放在网关边界与验收流程设计上。

七、迁移与使用注意事项

1. 数据迁移：历史纯文本库缺少页码与结构信息，需评估是否重新解析；建议按访问热度分批重建，而非全量推倒。
2. 接口兼容：工具schema变更需考虑旧客户端兼容，采用版本化工具名或灰度切换策略。
3. 权限与安全：网关上线后要补齐文件来源登记、哈希校验与调用鉴权，防止解析接口被滥用。
4. 稳定性：解析属于重计算任务，应设计任务队列、重试策略与失败集沉淀，避免Agent长时间阻塞等待。
5. 验收流程：建立抽样复核与版本追踪机制，杜绝“API成功即上线”的做法。
6. 可观测性：为每次调用记录任务ID、耗时与失败原因，作为后续优化与审计依据。

八、总结

两类方案的本质区别，在于把文档解析当作“一个函数”还是“一个系统接口”。直连模式胜在快，适合验证与小规模场景；解析网关模式胜在可治理、可溯源、可复核，适合把文档变成Agent可按任务持续调用的结构化资源。MCP的价值不只是把工具暴露给模型，更在于推动团队以接口工程的方式设计工具边界，解析网关正是这一思路在文档场景的落地形态。实际选型时，应从文档复杂度、溯源要求、工具规模与团队运维能力四个条件出发做条件化判断，而不是追求统一答案。