Agent Harness on DataAgentX

Data Agent 怎么做：把 23 篇内容收成一张工作地图

Sun, 04 Oct 2026 00:00:00 +0000

看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。

这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。

下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。

一、先决定它接手哪类工作

企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。

不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。

二、正确答案从找对数据开始

SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。

数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。

三、七层架构服务于一个任务

一条完整链路可以概括为：

接入与路由找到相关、授权、足够的数据；
语义层绑定业务定义和关系；
规划与编排把目标变成可恢复状态机；
受控执行校验、授权并运行 SQL、代码和工具；
验证与评测检查来源、语义、程序、分析和交付；
治理与安全贯穿身份、策略、缓存、文件和动作；
交付与行动把声明、证据、制品、审批和反馈连接起来。

这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。

四、自治升级等于责任转移

L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。

同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。

五、公开榜单只能帮你找候选

Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。

最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。

产品案例应该变成检查问题

不同厂商案例最有价值的部分，不是功能名单，而是设计线索：

内部 Data Agent 提醒我们，数据发现和组织上下文可能比 SQL 生成更难；
Skills 模式说明分析经验可以变成可复用、可评审的工作协议；
云平台产品展示了数据、语义、身份和运行时如何复用现有控制面；
只读设计说明查询与业务动作应拥有不同权限边界；
多 Agent 架构只有在职责、上下文或权限需要隔离时才有意义。

把每条线索变成自己的 POC 问题，而不是照抄厂商架构。

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 会规划，为什么任务仍然做不完

Wed, 09 Sep 2026 00:00:00 +0000

“新客转化下降，帮我找原因并给建议。”Agent 先查了渠道，再查地区，第三步遇到超时，于是从头重跑；或者生成十几步计划，却在拿到第一张结果表后忘了最初要验证的假设。它看起来会“思考”，任务仍然没有完成。

规划层的职责不是输出一段漂亮的待办清单，而是把复杂目标变成一个能保存状态、检查证据、恢复失败并在必要时交给人的执行过程。

图中每一步都应该有输入、产物、通过条件和失败去向。缺少其中任何一个，所谓“自主循环”很容易变成无界重试。

先分流任务，再决定是否需要规划

并非所有问题都值得启动 Agent 循环：

已有指标、单次只读查询、风险低的问题，可以直接走受约束的查询模板。
需要多个数据源、多个假设或代码分析的任务，才进入计划—执行—验证循环。
涉及写入、外发、敏感数据或高成本计算的任务，应在规划前标出审批节点。
目标、口径或数据覆盖不清时，先澄清，不要用规划掩盖需求缺口。

复杂度分流既节省成本，也缩小故障面。让每个问题都进入多 Agent 编排，通常只会增加延迟和排错难度。

一份可执行计划需要七个字段

每个步骤至少包含：

字段	作用
`step_id`	稳定引用，便于恢复和审计
`objective`	这一步要减少哪项不确定性
`inputs`	使用的数据、语义版本和前置产物
`tool_contract`	允许调用的工具、参数和权限
`output_contract`	预期结果的结构、版本和保存位置
`verification`	通过条件、容差和独立检查
`on_failure`	重试、改计划、降级、澄清或升级给人

“分析渠道影响”不是合格步骤，因为它没有说明使用什么数据、怎样判定完成。更好的目标是：“按渠道计算本月与基准期转化率，在相同口径和覆盖范围下标记绝对变化最大的三个渠道，并验证分母完整性。”

状态不能只存在对话里

长任务的事实状态应存放在 Harness，而不是靠模型记忆：任务目标、约束、当前计划版本、完成步骤、产物引用、失败次数、预算、审批和未解决问题。模型每轮只接收完成当前判断所需的切片。

一个实用状态机可以包含：PLANNING → READY → RUNNING → VERIFYING → COMPLETED，以及 WAITING_INPUT、WAITING_APPROVAL、REPLAN_REQUIRED、FAILED 和 CANCELLED。状态迁移由规则和工具结果触发，模型可以建议迁移，但不能随意把失败改成完成。

