>
企业真正需要的，通常不是让 AI 回答一次“销售额是多少”，而是让可信数据继续进入经营复盘、归因分析、报告生成、异常预警和后续协同。
这需要两类能力配合：Data Agent 负责按照企业已经确认的业务语义取得可信数据；Skill 负责把分析步骤、判断规则、工具调用和交付标准组织成可复用的工作流。
两者结合后，企业得到的不只是一个更方便的问数入口，而是一套可以持续复用的数据生产力。
假设经营负责人看到一条提示：“本月销售额同比下降 8%。”
这通常不是任务的终点，而是后续工作的起点：
如果每个环节都要重新找表、写 SQL、核对口径和复制结果，AI 只是把其中某一步变快了，并没有真正缩短完整工作链路。
所以，“从问数到数据生产力”要解决的是两个连续问题：
| 能力 | 要回答的问题 | 主要职责 |
|---|---|---|
| DataAgent | 数据从哪里来，这个数字能不能信？ | 理解业务问题，按企业语义和权限完成查询与分析 |
| Skill | 拿到数据以后，应该按什么方法继续工作？ | 组织步骤、规则、工具、判断条件、模板与验收标准 |
用户问：“去年每月销售额趋势怎么样？”
SQL 本身可能并不复杂，真正影响答案的是问题背后的企业定义：
这些知识通常不会完整写在表名和字段名里，也不适合由模型每次临场猜测。
可信问数需要完成一条更长的语义链：
自然语言问题 → 业务意图 → 指标、维度、筛选条件与时间口径 → 企业语义模型 → 可执行查询 → 可复核结果
SQL 或 API 是这条链路末端的执行方式，不是业务含义的起点。
企业问数长期存在两种常见路线。
确定性语义或知识图谱路线，可以提前定义指标、对象、关系和规则，结果更稳定、也更容易解释；但真实业务语言具有口语化、上下文依赖和长尾表达，仅靠预设结构很难覆盖所有说法。
纯 NL2SQL 路线擅长理解不同表达，也能根据 Schema 生成复杂 SQL；但模型自由度越高，越容易出现字段选错、Join 重复、指标口径变化或查询结果无法复核等问题。
| 路线 | 擅长解决 | 主要边界 |
|---|---|---|
| 知识图谱 / 确定性语义 | 固化业务定义、关系和执行约束 | 长尾表达与上下文理解需要额外处理 |
| 纯 NL2SQL | 理解灵活表达并生成查询 | 业务口径与生成过程不容易稳定约束 |
| Data Agent双层语义架构 | 让语言理解与确定性企业语义分工 | 需要持续建设语义模型、测试和治理机制 |
Data Agent 的关键不是在两条路线之间取平均值，而是重新划分职责：让模型处理它擅长的语言理解，让经过治理的企业语义拥有业务解释权。
在亿问 Data Agent 的技术架构中，SemanticDB、Alisa 与 LogicForm 共同组成可信问数链路：
自然语言问题 → Alisa 在 SemanticDB 的企业语义与业务知识图谱约束下理解问题 → 收敛为结构化 LogicForm → SemanticDB 将 LogicForm 映射为 SQL、API 或相应执行路径 → 返回可执行、可校验、可追溯的结果
三者职责不同：
| 组件 | 主要作用 | 对可信问数的价值 |
|---|---|---|
| SemanticDB | 承载对象、事件、关系、指标、时间、状态和业务规则等企业语义 | 让同一业务概念拥有稳定定义和数据映射 |
| Alisa | 在企业语义和关系约束中定位、校验并收敛用户意图 | 避免只根据字段名称自由猜测查询含义 |
| LogicForm | 结构化表达查询对象、指标、条件、时间、分组、排序和分析逻辑 | 让自然语言与执行语句之间保留可检查的中间层 |
当问题存在歧义时，更可靠的处理不是强行生成一个答案，而是识别候选含义、结合上下文进一步澄清。例如，“活跃客户”可能指近 30 天有支付订单，也可能指近 30 天登录过系统。系统应先确认企业采用哪一种定义，再继续执行。
这条链路并不意味着系统永远不会出错。它的价值在于让错误更容易定位：问题可能出在语言理解、指标映射、语义模型、权限配置、数据更新或执行阶段，而不是只留下一个难以解释的最终数字。
DataAgent 解决了“怎样可靠地取得数据”，但企业工作通常还包含固定步骤、判断条件和交付要求。这些内容适合通过 Agent Skill 封装。
一个月度销售复盘 Skill 可以规定：
在这个过程中，DataAgent 与 Skill 的分工是：
Skill：定义分析方法、调用顺序、判断边界和交付标准 ↓ DataAgent：按企业语义和用户权限提供查询、对比与分析结果 ↓ Skill：核验结果并继续生成报告、PPT、看板、预警或待办
如果把 SQL 直接写进每个 Skill，底层表结构或字段一旦变化，多个工作流都可能同时失效；同一指标也容易出现多份实现。
让 Skill 使用 DataAgent 提供的业务问数能力后，Skill 只需描述“需要什么数据、怎样分析、输出什么”，物理数据映射和指标规则仍在语义层集中维护。
月报 Skill、经营分析 Skill、PPT Skill、看板 Skill 和库存预警 Skill 查询“销售额”时，可以复用同一套指标定义、对象关系、时间口径和用户权限，而不是因为作者和提示词不同，各自形成一套答案。
从“查询销售数据”扩展到“生成月度经营复盘”，新增的重点是分析步骤、判断规则、交付模板和质量检查，而不是为每个场景重新建设一套数据接口。
业务 Skill 可以由人工请求触发，也可以按照企业设置的定时任务或指标事件进入执行流程。数据结果随后可以进入报告、PPT、看板、消息推送或异常处理。
但“可以编排”不等于“所有行动都应自动执行”。查看和生成类任务可以采用较高自动化程度；发送通知、修改业务数据、触发采购或影响外部系统的动作，仍应根据风险设置人工确认、权限和审计。
下面是一条完整但简化的月度经营复盘链路：
用户或定时任务发起复盘 → Skill 确认时间、组织和指标范围 → DataAgent 按统一口径查询核心指标 → 对比同比、环比与目标差异 → 按区域、产品、渠道和客户计算贡献 → Skill 根据阈值判断是否继续下钻 → 区分数据事实、统计归因与业务判断 → 按模板形成报告或汇报材料 → 高风险外部动作交由用户确认
这里最重要的不是“调用了多少工具”，而是每一层都有清晰责任：
Data Agent 与 Skill 并不要求所有工作都发生在同一个产品页面中。
目前，可以在 WorkBuddy / Codex 等支持 MCP 的工具中直接调用亿问的问数能力，无需切换回系统页面，也能查询业务数据并继续追问和分析。具体的外部 Agent 落地方式是：
WorkBuddy / Codex 中的任务或 Skill → 通过 YiAsk MCP 调用 ask_data → DataAgent 按企业语义、空间和用户权限完成问数 → 结果返回 WorkBuddy / Codex → 宿主 Agent 或 Skill 继续完成分析、文档或其他任务
这条链路中，MCP、DataAgent 和 Skill 仍然各司其职：
因此，YiAsk MCP 的价值不是让 WorkBuddy 或 Codex 绕过治理直接访问数据库，而是让已经建设好的企业语义与问数能力进入更多工作入口。
当可信问数被多个 Skill 和 Agent 复用后，企业可以形成四层能力结构：
应用与交付层：报告、PPT、看板、推送、告警 ↓ Skill 工作流层：分析方法、SOP、模板、判断规则、质量标准 ↓ DataAgent 可信数据层：企业语义、问数、归因、权限与治理 ↓ 企业数据与系统层：数仓、数据库、API 与业务系统
这套结构带来的核心价值是复用：
企业由此沉淀的不只是若干问答记录，而是可以持续维护、组合和扩展的数据能力。
“DataAgent + Skill”不会自动消除所有风险。要进入企业生产，至少需要明确以下机制：
可信不是一句产品标签，而是从语义定义、查询执行、工作流编排到最终行动的完整证据链。
NL2SQL 主要解决自然语言怎样转为 SQL。DataAgent 进一步用企业语义约束指标、对象关系、时间和权限；Skill 则定义取得数据之后的分析步骤、判断规则和交付方式。三者解决的问题层次不同。
DataAgent 可以可靠地回答企业数据问题，但不会替所有团队定义月报结构、归因顺序、异常阈值和审批流程。Skill 用来封装这些可复用的工作方法。
不一定。如果已有受控的 DataAgent 问数能力，Skill 更适合使用业务语言表达数据需求，把 SQL、指标映射和底层数据变化留给统一的数据语义层处理。
不能这样承诺。可完成范围取决于数据源、语义模型、指标覆盖、Skill 规则、宿主工具和用户权限。涉及因果判断、高风险决策或外部系统写入时，仍需要人工确认和审计。
YiAsk MCP 负责把亿问问数能力连接到 WorkBuddy、Codex 等支持 MCP 的外部 Agent。企业语义和数据查询仍由 DataAgent 承接，后续工作由宿主 Agent 或 Skill 组织。
企业需要的不是更多 SQL，而是更低成本、更高可信地把数据转化为判断和行动。
Data Agent 让自然语言问题沿企业已经确认的语义与权限执行，解决“数据从哪里来、这个数字能不能信”；Skill 把分析方法、判断条件、工具调用和交付标准封装成工作流，解决“拿到数字以后，企业下一步怎样做”。
YiAsk MCP 则提供了一条新的连接路径，让这套可信问数能力可以进入 WorkBuddy 和 Codex 等外部 Agent。连接扩大了使用入口，但真正让数据持续产生价值的，仍然是可信数据能力与可复用工作方法的结合。