跳转到主要内容
人类与代理流量

区分人类、AI 辅助和代理流量

为每次交互赋予清晰的类别和清晰的依据，让你的应用能够以各自应有的方式服务于人、与 AI 协作的人，以及自主代理。

获取抢先访问了解其工作原理
Toshendra Sharma

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

两个类别已经不够用了

多年来，流量通常被分成两类: 人类和机器人。人类获得产品服务。机器人则被阻止、限速或忽略。

这种划分现在已经不成立了。有些自动化访客是代表真实客户行动的代理: 例如，比较方案的助手、通过你的 API 拉取数据的代理，或者调用你的 MCP server 来完成任务的工具。AI 提供商现在也在自己文档中说明了这种由用户发起的访问: OpenAI 说明，当用户向 ChatGPT 提问时，其 ChatGPT-User agent 会访问页面 (OpenAI crawler documentation)，Anthropic 也为同样目的列出了 Claude-User (Anthropic crawler documentation)。与此同时，有些人会与 AI 密切协作，在助手支持下起草消息、填写表单并浏览产品。把这些情况都硬塞进人类或机器人二分法，会在两个方向上都造成错误决策。合法代理会被拦下，真实用户也会因为行为看起来异常而被质疑。

要以能导向良好决策的方式区分人类和 AI 代理流量，你需要更多类别，也需要知道每个结果的可信度有多高。关于 如何判断网站流量是否来自 AI 代理 的文章会逐步说明让这件事成为可能的信号，而 SaaS apps use case 则展示了这种区分会在何处改变产品决策。

四个类别，各自含义明确

Proof of Actor 会将交互归入四个类别。每一类都有定义和明确边界，因此团队中的任何人都不会把结果理解得超过证据所支持的程度。关于这套分类法背后的推理，请阅读 Human, AI-assisted or agent: a taxonomy for app traffic。

Human

受支持的可观察信号表明这是以人为主导的交互。这个类别关注的是谁在主导交互，而不是身份本身。Human 结果不会验证这个人是谁，也不会声称在任何地方都没有使用 AI。

Human + AI

AI 协助已被声明，或者通过一个能够实际观察到它的受支持集成被发现。例子包括: 用户通过你自己的披露控件将内容标记为由 AI 起草，或者你的应用报告其内置助手为已登录用户执行了某项操作。更多内容请参阅 AI-assisted interaction 词条。

Agent

自动化或由代理发起的交互，并且由可验证身份提供支持，例如来自已发布密钥的有效请求签名，或者来自经过谨慎限定的推断。Agent 结果描述的是谁在执行。它并不意味着该代理已获授权、安全，或者拥有来自某个人的有效委托。更多内容请参阅 autonomous agents。

Unknown

现有证据不足以作出可靠判断。Unknown 是一个诚实且有用的结果: 它显示出你的覆盖范围到哪里为止，也让你的策略能够有意识地处理不确定情况，而不是误打误撞地处理。

每个类别都带有依据

把人类流量和代理流量分开，只完成了一半。另一半是知道每个结论有多强。这就是为什么每个 Proof of Actor 结果都带有一个依据:

  • Verified: 已经通过检查验证的陈述，例如用已发布密钥校验的请求签名。
  • Declared: 客户端或你的应用已经声明，例如代理自报身份，或用户披露自己在使用 AI 协助。
  • Inferred: 从行为或上下文信号得出的结论，始终标记为推断。
  • Unknown: 证据不足，无法判断。

类别与依据的组合，才是你构建精确规则的基础。一个 verified 的代理和一个 inferred 的代理都属于代理，但你可能会希望前者获得结构化 API，而对后者只施加标准速率限制。一个声明了 AI 辅助的提交和一个人类会话都可以正常继续，只是前者会带上有助于支持团队处理的标签。完整分类法可以在 Detection & Limitations 中查看。

分类是如何发生的

Proof of Actor 对每次交互都遵循同样的证据优先路径。完整说明见 How It Works。

你的集成能够看到的信号

  • Request signatures 来自发布密钥的自动化客户端，使用 RFC 9421 中定义的 HTTP Message Signatures。IETF 的 Web Bot Auth working group 负责标准化自动化客户端如何通过这种方式进行身份验证。
  • Declarations 来自自我标识的客户端，例如 AI 爬虫和抓取器文档中定义的 user agents，以及来自你自己的应用在知道涉及 AI 协助时所作的声明。
  • Request context 由服务端集成可获取，例如 headers 和协议细节。
  • Interaction signals 来自在其运行页面上经批准的浏览器集成。

从信号到结果