检查点应保存逻辑产物与版本，而不是完整复制所有敏感数据。恢复时先检查数据、语义、权限和批准是否仍有效；不能拿昨天的批准运行今天已经改变参数的动作。

规划、执行和验证要分工

常用模式是 Planner 提出下一步，Executor 通过受控工具运行，Verifier 检查结果与约束。它们可以是三个独立组件，也可以由同一模型在不同权限和上下文下完成。关键不在角色名称，而在控制面是否隔离：

Planner 不能持有生产凭证。
Executor 不自行扩张任务范围。
Verifier 使用独立规则、查询结果或测试，不只让模型评价自己的输出。
Harness 决定预算、重试和停止。

多 Agent 只有在专业上下文、工具权限或并行工作确实需要隔离时才有价值。把一个任务拆成许多拟人角色，却共享同一上下文、权限和评分器，只增加通信损耗。

Data Agent 的七层架构：从数据接入到可信交付

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

业务负责人问：“这个月新客转化为什么下降了？”

如果系统立刻吐出一条 SQL，这通常不是效率高，而是跳过了最危险的部分。它还不知道“新客”按注册时间还是首购时间认定，不知道转化窗口是 7 天还是 30 天，也不知道本月渠道口径是否刚刚调整。SQL 可以运行成功，结论仍然可能是错的。

一个可用于生产的数据智能体，必须把这类模糊问题变成一条可检查的证据链：确认意图，找到被批准的数据和定义，制定分析计划，在受控环境里执行，验证结果，最后把结论和限制交给有权限的人。模型只负责其中一部分。

下面这张图把这条链路拆成七层。它不是厂商产品清单，而是一张职责地图：当结果不可信时，团队可以据此定位究竟是哪一层失守。

Data Agent 七层职责地图。点击查看原图。

先看清三张相互叠加的网

七层并不是一条只能从上往下走的流水线。一次分析会在规划、执行和验证之间多次往返，而权限、审计与评估贯穿始终。更准确的理解，是三张网叠在一起：

数据面负责让智能体找到数据、理解业务语义并运行工具；
控制面决定智能体可以看到什么、调用什么、在什么成本和风险范围内行动；
评估面检查单次答案，也持续衡量系统在一组真实任务上的表现。

很多原型只有数据面最显眼的一小段——“问句转 SQL”。一旦进入生产，真正拉开差距的往往是另外两张网：系统能否拒绝不该做的事，能否说明结论从何而来，失败后能否定位和修复。

第一层：接入与任务入口

入口可以是聊天框、Notebook、BI 侧边栏、API，也可以是定时触发的工作流。它的责任不是“做一个像 ChatGPT 的界面”，而是收集完成任务所需的最小上下文：用户身份、业务范围、时间窗口、期望输出和风险等级。

仍以转化率下降为例。一个合格的入口至少要知道提问者能看哪些地区的数据，并在定义不明确时主动追问：“这里的新客按注册还是首购计算？”

这一层的典型失败，是系统流畅地解决了另一个问题。产品设计上应允许用户低成本纠正假设，而不是把澄清隐藏在一长段回答之后。

第二层：语义、本体与可信上下文

物理表告诉模型有哪些字段，语义层告诉它这些字段在业务上意味着什么。这里需要管理指标、维度、实体关系、同义词、时间口径、Join 路径、负责人和版本。

例如，“新客转化率”可能被定义为：首个有效触点后 14 天内完成首购的新用户数，除以符合条件的新用户数。这个定义还要说明排除哪些渠道、退款如何处理、历史版本何时失效。只有把这些知识变成可检索、可引用、可执行的对象，智能体才不必每次凭字段名猜测。

