业务负责人问，上周新增用户为什么下降。Agent 很快给出数字，还附了一段解释。继续追问新增是否包含回流用户、退款订单算在哪一天，答案开始对不上。问题出在 Agent 与数据中台之间缺少一条可治理的协作链路。数据从哪来、按什么口径算、当前用户能看哪一层、结果如何复核，这些问题没有定清楚，演示越顺畅，进入生产后越容易暴露。
AI Agent 与数据中台的协作，是供给与消费的分工。数据中台把分散数据接入、建模、治理成统一指标和数据服务；AI Agent 在授权范围内理解任务、选择数据与工具、执行查询或动作，并把结果、依据和过程留痕。两者通过语义层、数据服务与工具接口、身份权限和审计记录连接，不需要让 Agent 绕过中台直接猜表。数据调用、权限治理和应用场景，是这条链路里最容易出问题的三段。
数据中台与 AI Agent 各自负责什么
数据中台负责可信供给，AI Agent 负责任务执行。
数据中台负责把数据变成可复用的资产。接入、清洗、建模、指标定义、资产目录、数据服务发布，这些工作决定了同一张表、同一个指标能不能被不同业务共用。它的输出是表、模型、指标、标签、数据 API 和权限规则，本身不发起业务动作。
AI Agent 负责把业务目标拆成可执行的任务。它理解问题，选择调用哪些数据和工具，组织查询结果，必要时再执行写回、触达或流程动作。腾讯云 DataBuddy 产品文档把 Agent 分成工作流模式和自主决策模式，前者适合结果一致性要求高的固定流程，后者适合开放式分析，实际项目会把两种模式混用。Agent 的价值在任务执行，数据中台的价值在可信供给。
两者的边界可以用一张表看清。
| 环节 | 数据中台 | AI Agent |
|---|---|---|
| 数据接入与建模 | 负责接入、清洗、建模 | 不承担底层建设 |
| 指标口径 | 定义、维护、版本管理 | 使用口径并反馈问题 |
| 取数与分析 | 提供语义层、数据服务、API | 理解问题、选择路径、组织答案 |
| 权限 | 维护数据权限事实 | 继承、收窄、执行 |
| 业务动作 | 不发起业务动作 | 可以发起，需审批与回滚 |
| 审计 | 记录数据访问 | 记录完整任务链路 |
有三条边界。Agent 不绕过中台直接猜表，否则口径、权限和审计都会失控。中台不替代 Agent 的编排能力，数据服务本身不会拆解任务。Agent 平台也不等同于数据中台，前者管智能体的创建、编排和治理，后者管数据资产和服务。数据中台的接入、建模、指标和服务化可以参看数据中台包含哪些功能；Agent 平台与数据中台的区别在AI Agent 中台与传统数据中台的区别里有更完整的展开。
数据调用：AI Agent 如何调用数据中台数据
分析型任务优先语义层，生产动作优先数据服务，受控 SQL 只用于探索。
Agent 取数不止“直连数据库”一种方式。路径选错，后面补口径和权限的成本更高。调用方式可以归成五类，治理强度从高到低排列。
| 路径 | Agent 拿到什么 | 适合任务 | 权限落点 | 主要风险 |
|---|---|---|---|---|
| 语义层或指标服务 | 指标、维度、口径、查询计划 | 高频问数、经营分析、跨部门一致口径 | 语义层继承行级、列级、表级权限 | 语义资产不完整时覆盖不足 |
| 数据服务 API 或工具 | 受控入参和结构化结果 | 生产流程、跨系统调用、固定动作 | API 网关、工具白名单、参数校验 | 接口设计不良会形成新的烟囱 |
| 知识库或检索 | 文档、规则、历史案例、指标说明 | 解释口径、客服问答、报告生成 | 文档权限、字段脱敏 | 知识过期或版本混乱 |
| 受控 SQL 或临时查询 | 直接查询结果 | 一次性探索、复杂关联 | 只读账号、schema 白名单、查询限额 | 绕过语义层，口径和权限容易失守 |
| 元数据、血缘与日志 | 表结构、血缘、任务状态、日志摘要、统计画像 | 数据开发、任务运维、质量治理 | 元数据权限、日志脱敏 | 信息碎片化，需要上下文整合 |
分析型任务优先走语义层或指标服务。业务人员说的是“新增用户”“利润率”“活跃门店”，这些词要先映射到明确的指标、维度和过滤条件，Agent 才能生成稳定的查询。语义层同时承载口径和权限，查询前就能把不该看的行、列、表挡掉。数据中台的指标和资产越完整，这条路径越稳。基础概念参看数据中台智能问数理念。
生产流程和跨系统动作更适合数据服务或工具接口。Agent 通过 API 或 MCP 这类标准接口调用数据服务，入参、出参、超时、限流和错误码都由接口定义，模型不需要理解底层表结构。腾讯云 DataBuddy 的 Agent 模块就是这样配置工具与知识库的，平台把创建、调试、部署、运行、评估和优化串成一条链路。接口标准化降低了连接成本，权限、审批和审计仍要单独建设。
知识库主要解决解释问题，指标定义、业务规则、历史案例和客服话术适合放进去，让 Agent 在回答时引用。实时数值仍应来自语义层或数据服务。把文档和明细数据混在一起喂给模型，容易让答案看起来有依据，实际却无法复核。
受控 SQL 可以保留，但要清楚它绕过了什么。Lightdash 官方文档指出，语义层的用户属性会约束行级、列级和表级访问，原始 SQL 不走语义层，sql_filter、required_attributes 这些规则不会自动生效。企业如果允许 Agent 执行原始 SQL，需要单独配置可访问的 schema 和 catalog 白名单，使用只读账号或个人仓库凭据，并设置查询扫描量上限。把“模型不会越权”当成权限方案，风险很高。
数据开发和运维场景则更多依赖元数据、血缘、任务状态、日志摘要和统计画像。InfoQ 2026 年 8 月 AICon 深圳站收录的演讲把生产级 Data Agent 的能力概括为上下文与长工作流闭环，并给出一个安全原则，Agent 默认不直接访问原始明细数据，优先使用元数据、语义层、血缘、任务状态、日志摘要和 profiling 统计信息。这样既能支持诊断，也能降低越权和误操作的概率。
判断一条路径是否合适，可以问三个问题。结果是否需要跨部门一致，如果需要，优先语义层。任务是否高频且结果要可复核，如果是，优先数据服务。错误是否可回退，如果不可回退，先不要开放写操作。能查到数据，和能拿它做决策，是两件事。 帆软 2026 年 11 月发布的《企业级 Data Agent 技术架构与落地实践》白皮书解读把企业级 Data Agent 的必要条件列为四点，处理业务目标、能够选择和组合工具、在企业约束中运行、输出可以被验证。约束能力和生成能力要一起看。
权限治理：四道闸门在查询前生效
权限判断要放在查询之前，并覆盖身份、数据、工具、输出四道闸门。
Agent 的权限风险有三个出口，用错身份、看到不该看的数据、把结果分享出去。治理要覆盖 Agent 的整条执行链路。
第一道：身份与入口
Agent 进入企业后，代表的是某个员工、岗位或组织范围的授权。平台要把 Agent 的身份接回企业已有的组织与权限体系，支持单点登录、租户隔离和调用入口控制。谁可以创建 Agent、谁可以调用、哪些 Agent 能进入生产，都要有清单。
共享入口要重点管。一些 BI 工具的 Agent 在 Slack 中默认使用创建者的身份，除非开启逐用户授权，否则每个提问者都会继承创建者的数据范围。企业自建 Agent 也会遇到同类问题，群聊里的机器人如果只配置一个服务账号，权限就可能被放大。应让 Agent 使用提问者身份，或者在无法逐用户授权时，限制可问的数据范围和输出内容。
第二道：数据范围
数据范围要落到行级、列级和表级。行级控制按区域、门店、项目或组织隔离，列级控制敏感字段，表级控制哪些模型可以被 Agent 引用。权限判断要在查询生成阶段完成，不能等答案出来再删字段。帆软白皮书里有一个说明性场景，用户没有查看单客户成本的权限，系统在任务开始时就限制下钻粒度，避免在生成答案后才删除客户名称。这个顺序决定权限能否生效。
语义层适合执行数据范围，因为行级、列级和表级规则可以跟随每一次查询自动生效。原始 SQL 是例外，它绕开语义层，企业需要额外的 schema 白名单、只读账号、查询限额和个人仓库凭据。敏感字段还要有脱敏、禁查或审批策略，尤其是手机号、身份证号、地址、支付信息这类字段。
第三道：工具与动作
Agent 能调用哪些工具，要和它能看哪些数据分开管理。工具清单按 Agent 配置，遵循最小权限，参数尽量结构化，避免让模型自由拼接命令。先开放只读工具，再评估是否需要写操作。写操作要有审批、幂等、预览、沙箱和回滚，不可逆动作默认禁止。
这一层还包括租户隔离和密钥管理。不同业务线、不同客户的 Agent 不能共享同一套高权限凭据，API 密钥和数据库账号要集中管理，不能散落在各个团队的提示词或配置文件里。Agent 调用外部工具时，还要确认对方返回的数据是否可信，避免把外部内容当成指令执行。
第四道：输出与分享
答案生成之后，风险还没有结束。导出、分享、嵌入、二次追问都可能扩大数据范围。平台要控制谁能导出报告、谁能分享给外部、哪些字段需要水印或脱敏，保存的结果也要继承原查询的权限。排行榜、文件附件、连续追问是泄露路径，需要单独测试。
全链路审计要贯穿四道闸门。一次任务至少要留下这些信息，提问者是谁、调用了哪个 Agent、使用了哪些数据和工具、查询条件是什么、返回了什么结果、是否经过审批、执行了哪个版本。全链路审计既服务事后追责，也是企业敢把 Agent 放进生产环境的前提。
提示词不能当作权限边界。Lightdash 官方文档把 Agent 指令和 Agent 上下文定义为引导，不具备强制执行能力，它们可以影响 Agent 怎么推理，不能扩大它能访问的范围。权限要落在身份、语义层、工具层和仓库层，不能只写在提示词里。
应用场景：哪些任务适合先上 Agent
先用高频、可验证、可回退的任务验证协作链路。
数据场景要筛选，以下几类适合先上 Agent。可以用五个条件做初筛，任务是否高频，数据是否稳定可用，答案是否可验证，错误是否可回退，权限是否可控。五个条件里有两三个不满足，先补基础，不要急着上线。
经营分析与即时追问
经营分析适合作为起步场景。Agent 从语义层取数，按管理者的问题拆维度、做对比、生成图表和报告初稿，回答里附上指标口径、数据来源和更新时间。它适合月报、周报、经营例会前的重复取数，也适合管理者临时追问。
边界要清楚。默认只读，经营判断仍由业务负责人签发，Agent 不替人做结论。核心指标要先统一，帆软白皮书的建议是从 10 到 20 个复盘会常用指标开始，把名称、公式、过滤条件、字段和更新时间写清楚，并指定负责人。指标口径没有确认，Agent 的回答越流畅，越容易让人误判。
用户洞察与分群运营
用户洞察场景离业务动作更近。Agent 可以按标签和行为圈选人群，解释分群特征，生成运营建议，必要时调用触达工具。它应调用治理后的用户标签、分群服务和行为分析结果，避免让模型直接扫原始明细。
这个场景对权限更敏感。行级权限要限制到区域、渠道或项目，列级权限要保护手机号、地址、支付信息，敏感字段要脱敏。触达、发券、改标签这类写操作要有审批和白名单，不能让 Agent 自动扩大人群或连续发送。先做“圈选和解释”，再做“执行和复盘”，风险更可控。
数据开发与任务运维
数据开发和运维也适合 Agent。报表没有数据时，Agent 可以沿着报表任务、ADS 表、DWD 表、上游同步、调度依赖、资源队列和质量拦截逐层定位，给出修复建议，必要时生成 SQL、管道配置或 DQC 规则。它依赖元数据、血缘、日志、任务状态和统计画像，不直接翻原始明细。
这类场景要把执行边界做厚。生成 SQL 后先试运行，变更前预览影响范围，生产修改要审批，失败要能重试和回滚。DQC 规则可以先从空值、唯一性、值域、波动阈值这些基础规则做起，再用字段类型和 profiling 统计推荐更贴近业务的规则。Agent 可以降低规则建设成本，不能替代数据负责人对质量标准的确认。
财务、供应链等强审计场景
财务和供应链的指标定义、责任边界通常比较明确，但对准确性和审计要求更高。Agent 适合辅助查数、解释差异、生成报告初稿，不适合在缺少审批的情况下修改凭证、出具法定报表或作出税务结论。月结状态、币种、合并范围、会计期间这些上下文要显式传递，不能靠模型猜。
供应链场景的难点常在数据时效和跨系统一致性。ERP、WMS、采购系统的更新时间不同，Agent 要展示各数据源的时间戳，避免把快照差异误判为业务异常。库存异常可以定位，补货和调拨这类动作仍要有审批和回滚。
如果企业选择成熟平台承接，需要核对三件事，Agent 能否在统一身份下调用数据与工具，知识和指标能否版本化、可追溯，运行过程能否审计和回滚。以 ThinkingAI 为例，Agentic Engine 负责 Agent 的创建、管理和多 Agent 协作，支持私有化部署；企业级知识库用 SSOT 保证同一概念在全系统只有一处定义，用 ChangeSet 让每次更新可追溯、可对比、可回滚；Tiki 智能助手曾获中国信通院数据分析智能体 4+ 级评级。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。这些能力能缩短平台搭建周期，前提仍是企业把数据接入、指标口径和权限边界梳理清楚。
落地顺序：从一条只读链路开始
先只读、再写操作，先单部门、再多部门。
协作链路不需要一次建全。做法是先选一个高频、只读、结果可验证的场景，把数据、语义、权限和审计跑通，再扩展写操作和更多业务线。
第一步，选任务。用高频、数据可用、答案可验证、错误可回退四个条件筛，经营日报问答、销售业绩下钻、库存异常解释通常比自动预算审批更适合作为起点。
第二步，盘数据与语义。列出问题涉及的数据源、表、指标、维度、时间字段、刷新频率和权限，建立核心术语表，给每个指标指定负责人、公式、过滤规则、可组合维度和版本。指标数量不必多，先把高频问题覆盖住。
第三步，定调用路径。分析型问题优先语义层，生产动作优先数据服务或工具接口，一次性探索才考虑受控 SQL。工具要拆到最小可控粒度，先开放只读，再评估写操作。
第四步，配权限与审计。把身份、行级、列级、表级、脱敏、工具白名单、审批、导出和日志逐项配置，专门测试越权、无数据、口径歧义和连续追问。共享入口要确认使用的是提问者身份，不能默认继承创建者权限。
第五步，建题库并小范围上线。题库至少覆盖正常题、歧义题、无数据题、越权题、错误口径题、长链路题和恶意输入。固定模型、Agent、语义和数据版本做盲测，把错误定位到交互、语义、规划、工具、数据或生成层。上线后持续看答案正确性、权限隔离、证据可追溯、失败恢复、延迟和成本，不要只看回答像不像。
上线前可以用六个问题做一次检查。
- 这个 Agent 代表谁，身份从哪里来。
- 它能看哪些行、列、表，权限在查询前还是答案后生效。
- 它能用哪些工具，哪些是写操作，哪些不可逆。
- 结果能否回到数据来源、查询条件和执行记录。
- 出错时能否停止、回滚、定位和追责。
- 共享、导出和二次追问是否会扩大数据范围。
六个问题里有任何一个答不上来，先不要扩大到更多部门。
常见问题
AI Agent 会取代数据中台吗
不会。数据中台负责可信供给，Agent 负责理解任务和执行。没有数据中台，Agent 仍可以使用核心业务数据，但通常要先补一层轻量的指标、语义和权限，否则容易停在演示阶段。两者的关系更接近上下游协作。
没有数据中台，能不能让 Agent 取数
能，但范围要收窄。先接核心业务数据，建一层轻量语义层，把高频指标的口径、字段和权限定义清楚，再做单部门试点。数据分散、口径混乱、权限边界不清的企业，即使先上 Agent，效果也会受限。中台是载体，治理是前提。
Agent 应该直接连数据库，还是调用数据服务
默认优先语义层或数据服务，直接连数据库只用于受控探索。原始 SQL 会绕过语义层的行级、列级和表级权限，需要额外的 schema 白名单、只读账号、查询限额和个人仓库凭据。生产动作走 API 或工具接口，入参、出参、超时和错误处理更稳定，也更容易审计。
权限配在 Agent 上，还是数据平台上
数据平台和身份系统是权限事实源，Agent 做继承和收窄，两层都要配。只在 Agent 上配权限，容易出现多个 Agent 各自维护一套规则，口径和边界对不上；只靠数据平台，又管不住 Agent 能调用哪些工具、能执行什么动作。分工是，数据权限跟随身份和语义层，工具权限按 Agent 配置，审计覆盖两者。
如何避免 Agent 在群聊或共享入口泄露数据
先确认 Agent 使用提问者身份，避免使用创建者或服务账号。逐用户授权做不到时，限制可问的数据范围和输出内容，关闭不必要的导出和分享，敏感字段脱敏，并对群聊、文件、排行榜和连续追问做专项测试。权限要在查询前生效，不能等答案生成后再删。
怎么判断协作是否跑通
看五类指标，答案正确性、权限隔离、证据可追溯、失败恢复、延迟与成本。再补任务完成率和实际使用率。只统计问答次数或回答长度，会把演示效果当成生产能力。跑通的标准是，业务人员敢用，数据团队能管，出问题能定位和回退。
参考资料
- 腾讯云 DataBuddy 产品文档，访问日期 2026 年 11 月 10 日，https://cloud.tencent.com/document/product/1835/137357
- InfoQ 2026 年 8 月 AICon 深圳站演讲《从 Tool Calling 到 Data Agent：企业数据智能体的生产化路径》，https://aicon.infoq.cn/2026/shenzhen/presentation/7217
- 帆软 2026 年 11 月 6 日发布的《企业级 Data Agent 技术架构与落地实践》白皮书解读，https://www.finebi.com/ai%e6%95%b0%e6%8d%ae%e6%99%ba%e8%83%bd/%e5%b8%86%e8%bd%af%e5%8f%91%e5%b8%83%e3%80%8a%e4%bc%81%e4%b8%9a%e7%ba%a7-data-agent-%e6%8a%80%e6%9c%af%e6%9e%b6%e6%9e%84%e4%b8%8e%e8%90%bd%e5%9c%b0%e5%ae%9e%e8%b7%b5%e3%80%8b%e7%99%bd%e7%9a%ae
- ThinkingAI 2026 年 10 月 11 日发布的《Agent 中台如何让不同业务的 Agent 复用能力和数据？》，https://www.thinkingai.cn/blog/f7b91f5f4b/
- Lightdash 官方文档，Data access control，2026 年 11 月 5 日，https://docs.lightdash.com/agents/data-access
