平台对智能体访问的条款

步骤 1协议是容易的那一半；条款才是那个接口。

沃尔玛的网关是以一台 MCP 服务器的形态交付的。那部分你的工程师一周就能做完。真正决定这个集成下个季度还在不在的，是那句「不遵守条款的智能体将被禁止访问本站」，再加上一道不由你掌握的审批环节。而在买家侧，亚马逊一直在往相反方向走——它在 2026 年 9 月切断了 Meta 的 Muse 智能体，理由是安全与隐私风险以及智能体没有恰当标明自己身份（Meta 对这一说法有异议）；更早在 2025 年 11 月，它就因 Perplexity 的 Comet 浏览器智能体在其商城下单而起诉了对方。

两个平台、同一套协议栈、相反的答案。区分这两种情况的不是任何技术因素，而是一个商业判断：一个坐在零售商与顾客之间的中介，算渠道还是算竞争对手——而这个判断，每当商业理由发生变化就会被重新评估一次。把它当成一个自带波动性的输入，而不是关于互联网的某个既定事实。

步骤 2顺着支付工具走，就能找到真正的强制边界。

条款文件又长又含糊；而关于钱怎么走的那几句又短又精确，它告诉你平台实际准备管住什么。在沃尔玛的网关上，智能体完成交易的全过程都不会拿到卡片信息，也不能新增或更改支付方式；面向顾客的 Agent Profiles 据报道将在 2026 年 11 月跟上；而即便智能体的行为不符预期，照常走的也是普通退货流程。把这读成一份设计声明：平台容许一个智能体去挑、去买，不容许它持有那件支付工具。

• 智能体持有凭证——你离「被当成 Perplexity 那个案子来定性」只差一次事故。预期是封禁，不是协商。
• 平台持有凭证、智能体持有限定范围的许可——这是被认可的形态。你真正耐久的工作，是让自己的智能体在这个形态里「可被读懂」：标明身份、守住被授予的速率、别去碰支付路径。
• 平台两者都持有、且每笔购买由人确认——最窄也最稳的那种授权，也是你该假设自己最终会被推向的那一种。

一个平台把这条线画在哪里，同时也告诉你它的哪些 API 是战略性的。支付工具那一侧见智能体支付，把它标准化的协议尝试见 AP2 与智能体商务。

步骤 3像盘点供应商那样，把这份依赖盘出来。

多数团队能说出自己用了哪些模型供应方，却说不出自己的智能体要兑现承诺时，暗地里还依赖哪些第三方平台。那张清单就是要交付的物件。一行一个平台，四个列决定了其中一行变红时你怎么办。

# platform-access.yml — the row that makes an outage answerable
- platform: walmart
  grant: approved-agent          # approved | public-api | unsanctioned
  identifies_as: registered-ua   # how THEY recognise us
  holds_payment: platform        # platform | us | agent
  revocable_by: them, unilateral
  user_promise: "buy groceries"  # what breaks for the user
  fallback: handoff-to-human     # NOT "retry"
  detect: 403-rate > 2% for 5m   # the alert that fires first

grant 这一列是最容易填错的。一个建立在「无需注册的公开端点」之上的集成，即便跑得完美无缺，也属于未获认可；而未获认可的访问权，正是那种不给任何废弃窗口就直接消失的类别。把这些行并进你的智能体清册，而不是另立一张表；并像评估任何其他第三方依赖那样去评估它们。

步骤 4被封不是一个错误；把它当成一个策略事件来埋点。

权限被收回时，不会以 500 的形式到来。它到来的样子是：昨天还能走的那条路由返回 403、过去给 JSON 的地方变成一张挑战页、账号突然被限速到毫无用处，或者恰好是最要紧的那一个端点被无声掐掉。重试逻辑会把这些统统读成「暂时性故障」，然后欢快地把一个策略决定变成对一个刚刚叫你停下的平台的重试风暴——一个本可挽回的误会，就是这样变成永久封禁的。

• 把信号分开。按平台单独统计「鉴权形状」的失败，而不是塞进一个笼统的错误率里——在那里，2% 的封禁是看不见的。
• 退避要狠，而且不对称。403 率持续升高时，是停下来，而不是重试。这是唯一一类「正确的自动反应就是安静下来并呼人」的失败。
• 把证据留下。请求标识、时间戳和原始响应体，是一场「账号恢复」对话赖以进行的东西；而等有人来问的时候，它们通常已经没了。
• 指定一个负责人。平台关系需要一个人，而不是一张值班表——这个封禁会在邮件里被解决，不会在代码里。

步骤 5要降级到一个诚实的状态，并告诉用户这是谁的决定。

访问权没了的时候，你欠用户一句真话。「沃尔玛目前不接受像我这样的助手下单——这是你的购物车，请你自己完成结账」既保住了用户的信任，也把抱怨导向了做出这个决定的那一方。悄悄换成另一家零售商，或者在一件你已经做不到的任务上假装有进展，等于把合作方的政策变动转成了你自己的信誉问题。降级路径应当在做这个功能时就一起设计好，并且要交出真实的状态——购物车、挑好的商品、地址——而不是一句道歉。

如果某一个平台承载着你在自己营销里立下的一条承诺，那你就有一份工程量再大也修不掉的集中度风险。要么握住第二条获认可的通路，要么在产品里把这份依赖说明白。单一零售商的审批名单，比它看起来要薄；而目前公开可见的格局——沃尔玛放进获批的智能体、Target 按一份获批供应方名单办事、亚马逊在买家侧限制却在卖家 API 上放开——是一个仍在争论中的市场，不是一套已经定下来的标准。

步骤 6做那个「容易被批准」的智能体。

到目前为止，所有公开给出的封禁理由都指向同样两件事：不标明自己身份的智能体，以及采取了平台无法归因到某位知情同意的顾客身上的行动的智能体。这两件事你都可以在任何人开口之前单方面修好。在请求里标明智能体身份、保留能证明「是哪个人要求了这次行动」的同意记录、遵守公布的速率，并保留平台会去查的那些核验信号。正在开放的那些平台都在搭建审批流程；而一个本来就像「已获批」那样行事的智能体，走的是一次简短的复核，而不是一场艰难的辩论。