企业官网建设流程全解析

文件解析，乍看并不复杂：转成 Markdown，切成片段，再存进知识库，就行了。

可一旦把真实资料交给 Agent，并期待它在生产环境中帮上忙，事情就没那么简单了。

一方面，生产环境的文档很少有那么“干净”的：扫描件、复杂表格、工程图纸……很多信息不只写在文字里，也藏在版式、位置和图形关系中。强行转成 Markdown，反而可能把重要细节弄丢。

另一方面，资料一多，Agent 也容易手忙脚乱。它不知道该先找哪份文件、再读哪一章，只能在大量片段之间反复尝试。Token 花了不少，答案却未必找对。

Knowhere 2.0 想解决的，正是这两个问题。

这次更新，我们主要做了两件事：一是将 VISION-MAP 与文本解析整合为双轨解析，让更多复杂文档进入 Agent 的知识库；二是升级检索机制，把“去哪里找、接着读什么”的判断交给 Agent。

如果说双轨解析解决的是“怎样把文档看懂”，那么 Agent 原生检索解决的就是“看懂以后，怎样找到真正需要的答案”。

从 VISION-MAP 到双轨解析

此前，我们已经介绍过 Knowhere 的视觉页面理解路线 VISION-MAP。

它解决的是传统文本解析不太擅长的问题：面对扫描件、复杂表格、PPT 和工程图纸，信息往往不只藏在文字里，还存在于页面布局、图形位置、表格关系、批注和标记之中。强行把这些内容全部转写成文字，难免会丢失细节，甚至把错误一起写进知识库，被 Agent 反复使用。

VISION-MAP 采用了另一种思路：不急着把页面完全改写成文字，而是保留原始页面，让视觉模型从整个页面出发理解内容。系统会为页面建立章节归属、主题说明和必要的内容标注，再把它组织进文档地图。Agent 需要时，可以先找到相关页面，再直接查看原页。

在 Knowhere 2.0 中，这条视觉路线与原有的文本解析正式组成了一套双轨架构。

结构清晰的 Word、Excel、Markdown、JSON 等资料继续走文本轨，尽可能保留准确的文字和原生结构；PDF、PPT 等以页面为主要载体的文档，则可以通过视觉轨理解整页内容。

两条轨道最终进入同一套文档记忆。对 Agent 来说，文字段落和视觉页面不属于两个分离的知识库，而是同一张文档地图中的不同节点。它们都带有章节层级、来源位置、相关资产和文档关系，可以在同一个任务中被查找、阅读和引用。

这意味着，用户不必先把所有资料手动转换成同一种格式。干净的文档可以继续高效解析，图纸、扫描件和复杂报告也不会因为难以完美转写，被挡在知识库之外。

但让文档顺利进入知识库，只完成了一半工作。

当资料从一份变成几百份，问题也会从“这句话在哪里”变成“这件事应该去哪些资料里找”。这时，仅仅返回几个相似片段，往往不够。

文档读懂之后，Agent 还要会找

很多 RAG 系统的工作方式并不复杂：先把文档切成许多 chunk，用户提问后，再通过向量相似度找出最相关的几个片段，交给模型生成答案。

这种方式适合回答简单、边界明确的问题。例如查询一个概念的定义，或者寻找一段已经明确写在文档里的说明。

但在更复杂的任务中，单次 top-K 检索经常不够用。

例如，一个设备编号可能同时出现在产品手册、施工图纸和设计变更中；一项企业制度也可能经历多次修订。单次 top-K 检索可以找到关键词，却未必能帮助 Agent 判断应该继续读哪一章、参考哪个版本，以及还缺少什么证据。它只能不断换一种问法、重复检索，再尝试把零散结果拼起来。

Knowhere 过去的 MapNav 已经开始利用文档结构进行导航。到了 2.0，我们进一步把固定的导航流程升级为 Agent 可以自主使用的检索底座。

Knowhere 会向 Agent 提供文档大纲、章节结构、精确搜索、模糊召回、全文阅读、图片和表格资产，以及跨文档关系等工具。Agent 可以根据当前任务，自己决定先调用什么、接着读哪里，以及需要查到多深。

简单问题可以直接搜索。复杂问题则可以先浏览资料范围，再沿目录进入相关章节；证据不足时，继续阅读原文、核对页面，或者转向其他文档比较不同版本。

整个过程更接近一个人在资料库中的真实工作方式：

