产品 on DataAgentX

腾讯云 DataBuddy：Data Agent 的 RSI 初现

Tue, 20 Oct 2026 00:00:00 +0000

腾讯云 DataBuddy 团队在 DataFunTalk 视频号直播发布了新版 DataBuddy。资料未明确直播日期，本文于 2026 年 10 月 20 日整理。

最值得注意的是两点：DataBuddy 可以接入外部已有的数据源，而不只是腾讯云上的数据源；模型未来也可以接入自有 API，比如 Claude、ChatGPT 的模型。

本文基于发布会直播内容整理。厂商自述的准确率和上线周期未做独立评测，文中区分了发布信息与编辑判断。

四类任务

发布会把 DataBuddy 的能力分成四类：

类别	做什么
数据工程	从自然语言需求生成、编排数据管道
数据治理	巡检元数据、血缘、质量和安全
数据分析	对话取数、报表、看板和异动归因
数据科学	把数据准备接到模型训练与部署

前三类在 Data Agent 产品里比较常见。第四类值得单独注意：它把分析结果直接接到模型构建和线上服务，而不是停在看板和报告。

工程和治理之间还有一条迭代链：随着任务执行与治理变更，系统自动更新相关的数据血缘、Catalog 等信息，让数据上下文跟着实际工作持续更新，再服务后续任务。

发布会演示链路

演示围绕“经营怎么样、复购为什么弱、接下来做什么”展开，串起三段：

数据工程：构建 ETL 数据流，为分析和建模供数。
经营分析：配置经营报表，分析复购等业务问题。
数据科学：构建模型，部署线上推荐服务。

这个顺序说明了产品的定位：不是单点问答工具，而是把发现问题、验证假设和落地改进接在一条链上。

三块基石

Unity Semantics

用 Catalog、指标与维度、本体模型，把数据结构和业务口径连起来。

这与语义层建设的通用思路一致：元数据负责找到资产，语义层负责统一口径，本体负责表达关系和约束。

Agent Runtime

包括用户身份绑定、高危 SQL 拦截、行列权限、动态脱敏、沙箱隔离与审计。

安全能力的介绍值得关注，但不能等同于安全认证。评估时仍应设计冲突任务，观察系统是在计划阶段阻止、工具阶段拒绝，还是执行后才过滤。

OneOps

把 DataOps、MLOps、AIOps 接在同一底座，减少分析与模型开发之间的搬数和衔接。

这一块是“数据科学”能力的基础：如果分析和建模分属两套环境，改进点很难顺畅地走到线上。

两条接入路径

发布会给出两种方式：

直连已有 OLAP：接入企业现有数据系统，从分析切入，沿用原有存算。
迁入统一存算：覆盖更完整的四类任务。

这个选择本身反映了产品的现实定位：不是要求所有客户先做数据平台改造，而是允许从分析场景逐步进入。

火山引擎 Data Agent：问数与深度研究为什么要分流

Fri, 02 Oct 2026 00:00:00 +0000

“昨天华东销售额是多少”和“新品复购下降后应该先改产品、人群还是触达策略”，看起来都在问数据，工作形态却完全不同。前者目标明确、数据域窄、答案可快速核对；后者需要拆解问题、组合多类证据并形成有条件的判断。

火山引擎的产品路线把智能问数和深度研究分开，核心不是增加 Agent 数量，而是让不同责任走不同链路。

问数链路追求短反馈

智能问数适合指标查询、归因切片和多轮追问。数据集、字段和业务场景需要预先约束，复杂指标最好在 ETL 或语义层中稳定下来。官方文档给单个 Agent 设有数据集与字段数量边界，也建议围绕单一业务场景和意图配置。

深度研究需要证据编排

开放问题要先形成研究子题，再决定查询哪些数据、检索哪些知识、调用哪些工具。最终交付不应只是一个数字，而要区分事实、解释、假设、建议和未决问题。

两条链共享底座，但验收不同

