跳转到主要内容
AI 代理检测

面向网站的 AI 代理检测，并附带每个结果背后的证据

查看你的网站上哪些交互来自人、与 AI 协作的人、自主代理，或证据暂时无法识别的来源。每个结果都会显示其依据。

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

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

你的网站现在不只有一种访客

在大多数网络历史里，网站都可以假设一个简单模型: 一个人打开浏览器，四处点击，然后也许登录。分析、速率限制、新手引导流程和安全检查，都是围绕这个人设计的。

这个模型已经不再符合真实流量。如今，一个网站同时会服务于独立浏览的人、让 AI 助手代为总结或填写内容的人、代表他人读取页面并调用 endpoint 的自主代理，以及大量爬虫和脚本。AI 提供商本身也记录了其中一些访客: 例如，OpenAI 为其搜索爬虫、训练爬虫，以及在 ChatGPT 用户提问时访问页面的 fetcher 分别发布了独立的 user agent (OpenAI crawler documentation)，Anthropic 也为 ClaudeBot、Claude-User 和 Claude-SearchBot 做了类似说明 (Anthropic crawler documentation)。其中一些访客是受欢迎的。有些需要不同的体验。有些在执行任何敏感操作前需要更仔细的审查。

问题在于，大多数这些交互乍看都很相似。登录只能告诉你正在使用哪个账号。它并不能告诉你，是人类在点击，还是助手通过该会话在行动，或者是某个自动化客户端在为别处的用户读取你的定价页。面向网站的 AI 代理检测就是用证据弥补这一差距，这样你的团队就能针对不同类型的 actor 做出适当响应，而不是把所有流量一概而论。要了解相关信号的实际过程，请阅读 如何判断网站流量是否来自 AI 代理，并查看 网站 use case，了解它在生产站点上的表现。

为什么单一 bot 分数不够

许多工具用一个数字来回答这个问题: bot 分数、风险分数、或者声称能描述访客有多像人类的百分比。它的吸引力很明显。一个数字很容易写进规则里。

问题是，单一数字会掩盖推理过程。当某个分数说某个会话大概率是自动化时，你的团队看不到这个结论是基于已验证签名、任何人都能复制的 user-agent 字符串，还是也会匹配快速打字的人类模式。当这个分数驱动阻断或挑战时，你要承担它的每一个错误，却没有办法向客户、同事或审计人员解释原因。

Proof of Actor 采用了不同的方法。每个结果都属于四个清晰类别之一，详见 Human、AI 辅助还是代理: 应用流量分类法，并且每个结果都会说明其依据。你可以同时看到结论和证据，这意味着你可以信任强结果，质疑弱结果，并构建与证据质量相匹配的策略。

如何用四步在你的网站上检测 AI 代理

你可以用现有工具开始在你的网站上检测 AI 代理。这四个步骤不依赖厂商，无论你是否使用 Proof of Actor 都适用; 博客文章 如何判断网站流量是否来自 AI 代理 对每一步都有更深入的说明。

  1. 列出会主动声明自己的代理。 在你的 server 或 CDN logs 中搜索 AI 提供商发布的 user agent。OpenAI 文档说明了 OAI-SearchBot、GPTBot 和 ChatGPT-User，并指出当用户向 ChatGPT 提问时，ChatGPT-User 会访问页面，而不是自动爬取。Anthropic 文档说明了 ClaudeBot、Claude-User 和 Claude-SearchBot。这会为你提供按 route 划分的第一层已声明代理流量视图。
  2. 验证声明，而不是相信字符串。 user agent 是自我声明的，很容易被复制。要用运营方自己的验证方法来核对它: Google 说明了先做反向 DNS 查询，再做正向 DNS 查询，并结合已发布的 IP 范围文件来验证 Googlebot (Google: verifying Googlebot)；Bing 对 Bingbot 也描述了相同的反向和正向 DNS 检查 (Bing: verifying Bingbot)；OpenAI 为其每个 user agent 发布了 IP 范围文件。对于会用 HTTP Message Signatures 签名其请求的客户端，可按 RFC 9421 的定义，用该签名与运营方发布的 key 进行校验。
  3. 为每个结果标注其依据，并保留 Unknown。 记录每个结论是 verified、declared 还是 inferred。匹配不到任何已验证或已声明代理、也没有清晰人类模式的流量，应标注为 Unknown，而不是强行归入 human 或 bot。这一步把有用报告和猜测区分开来。
  4. 先按 route 观察，再采取行动。 先按 route 和 workflow 观察几周结果: 公共内容、注册、账户设置、API。之后再为 actor 上下文最重要的 route 编写一个窄范围策略，并为 Unknown 设置明确的兜底。

