Agent 数据架构怎么选：五种方案对照

问五家供应商，该如何为 AI Agent 准备数据，你会得到五种不同的答案，而且每一种恰好都是那家供应商在卖的东西。做 graph database 的公司会说 knowledge graph，做 vector database 的公司会说 RAG，做 semantic layer 的公司会说 semantic model。严格说来，他们都没有撒谎。每一家只是在介绍自己工具箱里的那一件工具。

坦诚的答案是：为 AI Agent 组织数据，没有一种放之四海而皆准的最佳方式。目前，已有五种切实可行的方案用于生产环境：semantic model、ontology 和 knowledge graph、检索增强生成（RAG）、用 grep 搜索的纯 Markdown 文件，以及开放知识格式。每一种都解决不同的失败模式。如果选用的方案不适合你的问题，Agent 不会明显报错，而是悄无声息地给出一个流畅、自信、却错误的答案。因为瓶颈从来不在模型，而在交给模型的数据。

本文会逐一介绍这五种方案，并结合证据说明各自适用的场景，帮助你根据问题选择数据结构，而不是被供应商的推销话术牵着走。

“为 AI Agent 组织数据”是什么意思

为 AI Agent 组织数据，就是把信息整理成一种形式，让 Agent 能可靠地找到正确的事实、定义或文档。否则，它只能根据未经标注的原始数据猜测，最后给出一个听起来正确、实际上错误的答案。企业 AI Agent 失败，并不是因为底层模型能力不足，而是因为没人告诉 Agent，“活跃客户”究竟是什么意思，或者某个具体问题的答案在哪里。

首先，这是一个数据问题，然后才是 prompt 问题。给模型一个清晰、受治理的指标定义，它就会按这个定义来使用。给模型一堆原始表，却不提供上下文，它就会自行编出一个听起来合理的计算方法。直到有人在会议上核对数字，你才会发现问题。

为 AI Agent 组织数据的五种方式

semantic model（或 semantic layer）会把业务指标和实体统一定义一次，例如“月度经常性收入”“活跃客户”“客户流失率”，并明确每个定义背后使用的表、连接关系和过滤条件。Agent 可以直接按名称查询指标，而不必从零开始，针对原始表编写 SQL。

对于一种具体而常见的错误，这是投入产出比最高的解决办法：Agent 猜错了业务定义，算出了一个看似合理、实际不对的数字。在 dbt Labs 的 2026 年 benchmark 中，对于一组业务问题，通过 semantic model 查询的 Agent 准确率达到 98.2%–100%；而相同模型直接面对完整 schema，通过原始 text-to-SQL 编写查询时，准确率为 84.1%–90.0%。同一项 benchmark 还将当下的模型与一个 2023 年前后的模型进行了比较，两者都使用原始 text-to-SQL。结果显示，在这 2.5 年间，准确率几乎翻倍，从 32.7% 提升到 64.5%。这确实体现了模型的进步。但即使是最好的 2026 年模型，仍然没有达到使用 semantic model 时的准确率。这是更直接的证据：查询正确与否，差距来自 Agent 以什么作为依据，而不只是底层模型有多强。

如果问题涉及反复查询的业务指标，而且许多工具、许多 Agent 都会一再询问这些指标，“所有人拿到同一个数字”又很重要，那么 semantic model 就是合适的选择。如果只是针对某一份文档提出的一次性问题，或者需要关联一些 semantic model 在设计时根本没有打算关联的实体事实，它就不合适。

semantic model 还有一项价值，其他四种方案并不会自动具备：指标只需定义一次，任何 AI Agent 都可以通过 MCP 查询它。MCP 即 Model Context Protocol，是连接 Agent 与数据源的开放标准。这样，各个团队就不必为了回答同一个问题，分别构建自己的定制检索层或图层。semantic model 因而从一个一次性项目，变成了共享基础设施：其他 Agent 可以直接读取这个受治理的数据层，而不是让定义被锁在某个团队的 dashboard 里。

实现这一点，并不需要依赖某一家特定供应商。dbt 和 Cube 都能提供 semantic layer。相比选择哪种工具，更重要的是把指标定义当成值得一次做对的事情。

2. Ontology 和 knowledge graph

knowledge graph 存储实体，例如人员、账户、产品、合同，以及实体之间明确的关系，而不是把数据存成扁平的表或一段段文本。ontology 则是定义这些实体和关系允许表达什么含义的 schema，确保图在不断扩展时仍然保持一致。两者结合，可以让 Agent 沿着关联关系查找信息，发现关键词匹配或 embedding 匹配完全找不到的连接。例如：“这个联系人会影响哪些客户账户？其中哪些账户在支持问题升级后的六个月内流失了？”

