Tukun Agent 正式上线

今天，我们正式发布 Tukun Agent。

Tukun Agent 不是传统 ChatBI，也不是一个“把大模型接到数据库上”的演示产品。我们更关心的是把 semantic、ontology 和 evidence 放回同一条分析工作流，让它真正成为一个可落地的 data agent。

它要解决的问题也很具体。

很多 AI 数据产品在第一次演示时都很好看，但一旦进入真实业务，就会遇到同一组重复出现的问题：

• 指标定义不一致，模型和人看到的“同一个词”并不是同一个意思
• 结果看起来合理，但用户不知道证据到底来自哪里
• 结论可以读，过程却不可检查，也很难复用
• 分析做完停在一次对话里，无法继续变成卡片、仪表板和团队资产

Tukun Agent 就是围绕这些问题设计的。

Tukun Agent 是什么

Tukun Agent 是一个面向受治理数据分析的 Agent 产品，也是一种我们认为更接近真实业务工作的 data agent 形态。

它的核心不是“能不能回答”，而是“能不能在业务语义明确、证据边界清楚、结果可复用的前提下回答”。这决定了它和通用聊天产品的差别，也决定了它为什么不等同于常见的 ChatBI。

在当前版本里，Tukun Agent 由五个主要部分组成：

• Workbench：唯一的执行工作台，负责对话、查询、分析、进度、产物和批判性复核
• Semantics：语义资产工作区，管理模型、指标、维度、实体、关系，以及 review / publish 流程
• Dashboards：结果沉淀区，把来源明确的分析卡片保存为可阅读、可共享的下游资产
• Skills：运行时扩展入口，用于管理可安装和可用的能力
• Console：配置与健康检查入口，不承担日常分析工作

这里有一个我们非常明确的产品原则：Workbench 是唯一执行入口。

我们不希望查询在一个地方跑，分析在另一个地方跑，卡片又有一套独立逻辑。那样会很快变成多个“看起来相似、实际上彼此不一致”的系统。Tukun Agent 选择把运行时收敛成一条路径，再把卡片、仪表板和其他结果建立在这条路径之上。

为什么要从语义开始

如果没有共享语义，Agent 很容易给出“看起来像答案”的东西，却很难稳定地给出“业务上真的成立的答案”。

所以在 Tukun Agent 里，semantic 不是附属配置，而是一等产品资产；ontology 也不是只出现在学术讨论里的词，而是业务对象、关系和含义在产品中的实际组织方式。

当前版本中：

• 语义定义存储在 PostgreSQL 元数据层，是产品 source of truth
• 发布后的 manifest 文件只是执行产物，不是定义本身
• 每次 Workbench 运行都绑定一个明确的数据源范围
• 语义定义和发布状态也按数据源隔离

这意味着，Agent 在进入执行前，先要对齐业务世界里“这个指标”“这个维度”“这个实体关系”到底指什么，也就是先对齐 semantic 和 ontology，而不是把自然语言直接硬翻成 SQL 再碰运气。

这一步不炫，但很重要。因为真正决定分析质量的，往往不是模型会不会写一句总结，而是这个 data agent 到底有没有站在正确的业务语义之上。

为什么我们强调证据边界

Tukun Agent 的第二个核心原则，是证据优先。

对很多产品来说，最容易做的是把回答写得更顺；对我们来说，更重要的是在证据不足时明确承认边界。

所以在当前产品里，用户的请求只会被清楚地落在四种结果之一：

1. 直接回答
2. 返回受治理的查询结果
3. 返回基于证据的分析结论
4. 明确指出还缺什么

这背后有一套很朴素但必要的规则：

• 用户要求按时间粒度看，就必须真的拿到对应时间粒度的证据
• 用户要求按业务维度拆解，就必须真的拿到对应拆解结果
• 如果结果被截断、粒度不对、拆解不完整，系统不能假装已经分析完成
• 如果证据只有高层汇总，就不能把它包装成强结论

换句话说，Tukun Agent 不是为了“永远都能说点什么”，而是为了“只在该说的时候说到位，不该说的时候明确停下”。

不只是回答问题，而是沉淀结果

分析工作如果只停留在一次对话里，价值很快就会衰减。

因此，Tukun Agent 从一开始就把“结果资产化”放进产品主路径里。当前版本中，Workbench 产生的结果可以继续沉淀为卡片，再进入 Dashboards 作为下游可复用资产。它们和来源 turn 保持关联，保留数据源范围和证据上下文，阅读时不要求重新执行。

这件事的意义在于，团队不需要在“灵活分析”和“稳定复用”之间二选一。

你可以先在 Workbench 里完成一次真实的查询和分析，再把其中值得保留的部分沉淀下来，交给后续讨论、汇报、跟踪和复盘继续使用。

当前上线版本包含什么

截至今天，Tukun Agent 已经在生产环境运行，当前可用能力包括：

• 基于账号作用域的产品访问与隔离
• 邮箱登录、Google / GitHub OAuth，以及 passkey 登录
• 面向单数据源的受治理查询与分析工作流
• 查询、分析、证据、产物和诊断信息的统一 Workbench 体验
• 语义定义的发现、编辑、review 与 publish 流程
• 分析结果向卡片和仪表板的下游沉淀
• 运行时技能目录与可见能力管理

这些能力的组合，已经足够支撑一条完整的数据 Agent 工作路径：从提出问题，到对齐语义，到执行查询和分析，再到把结果沉淀为可复用资产。

这次上线意味着什么

对我们来说，Tukun Agent 正式上线，不是一个“功能堆到足够多”的时间点，而是一个产品边界终于清晰的时间点。

它已经不再只是一个内部原型，也不只是一个针对单点问题的实验系统。现在的 Tukun Agent 有明确的工作台、有清晰的语义资产层、有可追溯的证据边界，也有能继续复用的结果落点。

这使它第一次成为一个可以持续演进的产品，而不是一组分散的能力演示。

接下来

接下来，我们会继续沿着同一条方向推进：

• 继续强化语义层和分析层之间的一致性
• 提高运行时可检查性，而不是隐藏内部过程
• 让更多结果可以被稳定复用，而不是一次性消费
• 在不破坏当前工作流简洁性的前提下，扩展多空间和团队场景能力

如果你关心的不是“模型还能再多回答一个问题”，而是“data agent 能不能在真实业务里长期成为可靠分析接口”，如果你也在寻找比传统 ChatBI 更可靠、能把 semantic、ontology 和 evidence 放在一起的产品路径，那么 Tukun Agent 就是我们给出的答案。

Tukun Agent，现已上线。