大语言模型正在改变人与数据系统交互的方式。过去，用户需要理解数据库模式、查询语言和分析工具，再把自己的意图转换成SQL、Python或一组固定的数据流水线。在传统系统中，这一过程通常围绕CRUD展开：用户通过INSERT/UPDATE/DELETE完成数据写入与修改，通过SELECT查询数据，通过事务机制保证一致性，通过应用层逻辑或ETL pipeline将这些操作串联成业务流程。也就是说，用户不仅要表达“想要什么结果”，还需要明确“如何一步步操作数据”。Agent则能够代表用户探索数据、生成代码、调用工具、验证结果，并根据中间反馈不断修改方案。

这种变化带来的问题，并不止于之前热门的研究问题：Text-to-SQL。其本质上仍然是在利用传统数据系统暴露出来的CRUD接口，只是把“写SQL”这一步交给了模型自动完成。当Agent可以低成本地产生大量查询、并行探索多个方案、执行假设性更新并保存长期记忆时，数据系统面对的workload结构本身也发生了变化。

Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First(CIDR'26)将这一过程称为agentic speculation，即“智能体推演”：Agent围绕一个任务持续提出假设、访问数据、构造局部方案、验证结果、从多个候选方向中选择下一步行动，数据系统需要从面向单条查询的query-first架构，演进为能够原生支持这种探索过程的agent-first架构。

0x0 Agentic Speculation对workload基本结构的改变

Agentic Speculation的第一个特征是高吞吐请求。

传统数据库同样追求高吞吐，但传统吞吐通常来自大量相对独立的请求，例如一个网页后端可能通过JDBC并发地往数据库发送大量请求。系统主要优化单条查询的延迟、并发事务数和整体资源利用率在Agent workload中，大量请求可能来自同一个任务。 为了执行用户的一个任务，Agent可能先读取catalog，再查看表结构和列分布；随后抽样数据、尝试多个join key、生成几种过滤条件、执行近似聚合；如果结果不合理，它还会回到前面的步骤，更换数据源或修改分析路径。 因此，high throughput更准确地描述了一个高fan-out的任务结构：

这些请求之间通常具有明确联系：它们访问相似的数据，执行重叠的操作，并共享相同的最终目标。若后端仍将它们视为彼此独立的SQL或API请求，系统虽然可能实现很高的QPS，却会把大量计算资源消耗在最终被放弃的探索分支上

论文使用BIRD text-to-SQL benchmark做了一个初步实验。增加串行或并行尝试次数后，任务成功率提高了约 14% 到 70%；但在每个问题生成的 50 次尝试中，真正不同的子计划通常只占总数的 10% 到 20% 以下。这说明多次探索确实能够提高成功率，同时也产生了显著的计算冗余。

这种workload具有四个核心特征。

1. 规模性意味着一个任务会诱发大量后端请求。
2. 异构性意味着这些请求可能同时包含SQL、Python、向量检索、元数据访问、模型推理和外部工具调用。
3. 冗余性意味着不同探索分支经常重复扫描数据或执行相近计算。
4. 可引导性则意味着探索过程尚未固定，系统提供的成本、质量和数据特征反馈，可以直接改变Agent的下一步选择。

单独看，每一种特征都不是数据库领域的新问题。多查询优化研究共享计算，近似查询处理允许精度与成本交换，自适应查询处理根据运行时反馈调整计划，事务分支和time travel支持多个数据版本。Agentic workload的特殊之处在于，这些机制需要跨越多个动态生成的请求，并围绕完整任务进行联合决策。

优化单位开始从query转向trajectory，也就是Agent为完成一个任务，从开始到结束所经历的完整执行过程，包括每一步思考、查询、工具调用、中间结果、分支、回退和重新规划。

0x1研究方向

0x11 从Query接口转向Probe接口

传统查询接口要求调用者先准确描述自己需要什么。比如，一个BI用户可能通过一条精确的SQL查询，统计过去三个月各地区的销售额及同比变化。但是，当这个用户现在用Codex时，他更可能直接发出一个任务：“分析过去三个月各地区销售额下降的原因，找出最值得关注的异常，并给出可复现的证据。”Agent在探索早期通常无法提供完整的查询描述。它只知道任务目标，但尚不确定应该读取哪些表、采用哪些连接关系、分析哪些时间范围，以及需要用什么指标验证结论。这些信息需要在探索数据的过程中逐步确定。

Agent-first论文因此引入了probe。Probe仍然可以包含SQL或其他数据操作，但它还会携带任务阶段、Agent身份、精度要求、目标和优先级等上下文。论文将这些自然语言上下文称为brief。

例如，同一条统计请求可以对应三种不同的系统语义：

1. 探索阶段： 只需要判断某个方向是否值得继续，允许近似结果。
2. 验证阶段： 需要确认候选结论，要求更高精度和可追溯性。
3. 输出阶段： 需要稳定结果、完整权限检查和可复现的执行记录。

传统数据库只能看到查询文本，很难判断某个聚合究竟是最终答案，还是用于排除一个假设的临时探针。Brief让系统能够依据任务阶段选择执行策略：使用采样、返回已有中间结果、推迟精确计算，或者直接告诉Agent当前方向缺乏数据支持。

这篇论文的作者团队，在另一个工作 LLM-Powered Proactive Data Systems里面已经提出，数据系统应从被动执行查询，转向主动解释、重写和分解用户请求，并在查询结果之外与用户交互。Agent-first架构进一步把这一思想扩展到连续、多分支、可能由多个Agent共同完成的任务轨迹。

工业界目前最接近Probe接口的实现，是“自然语言意图 + 语义模型 + 工具调用”的组合。

Databricks AI/BI Genie允许团队为数据空间配置可信数据、示例SQL、Unity Catalog函数、业务规则和知识说明，并利用Unity Catalog中的指标、数据血缘和语义元数据约束Agent。Snowflake Cortex Agents则组合Cortex Analyst、Semantic Views和Cortex Search，使Agent可以在结构化数据和非结构化数据之间规划调用。

Google BigQuery Data Agents可以绑定表、视图、图和UDF等知识源，并结合表元数据与面向特定use case的查询处理指令回答自然语言问题。Microsoft Fabric Data Agent也采用类似方式，将Lakehouse、Warehouse、Power BI Semantic Model、KQL Database、Ontology和Microsoft Graph等数据源暴露为可对话的数据能力。

这些产品已经开始携带查询文本之外的上下文，但当前上下文主要用于grounding和工具选择。论文设想中的Probe还要求执行引擎理解任务阶段、精度预算和未来决策价值，这一层尚未形成稳定的工业接口。

0x12 优化器需要决定“执行什么”以及“执行到什么程度”

传统查询优化器通常假设查询的语义已经确定，它需要做的是在一组语义等价的执行计划中找到成本最低的一个。但在Agent任务中，一条请求往往不是独立的最终查询，而是探索过程中的一个Probe。它的价值不仅取决于自身返回了什么，还取决于这个结果会让Agent继续、放弃还是改变当前分析方向。因此，优化器面对的不再只是“如何执行这条查询”，还需要判断哪些Probe值得执行，以及每个Probe执行到什么程度才足够。

这两个问题实际上相互关联。如果某个Probe只是为了初步判断一个特征是否与目标相关，那么完整扫描数据并计算精确结果可能没有必要。一个小样本、粗略直方图或历史缓存结果，也许已经足以排除这个方向。相反，如果Probe用于验证即将写入最终报告的关键结论，系统就需要提供更高精度、可追溯且可复现的结果。同一种数据操作处于不同任务阶段时，合理的执行方式可能完全不同。

基于这一观察，Agent-first论文提出了satisficing probe optimizer。这里的satisficing不是简单地牺牲准确率，而是让计算投入与当前决策所需的信息相匹配：优化器不必把每个Probe都执行到最高精度，只需以尽可能低的成本，提供足以支持Agent下一步判断的结果。为此，它需要同时估计Probe与任务目标的语义相关性、结果可能带来的信息增益、可复用的共享计算、近似执行产生的误差，以及该结果可能诱发的后续请求。

于是，优化目标也从单条查询的最低latency转向整个任务的完成成本。一个执行极快但信息量不足的结果，可能让Agent继续生成十几个无效请求；另一个成本稍高但能够明显缩小搜索空间的结果，反而会减少后续探索，使任务更早收敛。判断一个执行计划是否“便宜”，不能只看本次Probe消耗了多少资源，还要看它如何改变剩余的任务轨迹。

近年来出现的一些系统已经开始从不同层面接近这一目标。DocETL: Agentic Query Rewriting and Evaluation for Complex Document Processing(VLDB'25)将复杂文档处理表示为声明式pipeline，由Agent生成重写策略并评估候选计划，再使用类似Cascades的方法搜索优化方案。在论文的四类任务中，优化后的pipeline相比基线取得了约21%到80%的准确率提升。这说明，当Agent的搜索空间受到结构化算子和评估器约束时，传统数据库的计划搜索思想仍然能够发挥作用。

Deep Research is the New Analytics System: Towards Building the Runtime for AI-Driven Analytics(CIDR'26)进一步把深度研究工作流抽象为计算算子、搜索算子和可物化的Context。系统在Palimpzest基础上加入ContextManager，为已经生成的上下文建立索引，从而把动态的Agent规划与上下文复用、物化等传统优化手段连接起来。其原型相较deep-research baseline将F1提升至1.95倍，同时将成本和运行时间分别减少约76.8%和72.7%。

类似的变化也发生在模型服务层。Efficient LLM Serving for Agentic Workflows: A Data Systems Perspective(SIGMOD'26)提出的Helium将Agent workflow视为查询计划，将每次LLM invocation视为其中的算子，再通过主动缓存和cache-aware scheduling优化执行，报告了最高约1.56倍的加速。虽然它主要处理模型推理侧的重复计算，但背后的逻辑与Probe优化一致：系统需要看到完整workflow中各次调用之间的关系，才能判断哪些结果值得计算、复用或推迟。

这些工作共同指向一个新的优化层次。数据库优化器未必需要接管Agent的完整规划过程，但它至少需要看到多个请求之间的关联，以及它们服务的共同任务目标。只有这样，多查询优化、增量执行和共享物化才有可能从局部技巧上升为面向整个Agent任务的执行策略。

0x13 Grounding应成为双向反馈机制

当前Agent数据产品普遍强调grounding：通过schema、semantic layer、catalog、lineage和示例查询，使模型生成更可信的数据操作。

Agent-first论文对grounding的要求更进一步。Agent不仅需要知道字段名称和业务定义，还需要理解数据分布、缺失值、编码方式、时间粒度、数据新鲜度、索引状态、查询代价和当前系统负载。

论文中的第二个案例让OpenAI o3在PostgreSQL、SQLite、MongoDB、DuckDB和Python之间完成数据分析任务。研究者向Agent提供人类专家总结的系统提示后，Agent发出的SQL数量从平均 12.67 条下降到 10.38 条，总体减少约 18.1%；用于探索列的查询减少约 27.7%，不完整查询尝试减少约 36.6%。这说明少量系统侧知识就能显著改变Agent的探索轨迹。

论文据此提出sleeper agents：部署在数据系统内部、持续观察数据和执行状态的轻量Agent。它们可以发现schema变化、数据异常、热点、陈旧缓存或昂贵访问模式，并在需要时将这些信息提供给主Agent。

现有工业系统已经完成了其中一部分。Databricks Unity Catalog的数据血缘能够追踪到列级，Metric Views则集中管理业务指标及面向Agent的语义元数据；Snowflake Semantic Views可以定义维度、事实、指标和表间关系；BigQuery Data Agents与Fabric Data Agent允许开发者配置数据源说明、示例查询和专用指令。两家公司也把可观测性纳入Agent平台：Snowflake Cortex Agent Monitoring记录规划、工具选择、执行结果和最终回答，Databricks MLflow Tracing则展示调用链及每个span的输入、输出和耗时；相应的evaluation与评估和监控能力可进一步检查Agent的行为与答案质量。

从公开能力看，这些系统当前更擅长将人工维护的语义知识注入Agent。数据库根据实时执行成本、数据质量和共享计算机会主动影响Agent计划的能力仍然有限。

MCP进一步统一了Agent调用数据工具的接口。其数据层定义了Resources、Prompts和Tools等核心原语，使数据库、搜索系统和业务API可以通过一致的发现与调用方式暴露给模型，具体实现则可以只支持其中一部分。Snowflake-managed MCP server能够将Cortex Analyst、Cortex Search、Cortex Agents、SQL和自定义函数封装为Tools；发布后的Fabric Data Agent MCP server则把一个Data Agent作为单独的Tool，通过远程MCP端点提供服务。

Fabric Data Agent发布后的MCP Server设置页，其中包含Server URL、Tool名称和Tool描述。来源：Microsoft官方文档。

从协议范围看，MCP关注的是上下文交换、能力发现和调用互操作，并不规定AI应用应当如何使用这些上下文。它没有定义多个工具调用如何联合优化，也没有定义数据系统如何向Agent反馈执行代价、近似误差和信息增益。因此，MCP可以成为Agent-first系统的连接层，但仅仅接入MCP并不会自动形成Agent-first优化器。

0x14 Agent Memory需要成为可管理的语义缓存

Agent在长期任务中需要记住此前访问过的数据、尝试过的假设、失败原因和中间结果。最直接的实现是把历史对话和文档切片写入向量数据库，再通过相似度检索放回上下文。

这种实现只覆盖了memory retrieval的一部分。一个数据系统意义上的Agent memory还需要解决：

• 哪些信息值得长期保留；
• 中间结果依赖哪个数据版本；
• 当源数据变化时，哪些记忆已经失效；
• 不同用户、Agent和任务之间能否共享记忆；
• 失败路径何时有价值，何时应被淘汰；
• 如何在检索质量、写入成本和读取延迟之间取舍。

Agent-first论文将memory store描述为一个持久、可查询的语义缓存。它既可以保存历史Probe和部分解决方案，也可以保存有关底层数据的统计与解释，例如字段编码、缺失值模式、时间粒度和空间粒度。论文同时指出，新鲜度、权限和生命周期管理仍然是开放问题。 Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads(arXiv'26)对十类Agent memory系统进行分析，将memory lifecycle拆为构建、检索和生成阶段，并指出不同架构会在写路径、读路径、延迟、新鲜度和资源调度之间转移成本。Are We Ready For An Agent-Native Memory System?(arXiv'26)则将memory拆为表示与存储、信息抽取、检索与路由、维护四个环节。其评估显示没有一种架构在所有workload上占优，局部维护通常比全局重组更具成本效率。

这些结果与传统数据库中的物化视图维护、缓存失效、增量计算和数据版本管理高度相关。Agent memory的工程难点很可能不在embedding index本身，而在于如何建立从记忆到数据版本、工具执行和任务决策的provenance。

例如一个可靠的memory entry应该记录以下信息：

这条memory的核心是把结论与产生它的数据状态绑定在一起。数据依赖和查询计划让系统能够追溯、验证或重新计算这条观察；有效范围和置信度帮助Agent判断它能否用于当前任务；失效条件则规定何时需要将其标记为陈旧并重新评估。例如，orders或refunds出现新snapshot后，系统不应继续把旧结论当作当前事实，而应触发增量更新或重新执行相关Probe。这样，memory才从一段可以被相似度检索出来的文本，变成一个能够随底层数据演化而维护的语义对象。

0x15 分支事务、可验证执行

数据分析Agent主要读取数据，操作型Agent还会执行更新。

论文给出的航班调度示例中，Agent需要为延误航班构造多个候选机组方案。每个方案可能涉及数十次数据库更新。为了比较这些方案，Agent需要复制数据库状态、执行推测性修改、验证约束，再回滚不合适的分支。

传统事务可以保证单个方案的原子性，却不适合频繁维护大量并行假设世界。论文将所需能力称为multi-world isolation，并形容为“MVCC on steroids”：系统需要低成本的copy-on-write分支、快速回滚、跨分支比较，以及最终选择性合并。论文还引用Neon的观察：Agent创建分支的频率约为人类用户的20倍，回滚频率约为50倍。

Neon Database Branching已经将数据库branch实现为copy-on-write clone。创建子分支时，系统不会完整复制父分支的数据，而是让两者引用相同的数据页；只有当子分支发生修改时，才为变化的内容写入新页面。子分支与父分支彼此隔离，还可以通过branch reset放弃修改并重新对齐父分支，因此适合作为Agent测试方案或执行推测性更新的临时环境。

Lakehouse领域也开始出现类似工作。GitLake: Git-for-data for the agentic lakehouse(DASHSys@VLDB'26)将Iceberg snapshot提升为lakehouse范围的commit、branch和merge，使Agent可以在隔离分支中执行数据修改，再由人类审核和发布。

0x2 研究空白

围绕Agent-first data systems，现有研究已经覆盖数据Agent评测、工作流优化、长期记忆和数据库分支等局部问题，但完整的系统架构仍处于早期阶段。当前比较明确的研究空白主要体现在以下几个方面。

0x21 缺少面向数据系统的Agent Workload Benchmark

这里需要区分两个问题：Agent能否完成数据任务，以及数据系统能否高效承载Agent产生的workload。前者已经有直接相关的工作。Data Agent Benchmark(DAB)覆盖六个行业中的跨数据库集成、转换和分析任务；AgenticDataBench则包含15个领域的真实数据科学任务，并提供细粒度skill标注。BranchBench和Agent Memory的系统化评测也开始分别关注数据库分支与长期记忆。

但这些benchmark的评价对象仍是Agent能力或某个局部机制。目前还缺少被广泛接受的端到端Agent workload benchmark，将完整的Agent任务视为后端workload，同时记录任务目标、数据和工具约束、schema与数据版本、Probe序列、并行分支、回退重试、任务预算和停止条件。评价指标也需要从QPS和单条SQL latency扩展到任务成功率、完成时间、总成本、重复计算比例、共享收益、memory新鲜度以及branch、rollback和merge开销。

0x22 缺少Trajectory-Level Optimizer

当前研究已经分别优化SQL、语义算子pipeline、LLM serving和多Agent workflow，但还没有统一的数据结构与成本模型，能够同时表示数据算子、模型调用、搜索、代码执行和外部工具。这样的优化器不仅要估计当前Probe的执行成本，还要估计它能够减少多少后续探索；目标也不能只是最小化单条查询延迟，而需要联合考虑任务完成时间、总成本、结果质量和信息增益。

0x23 缺少语义级的跨Probe共享执行

传统multi-query optimization通常面对一组已经给定的查询，通过匹配相同或相似的物理算子共享Scan、Join和Aggregate。Agent产生的Probe则是动态的：两个请求可能使用不同的自然语言、SQL结构甚至执行引擎，但访问相同数据并探索同一个概念。系统需要识别这种语义重叠，并判断能否安全复用数据扫描、模型推理、中间结果或近似答案。现有的语法级公共子表达式匹配还不足以解决这一问题。

0x24 缺少双向Steering机制

现有工业产品主要通过schema、semantic layer、verified queries和业务指令向Agent提供静态grounding。Agent-first系统还需要根据实时状态返回查询代价、数据新鲜度、结果置信度、缓存状态和why-not provenance，并在当前Probe过于昂贵、已有结果可以替代或继续探索的预期收益过低时主动建议Agent改变计划。这里不仅缺少稳定的表达协议，也缺少关于何时介入、Agent是否应遵循反馈，以及错误steering如何恢复的控制机制。

0x25 缺少Version-Aware Agent Memory

现有Agent Memory大多围绕历史文本的写入、压缩和相似度检索展开，但数据任务中的记忆往往依赖特定snapshot、schema、查询计划、模型版本和业务口径。任何依赖发生变化，都可能使历史结论失效。因此，Agent Memory更接近带语义和provenance的物化结果，其开放问题包括依赖追踪、增量失效、权限继承、跨Agent共享和生命周期管理。

0x26 缺少面向Speculative Writes的事务与治理机制

BranchBench、Neon和GitLake已经展示了Agent workload对数据库分支的需求，但低成本创建分支只是第一步。真实系统还需要在多个候选世界中验证业务约束、发现写冲突、比较方案质量，并把选中的修改安全合并回主分支；跨数据库、模型和外部工具传播的中间状态也必须遵守权限与数据流策略。传统事务解决一次确定执行的原子性与隔离性，Agent-first系统则需要进一步支持大量不确定候选方案的生成、验证、审核和淘汰。