专栏导语
AI 时代数据洪流来袭，晨章数据以创新 “数据基层” 架构破局！旗下分布式数据库系列产品，实现计算、内存、日志、存储四元解耦，0.1ms响应跨模态需求，更全面开源赋能生态。本专栏将邀请五位嘉宾，从不同视角深探晨章数据的领先之道：
解析云原生弹性架构优势，探索新硬件红利，看 AI 原生数据库如何突赋能AI创业者，锚定市场痛点破局，听创始人拆解技术创业逻辑，干货持续输出，敬请关注！
特邀数据库领域专家德哥带来深度研究报告，聚焦 AI Native 数据库技术内核，全面梳理其发展脉络与未来趋势。
德哥(digoal)
PostgreSQL 中国社区发起人之一, 荣获40余项数据库领域专利。曾就职于阿里云(至今)、杭州斯凯(SkyMobi), 担任过DBA、架构师、产品经理、开源社区运营与生态建设等工作. 长期致力于推动开源数据库技术、生态在中国的发展与开源产业人才培养. 曾荣获阿里巴巴麒麟布道师最高荣誉、OSCAR开源尖峰人物、PG分会ACED、PG中文社区猛犸象奖。
背景
本文分为2个部分:
1、什么是AI Native数据库?
2、AI Native 数据库发展趋势研究
什么是AI Native数据库?
什么是AI Native数据库? 研究一个新事物最好的办法是拿这个新事物来进行研究, 那么市面上有没有AI Native数据库呢? 还真有! 这个产品天生就是朝着这个方向去设计的, 所以研究它即可快速了解AI Native数据库。
这就是晨章数据!
这是在第一节就开始介绍晨章数据的原因之一, 另一个原因是本文相关的其他几个产品DuckDB、PostgreSQL(原生及Aurora、PolarDB、Neon、Citus等高级版)、DataFusion的产品推出时间都非常久, 大家相对来说比较熟悉，但并非为AI Native目标进行设计。
最重要的是我看完晨章数据的产品文档以及几位创始人的分享视频后, 他们的产品理念非常先进, 可以说是围绕AI 数据库赛道重新设计, 非常值得学习关注. 有兴趣的朋友可关注他们的公众号和视频号‘晨章数据’。
1、首先是晨章对AI Agent的需求分析判断非常深刻
AI应用分为无状态和有状态两类, 其中无状态应用每次调用都不依赖上下文，输入→输出是一次性的。系统不会记住之前发生了什么. 应用如提取文本摘要、图像识别、文章翻译等。
另一类是高附加值的有状态应用, 例如多轮对话助手、游戏智能NPC、智能客服. AI应用需持续维护用户状态/上下文，理解历史对话或任务过程，具备“记忆”或“多轮推理能力”. 也是数据库重点发力的部分, 需负责记录状态与外部知识. 其中就包括了大家最熟知的RAG应用, 数据库需要对数据进行清洗、分割、建立关系、向量化便于检索. 为了提高召回率和准确度, 不仅要支持语义检索, 还需要支持全文检索, 模糊检索, 甚至还需要支持ranking等. 对数据库来说挑战也是非常大的。
另一方面晨章对AI数据库发展趋势的判断, 与本文的深度分析基本一致. 都提到了生态的集成, 多模态的支持, 弹性扩缩容. 同时还考虑到用户更高层面的商务需求: 例如云中立、成本、防绑定等。
2、当前数据库架构难以满足AI应用的点有哪些?
- 数据多模态，简单应用也需要多个数据库，管理成本极高
- 各个Agent看到不同时间的数据状态，数据不一致性造成各种应用复杂性
- 无法灵活扩展数据模态，快速扩缩容，也无法共享资源
3、AI 需要什么样的数据库?
本文整篇都在说AI需要什么样的数据库,
无需多言, 晨章重点提了4点：
- 跨模态分布式事务
- 统一查询接口(指多模态统一接口)
- 标准化API
- 单节点极致性价比，动态伸缩
4、为了达成这个目的, 晨章提出了数据基层的概念。
存储计算分离大家都在提, 也有很多产品都这么做了, 但是很少有产品提的是分离之后怎么把多模态统一进来。
数据基层负责的就是黏合计算和存储, 抽象化所有数据管理系统的核心功能(缓存、并发控制、持久化、弹性和可扩展性、容错等)。
从此一个数据库可以通过以下方式组装：
- 根据数据模型选择计算模块
- 根据部署环境选择存储模块
- 启用或关闭特定功能（例如日志记录）以权衡性能与功能
5、最终的产品可想而知, 在这个平台上想实现什么样的模态就像PG/DuckDB加扩展一样方便, 最关键的是在计算存储分离的架构下加扩展模态, 这就不一样的, 天然具备了横向扩展能力。
EloqData 数据库基于统一架构引擎，提供多种标准API接口，高性能，可扩展，低成本，云原生，全面支持ACID事务。
KV, SQL, DOC, AI 一应俱全。
6、EloqConvergedDB 是在这个架构下诞生的, 一款专为AI 时代量身打造的数据库。多模态引擎灵活组合，API无缝兼容，满足AI多模态计算需求。专为AIGC、AI Agent及具身智能应用场景设计，确保高性能实时应用体验。
可以这么说, 数据基层发挥了重要作用, 在统一的产品中快速对接新的模态. 打破产品间的数据孤岛、状态割裂问题。
看到这, 你是不是开始对晨章的产品有点兴趣了。
大家后续可关注他们的开源项目进展: https://github.com/eloqdata
读完第一部分的内容, 想必大家对AI Native数据库有了一定的概念! 接下来就可以深度解读AI Native数据库发展的趋势了。
AI Native 数据库发展趋势研究
AI 智能体需要什么样的数据库产品?
现有的数据库为什么无法满足AI 智能体需求?
未来数据库的发展趋势如何?
是所有需求汇聚到一种数据库中?
还是不同需求使用不同赛道的专业数据库?
让我们来看看这个Google Gemini Deep Research生成的深度研究报告! (根据个人意见轻微调整. 提示:AI Agent需要什么样的数据库产品，未来数据库产品发展趋势)
摘要
本报告对当前人工智能（AI）代理(Agent/智能体)开发所需的数据库产品进行了全面分析，并展望了这些技术的未来发展趋势。AI代理以其自主性、多模态处理能力和持续学习特性而闻名，这要求其数据基础设施必须高度复杂且多样化。没有单一的数据库范式能够充分满足所有这些需求，因此 “多模态”方法变得至关重要。向量数据库已成为语义理解和检索增强生成（RAG）的基石，而图数据库则对实现复杂推理和上下文感知至关重要。传统的关系型数据库和NoSQL数据库在结构化数据和灵活数据管理方面继续发挥关键作用。展望未来，数据库领域将受到AI原生和自治系统、动态知识架构、去中心化数据网格/数据结构模型以及分布式无服务器/边缘计算解决方案的深刻影响。这些趋势将共同推动更智能、高效、可靠的AI代理部署，从根本上改变企业利用数据进行AI驱动创新的方式。
观察1：AI代理的“多模态”必然性。
AI代理的定义表明其能够同时处理文本、语音、视频、音频和代码等多模态信息，并具备对话、推理、学习和决策的能力 。它们能够执行复杂的、多步骤的操作，并随着时间的推移进行学习和适应 。这种能力要求管理多种多样的数据类型：例如，用户配置文件和日志等结构化数据；文本、图像和向量等非结构化数据；用于知识存储的嵌入(embedding向量)和RAG上下文；以及聊天历史等实时数据 。
然而，单一模态的数据库类型在满足所有这些数据形式的性能、可伸缩性和一致性要求方面存在固有的局限性 。例如，传统的关系型数据库在处理非结构化数据和满足AI工作负载的可伸缩性方面面临挑战，而专用的向量数据库虽然高度优化，但可能导致数据孤岛 。因此，将AI代理的各种能力与不同数据类型的需求进行匹配，并考虑到单一数据库解决方案的局限性，可以清晰地看到，采用“多模态”策略——即结合使用多种专业数据库类型(或采用天然支持多模态的数据库产品)——对于构建强大且高性能的AI代理来说，不再仅仅是一种选择，而是一种根本性的架构需求。
这意味着企业必须摆脱“一刀切”的数据库方法，转而采纳异构数据基础设施。这要求企业投入资源，掌握集成和管理各种数据库技术所需的专业知识和工具，从而影响数据架构、工程实践和组织技能。
理解AI代理：数据与操作要求
AI代理是复杂的智能系统，旨在感知环境、处理信息并自主执行操作以实现特定目标。与简单的机器人或被动助手不同，AI代理展现出更高程度的自主性，能够处理复杂的、多步骤的任务，并具备显著的学习和适应能力。其操作特性直接决定了其对数据库的严苛要求。
多样化的数据模态与处理需求
AI代理本质上是多模态的，能够同时处理和整合来自不同来源的信息，包括文本、语音、视频、音频和代码。这种能力主要由生成式AI和基础模型提供支持。为了理解复杂的上下文并做出明智的决策，AI代理必须具备处理这些多模态信息的能力。这意味着传统的、仅支持结构化数据的数据库已无法满足需求；数据库必须有效地支持非结构化和半结构化数据。
AI代理“观察”环境的能力涉及多种感知形式，例如计算机视觉、自然语言处理（NLP）或传感器数据分析。多模态AI系统通过整合这些多样化的数据类型，能够实现更好的上下文理解、更高的准确性、增强的问题解决能力、跨领域学习、创造性以及更丰富的交互。这种整合使AI代理能够解释更广泛、更丰富的信息集，从而产生更接近人类的预测和上下文感知的输出。
应用案例: AI代理正被部署到广泛的应用中，包括：
- 客户代理:通过理解客户需求、回答问题和推荐产品，在多个渠道（网络、移动、语音、视频）提供个性化客户体验 。
- 员工代理:通过流程简化、重复任务管理、回答员工问题以及编辑和翻译关键内容和通信来提高生产力。
- 创意代理:通过生成内容、图像和想法，协助设计、写作、个性化和营销活动，从而提升设计和创意过程 。
- 数据代理:专为复杂数据分析而构建，能够从数据中发现并采取有意义的洞察，同时确保结果的事实完整性 。
- 代码代理:通过AI辅助代码生成和编码协助，加速软件开发，并帮助快速掌握新语言和代码库 。
- 安全代理:通过缓解攻击或加快调查速度来加强安全态势 。
记忆与实时决策
- 记忆需求:AI代理通常配备多种记忆类型以支持其操作：用于即时交互的短期记忆、用于历史数据和对话的长期记忆、用于过去交互的事件记忆以及用于代理之间共享信息的共识记忆 。这种分层记忆架构支持复杂的、多步骤的操作和独立的决策 ，因此需要数据库能够随着时间的推移存储和检索各种形式的上下文数据 。
- 实时操作: AI代理在实时系统中运行，通过在严格的时间限制内持续处理输入、做出决策并执行操作 。这些系统优先考虑低延迟响应，以确保与环境的及时交互 。为了满足这些时间要求，实时执行通常依赖于轻量级模型、高效算法和硬件加速 。
- 示例: 自动驾驶汽车的AI代理在毫秒内处理传感器数据（如摄像头馈送或激光雷达）以检测障碍物并调整转向或制动 ；交易平台上的AI代理必须在几分之一秒内分析市场数据并执行买卖订单 。这种实时性要求意味着数据必须几乎即时地被处理和采取行动 。AI代理通过数据分析、预定义规则和机器学习算法来处理实时决策，并通过试验不同的行动和接收结果反馈来优化其决策过程 。
复杂查询与知识表示
- AI代理处理复杂查询的能力是其自主推理和行动的基础。在代理场景中，许多查询需要比传统检索系统更强大的功能 。这些查询通常是复杂的、会话式的，可能包含拼写错误或与相关文档的词语重叠度低，因此需要进行查询转换和上下文理解 。
- 推理与规划: AI代理的核心能力包括感知环境、理解上下文、分解复杂问题、制定解决方案以及创建实现目标的逐步行动计划 。这需要访问动态知识，而不是仅仅依赖静态训练数据，以防止“幻觉”（生成听起来可信但事实不正确的信息）并确保实时相关性。
- 检索增强生成（RAG）: RAG是一种关键机制，允许AI代理发现和利用动态知识 。代理式RAG超越了简单的查询-检索-生成模式，使代理能够提炼查询、将RAG作为工具使用，并随时间管理上下文 。
- 知识表示（KR）: KR是AI代理构建的基础，它提供了一种正式的框架，用于编码事实、关系和规则，从而实现推理、决策和问题解决 。它使AI系统能够解释非结构化数据并应用逻辑推理，这对于在复杂环境中自主操作至关重要 。
- 知识图谱（KGs）: KGs是KR的一种强大形式，将信息表示为节点（实体）和边（关系）。它们使AI能够实时检索洞察，发现以前隐藏的模式，并通过可识别的实体和有意义的关系来表示知识，从而做出更明智的决策 。KGs在通过模糊性进行推理、进行推断以及填补不完整数据中的空白方面特别有效，为上下文理解和规划提供了“认知支架” 。
证明RAG不够用的相关文章
[《AI论文解读 | KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation》](../202505/20250515_01.md)
[《AI论文解读 | From Local to Global: A GraphRAG Approach to Query-Focused Summarization》](../202505/20250514_02.md)
[《AI论文解读 | Retrieval-Augmented Generation with Graphs (GraphRAG)》](../202505/20250514_01.md)
[《为什么用了RAG, 我的AI还是笨得跟猪一样! RAG效果评测与优化》](../202504/20250414_04.md)
[《维基百科(wikipedia) RAG 优化 | PolarDB + AI》](../202504/20250417_01.md)
深层观察与影响：
观察2：AI代理“感知-处理-行动”循环的数据需求。
AI代理的核心操作模式是“感知数据、处理信息并自主采取行动” ，即“感知-规划-行动”循环。这个基本循环决定了支持AI代理的数据库系统必须在所有阶段都具备高性能。感知阶段，由于需要处理多模态数据 ，要求数据库能够以高速度摄取和管理大量、多样且通常是非结构化的数据流。随后的处理和决策步骤则需要极低的延迟访问和实时分析能力。最后，自主行动阶段需要可靠的数据持久化和状态管理，以确保操作的一致性和连续性。传统数据库主要为结构化关系数据设计，在处理这些多模态输入的规模、多样性和速度以及实时处理需求方面存在固有的困难。
这意味着数据库不再仅仅是存储库，而是AI代理操作循环中的活跃组成部分。数据库产品必须发展，以提供无缝的、高吞吐量的多样化模态数据摄取能力，并结合实时处理和检索机制，从而有效地支撑AI代理的持续自主运行。这必然推动向专业化或混合数据库解决方案的转变，这些方案能够处理“感知-处理-行动”循环每个阶段的独特需求。
观察3：记忆作为AI代理智能的基础。
AI代理的记忆概念 不仅仅是数据存储，它更是代理学习、适应和独立决策的基础 。短期记忆用于即时交互，而长期记忆和事件记忆则用于历史数据和过去的交互 。这表明需要能够处理瞬态、高速度数据（短期记忆）以及持久、不断演进的知识（长期记忆）的数据库。AI代理的持续学习特性 意味着其记忆系统必须是动态且可适应的，允许频繁更新、再训练和知识的完善。静态数据库将严重限制代理的学习和改进能力。
这意味着单一的数据库解决方案不太可能最佳地服务于AI代理的所有记忆类型。相反，需要一种复合方法，可能结合使用记忆数据库（如Redis）处理短期、高速度数据，以及更持久、可扩展的解决方案（如向量数据库或NoSQL数据库）处理长期知识和历史上下文。数据库架构必须促进这些不同记忆组件之间的无缝交互，以支持代理的完整学习和决策生命周期。
观察4：从“搜索”到“推理增强检索”的转变。
传统RAG的模式是简单的“查询、检索、生成” 。然而，AI代理面临“复杂查询” ，并需要“动态知识” 以避免“幻觉” 。这表明需要超越简单的关键词搜索。AI代理检索API 通过将复杂的会话式查询转换为多个优化的搜索查询、生成释义并纠正拼写错误，在检索之前执行这些操作，这展示了更智能的检索过程。此外，对知识图谱的强调 是为了实现“复杂推理” 和“通过模糊性进行推理” ，这突出表明数据库系统不仅要支持语义相似性（向量搜索），还要支持对互联数据的逻辑遍历和推理。目标是为大型语言模型（LLM）提供更丰富、更结构化的上下文，使其能够生成更准确、更明智的答案 。
这意味着未来的AI代理数据库产品不能仅仅是被动的数据存储。它们必须成为代理推理过程中的活跃参与者，提供智能查询转换、多步骤检索的先进功能，并原生支持图谱等复杂知识结构。这种演进预示着数据库系统本身将变得越来越“智能”，能够理解并促进代理的认知过程，而不仅仅是满足简单的数据请求。这将显著提高AI代理的准确性、适应性和可靠性，特别是在高风险、动态的环境中。
当前AI代理的数据库格局
AI代理的多样化需求要求数据库选择采用多方面的方法。没有(应该说少有吧, 现在越来越多数据库支持多模态了)单一的数据库类型能够高效地处理所有数据模态和操作需求。相反，通常需要结合使用专业化和混合型解决方案。
表1：AI代理数据需求与数据库类型
向量数据库：语义理解和RAG的基石
向量数据库是专门为管理高维向量数据而构建的，能够实现高效、快速和可靠的语义相似性搜索 。它们存储向量嵌入，即数据（如文本、图像等）的数值表示 ，并被广泛应用于自然语言处理（NLP）、异常和欺诈检测、推荐系统以及图像识别等领域。
AI代理的关键功能:
-检索增强生成（RAG）: 向量数据库在RAG应用中扮演着至关重要的角色 。它们将文档块存储为嵌入，通过比较查询的嵌入与存储的嵌入来查找相关的文本块 。这使得LLM能够访问外部的、最新的和特定领域的信息，从而减轻“幻觉”现象并克服令牌限制 。
- 语义搜索: 向量数据库通过使计算机能够根据数据的含义和上下文（而不仅仅是精确匹配）来理解和检索数据，从而弥合了“语义鸿沟” 。这对于需要解释细微查询的AI代理至关重要 。
- 多模态嵌入: 向量数据库支持多模态AI应用（文本、图像、音频嵌入），通过混合查询实现 。Weaviate因其开源性质、对混合查询的支持以及与OpenAI、DeepSeek和Hugging Face等AI工具的良好集成而被特别强调 。
- 示例: Pinecone、Weaviate、Qdrant、ChromaDB 。MongoDB Atlas和PostgreSQL（通过pgvector扩展）也提供了向量能力 。
关系型数据库：管理结构化数据和元数据
关系型数据库非常适合存储用户配置文件、日志和事务信息等结构化数据 。它们以结构化格式、ACID（原子性、一致性、隔离性、持久性）合规性和数据规范化为特点 。
- AI代理用例: 存储AI元数据、日志和管理事务性AI应用 。PostgreSQL通过pgvector扩展，可以在处理关系数据的同时支持向量搜索。
- 局限性: 在处理非结构化数据以及面对大规模数据集和高并发向量工作负载时，关系型数据库在可伸缩性方面存在挑战 。对于复杂的查询或模式变更，它们通常需要更多的开发工作。
-示例: PostgreSQL、MySQL、SQLite、MariaDB、Microsoft SQL Server 。
NoSQL数据库：非结构化和半结构化数据的灵活
NoSQL数据库旨在提供灵活的模式，能够很好地处理非结构化数据（文本、图像、JSON）和半结构化数据 。它们为特定用例提供高性能、可伸缩性（水平扩展）和高可用性 。
- AI代理用例:存储聊天历史、文档处理、物联网数据管理、内容管理系统和个性化引擎 。
- 局限性: 可能不适合复杂的连接操作或严格的结构化模式 。某些NoSQL数据库可能缺乏对高级分析的原生支持 。
- 示例: MongoDB、Redis、Couchbase、HBase、Amazon DynamoDB、Elasticsearch、PG JSON。MongoDB Atlas还提供集成的向量搜索功能。
图数据库：实现复杂推理和上下文理解
图数据库将数据存储为节点（实体）和边（关系），从而更容易连接、分析和遍历复杂的关系 。它们能够保留上下文信息并实现实时洞察检索 。
AI代理的关键功能:
- 知识表示: 提供一个结构化的框架来编码事实、关系和规则，从而实现推理、决策和问题解决 。这对于理解上下文和消除歧义至关重要 。
- 复杂推理:允许AI即时处理关系，发现隐藏的模式。它们支持通过模糊性进行推理，并从不完整的数据中进行推断。AI代理与图数据库结合，可以无缝地导航企业工作流，并做出自主的、上下文感知的决策。
- 用例: 欺诈检测、推荐系统、供应链优化、安全监控和个性化AI助手 。
- 示例: Neo4j、TigerGraph、Dgraph、PG age/CTE递归调用 。
专业化与混合解决方案：内存、时间序列和多模型方法
- 内存数据库: 提供快速检索和缓存，用于实时数据，如聊天历史 。Redis是缓存AI响应的流行选择。
- 时间序列数据库: 最适合基于AI的物联网、日志和实时事件处理 。InfluxDB是一个示例 。
- 混合/多模型数据库: 旨在将事务性、分析性和向量数据统一到单一平台中，消除数据孤岛并降低操作复杂性 。PolarDB被视为一个示例，提供分布式SQL、向量搜索、HTAP（混合事务/分析处理）和MySQL/PG兼容性。MongoDB Atlas也提供混合搜索（文本+向量）功能。
深层观察与影响：
观察5：数据模型融合以应对复杂性。
传统数据库（关系型）在处理AI的非结构化/向量数据方面存在困难 。专用的向量数据库虽然高度优化，但可能导致数据孤岛 。NoSQL数据库提供灵活性，但可能缺乏强一致性或复杂连接能力 。图数据库在处理关系方面表现出色，但可能不是所有数据类型的主要存储 。这种碎片化问题催生了“带向量能力的混合/多模型数据库” 的出现，例如TiDB 和带有向量搜索的MongoDB Atlas ，它们直接解决了这一问题。这清晰地表明，行业正朝着在单一平台内统一多种数据模型的方向发展，以降低操作开销并确保数据一致性。
这意味着数据库供应商正在通过构建更集成、多模态的解决方案来应对“多模态”挑战。这简化了开发人员的架构，并降低了管理不同系统的复杂性，从而更容易构建全面的AI代理。
观察6：向量数据库作为LLM的“语义桥梁”。
大型语言模型（LLM）虽然功能强大，但可能出现“幻觉”或缺乏最新、特定领域的知识 。向量数据库通过RAG机制，将LLM的响应建立在经过验证的、最新的外部数据之上。这不仅仅是存储问题；它涉及将语义含义转换为可检索的格式（嵌入），LLM可以利用这种格式来生成更准确、更具上下文相关性的输出。这突出了向量数据库作为原始数据与LLM推理之间关键“语义桥梁”的作用。
这意味着向量数据库不仅仅是一种存储解决方案，它更是构建可靠和准确的生成式AI应用的基本架构组件，直接解决了LLM的信任度和事实完整性问题。在实际的AI代理部署中，它们的作用正变得与LLM本身同样基础。
观察7：图数据库作为代理推理的“认知骨干”。
AI代理需要独立推理、规划和决策 。知识表示（KR）对实现这一点至关重要，它通过结构化事实和关系来支持推理和问题解决 。图数据库擅长表示这些复杂的、多维度的关系 。它们使AI代理能够遍历关系、发现隐藏模式并理解上下文 。这使得图数据库不仅仅是数据存储，它们是提供语义基础和上下文理解的“认知骨干”，对于高级代理推理至关重要。
这意味着对于高度自主和复杂的AI代理，图数据库将变得越来越不可或缺，以实现复杂的决策制定，特别是在需要深入上下文理解和关系分析的领域（例如，欺诈检测、供应链、医疗诊断）。它们建模“游戏规则”和“操作规范”的能力 是构建可信赖和可解释AI的关键。
表2：AI代理数据库类型：用例、优缺点
AI代理数据管理的关键挑战
在为AI代理管理数据时，组织面临着一系列重大障碍，这些障碍揭示了实施的复杂性。
数据质量、偏差与可用性
AI代理的开发高度依赖于准确、多样且大规模的数据集。数据质量差或数据不足会导致AI代理效率低下，并产生不正确或不完整的输出。例如，如果AI代理在订购新笔记本电脑时没有准确的员工软硬件使用数据，可能会导致购买不合适的设备。
算法偏差是一个重大问题，源于训练数据中的偏见。这可能导致歧视性结果，例如面部识别软件在识别深肤色人群时准确性不足，因为其训练数据主要由白人个体组成。为了应对算法偏差，必须确保AI开发过程包含多样化的团队和多样化的数据集。AI代理的实时适应能力要求访问实时、高保真的数据，以准确反映当前情况。代理的可靠性与其数据质量直接相关；质量差或过时的数据可能导致重复性故障或偏斜的输出。
可伸缩性、性能与成本
AI代理在处理大量数据或高并发用户请求时，若缺乏适当的可伸缩性考量，将面临挑战。例如，许多企业发现其AI代理在处理大量数据或高并发用户请求时表现不佳。
实时数据处理需要低延迟响应 ，这通常涉及计算复杂性与时间保证之间的权衡。例如，自动驾驶汽车可能使用简化的计算机视觉模型来避免障碍物，而不是高精度但速度较慢的神经网络。
AI开发和持续维护的成本可能对小型企业造成巨大压力。根据麦肯锡的报告，实施AI的平均成本可能从30万美元到超过100万美元不等，具体取决于项目的复杂性。许多CIO还经常低估AI的成本，误差高达1000%。多模态模型对计算和内存的需求巨大，例如，结合视觉转换器和语言模型会使参数翻倍，增加内存使用和训练时间。
与现有系统的集成
将AI工具与现有系统（如医疗保健领域的传统电子健康记录（EHR）系统）集成时，会遇到兼容性问题、数据不一致和操作中断 。例如，医院在尝试将AI工具与现有EHR系统集成时，遇到了兼容性问题、数据不一致和操作中断 。确保互操作性和最小化部署期间的干扰需要仔细规划 。
安全性、隐私与治理
安全和数据隐私是AI普及的主要障碍 。需要制定数据管理计划，以解决数据治理、知识产权问题以及AI代理使用组织敏感信息的问题 。确保合规性和伦理考量至关重要 。
AI驱动的数据治理利用代理式AI，通过自主代理进行异常检测、持续数据质量管理和动态访问控制，从而确保大规模的法规遵从性、维护数据质量并保护敏感信息 。挑战包括难以追踪特定数据对AI决策的影响（数据溯源性），以及难以关联分散的审计日志 。例如，审计日志可能显示“AI代理访问了数据库”的时间戳，但缺乏关于具体处理或转换了哪些数据的记录。需要动态的、基于行为的访问控制，而不是仅仅依赖静态的基于角色的权限 。
持续学习与维护
AI代理并非“一劳永逸”的解决方案 。一旦部署，它们需要持续维护和更新，以确保其有效性，并适应不断变化的用户偏好和新数据 。例如，Netflix的推荐算法需要根据新内容、用户行为和观看趋势进行定期调整。未能更新AI代理可能导致其过时和效率降低。实施持续学习管道和自动化监控系统至关重要。此外，嵌入是静态快照，除非明确更新，否则不会演变，这给自适应记忆带来了挑战。
深层观察与影响：
观察8：“输入垃圾，输出垃圾”的谬误与AI可靠性。
多项资料明确指出，“低质量或不充分的数据可能导致AI代理效率低下” ，并且“不准确或不完整的数据更有可能导致糟糕的决策” 。另有资料进一步强调，“AI代理的可靠性与其数据质量直接相关” 。这揭示了一个关键且常被低估的挑战：AI代理性能对数据质量的根本性依赖。与传统软件中不良输入可能仅导致错误不同，在AI中，不良输入可能导致AI自信地生成不正确或有偏见的“幻觉” ，这种影响更为隐蔽和有害。
这意味着投资于健壮的数据治理、数据清洗和持续数据验证流程并非可有可无的附加项，而是部署可信赖、高效AI代理的先决条件。关注点从仅仅“存储数据”转向“存储可信赖的数据”。
观察9：AI代理的“操作化鸿沟”。
资料将“与现有系统集成”和“可伸缩性与性能”列为关键挑战 。更深入的分析揭示了将认知计算、机器人技术、机器学习和自然语言处理等多项技术整合到一个“实时设置中无需人工干预的综合系统”的复杂性。另有资料指出，“扩展和维护AI代理成本高昂”，并且“从试点到企业规模的过渡往往会发现隐藏成本” 。这表明在AI代理概念验证阶段与成功部署和管理企业级AI代理之间存在显著的“操作化鸿沟”。挑战不仅限于选择数据库，还涵盖了整个数据和AI生命周期管理。
这意味着企业需要针对AI代理量身定制全面的MLOps（机器学习操作）和DataOps（数据操作）策略，重点关注自动化部署、监控、持续集成/交付（CI/CD）以及成本管理，而不仅仅是模型训练。这也推动了对“自治数据库”和“AI驱动数据治理”的需求。
观察10：“可问责性与可解释性”困境。
资料明确指出，“即使AI代理独立执行决策，问责仍在于人类” 。同时，AI代理常被视为“黑箱”，缺乏“透明度和可解释性”，这使得它们难以调试或信任，特别是在受监管的环境中。另有资料揭示了追踪特定数据如何影响AI决策的困难。这产生了一个根本性的困境：如果人类无法完全理解或追踪AI代理的推理过程，又如何对其自主决策负责？
这意味着未来的数据库和AI系统必须整合增强的日志记录、溯源追踪和可解释性功能（例如，AI决策的审计追踪、清晰的数据血缘），以支持人工监督、满足法规遵从性，并建立对AI代理的信任。图数据库凭借其建模关系和规则的能力，可以在提供这种透明度方面发挥重要作用。
AI代理数据库产品的未来趋势
本节将探讨数据库技术的演变格局，预测它们将如何适应并赋能下一代AI代理。
AI原生与自治数据库：自优化与智能系统
- 概念:AI驱动的自治数据库管理系统（ADBMS）利用机器学习、预测分析和自动化来优化数据库性能、减少管理开销并增强可伸缩性。它们是自我管理、自我调整、自我修复和自我保护的。
- 能力:自动调整性能参数（内存分配、查询优化、索引） ，检测并纠正故障 ，自动化安全更新和威胁检测 ，以及动态分片数据。Oracle自治数据库就是一个例子，它提供内置AI、RAG能力以及多模型支持（SQL、JSON、图、地理空间、文本和向量）。
- 影响:降低管理开销，提高性能，增强可靠性，并将人力资源解放出来，专注于更高价值的任务。
动态知识与代理式RAG：演进的数据检索范式
- 从静态到动态的转变: AI代理需要访问动态的、不断变化的知识，超越静态训练数据 。
- 代理式RAG:一种比传统RAG更动态的方法，代理在此过程中查询、提炼、将RAG作为工具使用，并随时间管理上下文 。这对于研究和总结等异步任务非常有效 。
- AI查询引擎: 作为动态知识系统的核心，这些强大的系统将AI代理连接到海量、多样且不断更新的数据源。它们摄取和组织大量信息（文本、图像、视频、结构化数据），使用多模态嵌入和向量搜索进行准确检索，并支持持续学习。Azure AI Search的代理式检索API能够转换复杂查询，执行多次搜索，并合并结果以生成答案。
- 知识图谱的动态上下文:知识图谱可以通过AI代理持续丰富和更新，模仿人类大脑形成连接的方式 。它们为上下文理解和规划提供“真相系统”和“认知支架”。
数据网格与数据结构架构：去中心化与统一数据管理
- 数据网格（Data Mesh）:一种去中心化的方法，将数据所有权和管理责任下放给使用数据的团队，从而创建“数据产品” 。它旨在防止数据孤岛、减少瓶颈并提高效率 。数据网格促进自主数据域的形成 。
- 数据结构（Data Fabric）: 一种通过智能和自动化系统，促进各种数据管道和云环境端到端集成的架构。它旨在消除数据孤岛、提高数据质量并加速洞察获取 。数据结构利用语义知识图谱、元数据管理和机器学习进行智能集成和数据质量提升 。
- 对AI的影响:这两种架构都旨在弥合原始数据源与AI模型之间的差距，提供组织良好且可消费的数据 。它们确保为生成式AI模型提供高质量、及时且相关的数据 ，并简化实时数据摄取并改进数据同步 。
无服务器与边缘计算数据库：分布式与低延迟解决方案
- 无服务器数据库: 根据应用程序需求自动扩展（向上/向下），包括在不使用时缩减到零 。它们抽象了基础设施管理，提供基于消费的定价，并提供实时访问和无限可伸缩性 。适用于不可预测的工作负载 。
- 边缘计算数据库: 允许数据在设备附近存储和处理，从而以最小的延迟实现实时反馈 。部署在网络边缘的AI代理可以直接与物联网设备和传感器交互，做出本地化决策 。
- 影响: 降低延迟，优化带宽，通过数据本地化提高安全性和隐私性，并在边缘实现预测性维护 。这对于自动驾驶汽车等需要快速响应的应用至关重要。
多模态数据管理的演进
- 现状:AI代理已经能够同时处理多模态数据（文本、语音、视频、音频、代码）。多模态AI系统整合了多样化的数据类型，以更有效地理解和生成信息。
- 挑战:依赖大量带标签的训练数据、整合不同数据类型的复杂性以及可伸缩性/实时处理需求。数据对齐和同步是主要障碍。
- 未来方向:数据库将需要发展以原生支持多模态数据类型，不仅通过存储嵌入，还要促进跨模态检索和理解。这包括将原始声音处理为结构化数据（声谱图、嵌入）、语音转文本转换以及将音频与图像/文本关联的功能。统一的多模态AI管道将成为标准配置。
深层观察与影响：
观察11：“自治数据平面”作为自治AI的赋能者。
AI代理被描述为“自主的、目标驱动的代理，能够做出上下文感知的决策，持续学习并独立行动” 。这种应用层面的自主性要求数据基础设施层也具备相应的自主性。“自驱动数据库” 和“AI驱动数据库” 通过自动化调整、打补丁、安全和查询优化等任务，直接响应了这一需求。它们减少了人工干预，确保底层数据基础设施能够跟上AI代理的动态和高要求特性。
这意味着未来AI代理的数据库管理不仅关乎存储什么数据，更关乎数据库本身如何运行。这一趋势将导致高度智能、自我管理的数据系统，能够动态优化AI工作负载，显著降低组织的运营成本和复杂性。
观察12：数据架构中“去中心化与统一”的悖论。
数据网格倡导去中心化的数据所有权和“数据即产品”，旨在防止数据孤岛并提高敏捷性。相反，数据结构强调通过智能自动化实现各种数据管道和云环境的端到端集成和统一 。虽然两者看似矛盾（去中心化与集中集成），但它们都旨在解决数据碎片化挑战，并确保为AI提供高质量数据。其核心主题是使数据对AI而言可发现、可访问且可用，无论其物理位置或所有权模型如何。
这意味着组织可能会采用混合方法，即通过统一的、智能的数据结构层来暴露和集成特定领域的数据产品（数据网格）。这既允许领域自主性，又确保了企业级的数据可见性和治理，这对于需要访问整个组织数据的复杂AI代理至关重要。
观察13：“边缘到云的连续体”实现实时AI。
AI代理需要低延迟的实时决策 。边缘计算数据库能够实现本地化处理，从而降低延迟和带宽限制 。然而，训练高级AI模型通常需要云环境的巨大计算能力和数据存储 。这表明未来AI代理的数据处理将沿着“边缘到云的连续体”运行。实时、任务关键型决策发生在边缘，而复杂的模型训练、再训练和大规模数据聚合则发生在云端。
这意味着数据库解决方案将需要支持边缘设备和中心化云基础设施之间的无缝数据流和同步。这将推动分布式数据库技术、数据复制和联邦学习方法的创新，从而优化即时本地响应能力和全球模型改进。
表3：新兴数据库趋势及其对AI代理的影响
数据库选择与战略实施建议
基于对AI代理数据需求的深入理解、当前数据库格局的评估以及未来趋势的预测，以下是为组织构建或增强AI代理的战略建议。
采纳多模态策略
单一模态数据库类型无法满足AI代理的所有复杂需求，因此采纳多模态策略是必然趋势。建议结合使用(或天然支持多模态的数据库)：
- 向量数据库：用于RAG和语义搜索，以实现对非结构化数据的上下文理解和高效检索 。
- 图数据库：用于复杂推理和知识图谱，以建模实体间关系并提供深层上下文 。
- 关系型数据库：用于结构化元数据和事务性数据，以确保数据完整性和一致性 。
- NoSQL数据库：用于灵活的非结构化数据和聊天历史，以提供可伸缩性和快速迭代能力 。
- 内存数据库：用于缓存和短期记忆，以满足极低延迟的实时交互需求 。
优先考虑数据质量与治理
高质量、无偏见的数据是AI代理可靠性的基础 。企业必须实施健壮的数据治理框架，包括持续数据质量管理、策略即代码的强制执行以及动态访问控制 。投资于数据清洗、验证和偏差检测工具至关重要 。这不仅仅是技术选择，更是确保AI代理输出可信赖的关键。
规划持续学习与动态知识
AI代理的适应性要求持续的数据摄取和模型更新/再训练机制。探索代理式RAG和AI查询引擎，使代理能够访问动态、最新的知识。考虑使用知识图谱为代理构建不断演进的上下文记忆，从而提升其推理能力和决策质量。
解决集成与操作化挑战
选择与AI框架（如LangChain、LlamaIndex）和现有企业系统具有强大集成能力的数据库。开发全面的MLOps/DataOps策略，用于大规模部署、监控和维护AI代理关注安全性、可解释性与问责制。利用AI原生和自治数据库功能来减少操作开销，从而将人力资源解放出来，专注于更高价值的任务。
关注安全性、可解释性与问责制
实施细粒度访问控制和数据脱敏措施。优先选择提供AI决策审计能力和数据溯源追踪的数据库解决方案。努力实现可解释的AI，可能利用知识图谱来追溯推理路径，从而增强信任和满足法规要求。
考虑边缘与混合云部署
对于低延迟、本地化应用，评估边缘计算数据库。设计能够无缝集成边缘和云数据流的架构，以实现全面的AI能力。这使得实时、任务关键型决策能够在边缘进行，而复杂的模型训练和大规模数据聚合则在云端完成 。
深层观察与影响：
观察14：数据中心AI的战略必然性。
AI代理面临的挑战（数据质量、可伸缩性、集成、安全）和数据库的未来趋势（AI原生、数据网格、边缘计算）共同强调了一个根本性的转变：AI的成功越来越以数据为中心。这不仅仅关乎AI模型本身，更在于支撑、管理和赋能这些模型的底层数据基础设施。上述建议中对健壮数据管理实践（质量、治理、实时性、动态知识）的强调，将其视为关键的成功因素，而非仅仅是技术选择。
这意味着组织必须将数据战略提升到AI计划的核心业务要务层面。这需要数据工程师、AI/ML工程师、安全团队和业务利益相关者之间的跨职能协作，超越孤立的工作方式。
观察15：混合与自适应架构成为新常态。
上述建议持续指向结合不同数据库类型（多模态）、集成各种架构模式（数据网格/数据结构），并同时利用云和边缘计算。这表明僵化、单一模态技术的方案已不再可行。未来要求高度灵活、自适应的架构，能够动态地整合新的数据类型、处理需求和部署环境。
这意味着数据架构师和工程师需要培养广泛的数据库技术和分布式系统设计专业知识。重点将从优化单个数据库转向优化整个数据生态系统以适应AI工作负载，并强调互操作性和无缝数据流。
结论
AI代理的快速发展正在重塑企业的数据基础设施需求。其对多模态数据、实时决策、复杂推理和持续学习的内在要求，使得单一模态的数据库解决方案无法满足所有需求。因此，采纳一种多模态战略，结合向量数据库、图数据库、关系型数据库、NoSQL数据库以及专业化内存和时间序列数据库的优势，成为构建高性能、高可靠性AI代理的关键。
然而，这条道路并非没有挑战。数据质量、算法偏差、可伸缩性、成本控制、与现有系统的集成以及安全与治理是当前面临的主要障碍。解决这些问题需要系统性的方法，将数据治理提升到核心战略层面，并投资于能够支持AI生命周期各个阶段的工具和流程。
展望未来，数据库产品将变得更加智能和自主。AI原生数据库将自动化管理任务，动态知识系统将通过代理式RAG和知识图谱实现更深层次的上下文理解和推理。数据网格和数据结构架构将解决数据碎片化问题，提供统一且高质量的数据视图。同时，无服务器和边缘计算数据库将支持分布式、低延迟的AI代理部署，满足从云端到边缘的广泛应用场景。
最终，AI代理的成功将取决于其底层数据基础设施的成熟度。通过战略性地选择和实施多样化的、智能化的数据库产品，并持续关注数据质量、治理和操作化挑战，企业将能够解锁AI代理的全部潜力，驱动创新，并在日益数字化的世界中获得显著的竞争优势。
一点点个人补充
个人认为AI Agent应该需要2种数据库(分别处理本地记忆和共享记忆, 类似云边一体):
1、边缘端需要一种轻便的库(类似lib库, 不需要部署单独的数据库服务), 仅依靠本地算力就可以对多模态数据进行处理, 同时具备联通其他数据源(其他远端数据库、对象存储中的数据等). 这种数据库就像我们身边的计算器, 日常的“数据访问、提取、理解、计算”不需要依靠外部服务, 短期记忆, 实时流式处理AI Agent感知层获得的大量数据。
典型代表, DuckDB这样的产品(lib、插件化、多模、湖仓、多模式混合查询、跨数据源混合查询及下推等特征), 和PG一样, DuckDB也具备插件扩展能力, 详见:
- 《祝贺DuckDB斩获30K star, Roadmap暴露野心, 估值可能过百亿》
- 《DuckDB进军AI数据库底座, 坐实了 | 文本语义(向量)搜索、全文检索、bm25搜索与排序、模糊搜索详解》
2、服务端(例如云端)则需要一种功能更加强大的数据库服务, 应该具备这些典型特征
- 多模态的支持; Databrick/Snowflake大手笔收购PG系商业公司Neon/Crunchydata可见一斑。
- 可扩展, 可快速支持新模态、存储扩展、算力扩展;
- 无孤岛, 连通访问外部各种资源;
- AI原生, 数据入库时即可智能转换、清洗、纠错、图式关系重组织等等;
典型产品代表:
1、典型的是PostgreSQL这种插件化产品(可快速支持多模)。 存储和算力扩展性方面可能需要更高级的版本例如citus, polardb, aurora, neon
2、DataFusion把数据库功能模块拆开发展, 也许会是另一支突起的异军(特别是在基于DataFusion的产品中可能会有值得关注的产品)。 https://datafusion.apache.org/user-guide/introduction.html
3、另外就是本文重点提到的晨章数据的产品。有点类似于DataFusion的架构, 并引入了数据基层的概念, 重点打造该层使得产品天然支持快速添加上层协议、多模态数据类型、底层存储高弹性扩展的能力, 最终弥补了DataFusion各模块较为割裂无法形成整体性产品的窘境。 https://github.com/eloqdata
传统单模态数据库产品则可能增加业务复杂度和成本, 不适应AI数据库赛道：
- 数据库仅仅能支持单一模态
- 导致的结果:
- 每个模态至少需要一种数据库, 设计复杂度增加。
- 写入时, 对同一份数据, 需要以不同模态存储在不同数据库中, 冗余存储PK关联到各个模态的相关数据. 增加了成本、错误几率。
- 查询数据时, 例如需要混合搜索时, 必须跨节点访问数据, 取交集, 然后再回到各个数据库中提取数据. 效率低下且非常复杂。
- 最终管理成本、使用成本、软硬件成本、开发成本随之明显提升. 做个数仓ETL的同学应该能感同身受, 使用ETL将不同数据源的异构或同构数据同步到数仓都会遇到各种问题, 何况是不同模态的数据库跨库的同步、访问等。
参考
https://milvus.io/ai-quick-reference/how-do-ai-agents-operate-in-realtime-systems
https://cloud.google.com/discover/what-are-ai-agents
https://www.datagrid.com/blog/ai-agent-types
https://oyelabs.com/common-challenges-in-ai-agent-development/
https://www.vktr.com/ai-technology/is-your-data-good-enough-to-power-ai-agents/
https://techcommunity.microsoft.com/blog/azure-ai-services-blog/up-to-40-better-relevance-for-complex-queries-with-new-agentic-retrieval-engine/4413832
https://www.pingcap.com/article/the-next-leap-in-data-management-unifying-ai-workloads-with-vector-databases/
https://aloa.co/blog/relational-vs-non-relational-database-pros-cons
https://nicholassamuel1107.medium.com/nosql-databases-challenges-use-cases-and-analytics-solutions-f1a2097bccdc
https://www.geeksforgeeks.org/blogs/databases-for-machine-learning-ai/
https://www.mongodb.com/resources/basics/databases/nosql-explained/nosql-databases-pros-and-cons
https://milvus.io/ai-quick-reference/how-are-embeddings-stored-in-vector-databases#:~:text=Embeddings%20are%20stored%20in%20vector,%2C%20images%2C%20etc.).
https://www.freecodecamp.org/news/how-ai-agents-remember-things-vector-stores-in-llm-memory/
https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/vector-db-choices#:~:text=Vector%20databases%20play%20a%20crucial,capture%20semantic%20meaning%20and%20relationships.
https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/vector-db-choices
https://lakefs.io/blog/what-is-vector-databases/
https://medium.com/@mirindiderrick/understanding-vector-databases-semantic-search-and-ai-b9e92551fd8d#:~:text=Therefore%2C%20vector%20databases%20serve%20as,exact%20matches%20or%20predefined%20tags.
https://myscale.com/blog/maximizing-ai-agent-performance-vector-databases-step-by-step-guide/
https://medium.com/@mirindiderrick/understanding-vector-databases-semantic-search-and-ai-b9e92551fd8d
https://dev.to/tak089/how-should-a-beginner-choose-a-database-for-an-ai-agent-3l9m
https://developer.nvidia.com/blog/traditional-rag-vs-agentic-rag-why-ai-agents-need-dynamic-knowledge-to-get-smarter/
https://zilliz.com/ai-faq/how-do-ai-agents-handle-realtime-decisionmaking
https://www.tigergraph.com/glossary/knowledge-graph-llm/
https://www.youtube.com/watch?v=Sln1n3Jba_U
https://hypermode.com/blog/how-knowledge-graphs-underpin-ai-agent-applications
https://www.deeplearning.ai/short-courses/knowledge-graphs-rag/
https://hypermode.com/blog/smarter-ai-agents-memory
https://bigbear.ai/blog/knowledge-graph-database-for-ai-ml/
https://medium.com/google-cloud/building-ai-agents-with-googles-gen-ai-toolbox-and-neo4j-knowledge-graphs-835c0cda3090
https://medium.com/@community_md101/building-self-evolving-knowledge-graphs-using-agentic-systems-48183533592c
https://arxiv.org/pdf/2501.14224?
https://www.tigergraph.com/blog/the-agentic-ai-graph-database-combo-powering-emerging-applications/
https://hypermode.com/blog/ai-agents-dgraph-google-gen-ai-toolbox
https://milvus.io/ai-quick-reference/what-is-the-role-of-knowledge-representation-in-ai-agents
https://www.graphapp.ai/engineering-glossary/cloud-computing/self-driving-databases
https://journalwjarr.com/sites/default/files/fulltext_pdf/WJARR-2025-0534.pdf
https://www.oracle.com/autonomous-database/
https://www.oracle.com/autonomous-database/select-ai/
https://www.mongodb.com/resources/basics/ai-databases
https://www.pingcap.com/article/understanding-ai-in-database-management-transforming-dbms/
https://medium.com/@casahome2000/leveraging-ai-for-advanced-sql-optimization-a-guide-to-smarter-query-practices-b0b44f873cd8
https://aiven.io/solutions/aiven-ai-database-optimizer
https://www.simform.com/blog/serverless-databases/
https://www.ibm.com/think/topics/data-fabric
https://datafortune.com/how-ai-and-machine-learning-are-shaping-the-future-of-data-fabric-architecture/
https://airbyte.com/data-engineering-resources/data-mesh-use-cases
https://www.allata.com/insights/fueling-generative-ai-the-role-of-a-data-mesh-and-data-products/
https://www.xenonstack.com/blog/agentic-ai-edge-computing
https://www.ibm.com/think/topics/edge-ai
https://www.akira.ai/blog/ai-agents-with-multimodal-models
https://www.splunk.com/en_us/blog/learn/multimodal-ai.html
https://zilliz.com/ai-faq/what-are-the-limitations-of-current-multimodal-ai-models
https://www.tensilityvc.com/insights/ai-interactivity-part-i-ai-agents-and-multimodal-agents
https://milvus.io/ai-quick-reference/what-are-some-challenges-in-training-multimodal-ai-models
https://encord.com/blog/multimodal-use-cases/
https://zilliz.com/learn/enhancing-multimodal-ai-bridging-audio-text-and-vector-search
https://www.edstellar.com/blog/ai-agent-reliability-challenges
https://www.acceldata.io/blog/ai-data-governance-ensuring-compliance-and-security
https://www.akira.ai/blog/real-time-data-analysis-with-ai-agents
https://www.datagrid.com/blog/ai-data-security-enterprise-trust-framework
https://avkalan.ai/how-to-fix-scalability-challenges-in-agentic-ai-systems/
https://www.debutinfotech.com/blog/scalable-ai-agent-architecture
https://getwren.ai/post/powering-semantic-sql-for-ai-agents-with-apache-datafusion
...
面向“AI+云时代”重新定义数据库