Proof of Actor 会在你的应用中自动化这些步骤: 它收集集成可见的信号，返回带有依据的分类，按 route 跟踪 Unknown，并把策略交给你的代码决定。

Proof of Actor 如何检测网站上的 AI 代理

Proof of Actor 围绕一条简单路径构建: 你的集成可以观察到的信号、带明确依据的分类，以及始终由你掌控的决策。完整流程可以在 How It Works 页面查看。下面是简版说明。

来自你集成的信号

每种集成都只看到其上下文允许的内容。服务器端集成可以看到请求上下文、协议细节，以及在客户端支持时看到请求签名。浏览器集成可以看到其运行页面上的交互信号。应用还可以记录自身声明，例如用户标记某内容是借助 AI 辅助起草的，或者某个 agent 客户端声明自己的身份。

Proof of Actor 只使用实际存在的证据。它不会假装看见你的网站无法观察到的东西。

四个有明确含义的类别

每次交互都会落入以下四个类别之一:

  • Human: 可观察到的信号表明这是人类驱动的交互。
  • Human + AI: AI 辅助已被声明，或通过能够看到它的受支持集成被观察到。
  • Agent: 自动化或代理来源的交互，并由可验证身份或谨慎限定的推断支持。
  • Unknown: 可用证据不足以支持可靠判断。

每个类别都有清晰定义和清晰边界。Human 结果不等于已验证身份。Agent 结果不表示该代理已获授权。Unknown 结果不是指控。完整分类法可在 Detection & Limitations 页面查看。

每个结果都有依据

除了类别之外，每个结果还会附带其依据: Verified、Declared、Inferred 或 Unknown。携带来自已发布 key 的有效签名的请求，在该次检查中属于 verified。自我标识为代理的客户端是 declared。与自动化一致的行为模式属于 inference。正因为有这种区分，你的策略才能精确。一个在只读 route 上带有已验证签名的代理，和一个在账户设置页面上自我声明的客户端，不应该被同样对待，而使用 Proof of Actor 时，它们也不必被同样对待。evidence basis 词条对此有更详细的说明。

你的团队能得到什么: Detect、Understand、Route

Proof of Actor 是一个产品，包含三个协同工作的能力。

Detect

收集你的集成可获得的 actor 信号，并将已验证的断言与基于行为的推断区分开来。Unknown 流量会作为独立类别保持可见，而不会被并入猜测。你始终清楚哪些交互可以自信地说明，哪些还需要更多证据。

Understand

在上下文中查看你的 AI agent traffic。按 route 和时间探索交互类型，跟踪 Human、Human + AI、Agent 和 Unknown 活动的趋势，并打开任意分类，查看已知内容、未知内容，以及结果基于什么。这正是产品、平台和安全团队获得一幅共享且可解释的网站使用图景的地方。

Route

使用你自己的策略，对特定交互执行 allow、adapt、challenge、review 或 limit。为读取文档的已验证代理提供结构化响应。对人类驱动的会话保持标准体验。当你自己的条件要求时，对敏感账户变更提出更强校验。为 Unknown 结果和超时按 route 设定明确兜底。Enforcement 始终发生在你的应用中，并且是在你的团队确认的策略之下。

为了适配你的网站，而不是替换它

Proof of Actor 作为你现有工具栈的补充运行。它不会替代你的身份验证、授权模型或现有的滥用防护。它为这些能力增加 actor 上下文。

一个典型的网站集成会从 actor 上下文最重要的 route 开始: 代理大量读取的公共内容、注册和新手引导流程、账户设置和其他敏感操作，以及支撑站点的任何 API。founding 团队会与我们的工程师一起选择这些 route，确认纳入范围的信号，并在任何代码上线前确认数据处理方式。

