定义
actor 结果的证据基础描述了其背后的证据类型。Proof of Actor 使用四个值：
- verified: 密码学上或其他可检查的断言已通过。
- declared: actor 或应用声明了这一点。
- inferred: 该结论是基于行为或上下文信号推导出来的。
- unknown: 证据不足，无法做出判断。
每个结果都同时带有一个类别（Human, Human + AI, Agent 或 Unknown，详见 我们对应用流量的分类体系）和一个基础。"Agent, verified" 和 "Agent, inferred" 是不同的结果，应分别对待。
为什么基础很重要
如果没有基础，分类就会掩盖它究竟能承受多大分量。一个仪表板如果对已签名请求显示 "Agent"，对基于请求时序的猜测也显示 "Agent"，就会让团队把同一政策套用到两者上。尤其对于安全敏感的应用，推断绝不能看起来像密码学验证。
将类别与基础分开，可以让政策与证据强度相匹配：
- 一个只读 route 可能允许任何 Agent 结果。
- 一个影响更大的 route 可能只把已验证的 agent 视为已知操作者，并要求其他所有人提供更强的凭证。
这四个值的详细说明
verified
某件事已经被检查并通过。最清晰的例子是 HTTP message signature（RFC 9421），它能通过由 agent 操作者发布的密钥进行验证。已验证证据只证明了具体检查本身，别无其他：有效签名表明是哪个密钥签署了请求，而不是该动作是否已 authorized。
declared
有人这么说了。一个客户端把自己命名为 agent，MCP client name，或者你自己的应用中关于 AI assistance 的披露，都属于声明。它们通常有用，往往诚实，但有时也可能是假的。User-agent spoofing 就是虚假声明的典型例子。User-Agent header 的设计本身就是自报。
inferred
系统根据信号进行了推断：浏览器会话中的交互模式、请求时序、缺失的浏览器上下文、协议细节。推断可能出错，因此它们始终被标记为推断，而且对人的重要决策绝不应只依据推断。
unknown
证据不足以支持判断。这与 Unknown classification 对应，并且应在你的 policy 中映射为明确的兜底处理。我们关于 为什么在分类 AI traffic 时 Unknown 是有效结果 的文章解释了原因。
基础与置信度分数的区别
许多系统把证据压缩成一个数字。分数会掩盖它到底来自密码学检查还是启发式方法，而未经校准的百分比会给人一种并不存在的精确感。一组明确命名的基础更容易推理、更容易审计，也更不容易被误用。
常见误解
"declared 就是不可信。" 声明往往是准确的，而且对于某些问题，比如 AI assistance 披露，声明甚至是唯一可用的证据。它们只是不能被当作验证。
"verified 就是安全。" 验证关注的是签名者的身份，而不是意图或权限。
Proof of Actor 中的证据基础
每个 Proof of Actor 结果都会说明其基础，并给出人类可读的证据摘要。Policy 在你的应用中运行，并且可以同时使用类别和基础。另见 Detection & Limitations，或 申请提前访问。
来源
- RFC 9421: HTTP Message Signatures: 已验证证据最清晰的来源
- RFC 9110: HTTP Semantics, User-Agent: 自报的、已声明的标识符