Agent 作为用户：当机器人成为你的主力用户时，产品分析为何失效

2025 年，自动化互联网流量同比增长了 23.5%，是人类流量增速的八倍。其中，agent 驱动的交互增长了 7851%。如果你的产品处理了相当体量的 API 流量，那你的最重度"用户"很可能根本不是人类。而令人不安的事实是：你的产品分析系统对此几乎一无所知。

这不是一个机器人检测问题，而是一个埋点架构问题。当 AI agent 预订差旅、提交费用报告、查询数据库或调用你的支付 API 时，它留下的行为特征与人类完全不同——而你的会话漏斗、NPS 问卷和队列留存图，正在悄悄对你撒谎。

传统分析是为什么而生的（以及为何在 Agent 面前失效）

传统产品分析建立在几个假设之上，而这些假设在 agent 规模化到来的那一刻就不再成立了：

会话是有边界的。 人类打开一个标签页，完成某件事，然后离开。会话时长是有意义的。但一个 agent 可能无人看管地运行数小时，在单个"任务"中循环重试或串联数十个 API 调用。一个历时 45 分钟、最终预订失败的会话，在数据上看起来与成功的完全相同。

漏斗是向前流动的。 会话漏斗模型假设流失发生在步骤之间。而 agent 会循环、重试、升级和回溯。它不会在结账时放弃——它会遇到一个模糊的错误，用相同的请求体重试四次，然后停下来。你的漏斗会显示那三次重试都"完成了结账"。

参与度是信号。 高页面停留时间和重复访问对人类来说是正向信号。对 agent 而言，这往往是负向的——它意味着循环、在卡住的状态上重试，或者失控的错误处理。一个对同一端点发起 200 次请求的 agent 不是"高度参与"，它是坏掉了。

用户能够理解歧义。 当人类看到"访问受限"的提示时，会等一等再试。而当 agent 收到同样的消息，却没有 Retry-After 响应头或机器可读的退避指令时，它可能会立即进入紧密循环——将一个短暂的容量问题变成对你自己基础设施的持续 DDoS 攻击。

真正重要的 Agent 原生指标

问题不在于如何调整现有仪表盘，而在于要改而测量什么。

意图识别率。 agent 是否理解了用户（或编排系统）的需求？这需要在任务层面埋点，而不是请求层面。一个任务可能涉及 15 个 API 调用；关键是既定意图是否得到了解决。

容纳率（Containment Rate）。 agent 发起的任务中，有多少比例在无需升级到人工或降级路径的情况下完成？成熟 agent 集成的行业基准是 70–90%。低于这个数字，说明你只是自动化了简单情况，而把复杂情况甩给了人工——这比完全不自动化还要糟糕。

工具成功率。 对于 agent 发出的每一个工具调用（数据库查询、外部 API、文件读取），首次尝试的成功率是多少？工具成功率下降，往往是某个依赖 API 更改了响应格式或限流规则的早期预警——在这种变化演变成生产事故之前。

情绪衰减。 对于涉及对话元素的 agent 交互，随着对话长度增加，下游人工反馈的情绪如何变化？那些开始时有帮助、后来陷入循环对话的 agent，比快速失败的 agent 让用户更加沮丧。

意图解决时间。 不是会话时长——而是从任务提交到任务完成或升级的时间跨度。这能够跨越运行速度差异极大的 agent 进行归一化，并允许你在不同任务类型之间比较性能。

这些指标在标准分析仪表盘中统统不存在。它们需要在任务和工具调用层面的埋点追踪，而不是页面浏览量和点击事件。

区分 Agent 流量与人类流量

在拥有独立指标之前，你需要正确地对流量进行分类。这比听起来要难。现代 AI agent 被设计成像复杂用户一样行事——它们交互式地浏览、对发现的内容进行推理、并适应页面结构。简单的 User-Agent 检测会漏掉大多数。

真正能区分 agent 流量的行为信号：

请求节奏的规律性。 人类表现出不规则的时间节奏和自然停顿。Agent 按照计划或以可疑规律的间隔快速连续地拉取资源。对请求间时间间隔分布进行建模的行为分析能够捕捉到这一模式。

错误响应处理方式。 人类遇到错误后会放慢速度、重新阅读、改变策略。Agent 遇到模糊错误时往往用相同的请求体重试。短时间内的重复请求——尤其是在 4xx 响应之后——是强烈的 agent 信号。

导航路径的几何形状。 人类的浏览是非线性的，会顺着兴趣点跑题，并根据好奇心回访之前的状态。Agent 的导航路径往往是高度目标导向的：它们沿特定路径完成任务，除非被错误状态强制偏离，否则极少偏转。

交互事件的缺失。 人类会话会产生鼠标移动、滚动事件、焦点变化和打字节奏。Agent 在 Web 界面上的会话不会产生这些，或者以与人类时间分布不同的模式合成地生成它们。

实用的方法是集成方案：结合行为时序分析、错误响应模式匹配、User-Agent 检查和 API 认证消费者画像。没有单一信号是可靠的；组合使用才行。

产品决策陷阱：当人类 UX 的改进破坏 Agent 可靠性

这里有一个令产品团队结构性地感到不舒服的地方：许多真正改善人类体验的决策，会让 agent 可靠性变得更差。

• 审批门控和确认弹窗能增加信任、减少人为错误。但它们也增加了 agent 无法在没有额外编排逻辑的情况下处理的延迟和阻塞状态。每一个"你确定吗？"弹窗，都是一个 agent 必须显式处理的同步点。

• 渐进式披露和情境帮助通过仅在需要时显示信息来降低人类的认知负担。Agent 需要一致、可预测的界面——基于先前答案出现的字段变化要求 agent 处理没有任何文档记录的条件逻辑。

