"ChatBI 可能要进入历史舞台了。"

作者｜王博

假设你是一款泛娱乐 App 的增长负责人。这款 App 的 MAU（月活跃用户数）达到 860 万，但最近三个月，新用户一直增加，次日留存却持续下降。你想知道问题出在哪里，该怎么办？

按照传统方法，你可能要先找分析师拆分渠道、版本和用户群，再请研发检查埋点、产品排查功能路径、运营核对投放变化。数据散落在不同系统里，每个环节都要排期、对口径，最后得到的往往仍是一组相关性线索。

如果把问题交给现在市面上的一些 AI Agent 产品，或许你可以迅速得到十几种可能性分析：渠道质量下降、新手引导过长、内容供给不足、产品性能不稳定……每种解释都很合理，数据表格美轮美奂，却未必真的是解决问题的方案。

10 月 28 日，在 ThinkingAI Summit 中国站的主题演讲中，ThinkingAI CTO 周津将同样的问题提给了 ThinkingAI 可私有化部署的 AI Agent 平台 Agentic Engine。在仿真演示中，Agentic Engine 没有急着回答，它给出的第一个结论是：数据还不够。

ThinkingAI CTO 周津，图片来源：ThinkingAI

这种 " 拒绝回答 " 显示了 Agentic Engine 的专业性。在真实应用场景中，企业需要的并非更多听起来合理的猜测，而是一套能够接入数据、核对口径、调用专业工具，并将问题继续推进到实验和运营的方法。

根据周津现场的演示，在补齐数据和关键埋点后，Agentic Engine 才开始继续分析。它沿着新用户的完整行为路径，将留存变化按渠道、版本、设备和用户群体拆开比较，寻找真正出现异常的环节，并允许用户追溯指标定义、筛选条件和数据来源。发现值得调查的差异后，它没有直接替业务负责人下结论，而是进一步圈定可能受影响的人群，提出产品改进和运营方案；经人确认目标、规则与风险边界后，再调用 A/B 实验检验方案是否有效，并根据实验结果决定继续推广、调整还是停止。

「甲子光年」发现，Agentic Engine 没有局限在一次问答、一次取数、一次图表生成，它是把 " 发现问题 - 补齐数据 - 分析原因 - 采取行动 - 验证结果 " 连成一项可以持续推进的工作。

" 我认为 ChatBI 可能要进入历史舞台了。" 周津告诉「甲子光年」，" 问数本身不是目的。问一句今天业务怎么样，马上给你一堆数字和一张漂亮的图表看板，看起来很爽，但它真的解决问题了吗？"

这也是很多用户面临的共同问题：在生成漂亮的图表之外，Agent 如何真正驱动业务增长？

1. 把专业数据分析能力送进不同的 Agent

今年 4 月，ThinkingData（数数科技）更名为 ThinkingAI，并发布了 Agentic Engine。

当时，ThinkingAI 强调的是一家游戏数据公司为什么有机会进入 Agent 领域：大模型提供推理能力，工程框架让 Agent 能够执行任务，企业长期积累的数据、业务知识和专业方法，则决定 Agent 能否给出可信的结果。Agentic Engine 也提供了自己的对话入口，用户可以在平台内创建 Agent、调用数据和工具。

但产品发布后的半年里，ThinkingAI 收到的客户反馈开始发生变化。

过去，客户会讨论页面上应该增加什么分析模型、按钮放在哪里、操作流程能否再简化；现在，他们更关心另一类问题：Agentic Engine 的能力能不能被自己的 Agent 调用？

研发人员可能已经在 Codex、Claude Code 或 Cursor 中写代码、查看日志，产品和运营人员则开始通过 WorkBuddy 等桌面 Agent 处理文档、表格和任务。不同岗位已经形成了各自的工作入口。如果为了查询数据、检查埋点或者创建报表，所有人都要重新进入 Agentic Engine 的对话页面，原有的代码、文件和任务上下文就会被切断。

" 最大的变化，是用户要的已经不是页面上的这些功能了。" 周津告诉「甲子光年」，" 他不会再跟你提某个模型怎么放、按钮在哪里。现在问的都是 Agent 相关的问题。用户工作的入口变了，而且变得很快。"

