先想象一个场景Agent 不只是写一份周报总结而是要接入数据源、生成 SQL与工作流、构建 DWD/DWS 模型最后再把每日同步任务发布到生产环境。这时候你最担心的其实已经不再是它说错一句话——那是内容问题识别和修正都相对简单。你真正担心的是它做错一个动作一条误读的 DDL 改了线上表结构一次越权读取把客户明细带到了错误的位置一个被忽略的口径差让全公司看到的是虚增了 30% 的订单。这就是腾讯云 DataBuddy 团队在 2026 AICon 全球人工智能开发与应用大会上想讲清楚的事在企业大数据场景里Agent 不只要会做更要在动作可控、结果可信、经验可进化这三条边界内做。三条边界缺一条都接不住核心任务企业Data Agent 要同时回答三个问题。动作可控。它会调用什么工具、能读哪些数据、能不能写入和发布、能不能把数据发出去这些不能只靠Prompt约束。Prompt是建议不是闸门。DataBuddy 把它落实为权限、确认和审计三件事。结果可信。一条 SQL 语法正确不代表业务口径正确。收入到底含不含退款新增客户按注册算还是按首购算这些答案不在模型参数里在企业自己的实体、关系、指标和维度里。经验可进化。如果每次人工纠错都只停留在那一次对话里下次它还会犯同样的错。修正和证据要经过治理变成后续任务能直接消费的资产。为什么可控排在第一位因为风险不是线性增加的它随动作等级跳变。DataBuddy 把动作分了四级回答出了错人能自己纠正查询出了错可能是越权读取或者错误的结论被拿去用了生产里的 DDL、DML 和任务发布会真实改变系统状态外联则让数据和错误离开组织边界。分界线就在这里Agent 从生成内容走向改变状态。DataBuddy 的应对原则不是给所有动作都加人工审批而是风险越高确定性控制越前移生成前缩小范围执行前做权限和策略判断改变状态前按策略要求人工确认执行后留下完整证据。敢不敢让Agent做Runtime的答案用一个任务来看。用户只说一句接入 MySQL 销售库构建 ODS/DWD/DWS配置每日增量同步。一句话背后是一条完整的工程链路源端探查、分层建模、DDL 和转换 SQL、增量策略、工作流编排、运行验证。主 Agent 负责理解目标、拆解计划、协调执行Runtime 为这次对话绑定独立环境装载本次允许使用的能力记录 Trace在发布前要求人工确认。DataBuddy目标态是小时级交付——过去这类工作要以周计。但比快更要紧的是怎么算做完。DataBuddy判定一个任务能不能托管给 Agent标准只有三条产物可定位模型 / DDL / 同步配置带编号、版本、负责人、评审状态动作可回放关键 tool_call 与 HITL 决策在 Trace 中可查结果可核验结构检查 抽样校验 质量规则 人工审批的验收单对话只是入口。企业真正要的交付是结构化产物和过程证据。架构上这套东西怎么落模型负责判断Harness 负责执行语义提供上下文安全收住边界。不让模型同时承担决策和最终控制这是整个架构里最重要的分工。具体分五层最上面是接入与编排控制面管会话、启动、能力装载和审计在执行前把动作限制住Runtime 执行面每个业务对话独立绑定语义与知识面负责检索注入最底层才是湖仓、计算引擎和数据库。DataBuddy能力边界有一个朴素的原则把确定性交给程序把判断留给模型。API、CLI、SQL 这类原子能力在底层往上封装成程序化 Tool用 schema 约束输入用 findings 结构化返回再往上是少量业务 SOP Skill最上面才是主 Agent。规则全塞进 Prompt没法测试也没法治理流程全写死成代码模型就没了处理开放问题的能力。分层封装之后确定型动作稳定执行开放型问题才轮到模型的 agentic 能力出场。Hook、Permission、Trace、Memory、MCP 不属于任何一层它们横切整条链路在正确的时机拦截、授权、留证、记忆。Agent做得对不对语义的答案如果说 Runtime 解决敢不敢让它做那语义解决的就是做得对不对。模型能生成 SQL但决定这条 SQL 对不对的是企业语义。DataBuddy 把语义拆成四个要素实体即客户、订单、收入这些业务对象关系即对象之间怎么连接指标即在度量上叠加口径、窗口和同环比维度即按什么来分析。同样是问本月订单金额排不排除已取消订单用下单时间还是支付时间按哪个组织层级汇总模型靠常识猜不稳。只有把指标、维度、关系和时间标识符从语义层检索出来编译成 SemQL 再生成 SQL口径才有稳定的基础。这套语义层叫 DataBuddy Unity Semantics是人与 Agent 共用的语义工程层。同一个收入不需要在 BI 里定义一次、在 Agent Prompt 里再写一次。DataBuddy 也是语义层的消费方之一不把语义能力封闭在自己产品里。理想很丰满现实是企业常常根本没有语义资产这就是冷启动问题。DataBuddy 的做法是机器先出草稿人来确认。两条路从元信息来表结构、字段注释、主外键、历史 SQL、BI 配置和血缘从业务文档来数据字典、Wiki、PRD 和口径说明。表推断出实体主外键和 Join 频次推断出关系聚合列推断出度量高频 group by 推断出维度。但有一条线不能越LLM 加规则统计产出的只是草稿。冲突检查、去重聚类之后还要 Owner 审核才能进权威语义资产。DataBuddy 降的是人工录入的成本不是人工治理本身。召回之后也不是直接生成 SQL先看覆盖程度。完整命中走 SemQLNL2SQL 并行兜底部分命中走受约束的 NL2SQL已召回的语义只作参考缺的东西记下来完全未命中加严 schema 范围、只读限制和确认策略。无论哪条路候选都要过静态、语义、权限三重校验失败的证据回到 Agent Loop 里修正重试缺失的 case 离线聚类归因变成四要素候选进治理。Agent能不能越做越好治理的答案行业里把Agent越用越准说得太轻巧了它不会自动发生。早期会撞上一个信任低谷语义资产少 → 准确率不高 → 用户不敢用 → 没足够反馈沉淀。跨过低谷要靠两条输入冷启动抽取的候选从元数据和业务文档来、运行中的部分命中 / 未命中 / 人工修正离线聚类归因后形成的候选。候选进入同一条治理链路去重 → 冲突检查 → Owner 审核 → 版本控制 → 可回滚发布。只有通过治理才能成为权威语义资产进入下一次任务的 Context。更准确的表述应该是越用反馈越多反馈经过治理系统才可能越准。记忆也要按作用域分层Session会话级任务态→ Personal个人偏好→ Team业务空间共识→ Enterprise治理后长期资产。越往下越实时、使用越频繁、权威性越低越往上作用域越大、权威性越高、治理要求越严。晋升要过两道关口去重聚类 冲突质量检查以及 Owner 审核。不能因为一条经验被用得多就自动把它当成企业真相。最后一关安全与评测DataBuddy 把风险拆成三类要素敏感数据、不可信内容、状态改变或外联。真正危险的不是单一要素出现而是它们在同一动作里汇聚。处理原则是拆分 分级 独立护栏。单点护栏一定会失效所以防御是纵深的沿 Agent Loop 的时序铺开基础设施层做 Runtime 隔离、短周期凭证和网络资源边界输入护栏识别注入、清理敏感信息规划护栏查工具和表名幻觉工具层做 Permission 和人工确认输出护栏查泄露和外联最后由审计观测通过 Trace 和告警复盘。两个引擎互补。规则和 HITL 同步阻断关键动作低延迟、可解释LLM 审计在多个时机异步复核能抓规则覆盖不到的语义风险默认不阻塞主链路。DataBuddy 不追求万能护栏要的是多层独立控制共同约束关键动作。落到 SQL 这个最关键的动作上是三个阶段。生成前限域按用户身份只给候选 Schema 和最小上下文。执行前收敛静态检查、只读护栏、默认 LIMIT状态改变进人工确认。执行后留证受控执行、脱敏交付、完整 Trace。敏感数据按级别管公开和内部数据按任务最小化提供业务敏感数据优先给 schema 或聚合最小权限加确认输出脱敏私密和高敏数据明细默认不进模型靠行级、列级权限和列级掩码收边界。凭证是另一条硬约束设计上不进模型短周期强制脱敏。最后是评测怎么证明系统在持续变好而不是只在 Demo 里好看答案是离线回归和在线观测接成一个闭环。离线侧评测资产覆盖工程、问数、治理三类场景接入了 CI评判不是单模型打分是确定性校验、多模型盲判、人工标注三层结合Bad Case 归因后进回归集。在线侧从真实链路的 Trace、Event 和告警里采样脱敏加人工审核后变成新样本。线上问题回离线修复结果再通过离线回归验证两个环才真正闭合。结语回到开场那三个问题。Data Agent动作如何可控Runtime、权限、沙箱、HITL、Trace。结果如何可信统一语义、受约束生成、可核验的证据。经验如何进化分层记忆、评测回流、治理后生效。DataBuddy 的目标是在可控边界内让 Agent 真正成为企业数据的自主生产力。