AI 智能体代人上网，网站如何建立信任？

AI 智能体正在替用户浏览网页、购物和办理事务。对网站而言，它可能看起来与普通用户没有区别，也可能表现为一个承载大量用户请求的统一访客。

核心问题是：网站看到了智能体，却未必看得到它背后的人。 这会影响个性化服务、风险控制和责任认定；出现问题时，网站往往还需要承担主要处理成本。

对于关注 AI 应用落地的开发者，以及写好标智库的技术读者，这个问题值得从系统设计层面讨论：当执行操作的一方不再等于发出指令的一方，网站应如何判断授权、建立信任并保留责任边界？

远程智能体是一种新的中间服务

本文讨论的个人 AI 智能体，是指接受用户指令，通过控制云端计算机或浏览器完成任务的自动化程序。它们通常由运营方托管和维护，不包括运行在用户本机或本地浏览器中的智能体。

远程智能体位于用户与网站之间：网站直接接触的是智能体，而不一定是用户。云浏览器、代理服务和 VPN 也具有类似的中间服务特征。

区别在于，智能体可以持续运行、并行执行任务，也能承受人类通常不会接受的操作阻力。这让网站过去围绕人类行为建立的容量规划、风控和商业模式面临新的挑战。

如果智能体流量持续增长，简单封禁中间服务就会越来越难以维持。网站需要回答的问题将变成：在无法直接观察用户的情况下，如何判断是否信任智能体及其运营方？

一个代办员，就能说明问题

设想一名代办员，同时为几位客户购物、预约和办理手续。

过去，杂货店老板认识每位客户，知道他们各自的偏好。现在只有代办员来下单，老板很难分清订单背后的人。

如果一位客户购买手机后否认授权，商店需要证明交易确实得到客户同意，但商店接触过的只有代办员。

如果另一位客户交给代办员一串密码，让她逐一尝试登录银行，银行能够发现异常尝试，却可能只能封禁代办员，连带影响其他正常客户。

把代办员换成 AI 智能体，把商店和银行换成网站，就能看到同样的矛盾：

封禁整个中间服务可能误伤正常用户；直接放行，又难以处理背后的滥用。

核心原则：中间服务不应抹去责任关系

无论用户是否通过中间服务访问，用户与网站之间的业务关系，以及各方应承担的安全责任，都应得到维护。

网站需要能够识别、服务并在必要时追究通过智能体访问的用户的责任。与此同时，智能体及其运营方也需要具备可识别性和可问责性，因为智能体的执行规模可能远超单个用户。

这里需要区分三个相互关联、但不能互相替代的问题：

这不意味着每次访问都必须实名，也不要求每一步操作都有人在场。匿名浏览和银行登录，本来就可以采用不同的验证要求。

为什么验证码和权限范围还不够？

验证码不能证明完整的代理关系

让智能体把验证码转交给用户，可以证明某个时刻有人参与，却不能单独证明这个人是谁，也无法说明智能体在其他时间代表谁行动。

“人在回路”有助于减少智能体误解用户意图带来的错误，但不能独立解决多用户流量混合、身份区分和责任认定问题。频繁要求用户介入，也会削弱智能体减少操作负担的价值。

权限范围不等于具体操作授权

限制智能体的访问权限很重要，但通用智能体可能为了完成广泛任务而申请较大的权限范围。

即使权限限定得很窄，它通常也只是说明“允许做什么”，不能完整回答以下问题：

• 智能体实际代表谁？
• 这一次操作是否获得授权？
• 出错后由谁负责？

因此，权限约束是必要控制，但不能替代身份、授权和问责机制。

网站与智能体需要哪些协作机制？

1. 用明确协议处理访问、限流和支付

网站与智能体需要能够表达并协商允许的行为、访问条件和执行规则，而不是完全依赖网站对流量特征的猜测。

一些协议和机制正在探索具体问题的解决路径：

• MOLE：探索在不使用用户专属标识符的情况下实施访问频率限制。
• x402：面向网络支付的协议，也关注隐私保护。
• Privacy Pass 等机制：尝试在不直接识别用户的情况下，为访问建立信任依据。

这些机制针对不同问题，不能被视为一套已经完成、能够覆盖所有场景的通用方案。

2. 识别智能体，也要理解调用链

Web Bot Auth（WBA）允许智能体对请求签名，为网站识别智能体及其背后的运营方提供一种方式。

但多层调用仍然是需要解决的问题。例如：

用户 → 智能体 A → 智能体 B → 浏览器 C → 网站

网站需要理解这条中间服务链，才能正确执行访问策略，避免策略被绕过。

同时必须注意：识别出智能体，不等于识别出最终用户。 是否还需要会话、账户或其他标识，应取决于具体业务风险。

3. 按风险分层披露用户信息

身份信息不应只有“完全匿名”和“完整身份”两个选项。遵循数据最小化原则，可以考虑不同层级：

并非所有场景都需要知道“你是谁”。有些场景只需要回答“是否可以信任这次访问”。需要更强身份信息时，也应根据具体风险逐步增加披露要求。

开发者需要拆开考虑的三个问题

智能体访问治理不只是“识别机器人后，决定放行还是拦截”。更关键的是，在用户、智能体、运营方和网站之间，保留必要的授权关系、信任依据与责任边界。

对网站开发者而言，可以先把问题拆成三项：

1. 信息需求：这项操作究竟需要什么程度的用户信息？
2. 用户区分：如何区分同一智能体背后的不同用户？
3. 处置粒度：发生滥用时，能否只限制相关行为，而不影响其他正常访问？

对智能体服务而言，减少用户操作负担，也不应以让网站失去必要的风险判断能力为代价。值得讨论的设计方向，是让执行效率、隐私保护和责任边界能够同时得到考虑，而不是仅用一个“是否为机器人”的判断替代所有访问决策。