Kubit：用用户行为数据驱动AI Agent优化的产品分析平台

当AI Agent遇上产品分析

随着AI Agent产品的爆发式增长，一个新的痛点正在浮现：开发者们知道如何构建Agent，却往往不知道用户为什么会反复重新提示（re-prompt）、中途放弃，或者最终转化。传统的产品分析工具聚焦于用户点击、页面跳转等行为，而Agent产品的核心交互——那些复杂的推理链路和工具调用——却处于分析的盲区之中。

AI Agent产品与传统SaaS产品在交互模式上存在根本差异。传统产品的用户行为是确定性的——点击按钮A必然到达页面B，因此漏斗分析、热力图等工具能有效捕捉用户意图。而Agent产品的交互是非确定性的：同一个用户输入可能触发完全不同的推理路径，Agent可能调用搜索引擎、数据库查询、代码执行等多种工具的组合，中间任何一步的失败或延迟都可能导致用户体验的劣化。这种"黑箱化"的交互模式使得传统点击流分析几乎失效，产品团队面对的是一个全新的可观测性挑战。

近日登上Product Hunt榜单第8位的Kubit，正是瞄准了这一空白。它的定位很直接：为Agent和用户提供统一的产品分析，帮助产品工程师用真实的用户行为数据来优化AI Agent的表现。

Kubit如何将Agent轨迹与用户行为连接起来

Kubit最核心的理念，是将**Agent执行轨迹（agent traces）与用户活动（user activities）**直接关联。这听起来简单，但实际上解决了一个关键的观测难题。

Agent Traces的概念借鉴自分布式系统中的"链路追踪（Distributed Tracing）"。在微服务架构中，一个用户请求可能经过多个服务节点，Trace记录了请求在每个节点的处理时间和状态。类似地，AI Agent的执行轨迹记录了从用户输入到最终输出之间的完整推理过程：包括LLM的每次调用及其输入输出、工具调用的参数和返回值、中间决策点的选择逻辑、以及各步骤的耗时。这些轨迹数据通常以树状或图状结构存储，每个节点（span）代表一个原子操作。将这些技术层面的trace数据与用户层面的行为事件对齐，正是Kubit要解决的核心技术问题。

传统产品分析工具的断层

在一个典型的AI产品中，用户发出一个请求后，Agent会经历多步推理、调用多个工具、生成中间结果，最终返回答案。如果用户不满意并重新提问，或者干脆离开，产品团队通常只能看到"用户流失"这个结果，却无法追溯到底是Agent的哪一步出了问题——是工具调用失败？是推理路径偏离？还是响应速度太慢？

Kubit的解决方案

Kubit的做法是把Agent的每一步执行轨迹与对应的用户行为拼接在同一条时间线上。这样一来，当用户re-prompt或drop-off时，团队可以精确定位到"用户为什么这么做"。官方描述中特别强调了三个关键指标场景：re-prompt（重新提示）、drop off（流失）、convert（转化）——这三者恰好覆盖了Agent产品体验的负面、中性和正面信号。

其中，Re-prompt是AI Agent产品中一个极具信息量的用户信号。当用户对Agent的回答不满意时，他们通常会尝试换一种方式重新表达需求，这类似于搜索引擎中的"查询改写（query reformulation）"行为。研究表明，re-prompt的频率和模式能揭示Agent理解能力的边界：频繁的re-prompt可能意味着Agent在特定领域的知识不足、指令遵循能力较弱、或者上下文窗口管理存在问题。更重要的是，每次re-prompt都消耗用户的耐心预算——大多数用户在2-3次重试后就会放弃，这使得re-prompt率成为衡量Agent产品体验质量的核心先行指标。

从数据洞察到代码优化的完整闭环

Kubit真正有意思的一点，是它并没有止步于"给出分析报告"。它主打的是一个完整的优化闭环：

将这些洞察直接喂给你的编码Agent，构建出真正能留住用户的AI产品。

这意味着，Kubit分析出的用户行为洞察，可以直接反哺到开发者的coding agent中，形成"观测—洞察—改进—再观测"的迭代循环。在AI辅助编程日益普及的当下，这种"数据驱动Agent优化"的思路，把产品分析工具从被动的报表角色，升级为主动参与产品迭代的一环。