这正是 GraphRAG 得名的原因：它通过查询 knowledge graph 来检索信息，并为相关实体组成的群组生成摘要，而不是依赖一个扁平的向量索引。Microsoft 在 2024 年的研究发现，相比普通的向量 RAG，GraphRAG 在全面性上的胜率为 72%，在多样性上的胜率为 62%。它的顶层摘要所需的 token，也比直接对源文本生成摘要少了 97% 以上。另一项独立的 2025 年系统性评估比较了 RAG 与 GraphRAG，发现如果在图检索之上增加选择与整合策略，在多跳推理 benchmark 上，相比表现最好的基线，结果可以提升 1.1%–6.4%。这是真实的提升，但比单看那些醒目的 GraphRAG 数字所暗示的幅度更小。它也提醒我们：检索技术与图本身同样重要。

knowledge graph 的构建和维护成本高于其他四种方案。需要有人为实体和关系建模，并在业务变化时确保 ontology 仍然准确。如果问题确实需要跨关联实体进行多跳推理，这笔成本值得付出。如果问题归根结底只是“查出这一个事实”，就没必要用这么重的方案。

3. RAG（检索增强生成）

RAG 会检索最相关的文本片段，通常通过 vector database 中的 embedding 相似度来完成，然后在模型回答之前，把这些片段作为上下文交给它。这是最快能搭起来的方案：把文档切块，生成 embedding，建立索引，一个下午就能得到可运行的系统。

如果要在规模庞大、结构松散的文档集合中查找事实，例如合同、支持工单、产品文档、会议记录，RAG 是合适的默认选择。如果回答需要关联不同文档中的多个事实，它就不是合适的工具，那属于前面介绍的 knowledge graph 场景。如果所谓的“事实”是一个受治理的指标，无论在哪里查询都应该得到同一个经过确认的答案，那么应该使用 semantic model。

还有一个更隐蔽的陷阱：检索到的上下文更多，并不意味着上下文更好。Chroma 在 2025 年的一项研究测试了 18 个前沿模型，包括 GPT-4.1、Claude Opus 4 和 Gemini 2.5，发现随着输入长度增加，准确率会下降，而且下降幅度并不均匀。相较于更干净的基线，即使只加入一段干扰文本，也会对表现造成可测量的影响。有时，模型面对逻辑结构清晰的长上下文，表现反而不如面对顺序被打乱的相同信息。这一发现已经得到相当广泛的验证，可以作为一条实用准则：检索内容的精准度，始终比数量更重要。

一些团队通过组合方案获得了实实在在的提升：先用向量索引检索，再用图中的关系核查或扩展答案。AWS 在 2024 年与 Lettria 合作的一项案例研究报告称，在向量 RAG 之上加入基于图的检索后，答案精确度最多提升了 35%。评估覆盖金融、医疗、航空和法律等使用场景。

4. 纯 Markdown + grep

这是最不起眼的方案，也是任何基础设施供应商都不会向你推荐的方案，因为他们都不卖这个：把数据放进纯 Markdown 文件，合理组织，再让 Agent 用 grep 或其他全文搜索工具检索。不需要 embedding，不需要 vector database，也没有图需要维护。

对于规模较小、组织良好的内部资料库，它的效果比听起来更好：这里说的是几百个文件，而不是几百万个。编程 Agent 已经在不断这样做。对于一个结构清晰的 Markdown 文档仓库，让 Agent 通过文件搜索工具直接读取，通常比为一个笔记本电脑就能装下的资料库搭建检索基础设施更快，也更容易理解它的工作方式。llms.txt、skill 文件约定等新兴模式背后，也是同样的思路：由熟悉内容的人组织、可以用 grep 搜索的纯文本，比对同一批材料建立一个只调了一半的向量索引更有效。

这里还有一个容易被低估的维护优势。Markdown 文件与其他代码和内容一样，可以纳入版本控制。每次修改都是人能读懂、审查和撤销的 diff，不需要重新运行 embedding 流水线，不需要重建索引，也不需要让 vector database 与权威数据源保持同步。

这种方案会在你预料到的地方失效：当资料库规模足够大，或者查询与目标文档在措辞上的差距足够大时，关键词匹配就会漏掉一些本可通过语义搜索或图搜索找到的内容。这是升级到 RAG 或 knowledge graph 的信号，而不是一开始就否定 Markdown 加 grep 这种合理起点的理由。

5. 开放知识格式

开放知识格式，例如 schema.org、JSON-LD（JSON for Linking Data）和 RDF（Resource Description Framework），使用共享的公开词汇体系来组织数据，而不是采用只有你自己的系统才能理解的格式。前四种方案组织数据，是为了让你自己的 Agent 读取；而当数据需要被你无法控制的 Agent 读取时，开放格式才显得重要。例如，客户的 AI 助手查看你的产品价格，搜索引擎的 AI Overview 总结你的文档，或者合作伙伴的 Agent 从你的公开网站获取结构化事实。

