「AI 行业一直在教企业买更聪明的模型，可模型再聪明，也推理不出你家对收入的定义。」10 月 15 日，做语义层起家的 AtScale 把这条判断做成了产品：AtScale for AI 套件发布，四件套覆盖语义模型构建、指标对齐、治理计算与结果复核。发布方自己的案例读数相当抓人：HSBC 在给 AI 智能体垫了这层语义底座之后，确定性分析的准确率从 65% 提到 99% 以上——测量对象是 Google Cloud 上一张 10TB 的表。
四件套的分工值得逐件看。CoModel 用 AI 创建并维护语义模型，所有改动需人工审；Ava（Ask, Verify, Answer）负责在计算开始前，把自然语言问题对上受治理的指标——「收入」指订单额、确认收入还是合同价值，先问清；ACE 计算引擎按治理定义与计算逻辑取数，保证智能体、应用和分析工具拿到一致的结果；Canary 拿验证过的结果给 AI 回答打分，框架基于 BIRD-Interact 基准加上客户自己的问答对，持续盯回归。节奏上，Ava 与 ACE 现已可用，CoModel 与 Canary 标注为即将推出。
这层治的是什么病
把 65% 到 99% 读对了，先要看清它的口径：确定性分析，不是开放式生成。同一个「上季度收入」问题，人问 BI、智能体问数、报表系统各算一套，答案对不上——病根不在算力，在定义。企业里「收入」至少有三种约定，配上报告期、币种、合并口径，组合出来十几个变体。提示词工程治不了这个病，因为定义不在提示词里，在组织的共识里，且共识会随业务变化。
AtScale 的解法是把定义变成可治理资产：模型可以提议改语义模型，但改动要过人审；计算前先对齐指标，计算中按治理逻辑执行，计算后拿金标准复核。这套流程对企业数据团队不新鲜——BI 时代就有语义层、指标平台——新鲜的是它明确把「智能体」列为服务对象：同一个定义层，人用的仪表板和 agent 用的取数接口，吃同一套逻辑。家乐福的数据与分析总监在发布稿里说的就是这个状态：语义层已管着数千个 KPI，希望智能体用的定义跟分析师、BI 工具一致。
放进台谱里看
语义层这条线，站点今年断断续续记了不少。Hang Ten 的 Xora Hobie（1040）主打免迁移接入；Stibo 的 AgentWorkx（1460）从主数据治理侧做「受治理的智能体」；OpenAI 的数据智能体（766）证明「对话问数」是企业最愿意买单的 agent 形态之一。AtScale 的不同在于它把「治理」做成了套件而不是单点：定义、对齐、计算、复核四件齐活，且直接拿银行客户的可追问读数说话。
把它和同周的 Scuba（1956）并读很有意思：Scuba 管「这家公司知道什么」，AtScale 管「这家公司怎么定义」。上下文的两半——事实与定义——同一周都被做成了产品。这不是巧合，是智能体进企业核心流程时撞上的同一堵墙：墙后面不是模型能力，是组织知识。
几盆该浇的冷水
先泼口径：65% 到 99% 出自单一银行的确定性分析场景，10TB 单表，换到开放式生成、多源异构的场景，读数不能直接外推。厂商另测的「七个模型在 BIRD-Interact 上全部改善」同样由自家实施，尚未见独立第三方复核，10 月 28 日安排了结果网络研讨会。其次，四件套里两件「即将推出」，现在的可采购版本只覆盖了对齐与计算。再者，语义层的建设成本是真实的——模型能提议改定义，但定义的对错最终靠人审，这套流程对数据团队的要求不降反升。
给数据团队一个可落地的判断：如果智能体已经开始碰你的指标口径，先别急着换模型，把「收入有几种算法」列成一张表。列得出来，AtScale 这类产品的价值就在那张表上；列不出来，问题比工具更靠前。