这让 ThinkingAI 重新思考 Agentic Engine 应该处在什么位置。它未必需要成为所有人的统一工作入口，更现实的方式是让专业数据分析能力进入用户已经在使用的 Agent。

因此，ThinkingAI 近期推出了 Agentic Engine-CLI（AE-CLI）。

AE-CLI 相当于给 Codex、Claude Code、WorkBuddy 等 Agent 安装了一套 " 企业数据工具箱 "，让它们能够调用 ThinkingAI 积累的数据接入、分析、运营和实验能力。

但它本身不是一个新的 Agent，我们可以把它理解为用户已有 Agent 与 Agentic Engine 之间的连接层。

用户仍然在 Codex、Claude Code 或 WorkBuddy 中提出任务，由这些 Agent 理解上下文、拆解问题；配套 Skills 提供经过整理的工作方法；AE-CLI 负责调用 Agentic Engine 的数据接入、埋点、分析、知识库、运营和实验能力。

简单来说就是：Agentic Engine 提供 " 专业数据能力 "，AE-CLI 解决 " 怎样调用 "，Skills 说明 " 按照什么方法调用 "。

Agentic Engine 架构，图片来源：「甲子光年」拍摄

那么，AE-CLI 进入真实工作后，会带来什么变化？

「甲子光年」从 ThinkingAI 内部获得了一个脱敏客户案例。这是一家游戏公司，过去制作人、策划和运营可以自行查看已有看板，但临时增加分析角度时，仍需向数据人员提需求、等待排期。等待的不确定性会影响提问意愿，一些问题因此被搁置，或者只能采用近似口径处理。

接入 AE-CLI 后，业务人员可以在已有 Agent 中发起查询、获得表格，并围绕结果继续追问。日常巡检也可以按照团队设定的规则运行，将渠道、版本、留存和付费等指标中的异常整理成简报。

这项变化的直接价值，不只是一张报表生成得更快。过去因为排期和操作成本而被放弃的问题，现在可以先由业务人员和 Agent 展开调查。

AE-CLI 在研发侧呈现出另一种用法。该团队已有的排障 Agent 能够查询代码、日志和活动配置。AE-CLI 进一步补充了按用户和时间范围查询客户端事件的能力。面对玩家反馈，Agent 可以把客户端行为与日志、代码和配置放在一起检查，帮助研发缩小排查范围。Agent 负责寻找和拼接证据，研发人员继续核对关键记录并决定怎样处理。

这家游戏公司团队还整理了能力说明、固定关键指标口径，并将高频任务制作成模板和 Skills。一次渠道分析、版本复盘或者异常巡检中验证过的方法，可以被更多成员和后续项目继续使用。

由此，AE-CLI 带来的变化可以概括为三个层次：业务人员能够主动调查更多问题；原有 Agent 获得新的专业数据能力；经过验证的口径和方法可以在团队中复用。

接入 AE-CLI 前后的变化，图片来源：ThinkingAI

ThinkingAI 不再要求所有用户先进入统一的对话入口，而是让能力进入用户已经工作的 Agent。软件的页面仍然存在，但不再承担唯一入口的角色。

2.AE-CLI 背后的能力

如果 AE-CLI 只让 Agent 查询一张报表，它与 ChatBI 的差别仍然有限。

ThinkingAI 提供的是一条更长的业务链路：当一个人做出了产品、应用、游戏或者内容，准备推向市场，他需要接入数据、观察用户、查找问题、理解原因、尝试改进，并验证改进是否有效。

以周津现场的 " 新用户增加、次日留存下降 " 仿真演示为例，Agent 先检查数据是否存在、时区是否一致、埋点是否覆盖关键行为。确认可以分析以后，再按渠道、版本和用户群体寻找差异。发现异常人群后，任务还要继续进入产品调整、运营动作和 A/B 实验。

"CLI 只是我们交付价值的一种形式，对 Agent 比较友好。" 周津告诉「甲子光年」，" 它背后代表的是数据采集、埋点、分析洞察、指标语义、运营、实验和数据开发的一整套能力。"