问数和研究都需要指标语义、身份权限、数据新鲜度与审计记录。不同的是验收：问数看定义和数值能否复现；深度研究还要检查来源覆盖、推理跳跃、反例和建议适用条件。

多 Agent 不等于把同一任务拆碎

若多个角色共享模糊目标、重复访问数据、最后由模型自由拼接，系统只会增加协调成本。合理分工应为每条链定义输入、输出、权限和失败去向，并由协调层决定何时从快速问数升级到研究任务。

试点时可以用同一批业务问题做分流测试：明确指标问题应在短链完成；跨域策略问题进入研究链；证据不足时必须请求补充或降级结论。多 Agent 的价值，来自可验证的责任分工，而不是界面上出现多少头像。

升级条件要写成规则

问数链不应因为回答困难就无限扩展。可以设置明确升级信号：问题包含多个业务域、需要外部资料、存在相互矛盾的指标、需要提出行动建议，或预计超过查询预算。协调层据此创建研究任务，并把已经确认的指标定义、查询结果和未决问题一起交接。

反过来，深度研究也不应把简单问题复杂化。若核心事实可由一次受治理查询回答，就直接返回并保留查询证据。短链负责效率，长链负责不确定性；两者之间的交接质量，决定多 Agent 系统是否真的节省时间。

运营指标也应分开：问数链关注首个可用答案时间、定义命中率和追问修正率；研究链关注证据覆盖、关键反例、建议采纳与后续结果。把两条链混成一个满意度分数，会掩盖各自真正的瓶颈。

还要观察协调成本：一次任务发生多少次路由、重复读取了多少上下文、交接是否丢失来源，以及人工需要在哪一步重新解释问题。若角色增加后这些成本持续上升，说明分工边界需要合并，而不是继续增加新 Agent。

参考：智能分析 Agent 产品文档

DataBuddy 架构拆解：Agent 为什么需要一套数据底座

Tue, 29 Sep 2026 00:00:00 +0000

分析 Agent 算出“新增用户 12 万”，经营看板却显示 10.8 万。两边都能解释自己的 SQL，也都声称使用了最新数据。此时团队面对的并不是一次问答错误，而是一个更根本的问题：Agent 和传统数据产品是否建立在同一套资产、语义和权限之上？

这正是 DataBuddy 架构里最值得研究的部分。它表面上提供数据工程、数据分析和数据治理三类 Agent，底层设计却不是给三个聊天入口分别接工具，而是把数据接入、湖仓、Catalog、统一语义和 AI-Ready 知识组织成一条共享主链，再用 Agent Harness 把上下文、工具、安全和评估接起来。

如果只关注“三个 Agent 能做什么”，很容易错过这个产品真正的架构主张：先把数据平台改造成 Agent 可以理解、调用和约束的系统，再让 Agent 参与生产。

先读懂官方架构图

腾讯云 DataBuddy 产品架构图。图中 OLAP 引擎在 2026 年 8 月版本标注为规划中，实际可用范围应以当前产品控制台和文档为准。点击查看原图。来源：腾讯云产品文档

这张图可以沿两个方向阅读。

纵向是一条数据主链：多模态数据接入后进入湖仓和资产管理体系，经 Catalog、统一语义与知识加工，最终由 Agent 或看板消费。横向是两组贯穿能力：Agent Harness 负责上下文、记忆、工具、安全和评估，数据治理 Agent 则让标准、质量、元数据和权限不再只是后台配置。

图的上半部分是业务交付，中间是能力平台，底部是引擎与存储。它们不是三个彼此独立的产品层，而是同一次任务的不同责任边界。

数据主链：从“能接入”到“能被 Agent 正确使用”

企业数据通常散在数据库、消息系统、文件、日志和业务应用里。把数据同步到湖仓，只解决了可访问性，并没有解决可理解性。Agent 还需要知道表之间如何关联、字段代表什么、哪个指标定义被批准、某项资产是否新鲜，以及当前用户能否使用它。