上下文也不等于把所有文档塞进提示词。系统需要按任务路由：指标问题优先取指标定义和血缘，客户问题取实体关系和权限，重复出现的分析则可参考已验证的历史查询。上下文越多不一定越好；过期定义和相似但错误的 SQL 会把错误包装得更像答案。

第三层：规划与编排

规划器把目标拆成有依赖关系的步骤。对“新客转化下降”这类问题，一份可检查的计划可能是：

确认指标版本和比较周期；
先复算整体指标，确认下降确实存在；
按渠道、地区、设备和新客来源做贡献分解；
对主要异常分组检查漏斗步骤与数据质量；
运行替代口径或对照查询，排除定义变更；
汇总证据，标出不能从现有数据确认的部分。

规划的价值不在于写出一段漂亮的步骤说明，而在于让依赖、预算和停止条件显式化。某个分组样本过小，就不该继续生成强结论；关键数据延迟，系统应停止并提示，而不是用昨天的数据补齐今天的故事。

单智能体配工具、Planner–Executor–Verifier、多智能体协作都可以实现这一层。角色越多，协调和状态管理成本越高。先把计划、工具契约和验证点做扎实，通常比先增加 Agent 数量更重要。

第四层：工具与受控执行

智能体通过 SQL 引擎、Python 沙箱、Catalog、文档检索、可视化组件和业务 API 把推理变成证据。每个工具都应该像一个受约束的服务，而不是给模型一把万能钥匙。

一个可上线的工具契约至少应写清：输入参数、输出结构、身份传递、数据范围、超时、成本上限、幂等性和失败码。查询默认只读；大扫描、敏感字段和写操作需要单独的审批或策略门槛。代码在隔离环境运行，产物和日志可追溯。

这也是 Agent Harness 的核心工作：把模型调用、上下文装配、工具选择、策略检查、状态与记忆连接起来。模型可以替换，Harness 中积累的权限、工具契约和失败处理才是系统工程的主体。

第五层：验证、反思与修正

“工具调用成功”只说明系统得到了一份结果，不说明结果值得相信。验证层需要同时检查计算和结论。

计算侧可以做 SQL 编译、空值与基数检查、时间范围检查、与可信总数对账、替代查询比较；结论侧要检查每个判断能否回到数据证据，相关性是否被误写成因果关系，以及样本量和数据延迟是否足以支撑措辞。

当验证失败时，系统应回到规划或执行层修正，而不是简单地“再生成一次”。例如两个渠道的合计对不上整体，正确动作是检查重叠归因或 Join 扩张；让模型换一种说法，并不会修复数字。

Data Agent 的 L0–L5：升级的不是功能，而是责任

Sun, 06 Sep 2026 00:00:00 +0000

一个系统会写 SQL，另一个系统会调用 SQL 和 Python，遇到错误还能重新规划。后者连接的工具更多，但这还不足以证明它更“自主”。真正的区别是：谁决定目标，谁组织过程，谁有权执行，谁验证结果，出了问题又由谁恢复并负责。

因此，Data Agent 的等级不是功能数量表，而是一张责任转移图。每升一级，Agent 接手的不只是更多操作，也包括更多判断与风险。

这套 L0–L5 框架来自 2026 年论文 Data Agents: Levels, State of the Art, and Open Problems 及其配套的 Data Agent 研究资料库。作者将公开研究的主体现状放在 L0–L2，把正在探索端到端自主编排的系统称为 Proto-L3；L4 和 L5 主要是未来愿景。它适合用来讨论人机分工，不是厂商排行榜，也不是采购认证。

判断等级，要看五种权力归谁

同一个产品在不同工作流上可能处于不同等级。判断时可以沿五个维度逐项追问：

维度	关键问题
发起权	任务必须由人提出，还是系统能主动发现问题？
规划权	人预先定义步骤，还是 Agent 能拆解、选工具并重新规划？
执行权	只能建议、可以只读执行，还是能触发写入与外部动作？
验证权	谁判断结果足够可靠、任务可以结束？
恢复与责任	失败时谁停止、回滚、接管并解释发生了什么？

