对比

Proof of Actor 与 bot management: 不同的问题，一个技术栈

Bot management 保护你的基础设施免受滥用自动化影响。Proof of Actor 为你的应用提供所需的 actor 上下文，让它可以以不同方式服务人类、AI 辅助用户和 agent。以下是它们的对比，以及它们如何协同工作。

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

在大多数互联网历史中，自动化流量在安全栈里只有一个职责: 被识别并被拦截。Bot management 就是围绕这个职责发展起来的。它位于你的基础设施边缘，对请求进行评分，并拦截或挑战那些看起来有滥用迹象的流量。它非常擅长这件事，你也应该继续使用它。

AI agent 改变了应用需要了解的内容。如今，越来越多的自动化请求来自代表真实客户行动的 agent: 一个比较方案的助手、一个提交支持工单的 agent、一个调用你的 MCP server 来完成任务的客户端。与此同时，许多人也在 AI 助手的陪伴下使用你的产品。这些不是攻击。它们是用户，应该得到合适的体验，而不是一个拦截页面。

这正是 Proof of Actor 所填补的空白。本页会清楚地比较这两类方案，让你看清各自适合的位置。

	Bot management	Proof of Actor
核心问题	这个请求是否应该被拦截?	是谁或什么在行动，以及证据是什么?
运行位置	在边缘，在你的应用之前	在你的应用内部、API 或 MCP server 中
典型输出	允许、拦截或挑战; 通常还会给出一个分数	Human, Human + AI, Agent 或 Unknown，外加一个依据
将 AI 辅助的人视为	通常与其他人类没有区别	一个独立类别，Human + AI
将不明确流量视为	通常会被挑战或拦截	Unknown，并且可按路由选择回退处理方式
谁决定响应	边缘规则集	你的应用代码
安装后的默认行为	强制执行	观察; 在你添加策略之前不会改变任何内容
最擅长的场景	阻止凭证填充、滥用抓取和大规模流量攻击	面向每一种 actor 的产品、分析和策略决策

两个不同的问题

Bot management 回答的是一个保护问题。它的目标是把滥用自动化挡在你的基础设施、账户和库存之外。它收集的每一个信号都是为了这个目标服务，而它的输出是一个决定: 放行请求、拦截请求，或者在请求前加一个挑战。

Proof of Actor 回答的是一个理解问题。它的目标是告诉你的应用每次交互背后是谁或什么在驱动，这样你就可以决定如何服务它。它的输出不是对请求的裁定，而是带有证据的分类:

Human: 可观察信号表明这是由人类主导的交互。
Human + AI: 该交互由人发起，并有已声明或已观察到的 AI 辅助。
Agent: 由自动化或 agent 发起的交互，且由可验证身份或合理推断支持。
Unknown: 证据不足以做出可靠判断。

每个结果还会说明其 evidence basis: Verified、Declared、Inferred 或 Unknown。这才是产品决策真正需要的信息，而保护分数并不是为承载这些信息而设计的。

它们分别运行在哪里

Bot management 通常运行在网络边缘或反向代理中，位于其他一切之前。这个位置非常适合做保护。它能尽早看到流量，在攻击产生成本之前吸收它们，并保持你的源站服务器干净。

Proof of Actor 运行在你的应用逻辑所在的位置: 服务器中间件、Next.js、你控制的边缘层、已批准的浏览器集成、通用 HTTP API，或者你的 MCP server。这个位置让它能够接触到你的应用已知的信息: 正在调用哪个 route，它属于哪个工作流，你自己的助手是否执行了某个动作，以及客户端是否声明了自己。完整列表请参见 integration paths。

因为二者运行在不同位置，所以它们不会争夺同一项职责。一个请求可以先通过你的 bot management，到达你的应用，然后再获得会影响响应的 actor 上下文。

分数与证据

许多保护产品会用分数来表达判断。分数很适合做拦截决策: 设定阈值，高于阈值就采取行动。可当问题变成“这个 actor 应该获得什么体验?”时，它就没那么有用了。

分数不会告诉你，一个低风险请求是来自人类、与助手协作的人，还是一个行为良好的 agent。它不会告诉你结论中哪些部分是已验证的，哪些部分是推断出来的。而且，如果没有把“我们不知道”强行塞进一个数字里，它也无法表达这一点。

Proof of Actor 保留了这些区分。一个 Verified 的 agent 结果，意味着请求签名已经与已发布的密钥进行了校验，例如通过 HTTP Message Signatures。一个 Declared 的结果表示客户端或你自己的应用已声明了这一点。一个 Inferred 的结果会被标注为推断。Unknown 则是一个一等答案，而不是隐藏的默认值。你的团队可以读取每个结果，并准确看到它基于什么。

AI 辅助的人不是 bot

在大多数应用中，增长最快的人群是与 AI 协作的人。他们在助手帮助下起草消息、填写表单，并在 AI 工具的陪伴下使用你的产品。保护工具并不是为把他们与其他人类区分开而设计的，也没有必要这么做。

