跳转到主要内容
未知流量

让未知自动化流量可见

大多数应用无法判断其自动化流量中很大一部分究竟是什么。Proof of Actor 将这部分流量作为独立类别保持可见，因此你可以衡量它、缩小它，并有意识地处理它。

获取抢先访问了解其工作原理
Toshendra Sharma

作者 Toshendra Sharma创始人兼 CEO，AgentCredia · Updated November 13, 2026

无人能命名的流量

仔细查看应用日志，你会发现一些难以解释的请求。它们来自没有浏览器上下文的客户端。它们的 user-agent 字符串要么通用、要么为空、要么是从常见浏览器复制来的。它们不会为请求签名。它们不会说明发送者是谁。其中一些是无害脚本。一些是代表真实用户工作的 Agent。一些则是你根本不希望提供服务的工具。

这就是未知自动化流量，大多数团队会用两种方式之一来处理它。要么它被悄悄算作人类流量，从而扭曲分析结果并放过有风险的活动。要么默认把它当作恶意流量，从而连同其他一切一起阻挡合法用户和 Agent。这两种做法有一个共同缺陷: 它们用假设代替了缺失的证据。

Proof of Actor 采取相反的观点。如果证据不足以支持可靠判断，正确答案就是 Unknown，而且 Unknown 应当是可见、可衡量、并被有意识地处理的。博客文章 为什么 Unknown 是 AI 流量的有效结果 对此做了完整说明。

为什么 Unknown 是一级结果

Proof of Actor 会将每次交互分类为四类之一: Human、Human + AI、Agent 或 Unknown。Unknown 不是错误状态，也不是产品中的空缺。它是一个有明确含义的刻意结果: 现有证据不足以支持可靠判断。

这种诚实带来实际收益。

  • 你的分析保持准确。 Human 和 Agent 的计数只包含有支持证据的交互，因此它们的含义与字面一致。
  • 你的覆盖范围可以被衡量。 每个 route 上 Unknown 的占比会清楚告诉你还需要在哪里补充证据。
  • 你的 policy 更安全。 不确定的情况会进入你选择的回退策略，而不是被默默当作可信，或凭猜测被阻止。

Unknown 绝不会被转换为 Human，也不会默认被当作恶意流量。你可以在 Unknown 分类 词条、检测与限制，以及 为什么 Unknown 是 AI 流量的有效结果 中了解更多。网站 和 APIs 用例展示了团队如何在实践中设置 Unknown 回退策略。

未知自动化流量从哪里来

了解来源，有助于你决定如何处理它。

未签名的自动化客户端

HTTP Message Signatures 中定义的请求签名，见 RFC 9421，是可选的，而 IETF 的 Web Bot Auth 工作组 仍在标准化自动化客户端应如何通过这种方式进行认证。没有签名时，客户端身份只能依赖它自己声称的内容。

复制或通用的 user-agent

user-agent 字符串很容易伪造。声称自己是知名浏览器或爬虫的客户端，可能确实如此，也可能只是在模仿它。user-agent 伪装 词条解释了为什么仅凭这个头部无法完成分类。这也是搜索引擎会单独说明验证方式的原因: Google 对 验证 Googlebot 提供了反向和正向 DNS 查询以及已公布 IP 段的方法，而 Bing 对 验证 Bingbot 也说明了相同的 DNS 检查。

没有集成的 route

如果某个 route 没有浏览器集成，也没有超出基础信息之外的服务端上下文，那么可观察到的内容就会少得多。这些 route 上的 Unknown 说明的是覆盖范围，不是威胁。

缺失或延迟的证据

超时、脚本被阻止，或者请求不完整，都可能导致结果缺少足够证据。Proof of Actor 会如实报告这一点，而不是补空。

Proof of Actor 如何让 Unknown 可管理

Proof of Actor 将工作组织为三项能力。每一项都能帮助处理未知自动化流量。

Detect: 保持 Unknown 独立

系统会检查信号，并按依据标记为 verified、declared、inferred 或 unknown。当这些信号不足以支持判断时，结果就会是 Unknown，并附带可用与不可用信息的摘要。不会凭空把它归入其他类别。

Understand: 看见 Unknown 存在于哪里

Understand 视图会在每个分解维度中展示 Unknown，按 route 和时间展开。你可以看到哪些 route 上的未知活动最多，在添加集成后它如何变化，以及单次交互当时有哪些证据。这会把模糊的担忧变成具体的地图。

Route: 为每个 route 选择回退策略

不同的 route 值得不同的回退策略。对许多应用来说，一个合理的起点是:

  • 公开页面和文档: 允许 Unknown，并使用标准 rate-limit。
  • 注册和 onboarding: 保持现有检查，仅在你自己的条件要求时加入 review。
  • 账户变更和其他敏感操作: 依赖你现有的认证和 step-up 控制，绝不依赖对 actor 的猜测。
  • 高影响的 API 操作: 要求你的 API 已经支持的更强凭证或控制。

