Cloudflare 位于相当大一部分 Web 流量的前端。对许多团队来说，它是 CDN、DNS provider、firewall，以及抵御滥用自动化的第一道防线，集于一处。它的 bot 产品就是为这个位置设计的: 它们尽早看到流量，判断是否应当被 challenge 或阻止，并让站点所有者控制爬虫，包括 AI crawler，如何访问其内容。
你的应用要回答的是另一个问题。一旦请求通过边缘，你的代码就需要知道是谁或什么在执行操作，以便选择合适的体验。这是一个人、一个与 AI assistant 协作的人、一个代表客户行动的 agent，还是证据无法解释的东西？你的代码应该有多确定？
这正是 Proof of Actor 的设计目标。它是一个聚焦的、应用层的能力，返回带有明确 evidence basis 的 actor class，并交给拥有该决策的代码。本文以 Cloudflare 截至 2026 年 11 月的公开文档为依据，对两者进行客观比较，帮助你看清各自的适用场景。
简要结论
| Cloudflare bot products | Proof of Actor | |
|---|---|---|
| 适用目标 | 保护边缘处的基础设施和内容 | 为你的应用提供用于产品和策略决策的 actor 上下文 |
| 运行位置 | Cloudflare 的 edge network，位于你的 origin 之前 | 你的 server、edge layer、获批页面、HTTP API 或 MCP server |
| 主要输出 | challenges 和 rule actions; 对于 Enterprise Bot Management，提供 1 到 99 的 bot score 以及 bot fields | Human、Human + AI、Agent 或 Unknown，外加 basis: verified、declared、inferred 或 unknown |
| 输出落点 | Cloudflare rules、analytics 和 Workers | 你的应用代码，以及按 route 和 workflow 划分的 actor analytics |
| AI 辅助的人 | 在 bot score 中不是单独类别 | 其自身类别 Human + AI，在声明或通过受支持的 integration 观察到时适用 |
| 不明确流量 | 通过边缘规则打分并处理 | Unknown 作为一等结果，由你按 route 设定回退方案 |
| 签名 agent | Web Bot Auth verification 和 signed agent signals | RFC 9421 signature checks，在你的代码中作为 verified basis 报告 |
| MCP server 和 API 调用方 | 作为边缘 HTTP 流量受到保护 | 位于处理工具调用或 API request 的 server 内部的 caller context |
| CDN 依赖 | 适用于穿过 Cloudflare network 的流量 | 与你是否使用 CDN 无关 |
| 安装后的默认状态 | 取决于你启用的产品和设置 | observation mode; 在你添加 policy 之前不会改变任何内容 |
本页其余部分将逐行说明。
在寻找面向 AI agent 流量的 Cloudflare Bot Management 替代方案？
大多数在寻找替代方案的团队，并不是对边缘能力不满意。他们面对的是一个边缘并未设计去回答的新问题: 一个 AI agent、一个 AI 辅助的人，以及一个普通访客，可能都在访问同一个注册表单、API route 或 MCP tool，而产品需要对他们区别对待。下面做一个清晰拆分。
Proof of Actor 替代决策的地方。 如果你现在使用 bot scores 或 bot fields 来驱动产品行为，例如给 AI 草拟的提交打标签、将 agent 路由到结构化 endpoint，或者为某个具体 workflow 中不明确的调用方选择回退方案，那么 Proof of Actor 更适合承担这项工作。它会把 actor class, Human、Human + AI、Agent 或 Unknown，以及 evidence basis，直接返回给你的应用代码。路由和策略决策回到已经了解每条 route 作用的代码中，而且无论你使用哪家 CDN，工作方式都一样。
Proof of Actor 补充 Cloudflare 的地方。 Proof of Actor 不是网络安全产品。根据 Cloudflare 截至 2026 年 11 月的文档，其 DDoS protection 会自动检测并缓解攻击，并且在所有 plan 上可用，而其 Web Application Firewall 会依据托管规则和自定义规则检查进入的 web 和 API request。保留这一层。大流量攻击、利用尝试和滥用自动化应该在到达 origin 之前就被阻止，Proof of Actor 并不试图承担这一职责。
所以，对“这是否是替代方案？”的直接回答是: 对于应用中的 actor classification 和按 route 的 routing，答案是是；对于边缘 DDoS 和 WAF protection，答案是否。大多数生产团队最终会同时保留两层，各自做它原本设计要做的事。
Cloudflare 的 bot products 是为哪些场景构建的
根据 Cloudflare 截至 2026 年 11 月的文档，它提供三种面向 bot 的产品:
- Bot Fight Mode，适用于 Free plan，通过一个开关对整个 domain 中检测到的 bot traffic 发起 challenge。
- Super Bot Fight Mode，适用于不包含 Bot Management add-on 的 Pro、Business 和 Enterprise plan，它增加了可按 bot category 配置的 actions。
- Bot Management for Enterprise，它增加逐请求 bot scores、自定义规则、按 endpoint 处理以及更详细的 analytics。
在 Cloudflare 的表述中，bot score 是一个从 1 到 99 的分数，用来表示一个 request 来自 bot 的可能性，其中 1 表示高度确信该请求由自动化产生，99 表示高度确信它来自人类。Cloudflare 文档说明，粒度化分数对已购买 Bot Management 的 Enterprise 客户可用，而其他 plan 看到的是分组结果，例如 automated、likely automated、likely human 和 verified bot。bot score 也可以用于 WAF custom rules 中，对 request 执行 block、challenge 或 allow，而且在 Workers 中同样可用。
Cloudflare 还维护 verified bots，其文档将其描述为那些清楚说明自己是谁以及自己在做什么的 bot 或 agent，例如 search engine crawler、monitoring services 和 user-driven agents。验证依赖诸如 Web Bot Auth signature 或 IP validation 之类的方法，并结合非滥用行为。
对于 AI 流量，AI Crawl Control 让站点所有者可以查看哪些 AI service 访问了其内容，允许或阻止单个 crawler，并跟踪 crawler 遵守 robots.txt 的程度。Cloudflare 文档将其列为在所有 plan 上可用。
这些工具非常适合它们被设计的任务: 在边缘决定哪些自动化流量可以到达你的 origin 和内容。
各自运行在哪里，输出落到哪里
最实际的区别是位置。
Cloudflare 的 bot products 运行在 Cloudflare network 上，位于你的 origin 之前。它们的输出落在 Cloudflare 控制生效的地方: WAF custom rules、bot analytics，以及根据 Cloudflare bot management variables reference, 的 request.cf object in Cloudflare Workers。那是决定请求应当被阻止还是被 challenge 的正确位置。
Proof of Actor 运行在你的应用逻辑所在之处: Node.js middleware、Next.js、你控制的 edge layer、你批准页面上的 browser collector、通用 HTTP API，或者你的 MCP server。它的输出以结构化结果的形式进入你的应用代码，并且进入按 route 和 workflow 划分的 actor analytics。详情见 integration paths。
这个位置对产品决策很重要。你的代码知道某条 route 属于哪个 workflow，知道你的自有 assistant 是否执行了某个操作，知道客户端是否已声明自己，以及该 route 的业务影响是什么。像“为已验证的 agent 提供结构化 endpoint，让人类走正常流程，为 AI 辅助的提交添加标签”这样的按 route 决策，应当放在这些知识旁边。Proof of Actor 正是把 actor 上下文放在这里，而且因为它运行在你的技术栈中，而不是某一家 provider 的 network 里，所以无论你使用 Cloudflare、其他 CDN，还是完全不使用 CDN，它都能一致工作。
分数与带 basis 的 class
分数是一个高效的保护规则输入: 设定阈值，并在高于或低于该阈值时采取行动。它的设计目标是回答请求有多大可能是自动化的。
产品决策需要更丰富的答案。Proof of Actor 返回四种 class 之一:
- Human: 可观察信号表明这是人类主导的交互。
- Human + AI: 某个人在 AI 辅助下执行了交互，这一事实已声明或通过受支持的 integration 观察到。
- Agent: 自动化或 agent 来源的交互。
- Unknown: 证据不足以支持可靠判断。
每个结果还会带上其 evidence basis: verified，例如基于已发布 key 校验通过的 RFC 9421 HTTP Message Signature；declared，表示由客户端或你的应用声明；inferred，明确标注为推断；或 unknown。你的团队可以读取每个结果并看到其背后的证据，这正是当决策影响的是客户体验而不是攻击面时所需要的东西。
AI agents、signed agents 和 AI 辅助的人
Cloudflare 一直在投入 agent verification。根据其截至 2026 年 11 月的文档，Cloudflare 支持 Web Bot Auth，这是一种基于 RFC 9421 的认证方式，使用 HTTP messages 中的 cryptographic signatures 来验证 bot 和 agent。其文档描述了一个 signed agent signal，对拥有 Bot Management 的 Enterprise 客户暴露为 cf.bot_management.signed_agent 字段，并且从 2026 年 7 月 1 日起提供 Direct versus Intermediary access 字段，用于区分单一操作者 bot 与许多终端用户都可以操作的 agentic services。Cloudflare 还在各个 plan 上提供 AI crawler 和 agent 访问策略。
Proof of Actor 将签名请求视为更大图景中的一部分。当请求携带一个已通过已发布 key 校验的有效 HTTP Message Signature 时，结果会是带有 verified basis 的 Agent，并直接传递到你的 route handler。关于 verifying signed agent requests 的指南展示了这一流程。有效签名只能证明是哪把 key 签署了请求，并不能证明该 agent 被授权做什么，因此 authorization 应当留在你的应用中处理，这才是它该在的地方。
更大的区别在于中间的那些人。有些用户会与 AI assistant 一起工作: 起草 support ticket、填写表单、推进 onboarding。边缘 bot scoring 的设计目标是区分自动化与人类，它没有理由为这一群体单独划分类别。而你的产品往往需要。Proof of Actor 会将 Human + AI 作为独立 class 进行报告，但仅在辅助关系已声明或通过受支持的 integration 观察到时才会这样做，这样你就可以给 AI 草拟的提交打标签，衡量 AI 辅助用户如何通过某个 workflow，或者为他们提供更顺畅的路径。更多内容见 AI-assisted interaction 词条。
Unknown 是结果，不是阈值
每个检测系统都会遇到它无法解释的流量。在边缘，无法明确判断的流量会被根据分数所在规则进行处理。这样可以让保护策略在整个 zone 内保持一致。
在应用内部，一个设置很少能适用于所有 route。针对公开文档页面的不明确请求，和针对修改账户凭证的不明确请求，应当得到不同处理。Proof of Actor 会将 Unknown 作为一等结果，跟踪你的 Unknown rate 随时间的变化，并允许你按 route 选择回退方案: 对公开内容放行，对账户变更保持现有检查，对高影响操作送审。关于 handling Unknown traffic 的指南介绍了这些模式，而 Unknown classification 词条解释了为什么诚实的 Unknown 优于被迫猜测。
MCP servers 和 APIs
Cloudflare 保护 MCP servers 和 APIs 的方式与其保护穿过网络的任何 HTTP traffic 相同。这很有价值，而且发生在请求到达你的 service 之前。
而 MCP server 或 API 通常接下来还需要的是处理器内部的 caller context: 是哪个 agent 在调用这个 tool，这个身份是已验证的还是仅仅已声明的，以及这个 tool call 应该被 allow、adapt、rate-limit 还是送去 review。Proof of Actor 提供 MCP server integration 和通用 HTTP API，使这些上下文能够在 tool 或 endpoint logic 运行的位置到达。示例见 MCP server caller identification 和 APIs use case。
如何将两者结合使用
最强的方案是让每个工具各自承担自己的层:
- 在边缘，Cloudflare 吸收攻击、质询滥用自动化、验证已知 bot，并执行你的 AI crawler 策略。
- 在你的应用中，Proof of Actor 将到达你的流量分类为 Human、Human + AI、Agent 或 Unknown，并附带 basis。
- 在你的代码中，按 route 的 policy 使用这些上下文来 allow、adapt、challenge、send for review 或 rate-limit，并为 Unknown 提供明确的回退方案。
- 在你的 analytics 中，产品和安全团队可以看到每种 actor class 使用了哪些 route 和 workflow。
Proof of Actor 从 observation mode 开始，因此在 Cloudflare 后面接入它，第一天不会改变任何行为。你可以看到真实的 actor mix，针对真实流量预览 policy，并一次只对一条 route 执行 enforcement。关于 rolling out actor-aware policies safely 的指南会逐步说明。Proof of Actor 不做身份检查、KYC 或 biometrics；它报告是谁或什么在执行操作，然后把决策留给你。
何时选择哪个
当你的主要需求是边缘防护时，选择 Cloudflare 的 bot products: 在请求到达 origin 之前阻止滥用自动化，在整个 zone 内质询可疑流量，并控制 AI crawler 如何访问你的内容。
当你的主要需求是应用层 actor 上下文时，选择 Proof of Actor: 了解每条 route 是由人类、AI 辅助的人还是 agent 在使用，查看每个结果背后的证据，妥善处理 Unknown，为 MCP server 和 API handler 提供 caller context，并编写不依赖于 CDN 的按 route 产品策略。
如果你运营的是生产环境的网站、API 或 MCP server，你很可能同时需要这两种答案，这也是它们能够在同一技术栈中和谐共存的原因。更广泛的类别对比见 Proof of Actor vs bot management。
开始使用
Proof of Actor 目前处于 private beta。通过 founding developer program，获选团队可在约定的使用限制内获得最长 12 个月免费，且不会自动计费。提交 申请早期访问，并告诉我们你最希望先理解的是哪个 application、API 或 MCP server。
本页关于 Cloudflare 的产品信息基于 Cloudflare 的公开文档，包括 bot score reference 和 Web Bot Auth reference、DDoS protection overview 以及 WAF overview，截至 2026 年 11 月。
Cloudflare 是 Cloudflare, Inc. 的商标。