1.1 背景：多智能体系统的崛起与数据基础设施的滞后
近年来，大语言模型（LLM）的飞速发展催生了一种全新的计算范式——自主智能体（Autonomous Agents）。与传统的软件程序不同，这些智能体具备推理、规划和工具使用的能力，能够处理复杂的、非确定性的任务。从自动化的代码生成到复杂的企业决策支持，智能体正在成为数字劳动力的核心。
然而，论文指出，尽管应用层的智能体技术日新月异，底层的数据管理基础设施（Data Management Infrastructure）却几乎停滞不前。现有的数据库系统（无论是关系型数据库、NoSQL还是新兴的向量数据库）大多是为“人类分析师”或“确定性应用程序”设计的。它们假设：
·查询是静态的：SQL语句在编译时结构已知。
·模式是稳定的：Schema变更不频繁。
·执行是确定的：优化器可以基于统计信息预先计算出最优路径。
1.2 核心冲突：智能体工作负载的独特性
智能体工作负载（Agentic Workloads）本质上是动态的、演进的且高度依赖上下文的。智能体在执行任务时，并不是一次性提交一个完美的查询，而是像人类专家一样，通过不断的“探测（Probing）”、“推理（Reasoning）”和“修正（Refining）”来逐步逼近答案。这种渐进式的查询生成模式与传统数据库“预先规划（Plan-first）”的执行模式之间存在着巨大的鸿沟。
例如，一个智能体在分析“为何包裹延误”时，可能首先需要查询数据库元数据来理解表结构，然后进行小范围采样以验证假设，最后才生成复杂的跨表联接查询。在这个过程中，智能体的意图（Intent）是流动的，而传统数据库僵化的优化器和缓存机制无法捕捉这种流动的意图，导致了严重的计算浪费和延迟。
1.3 论文的愿景：Agent-Centric Data Fabric
为了填补这一鸿沟，IBM Research的团队提出了一种革命性的架构思想——以智能体为中心的数据编织（Agent-Centric Data Fabric）。该架构的核心理念是将数据系统的角色从被动的“SQL执行器”转变为主动的“智能协作者”。它不再仅仅优化单一的查询，而是试图优化智能体的行为（Behavior）。通过引入注意力机制、语义缓存和概率性服务，该架构旨在实现数据检索与智能体推理过程的深度协同。
论文首先对现有数据系统的局限性进行了详尽的分析。在智能体工作负载的冲击下，传统架构的每一个层级——从查询解析到缓存，再到执行优化——都显露出“疲态”。
2.1 静态查询规划 vs. 动态意图涌现
传统的查询优化器（Query Optimizer）基于成本模型（Cost Model），假设在查询执行前，系统对涉及的表、谓词和连接条件有完全的可见性。然而，智能体的查询往往是涌现式（Emergent）的。
·不可预测性：智能体可能在推理链的中途突然决定需要结合情感分析结果，这会导致查询图（Query Graph）的拓扑结构在运行时发生突变。
·缺乏全局视图：传统优化器无法看到智能体的“下一步棋”，只能对当前的局部查询进行优化，这往往导致全局效率的低下。
2.2 语法级缓存vs.语义级复用
现有的缓存机制（如Redis, Memcached或数据库内部的Buffer Pool）主要依赖于句法匹配（Syntactic Matching）。如果两个查询字符串不完全一致，缓存就会失效。
·语义鸿沟：智能体生成的自然语言提示词（Prompt）或SQL 查询即使意图相同，表述也可能千差万别。例如，“Q1:查找延误订单”与“Q2:列出配送超时的货物”，在语义上高度重叠，但传统缓存无法识别这种相似性。
·跨智能体复用失效：在多智能体系统中，不同角色的智能体可能需要访问同一领域知识的“不同切面”。传统缓存无法支持这种基于语义的跨智能体知识共享。
2.3 引擎孤岛vs.跨模态数据流
当前的数据架构通常是引擎为中心（Engine-centric）的。结构化数据由关系型数据库处理，非结构化文本由搜索引擎处理，向量数据由向量数据库处理。
·割裂的协作：智能体需要在不同模态之间频繁切换（例如，将SQL查询结果转化为向量进行相似度搜索）。在现有架构下，这种跨模态的数据移动和对齐需要智能体手动协调，增加了复杂的应用层逻辑和网络开销。
·优化盲区：由于缺乏统一的控制层，没有任何单一引擎能够优化跨越SQL和向量检索的复合查询路径。
2.4 物理资源 vs. 混合推理成本
传统数据库的成本模型主要关注I/O、CPU和内存。然而，智能体工作负载引入了全新的成本维度：
·Token 成本：调用LLM处理数据的费用。
·推理延迟：模型生成的耗时。
·能耗：复杂的深度学习算子带来的能源消耗。
·失效的权衡：现有优化器无法回答这样的问题：“我是应该花0.5美元调用GPT-4处理这批原始文本，还是应该花100ms查询本地的预计算摘要？”这导致智能体经常过度查询或重复计算昂贵的Embedding。
为了设计适应未来的系统，必须首先深入理解“客户”——即智能体——的行为模式。论文通过一个全球物流供应链的案例，详细阐述了智能体工作负载的五大核心行为特征。
3.1 案例背景：全球物流供应链监控系统
该系统旨在预测、解释并缓解供应链中断。系统由六类专业智能体组成，它们协作处理结构化数据（PostgreSQL）、非结构化文本（NoSQL/Text）和实时流数据（Kafka）。
图1：供应链示例的工作流
该图展示了智能体间的工作流。异常检测智能体作为触发点，将信号传递给根因分析和情感分析智能体，最终汇聚于预测和路径优化智能体。这种动态的拓扑结构是智能体工作流的典型特征。
表1：示例数据源
该表列出了系统涉及的三种异构数据源：结构化的运输记录、非结构化的客户反馈JSON以及实时的天气/事件流。这种多模态环境是对单一数据引擎的巨大挑战。
3.2 五大核心行为特征
A. 动态任务分解(Dynamic Task Decomposition)
智能体不是按照预定义的脚本运行，而是根据实时反馈动态调整计划。
·现象：最初，异常检测智能体仅运行一个简单的SQL(SELECT AVG(delay)...)。当发现“东南亚”区域的高方差时，它并没有停止，而是动态生成了三个新子任务：(1)根因分析，(2)客户感知分析，(3)影响预测。
·挑战：查询边界变得模糊。数据库不仅要处理OLAP查询，还要应对这种突发的、由推理触发的查询扇出（Fan-out）。
B. 推测性查询(Speculative Querying)
在缺乏完整模式知识（Schema Knowledge）时，智能体会像人类一样进行“试探”。
·现象：智能体不知道具体的表名，因此先发出模糊的元数据查询（如%delivery%）。找到表后，它会查询前几行(LIMIT 5)来推断列的语义（例如，通过观察数据推断act_delivery是时间戳）。基于这些推断，它才构建正式的分析查询。
·挑战：这产生大量微小的、低选择性的“元数据探测查询”。在传统数据库（如PostgreSQL）中，大量并发的元数据查询会导致系统目录（Catalog）成为锁竞争的瓶颈。
C. 上下文驱动的数据访问(Context-Driven Data Access)
智能体的每一次查询都是基于之前的推理上下文（Context）。
·现象：根因分析智能体可能会复用情感分析智能体生成的Embedding，通过向量相似度将“客户抱怨”与“运输延误”联系起来。
·挑战：数据系统必须具备“上下文感知”能力，能够基于Embedding向量（而非仅仅是Key）来检索相关数据。
D. 智能体间协作(Collaboration Among Agents)
中间结果的交换构成了新的数据流。
·现象：异常检测智能体发布一个结构化消息{region:"Singapore",anomaly_score:0.92}，其他智能体订阅并消费此消息。
·挑战：系统需要理解不同智能体输出的语义等价性，并在异构模态间进行自动的数据对齐。
E. 自我评估与反馈闭环(Self-Evaluation)
智能体会监控自身性能并调整策略。
·现象：编排器（Orchestrator）可能会发现调用GPT-4进行情感分析成本过高，从而在低风险场景下协调优化器（Optimizer）自动切换到更廉价的DistilBERT模型。
·挑战：系统必须暴露详细的运行时遥测数据（Telemetry），如Token消耗、模型置信度等，以支持这种自适应决策。
针对上述行为特征，论文提出了Agent-Centric Data Fabric。这不仅是一个新的数据库，而是一个位于智能体与底层数据引擎之间的智能中间件层。
图2：以智能体为中心的数据系统架构
图 2 展示了系统的分层架构。从上至下依次为：Agent Layer（负责意图生成与微缓存）、Orchestration Layer（负责路由、预取与协调）、Execution Layer（负责多模态执行与监控）。核心组件如“注意力引导路由器”和“跨智能体缓存管理器”贯穿其中。
4.1 智能体层(Agent Layer):意图感知
该层直接与智能体交互，负责捕捉意图并进行初步的本地优化。
·注意力引导的数据检索(Attention-guided Data Retrieval):
o原理：借用Transformer的注意力机制，系统维护一个“注意力向量”，表示智能体当前的关注点（Focus）。该向量由任务上下文、历史交互和数据源摘要共同计算得出。
o作用：它将“查询”转化为“关注度分布”。系统不再盲目扫描所有数据，而是根据注意力权重（Weights）优先探测最相关的数据分区。
·微缓存(Micro-caches):
o原理：每个智能体或上下文语义联邦（Federation）维护一个本地的、语义感知的缓存。它存储的不仅是数据行，还包括Embedding、推理片段和中间计划。
o策略：缓存的淘汰策略由“注意力频率”驱动——如果智能体的注意力转移了，相关的缓存条目就会被降级或移除。
4.2 编排层(Orchestration Layer)
这是架构的核心，负责将模糊的意图转化为高效的执行动作。
·注意力引导路由器(Attention-guided Router):
o推测性探测：基于上层的注意力权重，路由器会先发起轻量级的“探测请求”（Speculative Probing），以低成本评估数据源的相关性。只有在确认高相关性后，才会投入资源进行全量检索。
o软路由：不同于传统的硬编码路由，这里采用概率性的软路由策略，平衡“探索（Exploration）”与“利用（Exploitation）”。
·预测性预取器(Predictive Prefetcher):
o机制：利用序列模型（如LSTM）学习智能体的行为模式。例如，如果系统观察到“查询元数据”通常紧接着“查询前 5 行”，预取器就会在元数据查询发出时，提前加载数据行到缓存中。
·跨智能体缓存管理器(Cross-agent Cache Manager):
o功能：它持续监控所有活跃智能体的任务 Embedding。一旦发现两个智能体（即使它们属于不同的任务流）关注相似的语义区域（如都在分析“新加坡”），管理器会强制合并缓存，甚至抑制冗余的探测请求，从而显著降低后端负载。
·基于共识的数据服务(Quorum-based Serving):
o创新点：针对非确定性任务，引入“足够好”的概念。系统不需要等待所有后端引擎返回结果，只要收集到的证据在“覆盖率”、“多样性”和“一致性”上达到了预设的置信度阈值（Confidence Threshold），即可提前返回结果。这对于降低长尾延迟至关重要。
4.3 执行层(Execution Layer):异构引擎的统一
·引擎编织 (Engine Fabric):
o 这是一个抽象层，统一了SQL数据库、向量存储、流处理引擎和推理服务器。它通过适配器模式将编排层的逻辑计划转化为特定引擎的物理计划。
·监控与反馈(Monitoring):
o 负责收集细粒度的运行时指标（延迟、成本、准确率），并将这些信号反馈给编排层的优化器，形成闭环的学习系统。
论文详细阐述了支撑该架构的三大核心机制，这些机制代表了数据库技术与AI技术融合的前沿方向。
5.1 语义联邦微缓存(Semantic Micro-Caching)
传统的缓存是“针对数据的（Data-centric）”，而语义联邦微缓存是“针对行为的（Behavior-centric）”。
·语义联邦(Semantic Federation)：系统将处理相似任务的智能体划分为一个联邦。在联邦内部，缓存是基于语义 Embedding 共享的。
·知识复用：当智能体A分析了关于“延迟”的文本并生成了Embedding，该结果被存入共享微缓存。当智能体B需要分析“配送中断”时，尽管查询词不同，但语义相似度匹配会直接命中缓存。这种机制极大地减少了昂贵的LLM推理调用次数。
5.2 注意力引导的数据检索(Attention-guided Retrieval)
这是将Transformer的核心思想下沉到数据系统的尝试。
· 数学直觉：
系统计算查询向量
与数据分区摘要
之间的相似度，并通过Softmax函数转化为注意力权重
：
其中
是温度参数，控制探索的激进程度。
·成本感知的探测：不同于传统的全表扫描，路由器根据生成概率性的探测计划。这允许系统在海量数据中快速定位“高价值区域”，极大提升了检索效率。
5.3 基于置信度阈值的数据服务(Quorum-based Serving)
这是对分布式系统CAP理论在AI时代的重新诠释。
·部分结果的价值：在推理任务中，100%的完整数据往往是不必要的，甚至是不可得的（考虑到多模态数据的异构性）。
· 置信度公式：
oCoverage:已响应的数据分区比例。
oDiversity:证据来源的多样性（如，是否同时包含了结构化数据和非结构化文本）。
oAgreement:不同来源证据的一致性。
一旦
超过阈值
，编排层就会截断剩余的查询，立即向智能体返回结果。这种机制显著提高了系统的响应速度和鲁棒性。
虽然该论文主要是一篇愿景论文（Vision Paper），但它引用了相关的初步实验和现有文献来支撑其设计选择的有效性。
6.1 潜在的性能收益
·减少冗余计算：通过语义联邦微缓存，预计可减少30%-50%的重复LLM推理调用，这直接转化为Token成本的降低。
·降低延迟：基于共识的数据服务机制可以有效削减长尾延迟（Tail Latency），特别是在涉及慢速外部API或复杂向量搜索的场景中。
·提升吞吐量：跨智能体缓存管理器通过抑制冗余探测，可以显著减轻后端数据库的并发压力，从而提升系统的整体吞吐量。
6.2 用户研究佐证
论文引用了类似系统（TiInsight等）的用户研究结果，表明引入语义层（如HDC或本文的Attention Mechanism）后，智能体生成SQL的准确率和任务完成率均有显著提升，证明了“语义抽象”在人机/机机交互中的关键作用。
论文在最后部分列出了实现这一愿景所面临的挑战，为学术界和工业界指明了未来的研究方向。
7.1 跨引擎与跨模态的统一成本建模(Unified Cost Modeling)
目前尚无统一的单位来衡量SQL连接操作的CPU周期与LLM推理的Token成本。
·挑战：如何建立一个多目标的成本空间，将金钱成本（Dollar Cost）、延迟（Latency）、准确率（Accuracy）和能耗（Energy）纳入同一个优化方程？
·方向：研究基于机器学习的成本估算器，能够动态学习不同算子在不同上下文下的“混合成本”。
7.2 成本感知的注意力映射(Cost-Aware Attention)
目前的注意力机制主要关注“语义相关性”。
·挑战：高相关性的数据可能存储在极高成本的存储中（如冷数据或昂贵的API）。
·方向：开发“ROI感知”的注意力模型，即在计算权重时，同时考量信息增益（Information Gain）与获取代价。这可能需要结合强化学习（RL）或Multi-armed Bandit算法。
7.3 语义缓存的一致性(Consistency in Semantic Caching)
·挑战：语义缓存的模糊性使得缓存失效（Cache Invalidation）变得异常困难。如果底层的结构化数据更新了（如订单状态变了），如何精确找到并更新与之相关的语义Embedding？
·方向：探索基于数据世系（Data Lineage）和版本控制的语义缓存一致性协议。
7.4 协议与接口标准化(Protocols)
·挑战：目前的数据库协议（如JDBC/ODBC）不支持传输“注意力权重”、“置信度分数”或“中间推理状态”。
·方向：定义新的“智能体-数据”交互协议，支持富语义元数据的双向传输。
《Supporting Dynamic Agentic Workloads》一文不仅指出现有数据系统的缺陷，更点明了未来数据基础设施的演进方向。它主张打破数据库作为“静态数据仓库”的传统定位，将其重构为能够理解语义、预测意图并主动协作的智能实体。
通过引入语义联邦微缓存、注意力引导检索和共识驱动的服务，IBM Research描绘了一个人机共生（Human-AI Symbiosis）的新蓝图。在这个未来中，数据系统将不再是被动的搬运工，而是智能体推理回路中不可或缺的、具有适应性的合作伙伴。对于企业而言，这意味着数据架构的现代化不再仅仅是迁移到云端，而是要为“智能体员工”准备好能够与其高效对话的数据环境。
这项工作为数据库社区提出了一个新的核心问题：当我们不再为人类编写 SQL，而是为AI提供数据时，数据库应该长什么样？本文给出的答案是：它应该像AI一样思考——动态、概率性、且高度互联。
论文解读联系人：
刘思源
13691032906（微信同号）
liusiyuan@caict.ac.cn