DataBuddy 把这条加工链连续画出来：多模态集成、资产管理、统一语义、AI-Ready 数据知识，再到 Agent 与看板。这里的顺序很重要。

所谓 AI-Ready，不应该被理解为“把文档转成向量”这么简单。对数据任务而言，它至少包括四类对象：

结构知识：表、字段、血缘、分区、数据质量和更新状态；
业务知识：指标、维度、实体关系、同义词和适用范围；
执行知识：可信查询、工具参数、工作流和失败处理；
治理知识：所有者、权限、敏感级别、用途与审计要求。

只有这些对象能被检索、引用并约束执行，Agent 才不是在一堆 Schema 名称上猜答案。

Data Agent 如何真正读懂“客单价”

Mon, 28 Sep 2026 00:00:00 +0000

“近 30 天各品类的客单价是多少？”模型很容易写出语法正确的 SQL，也很容易在业务上完全错掉。客单价可能是支付金额除以支付订单数，也可能排除退款、按买家数计算，或者只看签收订单。

这不是 SQL 技巧问题，而是业务术语尚未绑定到可执行语义。

一个指标至少有五组约束

实体与人群定义谁被统计；分子和分母规定公式；时间说明事件时间、窗口和时区；粒度决定按订单、用户还是商品聚合；有效期和版本说明这套口径何时生效。

指标名只是入口，指标契约才是可执行对象。契约还应包含允许关联、默认过滤、空值处理、Owner、验证查询和已知例外。

为什么需要读取代码和元数据

数据开发代码包含真实的派生、过滤和关联逻辑，表元数据描述字段、分区和血缘。二者结合可以生成语义模型草稿，再由业务和数据 Owner 编辑确认。只读 Schema 很难发现“已支付但未取消”这样的隐含条件。

阿里云 DataWorks 的相关路线值得关注，正因为它把语义生成放在数据开发与分析工作流之间：语义不是旁边的一份说明文档，而是 Agent 查询时要加载的约束。

生成语义模型后还要验证

可编辑 YAML 或其他语义定义只是载体。上线前应使用已知问句与可信查询做双向测试：同义表达是否绑定同一指标；边界日期是否一致；跨表 Join 是否改变粒度；新版本是否破坏历史结果。

一个可落地的最小闭环

先从十个高频指标开始，提取代码与元数据，生成草稿，由 Owner 确认后写入版本化语义仓库；查询时记录命中的指标版本；结果异常时，把修正回写为新的测试，而不是临时提示词。

Data Agent 真正理解“客单价”，不是因为模型见过这个词，而是因为词被绑定到了有版本、有 Owner、可验证的计算契约。

语义层还需要运行时观测

上线后应统计每个指标契约被哪些问题命中、哪些同义词频繁无法解析、哪些查询在 Join 后产生异常膨胀，以及用户在哪些答案上反复追问。它们能揭示语义定义缺口，比单纯统计问答满意度更接近根因。

契约变更也要区分兼容更新与破坏性更新。增加一个同义词通常可以直接发布；改变分母、默认过滤或时间窗口，则需要新版本、影响分析和历史回放。语义层不是一张静态指标表，而是一套面向 Agent 执行的变更管理系统。

对跨部门指标，还应显式声明适用组织与展示名称，避免销售口径覆盖财务口径。若用户问题没有足够信息选择版本，Agent 应展示候选定义并请求确认，而不是依赖语料中的多数用法替用户决定。

语义命中记录也可以反哺治理：高频歧义进入术语清单，反复失败的 Join 进入禁止规则，常用且稳定的问句沉淀为验证样例。每次失败都应改善契约，而不是只修补当次回答。

参考：阿里云 DataWorks 产品文档

Microsoft Fabric Data Agent 为什么坚持只读

Sat, 26 Sep 2026 00:00:00 +0000

Agent 一定要能改数据、发工单，才算有价值吗？Fabric Data Agent 选择了更窄的边界：生成并执行只读的 SQL、DAX 和 KQL 查询，把跨系统写操作留给外部编排。

