CAPTCHA 的思路很简单: 在访客面前放一个人类能完成、机器不能完成的任务，然后让通过的人进入。多年来，这是一种合理的交换。人们多花几秒钟，而最糟糕的自动化会被拖慢。
但有三件事改变了这一点。机器已经能很好地完成这些任务。人们也开始厌倦反复作答。而一种新的访客出现了: 代表真实客户行动的 AI 代理，以及 与 AI 助手协作的人。一个问“你是人类吗？”的测试，对这两类对象都没有好答案。
Proof of Actor 采用了不同的方法。它不再对每个访客进行测试，而是告诉你的应用是谁或什么在执行操作，并提供结论背后的证据，然后让你的代码决定是否真的需要挑战。
简要说明
| CAPTCHA | Proof of Actor | |
|---|---|---|
| 核心问题 | 这个访客能通过人类测试吗？ | 是谁或什么在执行操作，以及证据是什么？ |
| 谁承担成本 | 每个看到挑战的访客 | 没有人；分类在后台完成 |
| 可能的答案 | 通过或失败 | Human、Human + AI、Agent 或 Unknown，外加 basis |
| 合法的 AI 代理 | 被阻止，或被迫绕过测试 | 被识别，并路由到正确的体验 |
| 使用 AI 助手的人 | 作为普通访客对待 | 一个独立的类别，Human + AI |
| 不明确的流量 | 必须通过同样的测试 | Unknown，并使用你按 route 选择的 fallback |
| 适用范围 | 你放置它的页面 | 你的集成覆盖的每一条 route |
| 安装后的默认行为 | 可见的 challenge | observation；在你添加 policy 之前不会发生变化 |
测试与证据
CAPTCHA 只能产生一位信息: 访客通过或未通过。它不会告诉你访客是谁、是否在与助手协作，也不会告诉你应当对结果有多大把握。而且它是通过要求访客付出劳动来生成这位信息的。
Proof of Actor 会生成一个分类及其 evidence basis。Verified 结果表示某个可验证的断言已被校验，例如请求签名与公开密钥的匹配。Declared 结果表示客户端或你自己的应用已声明该信息。Inferred 结果会被标注为推断。Unknown 表示证据不足以做出判断。你的团队可以读取每个结果并查看其依据，而访客不必做任何事。
对每个人都进行挑战的代价
每一次 challenge，都是加在你的优质用户身上的摩擦，目的是拖慢最糟糕的那部分用户。在注册页上，它会降低转化率。在结账页上，它会带来收入损失。在可访问性层面，它甚至可能把人完全挡在外面。团队之所以接受这种代价，只是因为他们没有更好的信号来判断另一端是谁。
有了 actor 上下文，权衡就变了。你可以让普通的人类会话保持原有体验，在证据充分的地方跳过 challenge，并把它保留给仍然有价值的狭窄场景: 例如，高影响操作中的 Unknown 结果，比如修改密码或高价值操作。大多数访客不会再看到 challenge。
合法代理需要的是路径，而不是谜题
CAPTCHA 的设计初衷是阻止软件。当几乎所有访问你页面的软件都不受欢迎时，这种设计是合理的。现在已经不是这样了。
如今，助手可能会为客户对比你的方案，代理可能会通过你的应用安排会议，而 AI 客户端可能会调用你的 MCP server 来完成任务。阻止它们，就等于阻止你的客户。强迫它们通过为人类设计的页面和谜题，会让自动化系统变得脆弱，只要页面重新设计就会出错。
Proof of Actor 能识别代理，对于带签名的请求，它还可以验证背后使用的是哪把密钥和哪个操作方。随后，你的应用就可以做比 challenge 更好的事: 提供结构化 API、提供更适合代理的流程，或者应用一个适合自动化负载的 rate limit。关于如何向 AI 代理提供结构化内容 的指南展示了具体做法。
已验证的身份不等于授权。有效签名只能告诉你是哪把密钥签署了请求; 该代理是否可以执行某个操作，取决于你的授权决策。Proof of Actor 会把这两个问题分开处理。
与 AI 协作的人仍然是你的用户
一个人用助手起草支持消息，或者在 AI 帮助下填写表单，仍然是客户。人类测试无法给他们提供任何有用信息: 他们要么通过，要么因为行为看起来异常而被拦下。
Proof of Actor 会给他们一个独立的类别，Human + AI，当辅助是被声明的，或通过受支持的集成可以观察到时就会报告该类别。这样，你可以把 AI 起草的提交标记给合适的团队，研究使用辅助的用户如何在产品中流转，并保持他们的体验顺畅。更多内容请参阅 AI 辅助交互 词条。
有意识地处理不确定情况
总会有一些流量无法明确判断。CAPTCHA 对所有这些情况都一视同仁: 每个人都要做测试。
Proof of Actor 会将 Unknown 作为一级结果返回，既不会默认当作人类，也不会默认当作恶意流量。你可以按 route、按风险选择 fallback:
- 公共页面和文档: allow，并保持标准体验。
- 注册和联系表单: allow，并保留你常用的滥用控制。
- 账户变更: 保留你现有的 re-authentication 流程。
- 高影响操作: route 到 review，或者如果你仍然需要，可以在这里使用 challenge。
这正是 challenge 仍然有其价值的地方: 作为某条敏感 route 上的一种明确 policy 结果，而不是对每个访客都收取通行费。
决策发生在哪里
CAPTCHA widget 在显示的那一刻决定结果，只在你放置它的页面上生效，而且只生效一次。
使用 Proof of Actor 时，由你的应用决定，适用于你的集成覆盖的每一条 route: server middleware、Next.js、edge、受支持的浏览器集成、通用 HTTP API 或你的 MCP server。policy 会同时使用 actor class 和 basis: allow、adapt、challenge、review 或 rate-limit。它们存在于你的代码中，与其余业务逻辑放在一起，你可以在不重新设计页面的情况下修改它们。
推出过程
Proof of Actor 从 observation mode 开始。安装后不会改变用户看到的任何内容。摆脱全量 challenge 的合理路径如下:
- Observe. 保持现有 challenge 不变，同时添加 Proof of Actor。观察每条 route 上的 actor 组成和 Unknown 比例。
- Compare. 对每条使用 challenge 的 route，查看有多少 challenge 命中了人类会话、AI 辅助用户和经过验证的代理。
- Preview. 编写一条 policy，在证据充分时跳过 challenge，并在敏感操作的 Unknown 情况下保留它。预览它对真实流量的影响。
- Enforce. 一次只在一条 route 上启用该 policy，并配备文档化的 fallback 和回滚开关。
关于安全推出具备 actor 感知能力的 policy 的指南对每一步都有详细说明。
什么时候 CAPTCHA 仍然有意义
在少数场景中，challenge 仍然是有用的工具: 某个敏感操作突然出现一波不明确的流量、表单正遭受持续滥用，或者某条 route 你暂时还没有其他信号。Proof of Actor 并不是要你把这个工具扔掉，而是给你上下文，让你只在它真正有帮助的地方使用它。
开始使用
Proof of Actor 目前处于 private beta。经过筛选的 founding developer 团队可在约定的使用限制内获得最长 12 个月的免费使用权限，并得到构建团队的直接支持。请申请 early access，并告诉我们你现在在哪些 route 上使用 challenge。