文件解析乍看并不复杂转成 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 可以根据当前任务自己决定先调用什么、接着读哪里以及需要查到多深。简单问题可以直接搜索。复杂问题则可以先浏览资料范围再沿目录进入相关章节证据不足时继续阅读原文、核对页面或者转向其他文档比较不同版本。整个过程更接近一个人在资料库中的真实工作方式先了解资料范围判断答案可能出现在哪里沿着目录和线索缩小范围阅读相关段落、页面和资产对照其他文档补充或验证带着文档、章节和页码返回结论。这里的关键不只是“搜索得更准”而是 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.0GitHub 开源项目https://github.com/Ontos-AI/knowhereKnowhere 官网Knowhere API - Transform Documents into Structured Data Knowhere 2.0：让 Agent 看懂文档，也学会自己找答案
文件解析乍看并不复杂转成 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 可以根据当前任务自己决定先调用什么、接着读哪里以及需要查到多深。简单问题可以直接搜索。复杂问题则可以先浏览资料范围再沿目录进入相关章节证据不足时继续阅读原文、核对页面或者转向其他文档比较不同版本。整个过程更接近一个人在资料库中的真实工作方式先了解资料范围判断答案可能出现在哪里沿着目录和线索缩小范围阅读相关段落、页面和资产对照其他文档补充或验证带着文档、章节和页码返回结论。这里的关键不只是“搜索得更准”而是 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.0GitHub 开源项目https://github.com/Ontos-AI/knowhereKnowhere 官网Knowhere API - Transform Documents into Structured Data