这也反映了一个趋势：AI产品的开发正在从"凭直觉调Prompt"走向"用数据调Agent"。当Agent的行为可以被量化观测，优化就从艺术变成了工程。这一转变的背后是整个AI应用开发方法论的成熟——类似于Web开发从"拍脑袋设计"到"A/B测试驱动"的演进历程，Agent产品也正在进入以数据为核心的精细化运营阶段。

低门槛的数据接入方式

对于任何分析工具而言，数据接入的复杂度往往是采用的最大障碍。Kubit在这方面提供了三种灵活的集成路径：

• OTel（OpenTelemetry）：借助业界标准的可观测性框架接入Agent轨迹数据，这对已经在做LLM可观测性的团队非常友好；
• CDP（客户数据平台）：直接对接团队现有的用户数据平台，复用已有的用户行为数据；
• BYOW（Bring Your Own Warehouse，自带数据仓库）：允许企业在自己的数据仓库上运行分析，兼顾数据主权与合规需求。

OpenTelemetry在AI可观测性中的角色

OpenTelemetry（简称OTel）是CNCF（云原生计算基金会）旗下的开源可观测性框架，提供了统一的API和SDK来收集分布式系统的追踪（traces）、指标（metrics）和日志（logs）数据。近年来，OTel社区正在积极扩展对AI/ML工作负载的支持，已有多个语义约定（semantic conventions）提案针对LLM调用场景，标准化了如模型名称、token用量、温度参数等属性的记录方式。Langfuse、Arize、Traceloop等AI可观测性工具都已支持OTel协议。Kubit选择OTel作为数据接入方式之一，意味着已经在使用这些工具的团队可以零成本地将trace数据接入Kubit进行产品层面的分析，无需重复埋点。

BYOW模式与数据主权

特别是BYOW模式，对于注重数据安全的企业客户是一个重要卖点——数据无需迁移出自有环境，降低了合规和隐私顾虑。这种"数据不出仓"的架构，也是近年来现代数据栈（Modern Data Stack）中"仓库原生分析"的主流方向。

BYOW代表了数据分析工具架构的一次范式转变。传统SaaS分析工具要求将数据上传到供应商的服务器进行处理，这带来了数据安全、合规（如GDPR、CCPA）和数据新鲜度等问题。而BYOW模式下，分析逻辑以查询的形式下推到客户自有的数据仓库（如Snowflake、BigQuery、Databricks）中执行，数据始终留在客户控制的环境内。这一模式的先行者包括Census、Hightouch等反向ETL工具，以及Mitzu、Cube等仓库原生分析平台。对AI Agent产品尤其重要的是，Agent trace数据往往包含敏感的用户对话内容和业务逻辑，BYOW架构能有效降低数据泄露风险。

简评：AI Agent产品分析是一个被低估的细分赛道

Kubit所处的赛道——AI Agent的产品分析与可观测性——正处于早期但快速升温的阶段。目前市面上大量工具聚焦于LLM的调用监控、成本追踪和评测（eval），但真正把"Agent行为"和"用户行为"打通做产品分析的工具还不多见。

要理解Kubit的差异化定位，需要区分当前AI可观测性领域的不同层次。目前市面上的工具大致分为两类：一类是偏运维和工程视角的LLM监控工具，如LangSmith、Langfuse、Helicone等，它们关注的是模型调用的延迟、成本、错误率、token消耗等技术指标，以及prompt版本管理和A/B测试；另一类是偏评测视角的工具，如Braintrust、Patronus等，关注模型输出的质量评分。Kubit试图开辟的第三类是产品分析视角——它不仅关心Agent"做了什么"和"做得好不好"，更关心这些表现如何影响了用户的后续行为（留存、付费、推荐）。这种从技术指标到商业指标的映射，是产品成熟度提升的重要标志。

Kubit的差异化就在于它站在产品工程师而非纯运维视角，关注的是用户留存和转化这些商业指标，而不只是技术指标。这个切入点让它区别于单纯的LLM监控工具。

当然，作为一个新登场的产品，99票的成绩虽登上榜单前十，但仍需在实际场景中验证其分析深度和洞察质量。对于正在构建AI Agent产品、且苦于"不知道用户为何流失"的团队来说，Kubit至少提供了一个值得尝试的新思路：别再猜了，去看数据。