只要其中一个关键维度仍由人控制，系统的实际等级就会受到它限制。例如 Agent 可以自动写并执行 SQL，但每一步由人指定、结论也由人验收，它更接近 L2，而不是 L3。

L0：人是唯一的操作者

在 L0，分析师或工程师自己找数据、写 SQL 或代码、检查结果并决定下一步。数据库、BI 和 notebook 是工具，但不会代替人做判断。

L0 并不等于落后。在财务结账、监管报送、重大生产变更等高风险流程中，完整人工控制可能是合理设计。它的问题是吞吐依赖个人经验，过程难以规模化，隐性知识也容易留在个人电脑和脑中。

生产门槛：建立版本、评审、数据口径和操作记录。没有这些基础，接入 Agent 只会把原本不透明的人工过程自动化。

什么是 Data Agent：判断它是不是智能体的四个标准

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

“为什么本周转化率下降了？”

一个 NL2SQL 工具可以把这句话翻译成查询。一个真正的 Data Agent 则要先问清楚：是哪条业务线、哪个转化漏斗、自然周还是滚动七天、当前用户有权查看哪些数据。随后，它还要找到可信的数据集，调用指标定义，拆解异常，运行查询，检查样本量和数据新鲜度，最后把结论连同证据交给使用者。

二者都可能有聊天框，也都可能生成 SQL。区别不在界面，而在于谁对完整任务闭环负责。

一个可以落地的定义

Data Agent 是运行在受治理数据环境中的自主或半自主软件系统。它接受自然语言或高层任务，在权限边界内完成上下文装配、规划、工具执行和结果验证，交付可追溯的数据答案、洞察或行动。

这里的每个限定词都有用：

数据环境意味着系统面对的是真实表、指标、文档、元数据和访问策略，而不是一组预设答案。
自主或半自主意味着它能维护任务状态，根据中间结果继续、修正或停止，而不是只完成一次生成。
受治理意味着模型不能绕开身份、权限和审批规则；高风险操作必须有边界。
可追溯意味着使用者能看到结论依据了什么数据、口径和执行过程，也能复核关键结果。

近年的 Data Agent 研究也反复指出：这个名称同时被用于查询助手和自主系统，术语混用会掩盖能力差异。《A Survey of Data Agents》因此提出了从 L0 到 L5 的分类；后续的《Data Agents: Levels, State of the Art, and Open Problems》则把数据管理、准备和分析都纳入同一个工具使用框架。定义的价值，不是再造一个新名词，而是让产品承诺可以被检验。

Data、Model 和 Harness 缺一不可

只看大模型，很容易把 Data Agent 理解成“更会推理的聊天机器人”。实际系统更接近三个部分的乘积。

Data：不只是数据库连接

数据侧至少包含三类上下文：

事实数据：仓库、湖仓、业务数据库、文件和 API。
业务语义：指标定义、维度层级、实体关系、同义词和计算规则。
治理上下文：身份、行列权限、数据分级、新鲜度、血缘和使用限制。

能连上 Snowflake 或 BigQuery，只解决了“数据在哪里”。如果不知道“有效订单”是否排除退款，也不知道财务口径何时生效，系统仍然会稳定地产生错误答案。

Model：提供推理，不拥有权限

模型擅长理解意图、提出假设、生成 SQL 或 Python，并把结果组织成人能读懂的说明。但模型参数不是企业事实库，也不应该成为权限系统。把业务定义塞进提示词，只能暂时改善某个问题，无法替代版本化的语义层和强制执行的访问策略。

Harness：把能力组织成可靠过程

Agent Harness 是最容易被低估的部分。它负责装配上下文、保存状态、安排步骤、选择工具、传递身份、限制执行、校验结果并记录轨迹。模型可以替换，工具可以增加；只要 Harness 的契约稳定，系统仍能按同一套治理规则工作。