由于决策层位于你的代码中，你始终掌控体验。你可以先在内部仪表盘中展示结果数周，而不更改任何规则，然后只为一个 route 启用一个窄策略，之后在结果赢得信任后再逐步扩展。关于 处理 Unknown 流量 的指南会讲解如何设计这些首批规则。

先以观察模式开始

从 AI 代理检测中最快获得价值的方法，是先观察，而不是阻断。在观察模式下，Proof of Actor 会记录结果，而你的网站会保持完全相同的响应行为。随后你的团队可以将分类结果与已有明确理解的结果进行对照: 工单、已知集成、内部工具，以及你已经识别的爬虫。

在任何 enforcement 之前，这会给你三样东西:

  1. 基线。 你的流量中有多少是人类驱动、AI 辅助、代理驱动或未知，按 route 划分。
  2. 对证据的信心。 你的网站上哪些信号更强，以及哪些覆盖范围需要扩展。
  3. 更好的策略。 基于真实模式而不是假设设计的规则，并在影响任何人之前审查误报。

当某项策略准备就绪后，你只为它所设计的特定 workflow 启用它，并且始终保留随时调整的能力。

为什么基于证据的检测优于不透明分数

网站已经在并行服务代理、助手以及与 AI 协作的人。真正处理好这件事的团队，不会是那些过滤最激进的团队，而会是那些能够解释自己决策的团队。

基于证据的结果能提供这种解释。当支持人员问为什么某个用户看到了额外验证步骤时，你可以指出所适用的证据和策略。当代理运营方问为什么其已签名请求得到了结构化响应时，你可以展示已验证的依据。当证据较弱时，结果会显示 Unknown，而你的兜底会以你明确选择的方式处理它。

这种方法也能随着网络的发展而扩展。随着越来越多的代理运营方为其请求签名，以及 IETF 的 Web Bot Auth working group 等标准工作在 HTTP message signatures 的基础上推进自动化客户端的加密身份验证，更多流量会从 inferred 或 unknown 转为 verified，而你的策略也会在无需重写的情况下变得更精确。

加入 founding developer program

Proof of Actor 目前处于 private beta，面向少量应用团队。入选的 founding developer 可在约定的使用限制内获得最长 12 个月的免费访问，以换取实际使用反馈。你将获得来自我们工程师的直接集成支持、随着能力可用而逐步开放的早期访问，以及对我们下一步构建内容的真实影响力。

如果你的网站同时服务于人、AI 辅助用户和代理，并且你希望在决定下一步发生什么之前先知道是谁在使用它，申请早期访问。告诉我们你的网站情况，以及你最想理解的那种交互，我们会评估它是否适合当前 beta。

想先查看细节? 请浏览 Proof of Actor，阅读 how it works，或查看到底 证据能建立什么，不能建立什么。

来源

面向开发者

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 集成指南

常见问题

Proof of Actor 如何与面向网站的 AI 代理检测协作?

Proof of Actor 会收集通过你的集成可获得的信号，例如请求签名、客户端声明和交互信号，并返回带有其依据的分类: Verified、Declared、Inferred 或 Unknown。

安装后会阻止任何访问者吗?

不会。Proof of Actor ابتدا 以观察模式运行。你的网站会完全按原样运行，你的团队审查结果，然后再决定是否应用任何策略。

它能判断某人在另一个标签页里使用了 AI 吗?

没有任何网站可以看到另一个标签页或另一台设备中的活动。Proof of Actor 只会在已声明或通过受支持的集成可观察到时报告 AI 辅助，并且从设计上就会对其他情况保持如实。

当证据不清晰时会怎样?

结果会是 Unknown。Unknown 是一级结果，默认既不会被视为人类，也不会被视为恶意。你的策略决定每条 route 如何处理它。

Proof of Actor 是为谁打造的?

为运营 SaaS 应用、网站、API 和 MCP server，并希望在选择体验或访问策略之前先理解是谁或什么在执行操作的团队而设计。

我如何获得访问权限?

Proof of Actor 目前处于 private beta。你可以申请早期访问。入选的 founding developer 团队可在约定的使用限制内获得最长 12 个月的免费访问。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人