分析 Agent 算出“新增用户 12 万”，经营看板却显示 10.8 万。两边都能解释自己的 SQL，也都声称使用了最新数据。此时团队面对的并不是一次问答错误，而是一个更根本的问题：Agent 和传统数据产品是否建立在同一套资产、语义和权限之上？
这正是 DataBuddy 架构里最值得研究的部分。它表面上提供数据工程、数据分析和数据治理三类 Agent，底层设计却不是给三个聊天入口分别接工具，而是把数据接入、湖仓、Catalog、统一语义和 AI-Ready 知识组织成一条共享主链，再用 Agent Harness 把上下文、工具、安全和评估接起来。
如果只关注“三个 Agent 能做什么”，很容易错过这个产品真正的架构主张：先把数据平台改造成 Agent 可以理解、调用和约束的系统，再让 Agent 参与生产。
先读懂官方架构图
这张图可以沿两个方向阅读。
纵向是一条数据主链：多模态数据接入后进入湖仓和资产管理体系，经 Catalog、统一语义与知识加工，最终由 Agent 或看板消费。横向是两组贯穿能力：Agent Harness 负责上下文、记忆、工具、安全和评估，数据治理 Agent 则让标准、质量、元数据和权限不再只是后台配置。
图的上半部分是业务交付，中间是能力平台，底部是引擎与存储。它们不是三个彼此独立的产品层，而是同一次任务的不同责任边界。
数据主链：从“能接入”到“能被 Agent 正确使用”
企业数据通常散在数据库、消息系统、文件、日志和业务应用里。把数据同步到湖仓，只解决了可访问性，并没有解决可理解性。Agent 还需要知道表之间如何关联、字段代表什么、哪个指标定义被批准、某项资产是否新鲜，以及当前用户能否使用它。
DataBuddy 把这条加工链连续画出来：多模态集成、资产管理、统一语义、AI-Ready 数据知识，再到 Agent 与看板。这里的顺序很重要。
所谓 AI-Ready，不应该被理解为“把文档转成向量”这么简单。对数据任务而言，它至少包括四类对象：
- 结构知识：表、字段、血缘、分区、数据质量和更新状态；
- 业务知识：指标、维度、实体关系、同义词和适用范围；
- 执行知识：可信查询、工具参数、工作流和失败处理；
- 治理知识：所有者、权限、敏感级别、用途与审计要求。
只有这些对象能被检索、引用并约束执行，Agent 才不是在一堆 Schema 名称上猜答案。
TC Catalog 与统一语义：让 Agent 和看板说同一种业务语言
架构图把 TC Catalog 放在数据资产的中枢位置，并让 Unity Semantics 同时向 Agent 和 BI 看板提供业务语义。这个设计直接回应了开头的数字冲突：如果对话分析使用一套临时生成的口径，而看板使用另一套固化指标，Agent 越灵活，组织里的数字反而越多。
共享语义并不意味着把所有查询都固化。更合理的分工是：指标、实体、Join 路径和权限由语义层提供稳定边界；Agent 在边界内选择分析步骤、生成查询并解释结果。对于尚未纳入语义层的探索性问题，系统应把临时假设显式告诉用户，而不是伪装成组织标准。
评估这部分能力时，不能只问“支持多少数据源”。更值得验证的是：修改一个指标定义后，Agent 与看板是否同时生效；一个实体跨多个系统时，身份是否能统一；语义版本变更后，历史报告能否说明当时使用的定义。
Agent Harness：把模型接入变成可运行的系统
腾讯云当前的 Buddy 说明把 Buddy 定义为平台内统一的 AI 入口，并将不同页面的能力封装为可调用的 Skills。架构图中的 Harness 则更接近这套 Agent 运行时的底座：它连接知识与上下文、记忆、领域 Skills、工具、安全和评估。
可以用一次“定位新增用户下滑原因”的请求来观察这条链路：
- Buddy 获取当前页面、用户身份和业务域上下文；
- 从 Catalog 与语义层找到新增用户指标、相关资产和可信 Join；
- 规划器将问题拆成复算、分群、漏斗定位和异常核查；
- 数据分析 Skill 调用查询与 Python 工具，在用户权限范围内执行；
- 验证环节检查分组是否能与整体对账、数据是否延迟；
- 结果被组织为可追溯的结论，并能继续下钻或转成看板。
这条链上任何一环缺失，都会出现熟悉的问题：拿错口径、越权读数、生成昂贵查询、用过期数据解释波动，或给出无法复现的“原因”。因此 Harness 的价值不在于包装一次模型调用，而在于管理长期运行所需的状态、契约和控制。
三类 Agent 为什么应该共用底座
数据工程、数据分析和数据治理在产品界面上可以分开，但在真实工作里高度耦合。
分析 Agent 发现某个字段连续三天异常，可能需要治理 Agent 创建质量规则，再由工程 Agent 修复链路或调整任务。工程 Agent 生成的数据模型，需要进入 Catalog 和语义层，分析 Agent 才能安全复用。治理 Agent 如果看不到真实查询与任务上下文，也很难判断哪项质量问题优先级最高。
共用底座的意义，是让一次工作产生的资产能被下一次工作消费，而不是在三个对话窗口之间复制粘贴。这个闭环是否成立，比每个 Agent 单独演示多少功能更重要。
安全能力需要在真实任务里验证
官方架构资料将用户身份绑定执行、输入输出护栏和高风险 SQL 控制列为 Harness 的安全机制。它们是合理的设计方向，但采购或试点时不能把文档描述等同于已经验证的效果。
可以故意设计几类冲突任务：让无权限用户追问敏感明细，让 Agent 在汇总结果之后尝试下钻，让查询触发大范围扫描，或在同一会话里切换数据域。观察系统是在计划阶段阻止、工具阶段拒绝，还是执行后才过滤；同时检查 Trace 是否保留了身份、策略、SQL、审批和最终输出。
对于高危 SQL，“弹窗确认”也不一定够。审批者需要看到影响范围、数据对象、估算成本和回滚方案，才能做出有信息的决定。
一套更接近生产的 POC
产品功能文档会持续更新能力清单，因此 POC 最好围绕稳定的业务任务，而不是逐项对照演示菜单。可以选择一条有历史问题的数据链，安排四组测试：
| 测试 | 任务设计 | 通过标准 |
|---|---|---|
| 语义一致性 | 同一指标分别由 Agent 和看板计算，再修改一次定义 | 两端使用同一版本，历史结果可追溯 |
| 跨角色闭环 | 分析发现异常，治理创建规则，工程修复任务 | 上下文与资产在角色间复用，不靠人工搬运 |
| 权限与风险 | 越权下钻、敏感字段、大扫描和高危 SQL | 身份贯穿工具调用，阻断与审批均有审计 |
| 可恢复性 | 注入数据延迟、Schema 变化和工具超时 | 系统能定位失败、停止错误结论并给出恢复路径 |
最后还要核对架构图与当前交付状态。产品页面和文档在持续演进，架构中的规划项、预览能力和正式可用能力不能混为一谈。与其追求一次“无所不能”的演示，不如确认这套共享底座能否让工程、分析和治理在同一套语义、身份和证据上工作——那才决定 Data Agent 能不能从展示走进生产。