文章
Tukun.ai：
一个语义优先的 Data Agent
Tukun.ai 是一个语义优先的 Data Agent，围绕受治理语义、多数据源、多 LLM、运行时 Skills 和可复用分析资产构建。
在数据分析场景里，自然语言和结构化数据之间长期存在一条断层。
业务问题通常来自自然语言：增长为什么放缓？某个指标为什么波动？不同渠道的表现有什么差异？
真正执行分析时，系统又必须回到结构化世界：数据源、表、字段、指标口径、时间粒度、过滤条件、权限边界、结果复用。
Tukun.ai 想解决的，就是这两层之间的衔接问题。
一句话概括：
Tukun.ai is a semantic-first data agent.
它不是简单的 ChatBI 问答工具，而是一套围绕语义、数据源、模型、技能和分析资产构建的 Data Agent Harness。
为什么是 semantic-first
Data Agent 的难点不只是“把问题翻译成 SQL”。
在真实业务里，同一个指标可能有多个口径，同一个维度可能来自不同数据源，同一个分析问题也可能对应不同的时间粒度和业务边界。如果语义没有先被管理起来，后续再强的模型也很容易把问题答偏。
所以 Tukun.ai 的设计顺序是：
- 先管理业务语义
- 再接入数据源
- 再让 Agent 调度模型和工具
- 最后把分析结果沉淀成可复用资产
在这个流程里，指标、维度、实体、关系不是临时 prompt 里的描述，而是产品里可管理、可发布、可追踪的对象。
产品结构
Tukun.ai 由几层能力组成：
| 层级 | 作用 |
|---|---|
| 语义层 | 管理指标、维度、实体、关系和业务口径 |
| 数据层 | 接入 PostgreSQL、文件和其他业务数据源，并同步元数据 |
| 模型层 | 支持多 LLM 按任务切换，不绑定单一 provider |
| 语言层 | 支持多语言使用和输出，让语言能力进入运行时上下文 |
| 技能层 | 通过 Skills 扩展重复性的分析流程和业务能力 |
| 工作台 | 承接提问、分析、审核、追问和结果复用 |
| 资产层 | 将卡片、图表、仪表板、技能和语义定义持续沉淀 |
这个结构的核心目标很简单：让分析结果不止停留在一次回答里，而是可以继续追问、复用和演进。
一套完整的 Data Agent Harness
Tukun.ai 的核心不是某一个页面，而是一套分析运行时。
一轮用户请求进入系统后，运行时会负责：
- 识别当前请求的意图
- 组装 prompt 和上下文
- 选择可用工具和 Skills
- 调度合适的模型
- 执行语义查询或分析工具
- 将结果整理成前端可展示、可复用的结构
这个设计让产品层不需要把业务逻辑散落在页面里。工作台、语义管理、技能扩展和结果沉淀都围绕同一个运行时展开。
语义工作流
Tukun.ai 会把数据源同步进来的元数据作为起点，再结合 LLM 生成符合 MetricFlow 结构的语义草稿。
这个过程不是完全自动发布，而是默认经过人工确认。系统负责提高初始建模效率，人负责确认业务口径。
这种方式适合真实的数据团队：
- 元数据可以自动进入系统
- 语义草稿可以由 LLM 辅助生成
- 指标、维度、实体和关系可以继续编辑
- 发布状态和历史版本可以被追踪
最终目标不是让模型临时猜口径，而是让 Agent 在一个更稳定的语义层上执行分析。
多数据源支持
企业里的数据通常不会只存在于一个地方。
一部分在数据库里，一部分在文件里，还有一部分来自业务系统或 API。Tukun.ai 从一开始就按多数据源设计，让不同来源的数据可以进入统一的分析入口。
在当前架构里，语义资产和分析上下文会跟随 data_source_id 作用域隔离。这样可以避免不同数据源之间的指标口径混用，也方便后续做数据源级别的治理和复用。
多 LLM 支持
不同模型适合不同任务。
有的模型更适合推理，有的模型更适合工具调用，有的模型更适合成本控制，也有模型在特定语言场景下表现更稳定。
Tukun.ai 把模型设计成可配置、可治理的一层能力：
- 支持不同 provider
- 支持不同模型
- 支持按套餐控制可用模型
- 支持默认模型和模型偏好配置
- 支持配置变更后刷新运行时
这对商业化产品很重要。多模型不只是调用接口的问题，还涉及计费、账户、额度、缓存输入、输出和推理输出等细节。
Prompt Cache 友好的上下文设计
为了降低长期使用成本，Tukun.ai 在 prompt assembly 上采用了分层设计：
- Base System Prompt
- Core Runtime Rules
- Response Contract
- Evidence Rules
- Shared Memory
- Skill Prompts / Skill References
- Recent Turns
- Turn Context
这些上下文会被区分为 stable、semistable 和 volatile。
稳定内容尽量固定，半稳定内容按能力和任务变化，易变内容则保留在当前 turn 上。这样更容易利用 provider 的 Prompt Cache 机制，也能让高频分析场景的成本更可控。
多语言运行时
多语言不是简单的界面翻译。
对于 Data Agent 来说，语言会影响用户提问、工具输出、错误提示、分析结论和后续建议。Tukun.ai 会将 requested_locale 写入运行时上下文，让 prompt 组装和工具输出跟随语言环境处理。
目前 Tukun.ai 已围绕中文、英文和日语打磨多语言架构。后续扩展更多语言时，重点不是重新改业务逻辑，而是补齐对应的文案和语言配置。
Skills 扩展
除了内置分析能力，Tukun.ai 也支持通过 Skills 扩展重复性的工作流。
例如：
- 特定行业的分析模板
- 基于固定模版生成报告
- 基于数据结果生成 PPT
- 团队内部沉淀的分析方法
- 特定数据处理和解释流程
Skills 会作为运行时能力包参与 prompt 和工具上下文，而不是只作为界面上的快捷按钮。
和传统 BI / 通用聊天助手的区别
| 对比项 | 传统 BI | 通用聊天助手 | Tukun.ai |
|---|---|---|---|
| 入口 | 看板 / 报表 | 对话框 | 语义 + 工作台 |
| 语义管理 | 往往分散 | 基本没有 | 内置 |
| 数据接入 | 有，但偏配置 | 弱 | 直接进入分析工作流 |
| 分析过程 | 偏固定 | 偏临时 | 可追问、可审核、可复用 |
| 结果沉淀 | 看板为主 | 依赖上下文记忆 | 卡片、图表、仪表板和语义资产 |
Tukun.ai 的目标不是替代所有 BI，也不是做一个通用聊天入口。
它更关注一件事：让数据分析从自然语言问题开始，经过语义约束和工具执行，最终沉淀成可以继续使用的分析资产。
当前阶段
Tukun.ai 目前已经完成核心框架：
- Data Agent Harness
- semantic-first 工作流
- 多数据源接入
- 多 LLM 配置
- Prompt Cache 友好的上下文分层
- 多语言运行时
- Skills 扩展
- 工作台和结果资产化
接下来，产品会继续围绕真实数据分析场景迭代：让语义建模更稳，让分析链路更清晰，让结果复用更自然。
Data Agent 的关键不是让模型看起来更会聊天，而是让分析过程变得更可靠、更可控、更可积累。
这是 Tukun.ai 的方向。