业务同事在对话框里问一句“上个月华东的净收入是多少”，最省事的做法是让大模型现场写一条 SQL，去业务库里跑一遍，把结果念出来。这条 SQL 里，退款扣不扣、华东算哪几个省、按下单时间还是付款时间切月份，全由模型当场决定。换一个人问，或者同一个人换个说法再问，模型写出另一条 SQL，数就可能对不上。

报给财务的数，最怕被追问一句“这个净收入是怎么算的”而答不上来。这种时候，有数比没数还麻烦。

KnowWork 商业版的智能问数这一版（v0.0.7）把活分成两半。起草语义模型、回答问题，交给跑在 DeepSeek Harness 上的智能体；口径、SQL 和权限由业务服务定死，智能体改不了。每个数都要能说清它是哪个指标、哪段时间、按什么规则、语义模型第几版、实际执行了哪条 SQL，说不清的数不给，查不了的问题明说查不了。下面按一个数从定义到被人看到的顺序，讲每一步为什么这样做。

每个数都要能追回到口径和那条 SQL。追不回来的数，宁可不给。

智能体跑在 DeepSeek Harness 上，口径定在语义模型里

问数分三层。最底下是业务库，目前接 PostgreSQL 和 MySQL。中间一层是语义模型，把表写成数据集，把列写成字段，再把“净收入”“订单数”这些指标的算法定下来，包括指标自带的过滤、按哪个时间字段算、默认看多长时间。语义模型、SQL 的编译和执行都在 KnowWork 业务服务里。最上面是智能体，跑在 DeepSeek Harness 上。

智能体跑在 DeepSeek Harness 上，AI 起草、建模助手、问数都是它在做；语义模型和 SQL 的编译执行在 KnowWork 业务服务里，库的密码只在执行这一层解开

DeepSeek Harness 负责让智能体一步步调工具，看了结果再决定下一步。它还带着几样现成的能力，比如拿不准时给用户出一道选择题，写入之前等人批准，问数都用上了。KnowWork 在它上面登记了三种回答方式，AI 起草、建模助手和问数。每种回答方式由一份技能说明、这一轮的数据范围和放行的工具组成，智能体在问数方式里只能用查数的工具，在 AI 起草方式里只能读模型。

智能体调的每个工具都回到业务服务里执行。运行时带着短期令牌回调业务服务，数据库只读账号的密码加密存在业务服务里，只在执行查询的那一层解开，智能体这一侧拿不到。

智能体问数时，只说“要哪个指标、按什么分组、过滤哪些值、看哪段时间”，SQL 由服务端按语义模型编译。“净收入”在模型里只定义一次，谁来问、怎么问，编出来的都是同一个算法。智能体负责挑指标，算法写在语义模型里，它改不动。

编译这一步还管住了一类更隐蔽的错。订单表连上明细表再求和，每张订单被明细的行数复制一遍，金额就翻了几倍，SQL 本身没有任何语法错误。我们的编译器只沿“多对一”的关系连表，算指标的那张表一行都不会被复制。一次要的几个指标分属不同的表时，每张表先各自汇总，再按分组合起来。

语义模型由智能体起草，人批准了才改

语义模型从哪来，是上线前最费人的一步。私有化部署的库，外键约束经常一个都没有，有的是为了导数据快删掉了，有的是迁移时丢了，数仓那一层本来就不建。只认约束的话，模型就是一堆互不相连的表。所以添加数据源、勾好白名单以后，系统先扫描每张表的行数、每列的空值和常见取值，顺带读数据库记下的常跑查询，按规则起草第一版模型，自动发布成第 1 版，当天就能问。表和表怎么连，从外键、列名和历史查询里的连接条件三处找候选，每一条都在库上核对过数据才收进来，比如一端那一列确实不重复、多端的取值在一端都找得到。