信号会被检查、按依据标注并组合。强的已验证证据会产生高置信度结果。弱的或相互冲突的证据会产生限定性的推断或 Unknown。超时或缺失的信号永远不会变成 Human 结果。输出包括类别、依据以及任何团队成员都能阅读的证据摘要。

一旦流量分离出来，你可以做什么

Proof of Actor 围绕三项能力组织: Detect、Understand 和 Route。

Detect 每次交互背后的 actor

收集每种上下文中可用的信号，将已验证的陈述与推断分开。让 Unknown 保持可见。

Understand 每种 actor 如何使用你的产品

按 route 和时间查看人类、AI 辅助、代理和未知活动的构成。打开任一结果，查看哪些是已知的，哪些是未知的。找出代理集中的 routes，以及 AI 辅助常见的 workflows。

Route 将每个 actor 导向合适的体验

一旦证据支持，就应用你自己的策略。在公开网站上，websites use case 展示了这些选择如何映射到真实 routes:

  • 为已验证的代理提供结构化响应或 API，而不是人类风格的页面。
  • 为以人为主导的会话保留标准体验。
  • 为 AI 辅助提交添加标签，让正确的团队来处理。
  • 当你的条件要求时，在敏感操作上要求更强的凭证。
  • 为每个 route 选择一个明确的 Unknown 兜底方案，例如允许公开页面，同时对账户变更保留现有检查。

关于如何按 route 逐步从观察过渡到执行，rolling out actor-aware policies safely 这份指南有更详细的说明。

为什么这对你的用户很重要

把这件事做对，对所有使用你应用的人都有好处。

人们会获得更顺畅的体验，因为他们不会因为一个模糊的评分而被质疑。与 AI 协作的人会在适合的工作流中获得对已披露协助的支持。合法代理会得到可靠、结构化的执行方式，从而减少对你界面的抓取和负载。你的团队会得到可解释的决策，因此支持沟通、事件复盘和策略调整都建立在证据之上，而不是凭空猜测。

登录态不等于 actor

最常见的混淆来源之一是账户本身。已登录会话只能告诉你当前使用的是哪个账户，并不能告诉你是谁在主导当前交互。同一个账户可以在早上由所有者点击设置使用，中午由所有者要求助手导出报告使用，晚上又由通过 API key 操作的代理使用。

把这三者一视同仁会在两个方向上都造成问题。如果默认账户上的每个请求都来自所有者，代理就可能进入原本为人类设计的工作流。如果默认任何异常请求都是攻击，所有者自己的工具就会被拦下。把 actor 和账户分开，可以让你的应用保持原有的身份验证和授权不变，同时补上当前是谁在操作的缺失上下文。正是这种上下文，使你能够在不把仅限人类的工作流暴露给代理的情况下，为代理提供结构化访问。

从观察模式开始

每次部署都从观察模式开始。Proof of Actor 会在你的应用仍按原样响应时记录结果。你的团队建立人类、AI 辅助、代理和未知活动的基线，将其与已知结果进行对比，并在任何规则改变之前审查误报。一旦某条策略准备就绪，你就可以先在一个 workflow 上启用它，再逐步扩大范围。

加入创始开发者计划

Proof of Actor 目前处于私有 beta，面向一小部分应用团队开放。入选的创始开发者可以在约定使用范围内获得最长 12 个月的免费访问，并以实际反馈作为交换。你将获得我们工程师的直接集成支持、功能的优先体验，以及对优先级的影响力。

如果你需要在自己的应用中区分人类和 AI 代理流量， 申请早期访问，并告诉我们你最想理解的是哪种交互。

探索 Proof of Actor，阅读 how it works，或者准确了解 what the evidence can establish。

来源

面向开发者

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 集成指南

常见问题

你们如何区分人类和 AI 代理流量？

Proof of Actor 会结合你的集成能够观察到的信号，例如请求签名、客户端声明、请求上下文和浏览器交互信号，并返回带有明确依据的类别。

为什么需要 Human + AI 这一类？

有些人会在 AI 助手的协助下工作。把他们一律视为纯人类或完全自动化都会丢失重要上下文。Human + AI 覆盖的是通过受支持的集成已声明或可观察到的 AI 协助。

Agent 结果和恶意机器人是同一回事吗？

不是。许多代理都是合法参与者。Agent 结果描述的是谁在执行，而不是该行为是否被允许。由你的策略决定如何服务每个代理。

如果流量无法分类怎么办？

它会被报告为 Unknown，作为一等结果。Unknown 不会被自动转换为 Human，也不会默认被当作恶意流量。

我必须阻止某些流量吗？

不需要。你从观察模式开始，先审查结果，只在团队确认策略适用时才启用。

了解谁在使用您的 app。

面向少数 founding developers 的私有 beta。

获取抢先访问查看定价

想先聊聊？ 联系创始人