身份先于查询

数据访问沿用用户的 Microsoft Entra ID 与数据权限。Agent 能看到 Schema，不代表用户能读数据；对 Power BI 语义模型的访问还受 Read 权限、RLS 和 CLS 约束。这使权限检查落在数据平台，而不是交给提示词判断。

不同资产走不同查询语言

Lakehouse、Warehouse 和 SQL Database 通过 SQL 查询；Power BI 语义模型使用 DAX；Eventhouse/KQL Database 使用 KQL。一个 Agent 可以组合多种来源，但语言路由只是第一步，跨源口径、粒度和时间仍需业务定义约束。

只读降低了什么风险

只读阻止 Agent 直接创建、更新或删除数据，也不会从 Eventhouse 触发 Notebook 或其他动作流。这减少了误操作的爆炸半径，并让分析组件更容易嵌入 Copilot Studio 等上层编排。

但只读不等于安全或正确。错误查询仍会误导决策，过宽权限仍会暴露数据，Purview DLP 也可能让结果被截断或阻断。当前聊天输出还有行列限制，不适合被当作完整数据导出接口。

生产设计的三个检查点

第一，验证用户身份和每个数据源的实际权限，而不是只看工作区角色。第二，为关键问题提供示例查询和语义说明，并记录生成查询。第三，把“分析建议”与“业务动作”分开：若外部 Agent 要据此写回系统，必须重新审批目标、参数与接收者。

Fabric 的只读路线说明，一个 Agent 不必包办闭环中的全部动作。把受治理问数做成可靠组件，再由显式编排承担写操作，往往比给同一个模型无限工具更容易审计。

只读 Agent 也需要回归集

可以从真实高频问题构造一组覆盖 SQL、DAX 和 KQL 的任务，记录预期数据源、关键筛选、行级权限和可接受的汇总结果。每次模型、语义模型或数据源结构变化后回放，重点检查错误路由、静默截断和权限差异，而不是只看自然语言答案是否流畅。

AWS 的三条 Data Agent 路线，解决的是不同问题

Thu, 24 Sep 2026 00:00:00 +0000

同属 AWS 的 AI 能力，Amazon Quick、SageMaker Data Agent 和 Bedrock 并不是三个可以按功能数量直接排名的产品。它们从不同用户和责任边界出发。

路线	主要用户	主要交付	团队仍需负责
Amazon Quick	业务用户与 BI 使用者	对话问答、洞察、故事和工作流	Topic 语义、数据权限、答案复核
SageMaker Data Agent	分析师、数据科学与 ML 团队	查询、代码、分析开发过程	环境、成本、代码审阅和复现
Amazon Bedrock	构建自有应用的开发团队	可编排的 Agent 能力	工具契约、身份、状态、评测与 UX

Quick：从问答走向业务工作

Amazon Quick 的新体验强调跨数据集问答和 Agentic 工作流。多数据集 Topics 承担语义层作用。它更接近业务应用，但“能问多个数据集”并不意味着跨域指标已经统一；Topic 设计仍决定术语、字段和聚合是否一致。

SageMaker：把分析过程放进开发环境

这条路线更适合需要查看查询和代码、迭代模型或处理复杂数据的专业用户。优势是分析过程更可检查，代价是环境、依赖、算力成本与可复现性由团队共同承担。

Bedrock：给自建 Agent 一个底座

Bedrock 提供模型与 Agent 构建能力，但不会替企业决定指标口径、工具权限或结果验收。它给了最大自由，也把最多系统工程责任留给开发团队。

选型先问责任归谁

如果目标是让业务用户快速获得受治理洞察，先评估 Quick 的 Topic 和权限；如果核心是分析开发与代码审阅，关注 SageMaker；如果要嵌入自己的流程和界面，才需要 Bedrock 级别的可编程性。

Google Cloud Data Agent：三类上下文如何共同收敛

Tue, 22 Sep 2026 00:00:00 +0000