规则只搭得出架子，中文名、业务说明、常用指标要靠智能体补。第 1 版发布后，后台按“AI 起草”方式逐张表问 DeepSeek Harness 上的智能体，一张表开一个对话，库再大也不会把上下文撑满。这个方式里智能体只能读模型，改法写成结构化的结果交回，系统核对过再收，收齐以后一次发布成新的一版。它只补人还没写的地方，人改过的中文名和说明不会被盖掉。它建议的关联同样要在库上核对过才收，智能体可以提关联，能不能连由库里的数据说了算。

AI 起草在后台跑完，补了 29 个中文名、29 段说明，建议了 7 个指标，发布成第 4 版，不满意可以回到上一版

之后在指标页右栏和建模助手对话，接着改口径。编码代表什么、退款按退款日期还是原订单日期归期，这类拿不准的事，它用 DeepSeek Harness 自带的提问工具让人选，不替人定。真要改的时候，它先把改动列成清单给人看，提交走 DeepSeek Harness 的审批，人批准了才发布。每次发布都是一个新版本，发布前能看到改了哪些地方，改坏了可以回到任何一版。指标这一版也补全了财务常用的几类，上年同期、上月同期、累计、近 N 期，还有由别的指标算出来的派生指标，比如退款额除以订单数。

一个问题，智能体分几步查

用户在输入框里 @ 一个数据源，或者把回答方式切到“问数”，就可以开始问。每一轮，智能体先拿到数据范围，里面有指标、数据集、字段和筛选条件，有建模时写好的问数说明，还有和这一问相近的可信查询。分几步查由它自己定，每一步调了什么工具、用了几秒，回答上方都能展开看。

问“上个月各商品的成交金额排名”，智能体按指标查了一次，再把这次的结果交给卡片，回答里的数都出自下面这张图

能用指标回答的，它调按指标查的工具，交出指标、分组、过滤和时间。要看具体是哪几单，调明细查询。问“为什么跌了”“增长主要来自哪里”，调归因。回答里的每个数，都要出自它亮出来的那次查询。查出来是空的，就把这次空结果亮出来，不拿别的结果顶替。

问题本身说不清的时候，它停下来问。“上个月的大单有多少笔”，模型里没有“大单”的定义，智能体用 DeepSeek Harness 的提问工具出了一道选择题，列出 5000、10000、20000 元三档，也可以自己填，用户选完它接着查。

模型里没有“大单”的定义，智能体停下来问按多少金额算，用户选完接着查

问题里的说法还要对上库里的写法。“华东”在库里可能存的是“华东区”，也可能是一串地区编码。字段上打开取值检索后，系统在每次发问前，按问题去库里找相近的取值，把候选交给智能体，它再用库里真实存在的值去过滤。

一个问题进来，先对上数据源和库里的取值，按指标查的由服务端编译 SQL，指标覆盖不到的写受控 SQL，执行前过只读、预估行数、超时三道关，查不了就给出原因和能查的问法

指标覆盖不到的问题，智能体可以自己写 SQL，这条 SQL 要过一道审。只许一条 SELECT，表名只能是语义模型里的数据集名，写入、改表、多条语句、系统表一律拒绝。审过的 SQL 一个字不改。系统在它前面加一段受控的子查询，每个数据集只露出语义模型里登记过的字段，没登记的列模型碰不到。

执行时还有三道关。查询在只读事务里跑；执行前先看数据库给的查询计划，估出来的行数超过上限直接拦下，不让一条写坏的 SQL 拖垮生产库；每条语句有超时。同样的查询在十分钟内再问一次，直接用上次的结果，口径里写明这是几点查的。

问题在这个数据源里确实查不了，比如库里压根没有成本数据，智能体会明说查不了，写出原因，再给几条换个问法就能查的问题。运行记录把这一轮记成没答上来，管理员回头能筛出这类问题，看缺的是哪块数据。

数出来以后还能接着问

回答由一句文字结论和一张结果卡片组成。卡片按结果的形状画柱状、折线、面积或饼图，可以切回表格。卡片下方写着口径，点开能看到用了哪个指标、时间区间、指标自带的规则、语义模型第几版，以及实际执行的那条 SQL。