你的产品往往需要这么做。你可能希望给 AI 起草的支持工单打标签，以便交给合适的团队处理，衡量 AI 辅助用户如何完成注册流程，或者为他们提供更顺畅的路径。Proof of Actor 为这类人群提供了独立类别 Human + AI，并且只有在辅助已声明，或通过受支持的集成可被观察到时才会报告它。更多内容请参见 AI-assisted interaction 词条。

Unknown 是答案，不是威胁

任何分类器都会遇到它无法解释的流量。保护系统通常会倾向于谨慎，因此不明确的流量往往会被挑战。这在边缘是合理的选择。

但在你的应用内部，单一的谨慎默认值往往不是正确选择。一个指向公共文档页面的 unknown 请求，与一个试图更改账户密码的 unknown 请求，应该得到完全不同的处理。Proof of Actor 会把 Unknown 作为独立结果返回，并允许你按 route 设置回退策略: 在公共页面放行，在账户变更上保留现有检查，在高影响操作上将其路由到审查。关于 handling Unknown traffic 的指南会逐步说明这些模式。

谁来决定响应

对于 bot management，边缘处的规则集来决定。这种方式高效，并且能让你的各个属性上的决策保持一致。

对于 Proof of Actor，你的应用来决定。产品提供 actor 上下文；你的代码应用策略。你可以为已验证的 agent 提供结构化 API，而不是面向人类设计的页面；为人类会话保留标准体验；为 AI 辅助提交打标签；并在你的条件要求时，对敏感操作要求更强的凭据。策略按 route、按 actor 类别、按依据编写，并与其余业务逻辑放在一起。

先观察

Bot management 通常是为了强制执行而安装的，因为它的全部价值就在于阻止滥用。

Proof of Actor 从 observation mode 开始。安装它不会改变你的应用行为。你可以按 route 看到真实的 actor 构成，审查证据，预览策略对真实流量的影响，并且只在准备好时才逐步强制执行，一次一个 route。关于 rolling out actor-aware policies safely 的指南会介绍整个过程。

两者如何协同工作

最稳妥的方案是同时使用两者，并把它们放在各自的层中:

在边缘层，bot management 会拦截凭证填充、滥用抓取和大规模流量攻击。
在你的应用中，Proof of Actor 会把通过的流量分类为 Human, Human + AI, Agent 或 Unknown，并附带其依据。
在你的代码中，策略会利用这些上下文来选择体验: 为已验证的 agent 提供结构化 API，为人类提供正常流程，为 AI 辅助提交打标签，为 Unknown 提供明确的回退处理。
在你的分析系统中，你的团队可以看到每种 actor 类别使用了哪些 route 和工作流，因此产品和安全团队能基于同一视图开展工作。

把边缘决策和 actor 结果记录在一起，会让整张图更加完整: 保护做了什么，以及实际行动的是谁。

何时选择哪一个

当你的主要问题是滥用时，选择 bot management: 账户接管尝试、库存囤积、激进抓取或流量洪泛。

当你的主要问题是用户时，选择 Proof of Actor: agent 已经在多大程度上使用你的产品、哪些 agent 正在调用你的 API 或 MCP server、AI 辅助的人在哪些地方遇到困难，以及哪些 route 需要 actor-aware 策略。

运营生产环境应用、API 或 MCP server 的大多数团队都需要回答这两个问题，因此这两者属于同一个技术栈。

开始使用

Proof of Actor 目前处于私有 beta。入选的创始开发者团队可在约定的使用限制内获得最长 12 个月的免费访问，并由开发该产品的团队提供直接支持。请申请抢先访问，并告诉我们你想理解的应用和交互。

面向开发者

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 会取代 bot management 吗?

不会。Bot management 会在流量到达你的应用之前拦截滥用自动化，例如凭证填充、滥用抓取和大规模流量攻击。Proof of Actor 运行在你的应用内部，为产品和策略决策提供 actor 上下文。两者都要保留。

为什么不直接用 bot score 来做产品决策?

Bot score 的设计目的是回答是否应当拦截一个请求。它通常不会说明一个人是否在与 AI 协作、是哪个 agent 在调用，或者这个分数基于什么证据。Proof of Actor 会返回一个类别和明确的依据，而这正是产品决策所需要的。

这两者可以共享信号吗?

可以。你的应用可以把边缘控制的结果与 Proof of Actor 的结果一起记录下来，这样你的团队就能看到同一个请求的保护决策和 actor 上下文。

Proof of Actor 会阻断流量吗?

不会。它从观察模式开始，在你编写策略之前不会改变任何内容。强制执行始终由你自己的应用代码负责。

我应该先添加哪一个?

如果你正面临活跃滥用，先从 bot management 开始。如果你想理解并服务已经在使用你产品的人类、AI 辅助用户和 agent，就添加 Proof of Actor。大多数生产团队最终都会同时使用两者。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？联系创始人