这其实也是 ThinkingAI 对 "ChatBI 可能进入历史舞台 " 的进一步解释。自然语言问数降低了取数门槛，却没有自动完成数据准备、口径确认、原因分析、行动设计和效果验证。用户得到一组数字和一张图表以后，真正困难的工作往往刚刚开始。

游戏与 3D Agent 工具产品经理阿博粒一个人同时负责产品和增长。大部分时间用于开发和产品策划，功能上线以后，他还要回答另一组问题：用户有没有真正用起来？谁跑通了生成流程？谁会继续试玩、保存或者付费？

过去，这些问题需要自己写 SQL、核对多张表的口径，再手动画图。使用 Agentic Engine 复盘 " 一句话生成游戏 " 功能时，他从一个直接的业务问题出发：新功能究竟有没有被用户使用？

Agent 先确认事件定义和比较口径，再把提交、生成成功、试玩和保存放在同一条路径上。结果显示，一部分用户已经生成成功，却没有继续试玩。按游戏类型下钻后，解谜类成为优先排查对象。

但 " 生成成功后没有试玩 "，还不能证明游戏不好玩。用户可能没有看到生成结果，不知道从哪里进入，也可能打开后发现内容与预期不符。

Agent 建议抽查 20 至 30 个生成成功却未试玩的案例，将用户输入与生成结果放在一起检查；同时补充 " 查看预览 " 和 " 退出预览 " 等行为记录，区分 " 看到了但没进去 " 和 " 根本没看到 "。数据把问题缩小到可以调查的范围，人继续判断下一步应该检查生成质量，还是修改展示和进入路径。

" 我很看重这种追问方式。从整体流程问到按版本、渠道、新老用户拆分，不用重新组织语言，比我以前用 BI 报表工具快得多。" 阿博粒说。

按照一般的标准来看，Agentic Engine 已经做得够全面了，但是 ThinkingAI 还想做到更多：解答通过现有数据分析很难回答的问题。

比如在阿博粒的案例中，行为数据可以准确圈出这批用户，却很少记录他们当时看到了什么、怎样理解产品，以及为什么没有继续。

这次在 ThinkingAI Summit 中国站，ThinkingAl 创始人 &CEO 吕承通发布了一项新功能—— AI 用户访谈。

ThinkingAl 创始人 &CEO 吕承通，图片来源：ThinkingAl

这项新功能可以按行为圈选人群，在关键时刻触发 AI 访谈，将带有用户原话的结论写回用户标签和知识库，再供数据分析、A/B 实验和智能运营等 Agent 调用。这项能力来自 ThinkingAI 推出的 Heari.ai，这是一款 AI 驱动的用户研究平台，可以独立使用，也可以与 Agentic Engine 打通。

Heari.ai：AI 驱动的用户研究平台，图片来源：「甲子光年」拍摄

针对阿博粒遇到的问题，Agentic Engine 可以先圈出 " 生成成功但没有试玩 " 的用户，再询问用户几个具体问题：有没有看到生成结果？为什么没有进入？生成内容是否符合预期？

如果用户根本没有看到结果，团队应该检查页面展示和到达路径；如果用户看到了，却认为内容与输入不符，问题可能出在生成质量；如果用户对玩法缺少兴趣，还要进一步判断这是一种个别偏好，还是某类用户的稳定特征。

访谈获得的原因可以与行为记录、应用商店评论和社区舆情交叉核对。一个问题如果同时出现在用户原话、外部评论和具体行为路径中，就比单一来源更值得优先调查。

团队随后可以修改预览页面或者进入流程，通过 A/B 实验比较不同版本，再对仍未完成首次体验的用户提供相应引导。行动结束后，继续观察试玩率、保存率和后续留存是否变化。

这样一来，几类产品能力围绕同一项任务发生关系：行为分析回答 " 发生了什么 "，用户研究提供 " 为什么 " 的线索，A/B 实验检验 " 改法是否有效 "，智能运营处理 " 应该对哪些人采取什么行动 "。

但把更多能力连接起来以后，一个更难的问题随之出现：Agent 怎样避免 " 看起来很专业地犯错 "？

