市面上多数分析智能体，只做到一半
ThinkingAI 发布的 Agentic Engine 有一句措辞很能说明定位：同类平台上的分析智能体通常只是「发现一个问题」然后把结论交回给人；Agentic Engine 负责把它做完，变成一次产品改动。
这句话描述的是一个真实的断层。多数企业的数据链路是这样的：数仓里的数字被人发现异常，写成报告，排进需求队列，等分析或工程排期，最后才落到产品上。整条链路上，智能体只覆盖了发现环节，而恰恰是后半段的「排期与等待」吃掉了大部分时间。ThinkingAI 把这个断层称为增长闭环断裂。
公司前身是 ThinkingData，做行为数据业务十年，服务过超过 1500 家企业与 8000 个应用，客户名单里包括 Sega、Krafton、Habby 与 Century Games。这次的 Agentic Engine 是把这份积累转成自主增长软件的产品化结果。三位联合创始人之一的 Chris Han 在发布中说了一句相当诚实的话：现在各家的模型都足够聪明了，客户反复问的是敢不敢让一个智能体去碰真实的收入。
四类智能体 + 一张实体图谱
产品结构上，Agentic Engine 由四类智能体组成：数据埋点、分析、触达与实验。它们的差别在于工作对象不同——埋点智能体改的是采集方案，分析智能体查的是数据，触达智能体动的是人群与活动，实验智能体管的是验证。官方强调这四类智能体处理的是同一个问题，需要彼此协同产出结果，而不是各自独立地回答四个问题。
值得单独看的是 Knowledge Base。官方把它描述为「以 schema 为先的实体图谱」，做法是把企业已有的文档与报表收敛成同一份事实源，并带版本化的变更记录。
这一步是整条闭环能否成立的前提。智能体要自主决定改动什么，就必须知道这家公司的业务对象长什么样、彼此怎么关联、哪些指标口径已经过时。过去这类知识散落在分析师脑子里、文档里和看板定义里，每次交接都会损失一部分。把它做成带版本记录的实体图谱，本质上是给智能体提供一份可追溯的业务语义层——同时也是一个可以被审计的对象。
ae-cli：让智能体调用智能体
在接口设计上，ThinkingAI 做了一个容易被忽略但方向明确的选择：命令行接口 ae-cli。企业其他的 AI 智能体与开发工具可以直接调用引擎，不必经过它的界面。
这条设计把 Agentic Engine 从「一个给人用的软件」变成了「一个给智能体用的能力」。它对应的是多智能体协作里越来越常见的组织方式：编排层不直接操作业务系统，而是调用一个个已经封装好领域能力的下层智能体，再由上层决定何时调用、如何汇总。如果每个能力都必须有人在浏览器里点，自动化就很难向上扩展。
为什么必须跑在客户自己的环境里
Agentic Engine 的部署选项包括托管云、自托管、本地机房与虚拟私有云，客户可以运行自己的模型。官方给出了两个驱动因素：受欧盟通用数据保护条例约束的企业，以及需要通过企业安全评审的团队，无法把原始用户与客户数据交给一个开放云系统。
这是企业级智能体落地中一个越来越清晰的规律：能力不是限制条件，信任边界才是。数据出不出企业网络，往往比模型多聪明几个百分点更能决定一个项目能不能过审。把部署形态做全，等于把「数据主权」变成了产品参数。
商业条款上也做了一个取舍：官方称采用企业软件订阅制，不按事件计费。这个选择直指一类常见的激励错配——按事件或按月度追踪用户数计费的方案，会让企业为自己看得越仔细而付得越多，结果反倒促使团队少埋点、少监控。把计费与观测强度解耦，是个不显眼但合理的设计。
口径与待验证的部分
官方给出的效果数据是：数据埋点实施周期从数周缩短到数小时，初级运营也能得到资深分析师水平的答复。公司自称产品是围绕游戏工作负载打磨的，游戏场景里留存与变现按分钟级决定，对闭环速度的要求比多数行业更高。
需要标注口径的是，以上均为公司自述，未附第三方基准或客户可核对的量化结果。几个关键问题目前没有公开答案：实体图谱的构建需要多少人工参与、与企业既有数仓和 BI 工具如何对接、四类智能体在自主改动产品时的人工审批粒度如何设定、以及「不按事件计费」的订阅定价区间。此外，把分析到执行的闭环交给智能体后，改动效果的归因责任如何划分，官方也未展开。
结语
Agentic Engine 的价值主张不是更强的模型，而是更短的链路：把发现、判断、执行、验证压缩进一个平台，并让它运行在客户自己的围墙内。这个方向对企业有现实吸引力，因为它的收益可以用「从注意到数据到改完产品花了多少天」这类指标直接衡量，而这恰恰是多数团队仍在用周计量的环节。真正需要观察的是另外两件事：实体图谱的维护成本会不会成为新的隐性负担，以及当智能体开始自主改动线上产品时，企业的审批与追责机制能否跟上。