先想象一个场景：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，先看覆盖程度。完整命中，走 SemQL，NL2SQL 并行兜底；部分命中，走受约束的 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 真正成为企业数据的自主生产力。