• 为人类理解而设计的软性错误提示（"糟糕，出了点问题——试试刷新页面！"）对人类来说确实比堆栈跟踪更令人安心。Agent 需要结构化的错误信息：错误代码、受影响的字段、错误是否可重试、有哪些有效的替代选项。

• 分页和无限滚动之所以有效，是因为人类在获取足够的上下文后就会停止阅读。需要完整数据集的 agent 会穷举翻页，为获取相同信息产生比人类多 10–50 倍的请求。

• 依赖自然语言查询的搜索优先界面对人类效果很好。需要特定记录但不知道要找什么的 agent，更偏好确定性查找——过滤参数、结构化查询、基于游标的枚举。

根本的张力在于：人类 UX 针对不确定性下的理解和信任进行优化；而 agent UX 针对确定性、结构化错误和机器可读契约进行优化。这两者在很多地方存在直接冲突，没有明确建模自己主要在为哪种消费者优化的团队，最终会做出两者都服务不好的界面。

在问题变得昂贵之前捕捉它们的埋点方案

对于拥有大量 agent 流量的产品而言，ROI 最高的可观测性补充是循环检测。一个卡住的 agent 反复调用同一端点，在任何人注意到之前，每天可能产生数千美元的 API 费用。检测模式很简单：如果同一个 agent 会话在滑动窗口内发出超过 N 个相同请求，触发告警。

除了循环检测之外，真正有效的埋点栈：

将每个 agent 任务追踪为一个根 Span。 每个 LLM 调用、工具调用和决策点都应该是一个子 Span，记录输入参数、输出数据、错误状态和时序。OpenTelemetry 的 GenAI 语义约定（由 GenAI SIG 在 2025 年定稿）为此提供了标准 schema，请使用它。

在任务层面进行 Token 和成本归因。 Agent 交互消耗的 Token 可以是标准聊天机器人交互的 5–30 倍。为每个模型调用打上 agent ID、团队、任务类型和用户上下文的标签。没有这些，成本异常直到账单来临才会变得可见。

工具成功率告警。 当外部 API 更改其响应格式时，你的 agent 会开始静默失败——重试、混乱，并可能陷入循环。特定工具的工具成功率下降，往往是依赖变更的第一个可检测信号。

行为漂移检测。 为每种任务类型的对话长度、工具调用深度和 Token 消耗建立基准分布。与基准的统计偏差——agent 突然需要多 40% 的工具调用才能完成相同的任务——表明上游某些事情发生了变化。

实际实施方式：用 OpenTelemetry Span 对你的 agent 编排层进行埋点，将数据发送到时序数据库，并对上述指标构建阈值告警。这是管道工程，不是研究——它是应用于 agent 行为数据的、与微服务可靠性相同的可观测性模式。

两个仪表盘，而非一个

运营层面的结论是：同时服务人类用户和 agent 消费者的产品，需要独立的可观测性界面。

人类仪表盘追踪你现在已经在追踪的内容：漏斗转化、会话指标、队列留存、NPS 信号。这些对你的人类用户依然有意义，不应该被 agent 行为模式所污染。

Agent 仪表盘追踪意图解决率、每个集成的工具成功率、任务延迟分布、每种任务类型的成本、循环事件频率和容纳率。这些指标对人类用户分析毫无意义，会扭曲任何合并视图。

硬性前提是可靠的流量分类——你需要知道每一个会话和 API 调用，是来自人类还是 agent。没有这一点，你的仪表盘测量的是两个根本不同行为群体的混合体，而聚合数字对哪个都无法准确反映。

这对 API 设计意味着什么

如果你产品的 agent 流量规模显著且持续增长，分析问题是 API 设计问题的下游。你可以通过埋点来绕开一个结构糟糕的 API，但不解决根本问题，就无法修复 API 所传递的信息和错误处理方式。

机器可读的错误响应不再是可选项。RFC 7807 问题详情格式给了 agent 所需的一切：一个结构化的 JSON 负载，包含 type URI、title、status 和 detail——以及用于恢复路径、受影响字段名称和有效替代选项的自定义字段。收到这些信息的 agent 可以无需人工干预地恢复。收到"出了点问题"的 agent 则无能为力。

批量端点能减少让 agent 流量看起来像滥用行为的请求-响应放大效应。如果你的 API 只支持单条记录操作，做批量工作的 agent 会发出 1000 个串行请求，而一个批量请求就能搞定。这不是 agent 的不当行为——这是缺失的能力。

写操作上的幂等键让 agent 在网络故障后可以安全重试，而不会创建重复记录。没有它们，agent 需要在写之前先检查——在每次重试时将请求数翻倍。

这些不是专门为"AI 客户"准备的功能，而是提升所有自动化消费者可靠性的 API 设计模式。Agent 流量的浪潮只是让不具备这些能力的代价变得可见。

结语

当 agent 成为你产品的重度用户时，你现有的分析基础设施不只是变得不那么准确——它会主动误导你。高参与度信号意味着坏掉的 agent；漏斗完成数字包含了循环和重试；NPS 评分无法捕捉幻觉响应是否造成了伤害。

应对之道不是换一个新的分析供应商，而是重新思考埋点方式。对流量进行标记，追踪 agent 任务，用意图解决率取代会话时长，并在行为异常（循环和成本失控）在成为事故之前发出告警。为 agent 消费者建立独立的可观测性界面，停止用为人类设计的指标来分析它们。

从这里开始，产品决策只会越来越难。在足够多的设计决策上，优化人类理解和优化 agent 可靠性是相互拉扯的，以至于大多数团队最终不得不选择主要服务哪种消费者——或者构建两套界面。但在你的分析系统能够区分二者之前，这个决策是无法做好的。