关于 处理未知流量 的指南，会逐步说明如何设计这些回退策略，包括针对不同风险等级选择 fail-open 还是 fail-closed。

逐步缩小 Unknown

目标不是在一夜之间消除 Unknown，而是每个月都让它变少，而且原因正确。

  • 在重要位置增加集成。 在关键页面加入浏览器集成，在关键 route 上加入服务端集成，都能增加可用证据。
  • 支持签名请求。 随着 Agent 运营方采用 HTTP message signatures，原本 Unknown 的流量会变成已验证的 Agent 流量。
  • 在你自己的应用里记录声明。 当你的应用知道 AI 辅助参与其中时，就把它记录下来。这种证据精确且成本低。
  • 为 Agent 提供正式入口。 发布结构化的 agent 通道，会鼓励它们表明身份，而不是混入普通流量中。

由于 Proof of Actor 会按 route 跟踪 Unknown，你可以在数据中看到这些变化。

工作方式

每次交互都遵循同一条以证据为先的路径，完整说明见 工作原理: 你的应用接收请求或事件，集成在该上下文中收集可用信号，信号被标准化并以明确依据分类，结果被记录用于分析，然后你的应用应用自己的 policy 或只是观察。

超时和缺失的遥测会被明确处理。你的集成会使用你为该 route 选择的回退策略，而不会因为证据缺失就把结果升级为 Human。

几个月后的理想状态是什么样

善于处理未知自动化流量的团队，通常会达到同一种健康状态。Unknown 在每条重要 route 上都是已知量，并与 human 和 agent 活动一起显示在同一个仪表板中。每个 route 都有一份书面的回退策略，由 product、platform 和 security 团队共同确认。随着更多运营方签名请求，已验证的 agent 流量持续增长，这些 Agent 通过结构化通道提供服务，而不是抓取页面。敏感操作由应用已经信任的认证和 step-up 控制保护，actor 上下文只是额外输入，而不是门禁。

更重要的是，没人是在猜。当地有人问上周有多少流量是自动化流量时，答案会连同依据一起给出: 其中多少是 verified，多少是 declared，多少是 inferred，多少仍然是 Unknown。这是团队可以据此规划的数字。它也会改变与领导层的讨论，因为问题不再是 bot 是否有问题，而是哪些 route 值得投入更多证据，以及哪些回退策略需要进一步优化。

先从观察模式开始

Proof of Actor 默认不会阻止任何内容。在观察模式下，结果会被记录，而你的应用仍然按原样响应。你的团队可以看到每个 route 收到多少未知自动化流量，将其与已知结果进行比较，并基于真实模式设计回退策略。只有在团队确认适配后，才会一次启用一个 route 的 policy。

加入创始开发者计划

Proof of Actor 目前处于 private beta。入选的创始开发者团队可在约定使用额度内，获得最长 12 个月的免费访问，并通过我们工程师的直接集成支持，换取实际产品反馈。

如果未知自动化流量正在影响你的分析或安全决策，欢迎 申请早期访问。请告诉我们你的应用，以及 Unknown 影响最显著的 route。

探索 Proof of Actor，阅读 工作原理，或查看 证据可以确认什么。

来源

面向开发者

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human、Human + AI、Agent 或 Unknown。
basis
证据有多强：Verified、Declared、Inferred 或 Unknown。
evidence
结果背后的信号，让您的团队看清原因。

从观察模式开始: 将结果记录在日志旁边，在您选择 policy 之前不做任何更改。 阅读 Node.js 集成指南

常见问题

什么是未知自动化流量？

指现有证据无法可靠表明是人、借助 AI 的人，还是自主 Agent 在执行的活动，通常是没有浏览器上下文、未签名的客户端，以及通用或复制来的 user-agent 字符串。

为什么不直接阻止未知流量？

Unknown 不等于恶意。它包括合法客户端、注重隐私的浏览器，以及只是没有表明身份的工具。直接一刀切地阻止会造成真实损失。针对每个 route 设定明确的回退策略，效果要好得多。

Proof of Actor 会把 Unknown 变成 Human 吗？

不会。Unknown 结果始终保持 Unknown，包括证据缺失或检查超时的情况。是否采用回退策略，由你的 policy 为每个 route 决定。

未知流量能否随着时间减少？

可以。在更多 route 上增加集成、支持签名请求，以及在你的应用中记录声明，都会把流量从 Unknown 迁移到具有清晰依据的类别中。

我在哪里可以看到未知流量？

在 Understand 视图中，Unknown 在每个分解维度里都有自己的类别，按 route 和时间展示，并附带每次交互可用的证据。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人