Agent 知道表在哪里，不等于知道怎样回答业务问题。Google Cloud 的 Conversational Analytics 把 Data Agent 描述为“上下文 + 工具”的组合：上下文提供业务信息和数据，SQL、Python 与可视化工具负责执行。

三类上下文承担不同责任

数据上下文说明可查询对象、字段、关系与数据位置；业务上下文解释术语、指标、过滤规则和经过验证的查询；会话上下文保存用户在多轮对话中的范围、假设和追问。

把三者混成一个“知识库”会带来问题。字段元数据不能代替指标定义，历史对话也不应覆盖受治理语义。数据 Agent 应明确每类上下文的来源、有效期和优先级。

已保存 Agent、内联上下文与会话状态

API 支持引用已保存的数据 Agent，也可以在请求中直接提供上下文。多轮交互又可选择有状态会话，或由应用在无状态模式下自行管理历史。选择哪种方式，取决于复用、隔离、审计和数据驻留要求，而不只是开发便利。

语义资产怎样减少歧义

在 BigQuery 或 Looker 场景中，团队可以补充表字段元数据、解释指令和 verified queries。比如“top performers”究竟按收入还是订单数排序，应由业务语义约束，而不是让模型临场猜测。

生产边界

身份与访问仍由 IAM 和数据源权限控制。数据库数据源和部分能力的成熟度不同，可视化支持也不是所有来源完全一致。Google 官方明确提醒生成结果可能看似合理但事实错误，重要输出仍需验证。

适合的试点不是“让所有人随便问所有数据”，而是选择一个语义稳定的主题，为常见问题准备 verified queries，记录生成的 SQL、工具调用和结果，并把失败归因到上下文、执行或呈现层。

Google Cloud 的路线说明：上下文越多不一定越好。真正有效的是相关、授权、可追踪且能在多轮状态中保持一致的上下文。

建议的评测切片

同一问题至少要在四种条件下测试：语义信息完整、字段说明缺失、会话中途改变范围、用户权限不足。分别记录 Agent 选择的数据源、生成的查询、最终答案和拒绝原因。这样可以看出系统是在可靠使用上下文，还是只在理想演示里表现良好。

对有状态会话还要测试“上下文污染”：前一轮对某个地区或时间窗口的限定，是否被错误带入新的主题。对无状态集成则要检查应用是否完整传回必要历史，并避免把敏感内容带到不相关请求。状态管理本身也是数据治理的一部分。

参考：Conversational Analytics API 概览、BigQuery Conversational Analytics

Anthropic Skills：把分析经验从提示词变成可维护工作流

Mon, 21 Sep 2026 00:00:00 +0000

把模型接到数仓，不会自动得到稳定的分析师。它还需要知道团队怎样检查数据、如何建模、什么图适合表达结论，以及交付前必须做哪些复核。

Anthropic 将 Skill 定义为包含指令、脚本和资源的文件夹，相关时才加载所需内容。这个设计把“每次重新解释工作方法”变成可版本化的工作协议，也允许在需要确定性的环节执行代码。

Skill 封装的是方法，不是知识幻觉

指令可以规定步骤和边界；脚本可以承担清洗、计算或格式转换；模板与参考材料可以约束最终制品。三者组合后，同一套方法可用于表格、文档、演示和 PDF 等不同交付面。

但 Skill 不会凭空补齐企业指标定义和权限。分析类 Skill 仍需显式接入数据语义、来源优先级、允许调用的工具，以及谁负责最终批准。

为什么比一次性提示词更容易治理

Skill 可以进入版本控制，变更能审阅，测试任务能回归，组织也能分发经过批准的版本。它把模型行为的一部分从隐藏对话移到可检查文件中。

代价是新的供应链风险：Skill 可能包含可执行代码，也可能引导模型访问文件和连接器。Anthropic 官方同样建议只使用可信来源。企业至少需要来源审查、最小权限、隔离执行、依赖固定和制品扫描。

分析 Skill 的合理分层

