定义
Unknown 分类是 actor intelligence system 在某次交互的可用证据不足以支持可靠判断时返回的结果。它的准确含义是: 我们无法仅根据已观察到的内容判断这是一个人、一个人与 AI 协作的人，还是一个 agent。
Unknown 是 Proof of Actor 中的四个 class 之一，与 Human、Human + AI 和 Agent 并列。它是一级结果，不是错误状态，也不是委婉地表示“可能是 bot”。关于为什么 Unknown 在对 AI traffic 分类时是一个有效结果，我们的文章做了完整说明。
为什么 Unknown 很有价值
必须始终给出答案的分类系统，最终往往会做出带有把握的猜测。这些猜测看起来像数据，会进入 dashboard 和 policy，并悄然造成影响: 合法 customer 可能被 challenge，或者自动化 client 在敏感 route 上被当作人来处理。
改为报告 Unknown，能给 team 提供三样东西:
- 诚实的覆盖范围。 Unknown 结果的占比会告诉你，集成在哪些地方有可见性，在哪些地方没有。
- 更安全的 policy。 policy 可以针对每个 route 精确定义 Unknown 的含义，而不是继承一个隐藏的猜测。
- 改进路径。 如果某个 route 的 Unknown rate 很高，你可以在那里补充更好的 signal source，例如 browser integration 或对已签名 agent request 的支持。
Unknown 的常见原因
- 该 route 上没有运行受支持的 integration，例如缺少 browser collector。
- client 不运行 JavaScript，也不发送身份证据。
- 观察到的 interaction signal 太少，例如 session 非常短。
- request 到达时没有 signature，并且 client description 是通用的或缺失的。
- 现有 evidence 彼此冲突，而且没有任何部分强到足以做出决定。
应用应如何处理 Unknown
Unknown 应映射到应用 owner 按 route 选择的明确 fallback:
- Public, low-risk 页面: allow，不增加额外 friction。
- 只读 API: allow，并使用标准 rate-limit。
- 账户变更和其他高影响操作: 保留应用现有 checks，例如重新认证，不要仅根据 Unknown 结果本身做决定。
同样的思路也适用于 timeout 和缺失的 telemetry。某个 route 是fail open 还是 fail closed，应当是事先做出的明确决定，而不是意外。
常见误解
"Unknown 意味着可疑。" 它表示证据不足。很多完全正常的 visitor 也会产生 Unknown 结果。
"Unknown 应默认视为 Human。" 绝不能这样。把 Unknown 转成 Human 会掩盖差距，并可能让 automation 获得人类级别的信任。
"好的 system 不会有 Unknown。" 没有 Unknown 的 system，往往是在猜测。一个可见且有解释的 Unknown rate，才是诚实 classifier 的表现。
Proof of Actor 中的 Unknown
Proof of Actor 会在evidence basis 不支持判断时报告 Unknown，绝不将其转为 Human，并在 analytics 中保持 Unknown rate 可见。team 会在observation mode 下为每个 route 定义 fallback，然后再启用任何 policy。请阅读Detection & Limitations了解完整模型，或申请早期访问。