这与其他四种方案承担的任务不同，但人们很容易混为一谈。semantic model、knowledge graph 或 RAG 索引，是服务于你自己 Agent 的内部基础设施。开放格式则是一种发布方式，更接近你原本为搜索引擎给网页添加标记的做法，只是读取这些标记的受众越来越多地包含 AI Agent，而不再只有爬虫。如果你的数据只需要服务于自己团队的 Agent，那么在这份清单中，开放格式是你可以合理跳过的一项。

五种方案一览

应该选择哪一种？

根据问题选择数据结构，而不是根据供应商的推销话术。具体来说，就是先问清楚，Agent 需要回答哪一类问题：

“我们的［指标］是多少？”这是一个需要反复查询、受治理的业务数字。使用 semantic model。

“X 与 Y 有什么联系？这条关联链意味着什么？”这是跨实体的多跳推理。使用 ontology 或 knowledge graph，也可以选择搭配 GraphRAG 风格的检索。

“这份文档对……是怎么说的？”这是在一个并非由你手工编写的大型资料库中查找事实。使用 RAG。

“我们处理……的流程是什么？”资料库足够小，你大致知道答案在哪里。纯 Markdown 加 grep 往往搭建更快，而且同样可靠。

“一个不受我控制的 Agent 能读取这些数据吗？”它可能是合作伙伴、客户或搜索引擎的 AI。使用开放格式。大多数生产系统会组合其中两种或三种方案，而不是只选一种：用 semantic model 处理指标，用 RAG 处理合同和支持工单，用可通过 grep 搜索的内部文档保存团队操作手册，再让同一个 Agent 读取这些内容。问题不在于选择某一种方案，而在于认定一种方案必须覆盖所有问题。

实际应用会是什么样？

假设一个 Revenue Operations（营收运营）团队正在构建一个帮助处理续约的 Agent。在一次对话中，这个 Agent 可能要回答五种不同的问题，而每一种问题都需要背后有不同的数据结构。

“这个客户账户的净收入留存率是多少？”这是一个受治理的指标，只有一种正确的计算方式。Agent 应该查询 semantic model，而不是自己针对原始订阅表编写 SQL，再寄希望于结果能与财务部门的数字一致。

“Acme Corp 中谁向谁汇报？其中哪些人也参与续约决策？”这是一个跨人员、角色和客户账户的多跳问题，应该交给 knowledge graph。扁平表或文本搜索无法沿着汇报关系链进行追踪。

“合同对续约通知期限是怎么规定的？”这是一个事实，藏在数千份合同中的某一份文档里。RAG 可以检索出相关条款，不需要任何人逐一阅读所有文件。

“对于存在续约风险的客户，我们的内部处理手册是什么？”这个问题指向团队亲自编写、熟悉到几乎能背下来的几十份组织良好的操作手册。纯 Markdown 加 grep 就能在毫秒级找到正确文档，而且无需维护任何基础设施。

“我们公开的定价页面，客户自己的 AI 助手能看懂吗？”这是一个涉及不受你控制的 Agent 的问题，属于开放格式的适用场景。

这份清单里，没有任何单一方案能够回答全部五种问题。这才是为什么应该把“如何为 AI Agent 组织数据”视为一项方案组合决策，而不是一次性的架构选择。

迁移路径通常沿着一个方向推进。团队先从 Markdown 加 grep 开始，因为这是最快能奏效的方案。当资料库规模超出关键词搜索的能力时，再把其中一部分迁移到 RAG。只有遇到 RAG 总是答错的某类具体问题时，通常是多跳问题，才加入 knowledge graph。很少有团队第一天就从 knowledge graph 起步，这也是一个合理的默认做法：先构建当前问题需要的数据结构，等真实问题暴露出缺口时，再增加更多能力。

Context engineering 与 prompt engineering

上面介绍的所有做法，都属于如今被称为 context engineering 的工作：决定哪些信息进入模型的上下文窗口，以什么形式进入，以及放入多少。这与 prompt engineering 不同，后者关注的是如何在一条消息中组织指令的措辞。区分两者很重要，因为如果交给模型的是错误事实，或者事实太多，再完美的 prompt 也解决不了问题。

无论你如何组织数据，使用 semantic model、knowledge graph、RAG，还是 Markdown 文件，都要遵循同一条原则：给 Agent 恰好足够回答问题的事实，而不是把你拥有的一切都塞给它。

五种切实可行的方案，承担五种不同的任务。semantic model 用于受治理的指标，knowledge graph 用于多跳推理，RAG 用于大型资料库中的事实查找，纯 Markdown 和 grep 用于小型资料库，开放格式用于不受你控制的 Agent。销售这些组件的供应商都会告诉你，自己的产品就是答案。通常并不是，至少单靠它自己不是。先从 Agent 需要回答的问题出发，合适的数据结构自然会随之确定，而不是由哪种基础设施最容易卖给你来决定。

本文最初发表于 RevOS 博客。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。