AI 智能体正在替用户浏览网页、购物和办理事务。对网站而言，它可能看起来与普通用户没有区别，也可能表现为一个承载大量用户请求的统一访客。
核心问题是：网站看到了智能体，却未必看得到它背后的人。 这会影响个性化服务、风险控制和责任认定；出现问题时，网站往往还需要承担主要处理成本。
对于关注 AI 应用落地的开发者，以及写好标智库的技术读者，这个问题值得从系统设计层面讨论：当执行操作的一方不再等于发出指令的一方，网站应如何判断授权、建立信任并保留责任边界？
远程智能体是一种新的中间服务
本文讨论的个人 AI 智能体，是指接受用户指令，通过控制云端计算机或浏览器完成任务的自动化程序。它们通常由运营方托管和维护，不包括运行在用户本机或本地浏览器中的智能体。
远程智能体位于用户与网站之间：网站直接接触的是智能体，而不一定是用户。云浏览器、代理服务和 VPN 也具有类似的中间服务特征。
区别在于，智能体可以持续运行、并行执行任务，也能承受人类通常不会接受的操作阻力。这让网站过去围绕人类行为建立的容量规划、风控和商业模式面临新的挑战。
如果智能体流量持续增长，简单封禁中间服务就会越来越难以维持。网站需要回答的问题将变成：在无法直接观察用户的情况下，如何判断是否信任智能体及其运营方？
一个代办员，就能说明问题
设想一名代办员，同时为几位客户购物、预约和办理手续。
过去，杂货店老板认识每位客户，知道他们各自的偏好。现在只有代办员来下单，老板很难分清订单背后的人。
如果一位客户购买手机后否认授权，商店需要证明交易确实得到客户同意，但商店接触过的只有代办员。
如果另一位客户交给代办员一串密码，让她逐一尝试登录银行，银行能够发现异常尝试，却可能只能封禁代办员，连带影响其他正常客户。
把代办员换成 AI 智能体，把商店和银行换成网站，就能看到同样的矛盾：
封禁整个中间服务可能误伤正常用户；直接放行，又难以处理背后的滥用。
核心原则：中间服务不应抹去责任关系
无论用户是否通过中间服务访问，用户与网站之间的业务关系，以及各方应承担的安全责任，都应得到维护。
网站需要能够识别、服务并在必要时追究通过智能体访问的用户的责任。与此同时，智能体及其运营方也需要具备可识别性和可问责性，因为智能体的执行规模可能远超单个用户。
这里需要区分三个相互关联、但不能互相替代的问题：
| 维度 | 需要回答的问题 |
|---|---|
| 身份 | 行动者是否如实表明了自己的身份？ |
| 信誉 | 是否有理由信任这个行动者？ |
| 问责 | 行为造成后果时，由谁负责？ |
这不意味着每次访问都必须实名，也不要求每一步操作都有人在场。匿名浏览和银行登录，本来就可以采用不同的验证要求。
为什么验证码和权限范围还不够？
验证码不能证明完整的代理关系
让智能体把验证码转交给用户，可以证明某个时刻有人参与，却不能单独证明这个人是谁，也无法说明智能体在其他时间代表谁行动。
“人在回路”有助于减少智能体误解用户意图带来的错误，但不能独立解决多用户流量混合、身份区分和责任认定问题。频繁要求用户介入，也会削弱智能体减少操作负担的价值。
权限范围不等于具体操作授权
限制智能体的访问权限很重要，但通用智能体可能为了完成广泛任务而申请较大的权限范围。
即使权限限定得很窄，它通常也只是说明“允许做什么”，不能完整回答以下问题：
- 智能体实际代表谁？
- 这一次操作是否获得授权？
- 出错后由谁负责？
因此，权限约束是必要控制，但不能替代身份、授权和问责机制。
网站与智能体需要哪些协作机制？
1. 用明确协议处理访问、限流和支付
网站与智能体需要能够表达并协商允许的行为、访问条件和执行规则，而不是完全依赖网站对流量特征的猜测。
一些协议和机制正在探索具体问题的解决路径：
- MOLE：探索在不使用用户专属标识符的情况下实施访问频率限制。
- x402：面向网络支付的协议，也关注隐私保护。
- Privacy Pass 等机制：尝试在不直接识别用户的情况下，为访问建立信任依据。
这些机制针对不同问题，不能被视为一套已经完成、能够覆盖所有场景的通用方案。
2. 识别智能体，也要理解调用链
Web Bot Auth（WBA）允许智能体对请求签名，为网站识别智能体及其背后的运营方提供一种方式。
但多层调用仍然是需要解决的问题。例如：
用户 → 智能体 A → 智能体 B → 浏览器 C → 网站 网站需要理解这条中间服务链，才能正确执行访问策略，避免策略被绕过。
同时必须注意：识别出智能体，不等于识别出最终用户。 是否还需要会话、账户或其他标识，应取决于具体业务风险。
3. 按风险分层披露用户信息
身份信息不应只有“完全匿名”和“完整身份”两个选项。遵循数据最小化原则，可以考虑不同层级：
| 层级 | 能提供的信息或能力 |
|---|---|
| 不提供标识 | 用户不携带身份标识访问，网站通过其他机制判断是否允许访问 |
| 会话级标识 | 关联同一会话中的请求，用于建立会话信誉和实施访问控制 |
| 账户级标识 | 跨会话关联同一用户，例如支持网站账户与智能体账户绑定 |
| 跨运营方的用户级标识 | 在部分高风险场景中，提供跨运营方、账户、智能体和会话持续存在的标识 |
并非所有场景都需要知道“你是谁”。有些场景只需要回答“是否可以信任这次访问”。需要更强身份信息时，也应根据具体风险逐步增加披露要求。
开发者需要拆开考虑的三个问题
智能体访问治理不只是“识别机器人后，决定放行还是拦截”。更关键的是，在用户、智能体、运营方和网站之间，保留必要的授权关系、信任依据与责任边界。
对网站开发者而言，可以先把问题拆成三项：
- 信息需求：这项操作究竟需要什么程度的用户信息？
- 用户区分：如何区分同一智能体背后的不同用户？
- 处置粒度：发生滥用时，能否只限制相关行为，而不影响其他正常访问？
对智能体服务而言，减少用户操作负担，也不应以让网站失去必要的风险判断能力为代价。值得讨论的设计方向，是让执行效率、隐私保护和责任边界能够同时得到考虑，而不是仅用一个“是否为机器人”的判断替代所有访问决策。