一个成熟工作流通常分成六段：理解用户任务、加载方法指令、取得必要文件与工具、执行可重复计算、生成制品、进行内容与视觉验收。封面图中的每个区块都对应一个可测试的责任，而不是一句抽象的“做分析”。

适合怎么落地

先挑一个高频、边界清楚的交付，例如周度经营复盘。把输入契约、指标口径、异常处理、图表规范和验收清单写进 Skill；将真实历史任务做成回归集；让分析师审阅失败类型，而不是只看平均满意度。

Skills 最有价值的地方，不是给模型增加更多身份，而是把专家经验变成可以维护、组合和验证的工作流。

验收应覆盖过程与制品

分析 Skill 的测试不能只问“有没有生成文件”。过程层要检查输入数据是否完整、公式是否可追溯、异常是否被记录；制品层要检查表格公式、图表尺度、标题结论和移动端可读性。对同一批历史任务做版本回归，才能知道新指令是改进了方法，还是只让输出更像模板。

企业还需要明确失败策略：缺少关键字段时停止并说明，还是用替代口径继续；脚本报错后允许重试几次；生成的文件在发送前由谁批准。把这些边界写进 Skill，才算把经验工程化，而不是把一段更长的提示词放进文件夹。

维护时还应把方法更新与模型更新分开评估。模型升级可能改善推理，却也可能改变工具选择和制品风格；Skill 版本变化则会直接改变步骤与验收。分别固定变量做回归，才能知道质量变化来自哪里。

参考：Introducing Agent Skills

OpenAI 内部 Data Agent：难点不是写 SQL，而是找对上下文

Fri, 18 Sep 2026 00:00:00 +0000

表里都有 user_id，为什么两次查询算出的活跃用户仍不一样？企业问数最难的部分常常发生在 SQL 生成之前：应该用哪张表、哪个时间字段、哪套过滤条件，以及哪份定义仍然有效。

OpenAI 在 2026 年 1 月公开的内部实践，把问题中心放在上下文工程。文章给出的当时规模快照是超过 3,500 名内部用户、600PB 数据和约 70,000 个数据集。规模数字很醒目，但更值得借鉴的是系统如何缩小候选上下文。

六类上下文不是同一种知识

来源	提供什么	典型风险
表使用信息	Schema、血缘、历史查询	热门查询未必正确
人工注释	业务含义、已知问题、Owner 经验	可能过期或只适用于局部
管道代码	派生逻辑、过滤条件、新鲜度线索	实现复杂，需结合运行状态
机构知识	文档、讨论、决策背景	权威性和时效差异大
运行时反馈	查询结果、错误和数据分布	只能说明本次执行状态
记忆与纠正	已验证修正和失败经验	必须限制适用域与版本

这些材料不能简单拼进一个超长提示词。系统需要先检索候选资产，再按权限、时间、粒度和问题相关性收窄，并保留为什么选择这份上下文的证据。

查询生成只是中段

一个更完整的链路是：理解意图 → 检索元数据与机构知识 → 选择候选表和可信查询 → 生成与执行 → 根据错误和结果修正 → 独立验证 → 记录可复用纠正。

其中，执行反馈很关键。空结果可能意味着过滤错误，也可能是真实业务现象；SQL 成功只能证明语法和运行环境接受了它，不能证明业务语义正确。

记忆必须有适用边界

“上次把 created_at 换成 activated_at 就对了”不是全局规则。可靠记忆至少要绑定数据域、指标、表版本、时间范围和验证证据。否则一次有效纠正会成为下一次错误来源。

对企业团队的启示

不要先追求覆盖所有数据。先选一个定义相对稳定、Owner 明确、错误代价可控的业务域，建设可检索的资产说明、可信查询、运行时权限和回归任务集。每次纠正都进入审阅流程，而不是直接写入永久记忆。

这套内部实践不是可直接采购的产品规格。它真正说明的是：当数据规模扩大后，Data Agent 的瓶颈会从“能不能生成 SQL”转向“能不能找到、约束并验证正确的上下文”。