你的知识库有多少内容是"看不见"的？
前几天和一个做技术架构的朋友聊天，他给我看了一组数据：他们公司内部知识库里，大约 35% 的内容是截图、流程图和表格。这些内容在传统的文本知识库里基本处于"隐身"状态——Agent 知道它们存在，但看不懂它们在说什么。
听起来荒谬，但这就是现实。你辛辛苦苦维护的知识库，有三分之一对 Agent 来说是个黑盒。
而且这些多模态内容往往是最值钱的部分。一张系统架构图浓缩了几十个组件之间的调用关系。一份数据报表用数字和格式传达了业务关键指标。一个用户反馈的截图标注了界面上的具体问题。一份 PDF 合同表格嵌套表格，信息密度极高。
Agent 对这些内容只能说"抱歉，我无法处理图片"的话，你的知识库就永远缺一大块。
多模态不是"存起来"，而是"看明白"
市面上支持多模态的系统不少，但大多数只做到了"存储"——把图片、PDF、表格存进去，打上标签，等用户手动检索。这和"理解"差得远。
真正的多模态理解应该是什么样？
对图片，Agent 能直接从架构图中读取组件关系，从截图中识别 UI 状态，从流程图中理解业务逻辑。不是存一张图片然后让你写 alt-text。
对表格，它理解表格的结构——哪些是维度、哪些是度量、行与列之间的对应关系。你问"上个季度华东区的毛利率是多少"，Agent 能直接从表格中定位并回答。
对 PDF，一份技术白皮书里的公式、图表、脚注、交叉引用，都需要被结构化地理解和存储，不是变成一坨乱序的文本。
当然，做到这些并不容易。目前比较成熟的做法是在知识准入阶段就对这些内容做结构化解析——图片提取描述信息，表格保留行列语义，PDF 做加强解析后提取层次化信息。一些开源方案（比如结合 GPT-4o 的视觉能力做图片描述提取）也能实现部分效果，但在大规模场景下的成本和一致性还需要验证。
三层记忆架构怎么处理多模态
我在 RDS ContextDB 上测试过一种思路：用三层记忆架构来处理多模态内容。核心想法是非结构化的东西进来，结构化的东西出去。
拿一张架构图来说。系统从里面提取出多个原子事实（Atomic Fact）："订单服务通过 gRPC 调用库存服务""数据库层使用主从架构，主节点在杭州可用区 A""缓存层使用 Redis Cluster，3 个分片"。每个原子事实都带有置信度分数和时间戳，和从文本中提取的事实没有本质区别。这就是多模态"理解"的核心——把非结构化内容转化为结构化的知识单元。
这些原子事实往上聚合，就成了实体卡片（Entity Card）。比如"订单服务"这个实体，它的信息来源可能包括架构文档中的文字描述、架构图中识别出的调用关系、一份 PDF 性能测试报告中的数据、一张截图中的配置页面。多模态来源的信息最终汇聚到同一个实体画像里。
再往上，实体之间的关联关系也被保留在记忆图谱（Memory Graph）中。你查询"库存服务"时，不仅得到文字描述，还能拿到从架构图、性能报告、配置截图中提取的完整关系网络。
一个具体场景：当 Agent 遇到一张截图
假设你的团队有一份故障排查文档，里面写了这么一句：
"当出现以下界面时（见图 3-2），请检查 Redis 连接池配置。"
传统知识库怎么处理？把这段话存为文本，图片作为附件。Agent 检索到这段话时，能告诉你"检查 Redis 连接池配置"，但完全不知道图 3-2 长什么样，更不知道图中显示的是什么错误信息。
如果系统能解析图片，情况就不一样了。图片被解析后，相关原子事实被提取出来——"图 3-2 显示 Redis 连接池耗尽的错误""错误代码为 CONN_POOL_EXHAUSTED""当前活跃连接数为 200/200"。这些事实和"检查 Redis 连接池配置"关联在一起。下次你遇到类似问题，Agent 不仅知道要检查什么，还能判断你当前的错误界面是否匹配这个场景。
这个差距在实际使用中体感很明显。
知识准入：AI 筛选 + 人工拍板
多模态内容有一个绕不开的问题：解析质量。图片识别可能出错，表格解析可能有偏差，PDF 加强解析也不是万能的。说实话，目前多模态解析的准确率还不如纯文本——特别是复杂表格和嵌套图片，AI 的识别结果经常需要人工修正。
比较务实的做法是 AI 筛选 + 人工拍板。
系统对多模态内容解析后自动评估置信度。高置信度的事实自动入库，低置信度的进入待审核队列。团队成员定期审核待审队列，确认或修正 AI 的解析结果。审核结果反馈给解析模型，时间一长，自动解析的准确率越来越高。
文本内容的解析准确率通常很高，图片和表格可能需要人工介入——至少在最开始是这样。从"半自动"起步，逐步过渡到"高度自动"，我觉得这个思路比较合理，一上来就追求全自动不太现实。
另外需要注意的是，这套方案目前只在 RDS MySQL 环境下可用，如果你用的是其他数据库，暂时还跑不起来。
接入方式
如果你也想试试让 Agent 具备多模态理解能力，接入只需要一条命令：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>
支持的 Agent 包括 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes 和 QoderWork。
知识库的完整度，决定了 Agent 的上限
回到开头那个问题。如果你的知识库里截图和表格占比不低，那这些内容对 Agent 是否可用，直接决定了 Agent 的能力天花板。一个只能处理文本的 Agent，和一个能理解图片、表格、PDF 的 Agent，在同一个知识库上的表现差距可能比你想象的大。
我的看法是，多模态这件事不是锦上添花，更像是补短板。Agent 终于能"看懂"那些截图和表格的时候，它突然变聪明了不少——不是因为模型升级了，而是因为它终于看到了完整的知识。不过也要承认，目前这套方案在数据量特别大的场景下还没充分验证，小规模团队用起来问题不大，大规模（比如几十万张图片的知识库）的性能表现还有待观察。
参考链接