周津举了一个公司内部复盘的例子。有一次，Agent 给出的一项 " 商机金额 " 明显低于他的经验判断。他继续追问指标来源，并按区域溯源，最终发现一部分销售商机数据中没有填写所属区域。Agent 在汇总国内各区域时，自动漏掉了这些空值记录。

计算过程本身没有出错，统计范围却没有覆盖业务负责人真正关心的对象。

" 如果没有数据，可能还会凭直觉保持警惕；如果 Agent 给了一个错误数据，而且你信任了它，反而更可怕。" 周津说。

因此，ThinkingAI 强调 Agent 的结论需要能够追溯：使用了哪些数据表、指标如何定义、选择了什么时间范围和筛选条件、计算过程怎样完成。语义层、知识库和数据血缘提供业务上下文，人的经验则帮助发现结果与常识之间的冲突。

数据分析保留判断依据，支持进一步研究产品改进方向（画面为产品仿真演示），图片来源：ThinkingAI

同样的要求也适用于 AI 用户研究。访谈结论需要保留用户原话，并与真实行为和外部反馈交叉验证；A/B 实验则要说明样本、分流方式和统计结果。Agent 可以组织证据、调用工具和推进任务，但关键口径、风险边界和最终行动仍然需要人来确认。

当自然语言问数逐渐普及，一个负责任的 Agent 真正的分水岭也将从 " 能不能回答 "，转向 " 答案能否追溯，行动能否验证 "。

ThinkingAI 由此形成了五大能力：数据分析、舆情洞察、用户访谈、A/B 实验、智能运营。

" 能同时提供这五种能力，在行业里并不多见。" 吕承通说。

ThinkingAI 五大能力，图片来源：「甲子光年」拍摄

3. 走向更多用户

在发布 Agentic Engine 半年后，ThinkingAI 在 Agent 商业化方面也有主动转变。

Agentic Engine 面向数据分析场景提供按月或按年的订阅方案。个人开发者、小团队，以及产品、运营、研发人员，都可以从一个具体问题开始使用。ThinkingAI 目前提供 Agentic Engine 一个月免费体验，数据分析模块的入门版为 199 元 / 月，用户可以根据事件量、项目数和账号数升级套餐；企业版继续服务更高数据规模、复杂权限和私有化部署需求。

这意味着专业数据产品的销售起点正在变化。

通常来说，专业数据产品会从销售接洽、方案设计和部署实施开始。对个人开发者和小团队而言，这套流程的成本可能比问题本身还高。

不过，AI 正在改变这种供需关系。一个超级个体（OPC）或者一支小团队也能做出应用、游戏和内容产品。产品上线后，他们同样需要分析用户行为、比较渠道效果、验证版本改动，但他们很难配置完整的数据和增长团队。

这批过去难以被企业软件覆盖的用户，现在开始产生真实的数据需求。

ThinkingAI 希望通过 PLG（产品驱动增长）的方式，让产品本身承担过去由销售、售前和实施承担的一部分工作。用户先使用产品解决问题，再决定是否付费和扩大使用。

「甲子光年」认为，AE-CLI 和 PLG 对应着 ThinkingAI 此次变化的两个方向：通过 AE-CLI 降低专业数据能力的使用门槛，通过 PLG 降低产品的获取和购买门槛。

而在它们背后，Agentic Engine 试图连接数据采集、分析、用户研究、实验和运营，把一次提问继续推进为可以执行、验证和复用的任务。ThinkingAI 想交付的也不再只是一套需要人打开和操作的软件，而是一组能够被 Agent 调用的专业能力。

这条路径仍有许多问题需要回答，但一个变化已经逐渐清晰：自然语言问数正在成为大模型的基础能力，Agent 之间的差距，将越来越少地体现为谁能更快生成一组数字和图表，而更多取决于谁能找到可靠的数据、理解数字背后的用户、将判断推进为行动，再用结果检验行动。

漂亮的图表固然便于展示，但是 Agent 真正要做的是驱动业务增长，而 ThinkingAI 的目标就是让每个 Agent 拥有业务增长的能力。

（封面图：「甲子光年」设计）

END.