你让 Agent 打开一家商店，比较商品、登录账户，甚至提交订单。你知道是谁在替你操作，Agent 也可能知道自己正为谁服务；但站点看见的究竟是谁？
认出一个 Agent，和确认这个 Agent 得到了用户对当前动作的授权，是两回事。 2026 年 11 月 4 日，Cloudflare 把这个差别摆到了网站运营者面前：它开始让站点按个人 Agent 查看访问行为、设置差异化的允许或拦截策略，同时坦承，网站仍然缺少可靠的用户委托上下文。
这不是 Mira 应该立即接入某家反机器人产品的理由。它是一个更基础的工程信号：Agent 作为用户与网站之间的中介，开始成为需要独立识别、约束和审计的网络主体。
发生了什么：网站不再只能一刀切地拦机器人#
Cloudflare 在 11 月 4 日的产品公告 中发布了面向个人 Agent 的流量可见性与访问控制。Security Analytics 新增 Personal Assistants 分类，可以按 Agent 查看请求量、访问路径、响应状态码及来源网络。站点还可以在既有的 Agent 总策略之上，为受支持的个人 Agent分别选择允许、不允许访问带广告的页面，或全面拦截。
这与早先把自动访问笼统归入 Search、Agent、Training 三种行为不同。新策略不只问「这是不是自动化」，还问「是哪一个中介在代表人访问」。官方策略文档 明确：个人 Agent 默认继承 Agent 总策略，站点可以单独覆写；“Allow (do not block)”只意味着该策略不主动拦截匹配请求，不是授予网站业务权限。
Cloudflare 还描述了一个更接近真实用户账户的场景：在尚处 early access 的 Account Abuse Protection 中，风控人员可以查看某个账户关联了哪些个人 Agent，识别异常登录，并按 Hashed User ID 限制特定账户，而不必封禁同一 Agent 的所有用户。这是站点侧的分析与缓解能力，不是对每一次 Agent 操作的用户授权证明。
Verified bots 官方文档 给出了身份识别的另一层事实：一个被验证的 Agent 可以通过 Web Bot Auth 签名、稳定 IP 与 User-Agent、反向 DNS 等机制表明运营者身份；平台还区分单一运营者的 Direct 与可由众多最终用户驱动的 Intermediary。验证了运营者，并没有验证运营者背后每个用户的每次委托。
暴露的问题：代理身份、用户身份、操作授权被混成了一张通行证#
一个浏览器请求至少可能涉及四个不同的问题：
- 谁发出了请求？ 这涉及 Agent 运营者、浏览器客户端或网络自动化的可识别性。
- 它在替谁办事？ 这涉及用户身份、会话、账户以及代理关系。
- 用户允许它做什么？ 「帮我比较价格」不自动包含「替我付款」；同一用户的授权也应受目标站点、动作、时间与范围限制。
- 网站允许它做什么？ 网站自己的风控、业务鉴权与访问策略仍然独立有效。
四个问题互相有关，却不能互相代替。Agent 的签名不能证明用户同意；用户在本地点击「允许」不能要求第三方网站必须放行；持有已登录 Cookie 也不能证明用户授权了这一轮具体动作。反过来，网站把某类 Agent 识别为风险流量，也不能直接证明其背后的用户有恶意。
Cloudflare 在公告结尾主动承认：站点即使认出了 Agent，也未必知道最终用户是否已有订阅、究竟委托了什么、应适用哪些保护。如何以保护隐私的方式传递用户上下文、评估信誉和追究责任，仍是下一步目标，而非这次发布已经解决的能力。
因此，Agent 身份识别是一道入口；可验证的委托关系才是行动权限问题的核心。 这是基于公告与协议边界得出的工程判断，不是 Cloudflare 已经交付完整委托授权标准的事实。
Mira 的真实实践：本地能管住工具，不代表网站认得委托#
以下对照来自本次直接读取的 Mira Desktop 当前 dev 浏览器会话管理器、Browser Service、Browser Tool 定义 与 Harness Capability Profile。这里描述的是源码可见的控制机制，不是本次做过外部站点联调。
Mira 当前有两种性质不同的浏览器能力。
Managed Browser（智控）由 Mira 管理隔离的 Playwright 浏览器会话。会话管理器在导航时检查 URL scheme 与允许域名，并对切换到的标签页再次检查 URL 策略。Browser Service 用当前页面观察、URL 与 snapshotHash 约束后续交互，避免旧观察被当作新页面的动作依据；Tool 定义为点击、填写等操作标记了审批要求。这里形成的是Mira 本地执行边界：哪些域名可以去、哪些动作需要审批、依据哪份页面证据行动。
**Attached Browser（触界）**则通过 Chrome Extension 操作用户已经连接的真实浏览器，Profile 明确将既有标签页和已认证 Web 会话作为能力范围。它可以让 Agent 在用户的登录态里工作，但「浏览器里已有登录态」仍不等于「网站能辨认这是 Agent 发起的动作」，更不等于「当前任务的每个副作用都有独立、可向网站证明的授权」。
这两条运行路径都很重要，也都不能冒充 Cloudflare 所说的 Verified Personal Agent。本次读取的浏览器会话、工具与 Profile 源码，没有提供 Mira 已经实现跨站点 Agent 身份签名、面向第三方站点的用户委托证明，或已被 Cloudflare 收录为受支持个人 Agent 的证据。 这不是对整个组织所有认证模块的不存在性断言。
Mira 的现有优势在于把工具暴露、运行时可用性、会话范围和动作审批放在 Agent 自己可控制的边界内；但外部站点是否放行、能否将访问归因于某个 Agent、能否接受用户授予的细粒度权限，属于另一条独立信任链。客户端的 allowlist 不是网站的 allow；本地的 approval 也不是网站的 consent。
应该验证什么，而不是先注册一个 Agent 名字#
如果 Mira 将来需要稳定访问对自动化敏感的网站，值得做的是一个可复现的小型兼容性矩阵，而不是先宣布支持「Agent 身份」：
- 在有授权的测试站点，分别使用普通浏览器、Managed Browser 和 Attached Browser，观察访问是否被识别为自动化、是否触发挑战、哪些请求被拦截。
- 将「未登录只读」「用户已登录只读」「需明确确认的写动作」分开记录，核对 Mira 的本地审批与站点实际鉴权有没有被错误地当作同一回事。
- 对每次失败保留最小证据：请求目标、站点响应、当前会话类型、动作类型与本地审批结果；不采集原始 Cookie、凭据或无关私人页面内容。
- 如果未来考虑 Web Bot Auth 或 OAuth 式委托，再单独评估身份密钥保管、用户撤销、权限范围、重放防护与跨设备一致性；不能把换一个 User-Agent 当成身份认证方案。
以上是待验证建议，不是已批准的 Mira 工程任务，也不是已经完成的测试。尤其不应为绕过网站反机器人策略而伪装人类流量。
仍然不确定：平台识别能走多远#
Cloudflare 这次提供的是受支持个人 Agent 的识别、分析和站点侧访问策略，不是互联网所有 Agent 的统一身份层。哪些自建、私有部署、Attached Browser 或不同网络出口的 Agent 会被稳定识别，公开材料并没有给出覆盖率和误判率。Account Abuse Protection 的相关账户关联能力仍处 early access，不能假定所有站点和套餐都可用。
站点的阻断策略也可能与用户意愿冲突：用户明确想让 Agent 帮忙，网站仍可拒绝；网站允许某个 Agent 访问，也不意味着它应替用户执行任意交易。对隐私保护与用户可撤销委托而言，平台层关联用户和 Agent 的方式本身还需要审视。
Mira 目前没有本次研究产生的跨站点实测数据，也没有理由凭公告推断自己的浏览器工具即将大规模失效。真正值得记住的是边界的变化：过去 Agent 主要向用户解释「我能调用什么」；现在它还必须面对网站的追问——「你是谁，替谁来，凭什么做这件事？」
这三个问题如果不能分别回答，再漂亮的浏览器自动化，也只能算会操作网页，不能算完成了可信的委托。