演示库里“成交金额”的口径展开，写明只算已支付订单、不含取消和退款，时间区间、规则、语义模型第 13 版和实际执行的 SQL 都在

很多追问其实只是改个条件。卡片上点“改条件”，直接改时间、加过滤，写 SQL 查的就改那条 SQL，改完按新的条件就地重查，不用重新组织一句话。

在卡片上改时间和过滤，按新的条件重查一次，回答里的结论还是按原来的条件写的

看到某一项想细看，点图上那根柱子就能往下钻。系统按这个值过滤，再按你选的字段重新分组查一遍，比如在“台式工作站”上按销售渠道往下看，看完点“返回上一步”。下钻没有预先定好的层级，指标能按哪些字段分组，就能往哪钻。

点“台式工作站”那根柱子，选按销售渠道往下看，卡片就地换成三个渠道各卖了多少，左上角可以返回上一步

“为什么跌了”这类问题交给归因。问“10 月的成交金额比 9 月少了，主要是哪个销售渠道带来的变化”，智能体调归因，给出指标、两段时间和要拆的字段。系统把两段时间各查一次，按分组相减排序，每组给出基期、本期、变化、两期各占合计的份额和增长率。这一步在服务端算，不经过大模型。

10 月比 9 月少了约 13 万，企业采购少了约 16 万，线上商城多了约 10 万，占比一列是每个渠道在两期各占合计多少

占比这一列是 11 月 5 日改的。原来那一列算每组“占总变化的比例”，演示时总数只变了 0.35%，这一列算出了 1148%，没人看得懂。换成每组在两期各占合计多少以后，数永远在 0 到 100% 之间，谁变大了一眼看得出来。

分享看板，只分享问法

查对了的结果可以加到看板上。看板存的是那次查询，不存结果。每次打开，每张卡片按语义模型的当前版本重新查；“上个月”这种说法，可以选择跟着日子往后走。

销售看板上的四张卡片都是从问数的回答里加过来的，打开时重新查，三张按“上个月”跟着日子走，今年的走势固定在 1 月到 11 月

看板分享出去的是问法。数按看的人自己的权限重新查。

权限分两层。资源授权决定一个人能不能用这个数据源。数据源里每张表还可以设行规则和列规则，比如订单表按渠道分行，折扣列只给综合管理部看。

行规则包在数据源最外面，聚合和连表都发生在过滤之后，连进来的表同样过滤。看不见的列和用到它的指标，直接从这个人那份语义模型里拿掉。问到这些，回答和“不存在”一样。智能体替谁写 SQL，就只能在谁看得见的范围里查。看板上的卡片也按看的人的规则查。用不了那个数据源的人，卡片上只看到没有权限，标题也不显示，因为标题就是问法。

改了模型，怎么知道没改坏

语义模型会一直改，加指标、改说明、调关联。改完以后，以前答对的问题还答不答得对，要有个说法。

问得好的回答可以存为可信查询，写下问法，连同这次的查法一起发布。可信查询有两个用处。智能体回答新问题时，按问法找出相近的可信查询参考它的查法；它也能被设成新对话下方的示例问题。

这次评测考的是语义模型第 13 版，3 道题都答对，逐题写着判定和用时，可以打开对话看查法

评测拿可信查询当考题。每道题新开一个对话，让同一个智能体按“问数”重新问一遍，走的是用户提问时的同一套流程。考这道题时，这条可信查询对智能体是隐藏的，免得它直接抄答案。标准答案由可信查询自己的查法在同一个库上现跑出来，再和回答里展示的结果逐行比对，判定不调大模型。报告给出答对几道、和上一次相比哪几道退步了、平均用了多久。

怎么开通

智能问数在 KnowWork 商业版里，要和内置知识库一起开通，可信查询的召回、取值检索都用知识库的检索引擎。数据源建议给一个只读账号，测试连接时会检查 PostgreSQL 账号是不是只读。

这一篇按一个数的生命周期走了一遍。下一篇回到第一步，讲语义模型怎么从一个没有外键的业务库里起草出来，关联又是怎么在库上核对的。