你的仪表盘正在统计一个已经改变的世界
大多数分析栈的初衷只有一个:人们在我的网站上做了什么?会话、页面浏览、漏斗和活动都默认每次交互背后是一个人。
这个假设已经不再适用于所有交互。AI 助手会代用户打开页面;例如,OpenAI 文档说明了一个 ChatGPT-User agent,当用户向 ChatGPT 提问时它会访问页面(OpenAI crawler documentation)。自主 agent 会调用 API 和 MCP 工具来完成任务。人们也会在同一会话中与 AI 协同工作,有时会声明,有时不会。爬虫和脚本则持续读取它们能够访问到的一切内容。
结果就是,你的团队依赖的数据出现了静默失真。转化率发生变化,却没人能解释原因。一个热门 API 路由最终发现是由少数自动化客户端驱动的。看起来像营销成果的流量激增,其实是 agent 在阅读文档。如果没有 actor 上下文,每张图表都会把差异很大的行为混在一条线上。有些工具还会在你看到之前先移除一部分画面:Google 表示,Google Analytics 会自动排除来自已知 bot 和 spider 的流量,而且你无法看到究竟排除了多少(Google Analytics: known bot-traffic exclusion)。
AI agent 流量分析 通过为每次交互增加一个新维度来解决这个问题:谁或什么在执行,以及你有多大把握。关于这个维度背后信号的博客文章见 how to tell if website traffic comes from AI agents,而 websites use case 则展示了它在生产网站中的应用。
有 actor 感知的分析会告诉你什么
Proof of Actor 将你的流量组织为四个类别,这些类别在 Human, AI-assisted or agent: a taxonomy for app traffic 中有详细说明,并为每个类别保留对应证据。
- Human: 可观察到的信号表明由人类直接控制的交互。
- Human + AI: AI 辅助已被声明,或通过受支持的集成被观察到的交互。
- Agent: 由可验证身份支持,或由经过谨慎限定的推断支持的自动化或 agent 来源交互。
- Unknown: 证据不足以支持可靠判定的交互。
每个结果还带有一个依据:verified、declared、inferred 或 unknown。第二个维度正是让这些分析可信的关键。一个仪表盘如果说你的 API 流量有三分之一来自 agent,这在结果是 verified 签名还是基于请求模式推断出来时,含义完全不同。使用 Proof of Actor,你可以同时看到这两者,并按任一维度筛选。
按路由和工作流
不同应用中的 actor 组成差异极大。公开文档、定价页和目录页通常会吸引 agent 和助手。注册、结账和账号设置页的 agent 较少,但一旦出现就更重要。API 路由和 MCP 工具可能主要由自动化客户端驱动。Proof of Actor 会按路由和工作流拆分结果,因此每个团队都能看到自己负责的那一部分。
随时间变化
趋势能告诉你产品正在走向哪里。观察 agent 和 AI 辅助活动在关键路由上的占比如何变化,查看新的 agent operator 何时开始读取你的内容,并跟踪有多少流量随着更多客户端对请求进行签名而从 Unknown 变为 verified。
带解释
仪表盘中的任何数字都可以下钻到单个交互。对于每条交互,你都能看到类别、依据、已知内容、未知内容,以及将适用的 policy 输出。这就是把图表变成产品、平台和安全团队可以共同采取行动的依据。
工作原理
Proof of Actor 采用以证据为先的路径。你可以在 How It Works 中阅读完整说明。
- 你的应用接收请求或事件: 一个页面浏览、一次 API 调用、一次 MCP 工具调用或一次应用内动作。
- 你的集成收集该上下文中可用的信号: 服务端的请求上下文和签名,collector 运行的浏览器中的交互信号,以及来自客户端和你自己应用的声明。
- 对信号进行检查、按依据标记并组合,形成分类结果。
- 记录该结果,连同其依据和证据摘要一起进入你的分析数据。
- 你的应用决定 是仅观察还是应用某个 policy。
因为分析和决策使用的是同一组结果,所以你研究的数据,正是你的 policy 将会作用的数据。仪表盘所说的内容与应用实际执行的内容之间没有落差。
Detect, Understand, Route
AI agent 流量分析位于 Proof of Actor 三项能力的中间层。
Detect
收集每个集成可获得的 actor 信号,并将 verified 断言与行为推断分开。Unknown 作为独立类别保持可见,因此覆盖缺口不会被掩盖进其他数字里。
Understand
这是分析层:actor 拆分、交互趋势、按路由视图以及可解释分类。团队会用它来回答这样的问题:agent 依赖哪些路由、某个工作流看到多少 AI 辅助活动,以及哪些地方的证据足以支持 policy。
Route
当分析显示出清晰模式时,使用你自己的规则对其进行处理。为 agent 提供一条结构化路径,让他们访问最常阅读的内容。对人类主导的会话保留标准体验。仅在你自己的条件足够时,才为敏感操作添加 review。为 Unknown 和超时设置明确的回退策略。
面向应用、API 和 MCP server 构建
agent 活动最集中的地方,往往也是机器最受欢迎的地方:API、文档、目录和工具。这就是 Proof of Actor 覆盖范围不止于页面浏览的原因。
- SaaS 应用和网站 可以看到浏览器会话及其背后的服务端路由的 actor 上下文。更多内容见 SaaS Apps & Websites。
- API 获得请求级上下文,用于区分已签名的客户端身份、API 凭据和授权。更多内容见 APIs。
- MCP server 可获得每次工具调用的 actor 上下文,因此你可以看到哪些客户端在使用哪些工具。更多内容见 MCP Servers。
创始团队可在工程师的直接协助下完成集成。关于 adding actor context to a Node.js app 的指南展示了集成在典型请求处理器中的位置。
为什么证据比流量规模更重要
要制造一个很大的 agent 流量数字并不难。统计每个没有浏览器指纹的请求,然后把它叫作自动化即可。问题在于,这样的数字无法支撑决策,因为没人知道其中有多少是真实的。
Proof of Actor 的设计目标是让每个数字都经得起质疑。verified 结果来自确实通过的检查。declared 会被标记为 declared。inferred 会被标记为 inferred。Unknown 会如实报告为 Unknown。当你向管理层、安全团队或客户展示 agent 流量时,你可以准确说明每个数字的来源。
这也让分析随着时间推移更有价值。随着 agent operator 采用基于 RFC 9421 HTTP Message Signatures 的签名请求,以及 Web Bot Auth 这类标准工作在 IETF webbotauth working group 中继续推进,你的更多流量会进入 verified 依据。你的图表会更清晰,而你的阅读方式无需改变。
先观察,再决定
每次 Proof of Actor 部署都从 observation 模式开始。结果会被记录,分析会逐步填充,而你的应用会继续按原样响应。你的团队会利用这段时间建立基线,将结果与已知结果对照,并找出最适合首先应用 policy 的路由。
当你准备好之后,就为某个工作流启用 policy,衡量其效果,然后再逐步扩展。因为安装了 Proof of Actor,所以不会有任何内容被阻止。每一个 enforcement 决定都由你掌控。
加入创始开发者计划
Proof of Actor 目前处于 private beta。入选的 founding developer team 可在约定的使用限制内获得最长 12 个月的免费访问,以换取实际使用中的产品反馈。你将获得直接集成支持、对新能力的早期访问,以及对路线图的影响力。
如果你希望拥有整个团队都能信任的 AI agent 流量分析,请 申请 early access。告诉我们你的应用、你最关心的路由,以及你希望分析回答的问题。
了解 Proof of Actor,查看 how it works,或阅读 what the evidence can establish。
来源
- Overview of OpenAI crawlers, OpenAI.
- Known bot-traffic exclusion, Google Analytics Help.
- RFC 9421: HTTP Message Signatures, IETF, 2024年2月。
- Web Bot Auth (webbotauth) working group charter, IETF。