“高价值用户最近是不是流失了？”
设想运营负责人在群里抛出这个问题。Agent 很快生成一张趋势图，并给出结论：“高价值用户的流失情况正在加剧。”
看起来效率很高，但先别急着采取行动。
这里的“用户”指账号、自然人，还是账号下的使用角色？“高价值”看历史累计付费，还是近 30 天付费？“流失”是连续多日未使用，还是订阅到期后没有续费？
这些前提没有说清，同一句话完全可能得到不同答案。更危险的是，每个答案使用的数据都可能是正确的，图表也没有计算错误。
企业分析 Agent 最危险的错误，不是 SQL 写错，而是用正确的数据回答了定义错误的问题。
这正是 Ontology 对分析 Agent 的价值：它不是再给模型塞一份说明书，而是把企业确认过的业务对象、指标定义、数据资产和适用边界连接起来，让 Agent 在分析时能够找到、调用并遵守这些项目语义。
一、数据分析 Agent 为什么需要业务语义
我们在日常沟通中，经常省略默认前提。
运营说“高价值用户”，默认可能是近 30 天付费达到某个门槛的账号；财务说“高价值客户”，想到的可能是历史累计收入；销售口中的“重点客户”，又可能来自人工维护的客户名单。
人能够根据部门、场景和经验补齐这些信息，Agent 却未必知道。它不仅需要理解一句话的字面意思，还必须回答五个问题：
- 分析谁：账号、用户、角色，还是企业客户？
- 怎么算：高价值和流失分别如何定义？
- 看多久：使用什么时间窗口和对比周期？
- 用什么：哪些指标、分群和报表适合这次分析？
- 怎么行动：结论可以支持什么动作，又不能被解释成什么？如果这些问题没有答案，Agent 即使可以访问数据库、调用报表，也只能根据字段名称、资产标题和零散文档进行猜测。
二、业务定义与数据资产为什么需要统一组织
多数项目已经积累了大量分析经验，只是它们没有被组织在一起。
数据团队的指标说明写着“付费用户”如何计算；运营看板长期沿用固定的时间窗口；“高价值待召回”分群保存着一套筛选条件；复盘报告解释过为什么排除测试账号和刚注册用户。
这些资产背后，都藏着企业对业务的理解。但对 Agent 来说，它可能只看到几个相似名称：累计付费用户、近 30 天高消费用户、重点客户账号、高价值待召回用户。
如果只根据名称选择，Agent 很容易把用于财务盘点的累计付费分群，拿来回答本周的运营预警。报表能查出来，数字也未必算错，问题却已经答偏了。
因此，Agent 不只需要知道“这里有哪些资产”，还要知道资产统计谁、采用什么口径、适合回答什么问题、由谁维护，以及哪些场景不能使用。
数据资产告诉 Agent“这里有什么”，项目语义还要告诉它“什么时候该用什么”。
三、Ontology 如何组织业务对象、指标定义与数据映射
Ontology 经常被翻译为“本体”。完整的企业 Ontology 可以包含对象、关系、状态、规则、动作和权限。但在分析场景里，我们可以先从一个最小版本理解它：把原本散落的业务定义组织成一套可查询、可调用、可约束的结构。
仍以“高价值用户最近是不是流失了”为例，项目可以明确记录五类信息。
第一类是业务对象：这里的用户指付费账号，而不是账号下的使用角色；账号关联订阅、订单和使用行为。
第二类是对象关系：付费账号拥有订阅、产生使用行为、进入特定分群；订单归属于账号。关系让 Agent 知道分析应该沿着哪条路径查找数据，而不是仅凭关键词匹配报表。
第三类是业务定义：高价值账号指近 30 天付费达到约定门槛的账号；流失风险指连续 14 天没有发生核心使用行为；实际流失则需要订阅到期且未续费。相近概念被明确区分，Agent 不能随意混用。
第四类是数据映射：哪个分群实现了高价值定义，哪张报表统计账号级核心行为，哪个字段表示订阅到期。Ontology 不必取代现有数据资产，而是为它们补上业务身份和用途。
第五类是约束与边界：排除测试账号；角色级登录次数不能用于账号级分析；数据只能证明风险升高时，不得写成“用户已经流失”。
这些信息连接起来后，项目语义就不再只是几份孤立说明，而成为 Agent 能够沿着关系查询的业务结构。
## 四、Ontology 参与数据分析 Agent 的五个环节
当 Agent 收到问题，它不应该立即搜索一张名字最相近的报表，而应经过五步。
第一步，识别对象。判断“用户”在当前项目中对应付费账号、角色还是其他对象。
第二步，匹配定义。找到项目认可的高价值和流失定义。如果同时存在“流失风险”和“实际流失”，Agent 应说明区别；无法判断时，请业务人员确认。
第三步，映射资产。沿着业务对象和关系，找到对应的指标、分群、报表和字段。
第四步，执行约束。检查时间窗口、排除条件、统计粒度、数据权限和适用范围，避免拿一张“能查”的表回答一个“不适用”的问题。
第五步，输出依据。结论同时附带使用的口径、数据来源、时间范围和限制，让业务人员能够复核。
因此，Ontology 提供的并不是更多 Context，而是三种更具体的能力：概念之间的连接、业务定义与数据资产的映射，以及 Agent 推理时必须遵守的约束。
五、用户流失分析：有无项目语义的两种回答
没有项目语义时，Agent 可能找到一张按角色统计登录次数的报表，再关联累计付费用户分群，最后得出“高价值用户流失加剧”的结论。
查询可以正常运行，但分析单位、高价值口径和流失定义都可能不适合当前场景。
有了项目语义后，Agent 会先说明：本次将“用户”解释为付费账号，将“高价值”定义为近 30 天付费达到约定门槛，将“流失”暂按 14 天未发生核心行为的流失风险口径分析。
随后，它选择账号层面的核心使用行为报表，比较本期与可比周期，并给出一个更克制的结论：
部分高价值账号的核心使用行为下降，流失风险有所升高；现有数据尚不能证明这些账号已经流失，需要结合订阅到期和续费数据进一步判断。
两次回答的数字未必不同，真正的差别在于：第二个答案说清了分析的是谁、为什么这样算、依据来自哪里，以及结论能用到什么程度。
六、如何让业务定义贯穿分析、运营行动与验证
查对数据只是第一步。如果部分高价值账号确实出现使用下降，运营还需要区分：哪些账号过去频繁使用某项关键功能，哪些即将到期但仍然活跃，哪些已有客户经理跟进，哪些不适合自动触达。
这些人不应该进入同一套策略。功能使用下降的人可以接受使用指导；临近到期但仍然活跃的人，可能需要另一种沟通方式。运营审核人群和内容后，可以先选择一小部分账号测试，并设置对照组，观察核心行为和续费指标是否改善。
实验结束后，团队不仅要判断策略是否有效，还要反过来检验：最初的“流失风险”定义真的找对人了吗？
由此形成一条完整链路：
如果分析时使用一套定义，圈人和触达时又换成另一套口径，最后就很难解释策略究竟对谁有效。Ontology 的意义之一，就是让对象和定义在分析、行动与验证之间保持一致。
七、ThinkingAI 的业务分析实践路径
ThinkingAI 的 Agentic Engine（AE）支持自然语言查数、多维分析、图表与看板，并提供智能分群、运营触达、实验验证和执行留痕等能力。公开接入指南显示，Agent 可以读取项目实际存在的埋点方案，基于真实事件和属性创建报表，并验证查询结果。
在这些能力之上，可以进一步把指标说明、分群用途、报表边界和业务规则组织成 Agent 可参考的项目语义，让同一套定义贯穿查数、圈人、触达和实验。
这并不意味着 AE 已经是一套完整的企业 Ontology 平台。更准确地说，这是把 Ontology 思想用于业务分析的一条可实践路径：先让 Agent 理解业务问题，再让它选择数据；先让分析结论可以复核，再让结论进入行动。
过去，我们关注 Agent 能不能把数据查出来。接下来更重要的问题是：当 Agent 给出答案时，它是否真的理解企业所说的“用户”“高价值”和“流失”分别意味着什么？
Ontology 不是替 Agent 完成分析，而是为分析划定一个经过企业确认的业务世界。Agent 可以在这个世界中查询、计算和行动，但不必每次都从数据库字段和零散文档里重新猜测业务含义。
只有说清分析的是谁、为什么这样判断，以及结论能够支持什么行动，Agent 的答案才真正接近业务需要解决的问题。