1. 先了解资料范围；

2. 判断答案可能出现在哪里；

3. 沿着目录和线索缩小范围；

4. 阅读相关段落、页面和资产；

5. 对照其他文档补充或验证；

6. 带着文档、章节和页码返回结论。

这里的关键，不只是“搜索得更准”，而是 Agent 获得了调整检索策略的能力。也就是说，Knowhere 不再替 Agent 固定一条检索路线，而是把文档地图和工具交给它，让它围绕任务自己找路。

对于需要稳定 top-K 结果的任务，开发者仍然可以使用经典检索；需要完成多步骤任务时，则可以把探索过程交给 Agent。

同一套文档记忆既可以供 Knowhere 内置 Agent 使用，也可以通过 MCP 接入其他 Agent、模型和编排框架。无论由谁来探索，Knowhere 都会把最终引用解析回具体文档、章节、页码和相关资产，方便用户复核。

当 Knowhere 2.0 进入真实资料库

双轨解析和 Agent 原生检索并不是两项彼此独立的功能。

前者让不同格式的资料进入同一套文档记忆，后者让 Agent 可以在这些资料之间继续寻找、比较和核验。只有把两者放进真实任务里，2.0 带来的变化才会更直观。

接下来我们就以工程和尽调这两个场景来举例。

工程知识库：工程资料不只是一堆文件

一套工程项目资料，可能同时包含设计规范、施工图纸、设备手册、材料表和历次设计变更。设备型号写在手册里，安装位置画在图纸上，安全要求来自技术规范，最新调整则藏在另一份变更记录中。

如果工程师想确认某型号设备的安装位置、间距要求，以及最近一次设计变更是否影响原方案，靠一次关键词搜索很难找到完整答案。

在 Knowhere 2.0 中，手册、规范和变更记录可以通过文本轨保留章节与条款，图纸和复杂表格则可以通过视觉轨理解页面。

Agent 可以先在设备手册里确认型号，再查看相关规范，随后回到图纸核对位置、尺寸和周边管线，最后检查变更记录是否更新了原方案。得到的结果会同时带上条款、章节、图纸页码和变更依据。

双轨解析让不同格式的资料进入同一套知识库，Agent 原生检索则把分散在不同文件里的证据重新串联起来。它不能替代工程师的专业判断，但可以减少翻目录、对型号、查版本和找原图的时间。

企业尽调：当问题跨越制度、合同和历史版本

企业尽调面对的是另一类复杂资料：公司章程、内部制度、合同、财务报告、董事会纪要和修订记录，来自不同年份，也采用不同格式。

假如尽调人员想了解一家公司对外担保需要经过哪些审批，以及过去三年是否存在需要进一步核验的事项，答案通常不会完整地出现在某一份文件里。

Agent 可以先从公司章程和内部制度中确认审批规则，再查找董事会纪要、合同与财务资料。如果制度经过修订，它还需要比较不同版本，确认每笔事项发生时适用的具体要求。

遇到扫描合同、签章页或复杂财务表格时，Agent 可以回到原始页面核对金额、日期和签字；完成初步梳理后，再输出一份带有文档、章节和页码的待核验清单，交给专业人员进一步确认。

在这个过程中，Knowhere 的价值不只是找出包含“担保”两个字的段落，而是让 Agent 围绕一个任务，在多份文件和多个版本之间逐步补齐证据。

Knowhere 2.0，还会继续向前

除了双轨解析和 Agent 原生检索，Knowhere 2.0 也进一步支持超长 PDF、技术图册和图纸集合。文档中的图片、表格与页面会继续关联到来源章节，答案也可以保留文档名称、章节路径、页码和视觉证据。

从最初的文档解析，到 VISION-MAP，再到今天的 Agent 原生检索，我们一直在解决同一个问题：怎样让真实世界中的复杂资料，成为 Agent 可以长期使用的记忆？

目前，Knowhere 已经在 GitHub 获得超过 3000 个 Star。感谢每一位使用产品、提交反馈和参与贡献的朋友。

2.0 仍然只是一个新的开始。欢迎大家把真实场景中难解析、难检索的资料交给我们，也欢迎继续提出意见。我们会持续改进文档理解、检索和证据引用，让 Knowhere 变得更好。

体验 Knowhere 2.0：

• GitHub 开源项目：https://github.com/Ontos-AI/knowhere

• Knowhere 官网：Knowhere API - Transform Documents into Structured Data