本文仅梳理公开技术实现与产品状态，不作采购或产品路线评价。
导读
2026 年初，Agent 与企业数据平台的结合还是一个架构问题：Agent 会不会成为数据平台的新用户，平台需要怎样接住它。到 9 月，问题已经落到具体的工程取舍上。
现在更适合把 Data Agent 看成一条任务链，而不是一个自然语言入口。语义定义决定答案是否可信，引擎 MCP 化决定能力是否可调用，受控编排决定任务能否推进，执行轨迹与评测决定结果能否进入生产。
数据集成、存储格式和查询引擎没有因为 Agent 出现而重写架构原理。真正发生变化的是负载和责任边界：一次用户请求会被拆成多次 schema 探查、查询、校验与重试；一个本来只给人看的目录，需要对 Agent 暴露可授权、可发现、可解释的工具；一次指标查询不再只需要返回结果，还需要说明口径、权限和执行路径。
当前跨过门槛的是受治理的只读分析、诊断和带人工闸门的数据开发。跨域自治、治理上游与无人值守写回仍处于早期。这条任务链可以拆成四个工程合同：语义与上下文合同规定指标、关系、来源和适用范围；工具与权限合同规定 Agent 能发现什么、调用什么、以谁的身份调用；计划与执行合同规定状态、重试、补偿和人工接管；结果与证据合同规定 SQL、数据快照、模型版本、评测结果和 receipt 如何留存。四个合同缺一，任务执行结束，并不代表结果正确，也不代表结果可证明。
01 已经跨过可用门槛的能力
1.1 语义层把静默错误变成了可捕获失败
Snowflake 在 2026 年 6 月 30 日的官方博客披露了一组内部测试。在需要跨表 Join、指标公式查找和过滤规则的问题集上，前沿编码 Agent 不接入上下文时准确率为 24.1%，接入 Cortex Sense 后为 86.3%，单查询成本从 $1.76 降到$0.59。测试题目集、样本量和完整配置未公开，这组数字只能说明上下文层可能带来的作用，不能用于产品横评。
同一篇博客还披露了一个冷启动事实：Snowflake 自己的产品数据团队给表加语义视图，覆盖了 9,685 张表中的不到 5%。这个数字不能外推为行业平均值，但它说明手工维护语义定义存在覆盖率上限。
dbt Labs 的 2026 年基准更适合解释语义层到底改变了什么。ACME Insurance 数据集有 11 个问题，每个问题重复运行 20 次。Claude Sonnet 的裸 Text-to-SQL 准确率为 90.0%，通过语义层为 98.2%；GPT-5.3 Codex 的两组数字为 84.1% 和 100.0%。
比准确率差值更重要的是测试者对失败形态的描述：
With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message.
语义层并没有让系统回答所有问题。超出建模范围的问题仍然无法回答。改变的是失败是否能被看见：明确报错可以进入人工路由、语义建模和回归评测；错误数字会以数据结论的形式进入报告、看板和决策流程。
语义层的第一价值在于把错误变得可捕获，模型能力提升只是次要结果。
1.2 权限继承与 Agent 身份已经有稳定工程路径
2026 年主流数据平台没有为 Agent 重新造一套孤立权限体系，常见做法是继承现有治理：Databricks 通过 source-native ACL 或 Unity Catalog 逐答案鉴权；Snowflake 通过 RBAC、行访问策略和脱敏规则控制访问；AWS 延续 IAM 与 Lake Formation；Microsoft 使用 OneLake Security 的 RLS/CLS 与 Purview。
Snowflake 的 Agent Identity 是目前公开细节较多的一套实现。它把 Agent 分为两种：delegated agents 的会话属于用户，autonomous agents 使用独立的 SERVICE_AGENT 用户类型。查询历史可以记录 agent_type，访问历史记录 agents_info，masking policy 可以读取 Agent 是否处于激活状态，再决定是否返回敏感列。
身份协议仍未完全收敛。RFC 8693 的 OAuth Token Exchange 提供了 subject、actor 和委托链表达方式；SPIFFE/SPIRE 解决工作负载身份；MCP 授权规范使用 OAuth 2.1、PKCE 与 resource indicators。IETF 关于 Agent 委托身份的两条草案尚未形成单一标准轨道。现在可以稳定采用的是分层做法：SPIFFE 管工作负载身份，OAuth 管用户到 Agent 的委托，策略引擎管资源授权，审计系统记录实际行动链。
公开身份安全调研都显示，Agent 身份已经进入生产治理议程，但正式的全企业身份战略和现有 IAM 对 Agent 的覆盖仍不充分。不同调研的样本与问法并不一致，不能把单一比例外推为所有企业。组织仍在把 Agent 从临时调用主体转成独立且可审计的主体。
1.3 长链路可靠性不需要等新范式
数据 Agent 的多步任务可以使用已经成熟的 durable execution。Temporal、LangGraph checkpointer、Azure Durable Functions、Cloudflare Workflows 与 Restate 都能持久化任务状态，进程崩溃后从断点恢复，不必重跑整条链路。
数据平台任务还需要增加四个工程约束。
• 工具调用需要显式幂等键，常见格式是：
run_id:step_name:operation_name
• 跨系统动作不能依赖单一数据库事务回滚，需要用 Saga 和补偿动作。
• 投递语义不能承诺 exactly-once，实际目标是 outbox/inbox 加消费端去重后的 effectively-once。
• 高危 SQL、超预算查询、敏感列访问和语义层拒答后的兜底路由，需要挂起等待人工确认。
人工接管应当写进状态机。queued、running、waiting_for_approval、retrying、dead_lettered 和 completed 这些状态需要写入轨迹，补偿失败和人工等待超时都需要可观测。
这部分已经跨过可用门槛，但它解决的是任务是否能够可靠执行，不解决 Agent 是否理解了正确的业务口径。
02 数据集成、存储与计算：改的是负载权重
2.1 集成先自动配置，生产发布仍由人把关
传统 ETL/ELT 的 Agent 化，目前集中在字段映射建议、pipeline 生成与改写、失败诊断和修复建议。Snowflake Openflow 在主要云环境提供 GA 能力，Snowflake AIM 把迁移依赖识别与风险分析接入 CoCo；其他平台也在把连接器配置和迁移任务做成 Agent 入口。
生产自动发布仍然是另一件事。LLM 生成 pipeline 时可能忽略分区和聚类键，产生类型强制错误，用自愈逻辑掩盖根因，或者按过期文档生成代码。可靠做法是把数据证据、设计确认、验证 SQL 和发布动作拆开，生产发布保留人工闸门。
非结构化数据入湖的基本路径已经趋同：解析、切分、embedding、元数据抽取、写入对象存储或开放表格式。真正的瓶颈落在成本、一致性和权限上。
非结构化抽取的成本会随文档结构、版面复杂度和调用方式明显分层，当前没有统一公开的跨服务成本基准。一个业务实体往往同时存在于湖仓元数据、向量库、对象存储和文档库，更新后多份副本的版本与权限需要同步。Hudi 在 2026 年 6 月的发布材料把多存储 silo 带来的同步与运营负担列为多模态数据管理的工程难点。
2.2 MCP 化让引擎能力成为工具接口
MCP 在数据系统中的位置是 catalog 和 warehouse 之上的工具暴露层。它解决 Agent 如何发现和调用能力，不解决业务指标如何定义。
2026 年已经出现从单一 SQL 工具向完整引擎工具接口的迁移。Apache Doris MCP Server 1.0.0 于 7 月底发起 release vote，把 Doris 能力组织为 8 个稳定一级领域和 55 个渐进披露的子能力，覆盖 catalog、查询、集群、管道、检索、治理、湖仓和语义。它严格只读，支持 MCP 2026-07-28 协议、请求级授权、有界查询和 fail-closed 错误处理，语义域还可以消费 Apache Ossie 与 MetricFlow。
StarRocks 的公开产品材料已把 Agent Facing Analytics 作为一类工作负载，强调亚秒数据延迟、高并发和面向 Agent 的查询服务；其 MCP server 的具体维护归属、写操作范围与生产状态需要以当前官方仓库和文档为准。
TiDB 通过 pytidb 提供 MCP；社区版本默认只读，INSERT、UPDATE、DELETE 需要显式开启。人大金仓在 2026 年 8 月发布 KES MCP Server 并适配 Cursor。信创与长尾数据库的 MCP 覆盖大量依赖通用第三方 server，有项目声明支持 34 种数据库，包含达梦、人大金仓、GaussDB、OceanBase 与 GoldenDB，但这类实现的维护责任、权限边界和安全审计不能等同于数据库厂商官方 server。
引擎 MCP 化带来三个新约束。
第一，连接池和并发模型需要面对 Agent 的多轮探查。一个问题可能触发多次 schema 查询、执行计划查询、SQL 重试和结果解释。传统 BI 的查询模式更容易命中缓存，Agent 的探索路径局部性更低。
第二，工具发现需要渐进披露。把大量表的完整 schema 一次性塞入上下文，会把 token 和延迟消耗在 Agent 不一定使用的信息上。第三方工具对照测试显示，MCP 在某些任务中会显著增加工具描述和上下文开销；这是单一数据集与单一工具的测试，不能外推到所有 MCP，但足以说明全量工具描述的成本风险。
第三，写权限需要在 MCP 层再收紧一次。结构浏览、查询 profile、慢查询诊断可以默认只读；DDL、DML 和外部动作需要显式工具、独立权限与人工审批。平台内置 MCP Gateway、tool allowlist、rate limit、审计和 model routing，已经成为企业治理 MCP server 的一类产品实现。
2.3 存储格式为随机读写补通用能力
Iceberg v3 在 2026 年进入多个平台的落地阶段。Snowflake 于 2026-05-07 GA，支持 VARIANT、deletion vectors、row lineage、纳秒时间戳等能力；外部引擎读取 Snowflake 管理的 v3 表已经可用，写入仍有限制。Databricks 处于 public preview，AWS 通过 S3 Tables 与 Glue 支持相关能力。
这些通用机制与 Agent 负载存在适配关系。row lineage 为数据行提供可追溯标识，适合训练样本和分析结果追溯；deletion vectors 让过滤、删除和迟到修正不必每次重写整文件。它们面向通用数据变化，恰好覆盖 Agent 高频、小批量写入中的一部分需求，不能据此推导出格式演进由 Agent 直接推动。
Hudi 1.2.0 于 2026-06-07 GA，增加 VECTOR、VARIANT、BLOB 三种逻辑类型，并集成 Lance 文件格式。限制也很具体：VECTOR 只能是顶层列，维度与元素类型建表后不可改；向量搜索初始实现是分布式暴力搜索，原生 ANN 索引仍在推进。Delta 4.3.0 提供 Variant 列统计与 UC Delta REST API，4.4.0 支持 Spark 4.2 与 UC metric views。
Lance 的优势主要在带索引的随机检索，不在所有查询。
DuckDB 2026-05-21 的公开基准使用 LAION-1M，包含 768 维 CLIP embedding、图片字节、标题和标量元数据，设备为 Apple M1 Max，分别测试裸 LZ4 Parquet、DuckDB 原生索引表和 Lance。vector_indexed 冷启动从 Parquet 的 761ms 降到 Lance 的 12ms，hybrid 从 465ms 降到 17ms；但冷启动 FTS 中 Lance 为 21ms，Parquet 为 12ms，vector_exact 中 Lance 为 89ms，DuckDB indexed 为 61ms；blob_read 中 Lance 278ms，DuckDB indexed 271ms。
这组数字说明，Lance 的量级收益来自索引与 Blob 布局在随机检索中的配合，并不代表格式在所有扫描任务上更快。大范围列式聚合的公开对照数据未找到。适合 Agent 的形态是 Iceberg 管事实、版本和事务，Lance 或专用索引层管多模态随机检索，计算层负责批量解析与 embedding。一个格式吃掉全部负载的路线没有形成。
2.4 引擎优化先处理编译与冷启动
Agent 查询对引擎的冲击不只是查询量增长。一个业务问题可能触发多次模型调用、schema 探查、SQL 重试和 warehouse 查询，缓存命中率的前后对照数据尚未找到统一实测。
Snowflake 2026 年开始把交互式查询编译器、热谓词元数据与高频点查索引作为产品能力。Adaptive Compute 提供按 query 调资源的性能优化，但它按 query 计费，用户失去用速度换成本的控制，性能提高可能带来额外花费。Optima Indexing、Optima Metadata 和 Optima Planning 则分别对应高频点查、热谓词裁剪和历史计划调优。
引擎侧的成本治理也开始产品化：独立 AI Credits、per-user quotas、组织级 AI 用量视图、tool allowlist 和预算硬阻断陆续出现。成本治理的第一步是把 warehouse credits、AI credits、serving compute 和 embedding 重算放进同一个可查询视图，预算限制放在其后。否则 Agent 的调用扇出会被拆散在不同账单里。
向量与混合检索的关键差别是过滤和搜索是否在同一阶段。post-filter 在高选择度过滤下会造成召回下降，pre-filter 需要索引原生支持。HNSW、IVF/IVF-PQ、DiskANN 和 ScaNN 各有适用负载，Agent 更关心小 top-k、强过滤、短延迟、冷启动和增量刷新；离线召回的单一极限分数不是唯一指标。
03 语义、开发与分析消费
这几层在任务链中承担不同职责。Semantic Layer 负责指标、维度、Join、过滤和口径；Context Layer 管理业务规则、使用模式、来源权威与冲突信号；Ontology 描述实体、关系、规则与动作；MCP 负责工具发现与调用；Agent Runtime 负责身份、状态、重试、人工接管、轨迹与评测。它们可以由同一平台提供，也可以由不同系统组合，不能因为产品名称相近就视为同一层。
3.1 上下文层成为新的控制面
手工建语义层覆盖不足以后，平台厂商开始自动挖掘上下文。Databricks Genie Ontology 从表、查询、仪表盘、管道和外部应用中抽取指标定义、业务术语、权威数据源与规则，再用 OntoRank 进行排序。Snowflake Cortex Sense 从查询历史、对象元数据、BI 定义和语义视图中形成上下文，并按相关性、权威性、流行度和新鲜度排序。
两套机制都在回答同一个问题：企业内部有多个相互冲突的定义时，系统如何决定哪个来源更可信。Snowflake 官方博客披露，内部测试时发现了数十种 DAU 定义；遇到冲突时，Cortex Sense 会要求人解释，避免静默选择一个答案。
自动排序的边界同样清楚。排序的是来源可信度，不是计算正确性。一个来自权威来源、被频繁引用的错误定义，仍然可能获得高权重。自动挖掘把一次性语义建设变成了持续治理任务，但目前没有公开说明裁决结果如何沉淀、裁决人的生效范围如何界定、下一轮自动挖掘如何避免推翻人工裁决。
语义层与本体层承担不同职责。语义层回答指标怎么算、Join 怎么走、哪些过滤条件默认生效；本体层描述业务实体、关系、规则和可执行动作。多数生产系统需要二者协作：语义层负责可信分析，本体层负责跨域关系与动作约束。
3.2 数据开发是有闸门的加速
数据开发 Agent 已经可以生成 SQL、ETL、数据模型和任务编排，但能够进入生产的案例都保留了验证和发布闸门。
Meta Engineering 公开过一个老数据管道迁移案例：团队把接手工作拆成多个窄职责 Agent，分别处理文件解析、依赖提取和模式识别。案例的价值在分工方式，不能归因于 Agent 数量。复杂任务拆成有限职责的工具，比让一个 Agent 贯穿所有阶段更容易验证。
数据治理的上游环节更难自动化。标准设计、指标定义、数仓模型规划和质量规则采纳都涉及企业责任归属。厂商公开的治理案例通常可以生成候选规则，但最后仍需人工审批。部分试点材料披露，候选规则的初步采纳仍需要业务复核；候选规则仍需业务复核，生产元数据变更仍需人工负责。
3.3 只读分析已可用，跨域分析仍不稳
NL2SQL 的水位不能用单一榜单概括。PVLDB 19(5) 的研究发现，BIRD Mini-Dev 标注错误率为 52.8%，Spider 2.0-Snow 已公开 gold query 中抽查样本的错误率为 62.8%；修正标注后，16 个开源 Agent 的相对性能变化为 -7% 到 +31%，排名变化为 -9 到 +9 位。未修正子集的排名与全量 Dev 相关性为 0.85，修正后相关性降到 0.32，统计显著性消失。
真实生产库的结果明显低于厂商内部 benchmark。BEAVER、DAB、DABStep 等公开研究都把陌生 schema、跨域 Join、业务规则和多步计划作为主要难点；这些研究的任务定义和数字口径不同，不能拼成一个统一准确率。
可以进入稳定生产的通常是单表、简单 Join、口径已定义、错误影响可局部验证的任务。跨事实表聚合、跨域身份映射、复杂归因和业务规则随时间变化的任务，仍需语义建模、人工复核和持续评测。
归因分析与异常检测没有公开的非厂商准确率或采纳率数据。异常检测的规则与统计方法本身已经成熟，LLM 的作用主要是解释、追问和推送。把厂商自述的 98% 或 99% 当作行业水平，会混淆测试集与生产任务。
3.4 BI 从终点退为一个消费端
BI 产品正在沿两条路径接入 Agent。
一条路径是把已有语义模型交给 Agent。Looker 通过 LookML 语义层、Conversational Analytics API 和 Managed MCP 提供对话式分析；Power BI 语义模型成为 Fabric Data Agent 的数据源；Tableau Semantics 负责指标定义与冲突识别；FineBI NEXT 把指标中心、经营记忆和 Skill 组合成 Agent 入口。
另一条路径是把 Agent 嵌入业务应用。Cortex Analyst 提供 REST API；Looker 提供 Conversational Analytics API；Databricks Genie 提供 MCP App；Tableau 的 Headless Analytics 通过 MCP 进入 Teams、Slack 和 Google Workspace。
这会改变 BI 的位置。过去 BI 是用户看到结果的终点，未来它转为语义模型、可视化和工作流的组合消费端。数据 Agent 能不能输出一个图表已经不是主要问题，主要问题是图表中的每个数字能否绑定到指标 ID、查询参数、权限上下文和数据版本。
04 Data Agent 产品的五种架构选择
Data Agent 产品数量已经远超单篇文章能够完整罗列的范围。产品形态可以按架构选择来理解，每条路线拿一个代表拆开看，同类产品放在后面说明。
4.1 自动上下文挖掘：把冷启动交给平台
Databricks Genie One 与 Genie Ontology 代表这一条路线。它不要求企业先完整搭建语义层，而是从表、查询、仪表盘、管道和外部应用中自动抽取知识片段，再按来源、权威性、使用频次、认证资产关系和新鲜度排序。Agent 可以由单条 prompt 创建，连接 MCP 工具，并向外部系统写回。
这条路线解决的是语义层覆盖率问题，边界是自动排序无法证明业务定义的数学正确性。产品内部 28 题 benchmark 的 84.5% 首答准确率属于厂商内部结果，对比系统匿名，不能外推到陌生企业库。每个 space 30 张表/视图的硬限制，也说明产品仍以小范围领域 Agent 为主要组织单元。
同类产品包括 Snowflake Cortex Sense。它在 2026 年 7 月中进入 private preview，只摄取元数据和使用模式，不摄取数据行；冲突会要求人裁决。两者都在把上下文维护从一次性建模变成持续挖掘与纠错。
4.2 仓内语义对象：把定义、权限与身份放在一起
Snowflake Cortex Analyst、CoWork 与 Agent Identity 代表第二条路线。Semantic Views 是仓内一等对象，Cortex Analyst 直接消费语义视图；官方最佳实践要求先把指标、关系和 verified queries 建模清楚，再让 Agent 消费，具体容量限制随产品版本变化。
这条路线同时把重点放在语义层和 Agent 身份治理。delegated agents 继承用户会话，autonomous agents 使用独立 SERVICE_AGENT 身份，访问历史记录 Agent 链路，masking policy 可以针对 Agent 状态隐藏敏感列。Cortex Analyst 的准确率数字来自厂商内部测试，测试集与完整条件未公开，不能与其他产品横向比较。
同类包括 Looker Conversational Analytics、Microsoft Fabric Data Agent。Microsoft Learn 文档显示，Fabric Data Agent 只读，最多接入 5 个数据源，每个数据源最多 100 个示例查询，响应上限为 25 行 × 25 列；其 MCP server 与 service principal 鉴权仍为 preview。
4.3 本体加动作：从回答问题到调用业务动作
Palantir AIP 代表 ontology-first 路线。Ontology 既定义实体、关系和指标，也描述可对实体执行的动作。AIP Analyst 于 2026-04-13 GA，Ontology MCP 于 6 月提供，Pro-code Agent 于 7 月增加 Claude、OpenAI、Google agent SDK 模板。
这条路线适合需要把分析结果写回业务系统的任务。代价是本体维护重：数据源、组织结构和业务流程变化后，模型需要重新维护，交付周期与迁移成本都由此上升。
同类包括 Fabric IQ Ontology、用友 YonOnto。前者截至 2026 年 9 月仍 preview；后者把企业本体、领域智能体、Skill、MCP 和业务系统动作放在同一套产品叙事中，公开材料称已有 60+ 领域智能体和 625 个 Skill，具体评测条件未公开。
4.4 BI 资产复用：让指标中心承担语义责任
FineBI NEXT 代表 BI 资产复用路线。管理员先在指标中心搭建指标，用户基于指标中心提问；系统再把经营记忆与 Skill 接入跨会话分析。三级溯源从指标层到模型层再到数据层，承担的是口径与证据责任。
这条路线的前提是企业既有 BI 资产足够完整。如果指标中心没有唯一 owner、系统来源和例外规则，Agent 只是把原有的不一致更快地传播出去。
同类产品包括 Smartbi 白泽、观远问数 Agent、永洪 AI Copilot、Quick BI，以及 Tableau 的 Semantics。它们的产品状态、表数量上限、长期记忆上限和复杂归因评测条件，公开资料并不完整。
4.5 确定性语义编译：让 SQL 退到中间层之后
Aloudata 代表 NL2MQL2SQL 路线。模型先把自然语言映射到指标查询语言 MQL，再由语义引擎确定性编译成 SQL。这样做不会让所有问题都有答案，但能让超出覆盖范围的问题更容易明确拒答，减少模型直接猜 Join、猜过滤条件和猜指标定义。
数势科技走 NL2Semantics，网易数帆有数 ChatBI 使用逻辑查询层 DSL，dbt Semantic Layer 与 MetricFlow 走开放语义模型，Cube 把语义查询通过 MCP 暴露给 Agent。各家实现细节、覆盖范围与限流边界不同，公开资料不足以做横向优劣判断。
05 多 Agent 与“专家团”：角色多不等于能力强
Data Agent 产品中的“专家团”通常包含两层含义：把领域知识封装成专职 Agent，以及让多个角色在一个任务流程中协作。思迈特白泽公开了分析、专家、报告三类智能体；火山引擎采用规划器、反思器、执行器三段；用友公开了 60+ 领域智能体和 625 个 Skill；数势把 Multi-Agent 从分析、归因、报告延伸到决策与行动；Genie Agents 支持由一条 prompt 创建专职 Agent。
多 Agent 是否更强，取决于任务结构，不取决于角色数量。
arXiv:2512.08296 的研究评估了 180 个配置、5 种架构、3 个模型家族和 4 个 benchmark。在该研究的样本与预算条件下，单 Agent 基线超过约 45% 后，多 Agent 协调出现递减或负回报（β = -0.408，p < 0.001）；工具密集任务中，协调开销更容易超过收益；Independent 拓扑的错误放大指标为 SAS 基线的 17.2×，Centralized 为 4.4×；顺序推理任务上，多 Agent 变体相对劣化 39–70%。可并行的金融分析任务中，Centralized 架构相对提升约 80.9%。
研究者把顺序任务中的问题称为认知预算碎片化。顺序推理依赖持续的上下文，Agent 之间的交接会消耗 token，也会丢失上下文。对取数分析而言，schema 探查、SQL 执行、结果校验和报告生成往往存在前后依赖，天然不利于无约束的多 Agent 拆分。
目前可以确定的是，专家团形态的效果证据仍然有限。公开材料中常见的成本与准确率对照多来自厂商或第三方测算，缺少可复核的生产数据，不能用来证明多 Agent 普遍优于单 Agent。
对 Data Agent 来说，专家团的工程前提有四条：
- 子任务必须能独立输入、并行执行，再由主控 Agent 汇总；
- 主控必须承担 schema、权限、结果和动作校验；
- 每个角色需要独立 trace，不能只记录最终答案；
- 多 Agent 数量需要受 token、延迟和预算约束，单 Agent 已能处理的任务不应继续拆分。
没有中央校验、幂等、死信队列和人工接管的专家团，只是把一个错误扩散成多个错误来源。
06 还没有跨过门槛的地方
6.1 真实企业库仍不是榜单上的 90%
Spider 1.0 这类干净 schema 任务已经接近饱和，不能代表真实企业环境。Spider 2.0、BEAVER、DAB、DABStep 和 EntSQL 的结果共同显示，复杂企业任务的瓶颈主要落在表和列选择、业务规则理解、身份映射、跨域 Join、计划质量和结果验证，SQL 语法只是其中一环。
BIRD Mini-Dev 与 Spider 2.0-Snow 的标注错误还进一步削弱了榜单可比性。基准先要能够稳定回答“什么是正确答案”，再谈模型排名。
6.2 归因、异常与治理上游缺少公开证据
自动归因的方法本身并不新。维度归因、因子归因和相关性分析已经有成熟统计实现，LLM 主要负责解释、追问和把过程组织成可审计步骤。2026 年没有找到非厂商的自动归因准确率或采纳率数据。
数据治理 Agent 可以生成元数据注释、标准候选和质量规则，但标准定义与规则采纳涉及组织责任。生成数量不能代替业务接受度。公开案例中，候选规则的初步采纳率约 40%，这说明治理 Agent 当前主要承担候选生成与人工筛选，生产元数据变更仍需人工负责。
6.3 可复现性仍是审计缺口
Agent 是非确定性的。同一个问题两次执行，可能产生不同 SQL、不同工具路径和不同结论。数据版本化可以通过 Iceberg、Delta、Lance 和 Lakebase 的 time travel、branch 或 tag 记录数据状态，但仍缺少“语义上下文快照 + 分析结论 receipt”的联合版本化。
EPFL 的 arXiv:2607.10508 提出的边界很清楚：LLM 应该做查询编译器，不能做执行器。执行器只运行版本化计划，任何被报告的数字都必须能够追溯到一次真实执行。重跑模型不能证明复现了原来的轨迹，模型版本、采样结果、工具参数和数据快照都必须写入不可变记录。
6.4 成本与受治理生产率存在落差
Stacklok 与 Linux Foundation 的 MCP 调研把“在生产”进一步拆开：报告中有一部分受访者称已经进入生产，但受治理的企业级生产占比很低，大多数使用仍处于实验或本地开发阶段。该调查的样本与口径需要与具体版本报告一起阅读，不能把“在生产”直接当作规模化部署率。
Data Agent 的成本问题不只来自模型 token。每次问题的多轮探查、反思、重试、候选 SQL、warehouse 唤醒和 embedding 重算都会增加费用。仓库的 AI credits 与计算 credits 分散在不同视图时，用户无法知道一次自然语言请求到底消耗了多少基础设施成本。
07 2026 年新开的平台路线
7.1 上下文层开始独立交付
Snowflake Cortex Sense、Databricks Genie Ontology、Microsoft Fabric IQ、AWS Context 和 Google Knowledge Catalog 在同一年出现，说明上下文已经从应用内部的 prompt 工程，变成数据平台可以单独交付的一层。
平台原生上下文通常服务本平台的 Agent，不会天然向外输出。跨平台企业需要提前决定哪一层持有业务定义的权威，平台原生上下文只做本地信号补全，还是反过来由某个数据平台承担主定义。Apache Ossie 的意义在于让语义定义具备交换格式，但 v1.0 仍在孵化期，格式标准不等于执行引擎、权限策略与生产可移植性。
7.2 引擎 MCP 化扩展工具接口
Doris MCP Server 的 1.0.0 release vote 把 catalog、查询、集群、治理、湖仓和语义组织到 MCP 工具目录中，说明引擎对 Agent 的接口可以不只是一条 execute SQL。StarRocks、TiDB 与多种数据库也在以官方或社区 server 方式暴露能力。
MCP server 的产品差异需要从工具暴露粒度、权限边界、渐进披露、连接池管理、执行预算、失败语义和审计完整性观察。一个只提供裸 SQL 的 server，与一个能够暴露语义、查询计划、血缘和受限执行的 server，不属于同一成熟度。
7.3 Agent 原生分支与轨迹资产
Lakebase branching、Lance version/branch/tag、Iceberg snapshot refs 让 Agent 可以在隔离空间内试错、回滚和保留版本。Agent 还在生成 scratch table、中间结果、工具调用轨迹和评测记录，这些数据正在从临时日志变成可写回数据湖的长期资产。
实践中已经出现 Bronze 原始 trace、Silver 规范化轨迹事实、Gold 评测与回归集三层模型。Harbor ATIF 面向评测与可观测，Agent Data Protocol 面向训练数据，两者的受众不同，短期内不会合并成一个格式。
7.4 本体与动作仍处于高成本阶段
语义层解决指标、维度和查询路径，本体层把实体关系、规则与可执行动作放到一起。它适合跨系统操作和写回，但构建周期、维护成本和组织协同要求更高。2026 年本体能力大多仍是部分 GA、预览或垂直交付，不适合被当作所有 Data Agent 的默认基础设施。
08 从业者核查清单
在判断一个 Data Agent 是否已经达到生产条件时，至少核对以下八项。
-
语义层是必选还是可选旁路？如果 Agent 可以绕过语义层直接访问裸表，语义治理就可能退化为提示词配置。
-
准确率数字的测试集、样本量、基线和人工复核规则是什么？厂商内部 28 题或 150 题 benchmark 不能直接外推到企业生产库。
-
超出覆盖范围时系统是明确报错，还是返回一个看似合理的数字？这比单次准确率更能决定上线风险。
-
Agent 的身份是否独立、可委托、可审计？查询历史能否区分用户执行与 Agent 执行？
-
MCP server 是只读还是可写？是否有渐进披露、tool allowlist、QPS、查询预算、危险 SQL 检查和连接池隔离？
-
多 Agent 任务能否画出独立子任务的依赖图？如果任务是顺序依赖，增加专家团可能只增加 handoff 和错误传播。
-
关键结论能否回溯到指标 ID、语义上下文、SQL、数据快照和模型版本？没有联合 receipt，就不能把重跑结果当作审计证据。
-
预览能力是否写入了生产承诺？Fabric Data Agent、Cortex Sense、Fabric Ontology、Tableau Command Center 等产品或能力的 GA、preview 与路线图状态必须分别核对。
结语：数据平台的责任边界正在向语义与运行时移动
2026 年跨过门槛的能力集中在三个地方：语义层让失败可捕获，权限体系开始承认 Agent 是独立主体，durable execution 让长任务可以恢复。存储格式、向量索引和计算引擎的变化更多是在适应 AI 负载，Agent 使用方式把随机读、小查询、冷启动和成本治理的重要性抬高了。
尚未跨过门槛的部分也很清楚：开放式跨域分析、自动归因、治理上游、无人值守写操作、语义冲突的长期沉淀、分析结论的联合版本化。专家团可以在并行任务中带来收益，但在工具密集、顺序依赖的取数链路中，默认拆分会增加成本和错误传播。
Data Agent 产品接下来会继续增加工具、记忆、动作与编排能力。大数据 与 人工智能 的交汇处，能否进入关键业务流程，取决于语义是否可验证、权限是否可传递、执行是否可恢复、结果是否可追溯，以及失败能否被系统明确地说出来。
参考资料
发表于 15 小时前
|
查看: 14|
回复: 0
