Mixpanel Agent Intelligence：终于能回答「我的 Agent 到底值不值」

Mixpanel 推出了 Agent Intelligence，它围绕一个令大多数上线 Agent 的团队都答不上来的、简单到令人头疼的问题：这东西到底值不值？团队并不缺数据——他们能告诉你发生了多少次对话、每次花多少钱、响应耗时多长。他们说不清的，是规模化之后用户身上究竟发生了什么。Agent Intelligence 把 Agent 在一次对话里「做了什么」，与用户随后「做了什么」、以及是否带来业务结果连接起来。即便你最终不买这款产品，它背后的设计取舍也值得一读。

对话会落到与产品其他行为相同的用户上

问题所在：两个工具加一堆胶带

Mixpanel 找到的最清晰信号，不在某个基准里，而在一种「绕路方案」里。多数团队在另一个可观测工具里度量 Agent——这很合理，因为你总得有东西来追踪请求、调试故障——但那个工具与产品其余数据是割裂的。于是团队把 AI 事件导出到 Mixpanel，手工建分群，再自己把 Agent 缝回客户体验里。一位客户说得很直白：当大部分体验都发生在一次对话里时，你怎么把它接回你度量的其他一切？

# The core idea: conversations are the unit a PM thinks in,
# not spans and traces. Agent Intelligence is built on OpenTelemetry.

INGEST = {
    'protocol': 'OpenTelemetry (OTLP)',
    'sdk_needed': False,
    'join_key': 'user_id (ties each conversation to the person)',
    'unit_of_analysis': 'conversation -> turn -> span -> tool call',
}

取舍一：以对话为先

Mixpanel 做了一个几乎决定了其余所有设计的取舍：你看到的主对象是「对话」，而不是 span 或 trace。span 与工具调用，是工程师调试单次请求的正确视角，却不是一个 PM 思考客户的方式。PM 想知道：客户问了什么、Agent 如何回应、是否得到了所需，还是不得不问三遍。于是对话成为顶层对象，其下的一切——每个轮次、每个 span、每个工具调用及其返回——都层层嵌套、一次点击即可下钻。深度被保留，入口却是人话。

# Send the traces you already collect; just add a user_id so each
# conversation connects to the rest of the customer journey.

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

exporter = OTLPSpanExporter(endpoint='https://api.mixpanel.com/v1/otel')

tracer = trace.get_tracer('my-agent')
with tracer.start_as_current_span('conversation') as span:
    span.set_attribute('user_id', current_user.id)
    span.set_attribute('conversation_id', conv.id)

沿用你已有的漏斗、分群与留存报表

取舍二：构建在 OpenTelemetry 之上

第二个取舍，是基于 OpenTelemetry 而非自造一套专有采集协议。这一点很关键：大多数构建 Agent 的团队已经在发出 OTel trace，因此无需新增 SDK。你把你已在采集的 trace 发来（与你在用的其他工具并行），并附上用户 ID，让每次对话绑定到背后的人。这是整个产品那个沉默的使能器：因为 Agent 事件与其余分析落在同一个用户上，Agent 就不再是隔离在一边的黑盒，而成为一段你可以真正追踪的旅程中的一步。

# Ask the question that engagement charts cannot answer:
# was a long conversation deeper, or just the same question rephrased?

def quality_signal(conversation):
    # turns alone are ambiguous; outcomes disambiguate
    return {
        'turns': conversation.turns,
        'resolved': conversation.ended_with_goal_met,
        'user_returned_7d': conversation.user.retained(7),
        'tool_failures': [t for t in conversation.tools if not t.ok],
    }

你终于能回答什么

当对话与用户行为被放进同一处，问题的形态就变了。你无需搭建仪表盘就能区分好对话与坏对话：trace 一落地，成本、延迟、错误与量级指标就出现了。这很重要，因为单看「 engagement（参与度）」会误导——一个用户连发六条提示，可能是在深入，也可能是因为 Agent 老是答错而在反复改写同一个问题。在用量走势图上，这两种情况长得一模一样；而当你打开对话看清楚发生了什么，它们就不再相像。又因为 token 花费与留存现已同处一地，你可以用已有的漏斗、分群与留存报表来分析它们。

# Now you can use the reports you already know - funnels, cohorts,
# retention - because agent events land on the same user.

funnel = [
    'opened_agent',
    'conversation_started',
    'goal_achieved',
    'returned_next_week',
]

cohort = users.where(
    lambda u: u.used_agent and not u.returned(days=7)
)

把 Agent 与客户旅程放进同一个平台

把闭环收上

重点不是更好看的仪表盘，而是把 Agent 修好。Mixpanel 描述了一个典型闭环：你发现有一群用户用过 Agent 之后不再回来，钻进他们的对话，发现他们都在做同一件事——而且每次都是同一个工具调用失败。你把它修好，落在功能开关之后发布，再以一个实验来验证留存是否提升。你从「注意到一个问题」到「证明修复有效」，全程不必离开这个平台。正如其客户 Sprout 所说：知道 Agent 回了话，并不能告诉你客户是否达成了目标，而后者才是最重要的。

# Close the loop: find the failing tool call, fix it, ship behind a
# feature flag, and run it as an experiment. All in one place.

STEPS = [
    'spot a cohort that does not return after using the agent',
    'open their conversations; find the same failing tool call',
    'fix it; ship behind a feature flag',
    'run an experiment; check whether retention improves',
]

如何接入

接入被刻意做得轻：因为它构建在 OpenTelemetry 之上，你把 trace 带上用户 ID 属性导出到 Mixpanel，基本就完成了。剩下的工作是概念性的，而非机械性的。先定义「一次成功的对话」对你的产品意味着什么，然后把那个结果——一次转化、一次被解决的问题、一次回访——埋成一级事件，而不是事后缝补的东西。挑一个不再回访的分群，打开他们的对话，去读究竟发生了什么。如果你学到的第一件事让你不太舒服，那么这个产品已经开始起作用了。