如果你这几个月在小红书或 X 上刷到有人让 AI 帮忙比价、下单、改机票、退个货，那大概是今年最热闹的一条产品线：个人 Agent（personal agent）。它们不发自拍，但已经在替你点按钮、填表单、刷购物车。

问题出在它们抵达商家网站的那一刻。沃尔玛的服务器看到的是一个来路不明的「用户」——分不清是真人在浏览，是一个正经的购物助手，还是一个被 prompt injection 劫持、正把钱往外转的机器人。于是商家只能一刀切封掉，用户的 Agent 就成了「坏掉的产品」。

10 月 6 日，Sierra 和 Meta 宣布了一条新标准 Personal Agent Protocol（下文简称 PAP），想给这件事一个统一答案。一起署名的还有 Genesys、Instinct、Rocket、Shopify、Stripe 和沃尔玛。

我看完的第一反应不是「AI 圈又多了一个协议」，而是：这批人挑的切入点很刁。支付那一层早就挤爆了，他们偏偏绕开它，去抢上面那层至今空着的东西——「你是谁，你被允许干什么」。

PAP 想管的是「登录」，不是「结账」

先把坐标摆正，不然后面全乱。

现在的 Agent 协议大致分三层。最底下是连接层，MCP（Model Context Protocol）负责让 Agent 调用工具和数据，这一层的归属基本定了，Anthropic 把它捐给了 Linux 基金会。中间是交易层，负责「把这一单买完」，OpenAI 和 Stripe 的 ACP、Google 的 UCP、Coinbase 的 x402 都在这里厮杀。

PAP 说自己不属于上面任何一层，它要做的是关系层：哪个 Agent 在访问、它替谁办事、它被授权做了什么。用 Sierra 自己的话，是「在网站上和公司建立一段会话，用户决定给 Agent 只读还是可写权限」。

这个定位很聪明，也很危险。聪明在于没人占；危险在于，它必须和上下两层都能对接，否则就是个孤岛。

一次会话怎么走：从「游客」到「读/写」

PAP 目前只公布了高层设计，没有线上格式（wire format）。但四个设计点已经说得很清楚，每一条都值得盯着看。

第一，底座是 OAuth。 用户授权 Agent 的方式，和你今天让某个 App 访问你的另一个账号是一回事：授权可读、可写，随时能撤销。这是它相对「把密码交给 Agent」那种野生做法的关键区别——凭证不再被 Agent 攥在手里。

第二，会话从游客身份开始。 Agent 先以访客身份进来，可能只够查个库存、问个退货政策。真需要动你的账号了，你才在商家页面上登录，或者用你已经配给 Agent 的凭证。Sierra 强调「客户始终在掌控之中」，决定给不给写权限。

第三，会话跨渠道连续。 登录前问的那句话，和登录后改的那张订单，属于同一次访问。这听着琐碎，但它正是今天「Agent 登录后就失忆、每次都被当新访客」的痛点。

第四，商家决定走哪条路。 同一个会话，可以走商家自己的网页、走 MCP/OpenAPI 这类接口、或者走商家自己养的客服 Agent。三条路任选，商家说了算。

未来还画了三个饼：更细的权限（能按具体动作设限）、推送通知（航班延误、订单发货时主动告诉 Agent）、以及支付扩展（让 Agent 完成购买但不接触信用卡号）。最后这条是大头，也是最难的一条，目前仅止于「未来扩展」。

把流程跑一遍：一次改机票

光看条款没感觉，拿一个具体场景走一遍。假设你让 Agent 把周四的航班改到周五。

今天这件事怎么做？Agent 用你存的账号密码登录航空公司网站，像人一样点流程，或者干脆打客服电话。航空公司那边看到的，是一团和爬虫没区别的流量，它既不知道对面代表谁，也不知道这个动作有没有被你授权。

换成 PAP 的流程，会长这样：你先给 Agent 一个「可读行程 + 可改行程」的限定授权；航空公司校验这份授权，把一个「改签」的动作通过 API 或它自己的客服 Agent 暴露出来；Agent 完成改签，航空公司那边留下一笔记录，写着「由某个具名个人 Agent 替某位客户执行」。如果产生了差价要付款，规划中的支付扩展会接手，而 Agent 全程不碰你的卡号。

关键在于，每一步航空公司都能选择「允许、限制或拒绝」。这正是「一刀切封机器人」给不了的东西——它把一次黑箱式的爬取，拆成了一串可被商家逐项批准的具名动作。

一张表看清 2026 年的「协议丛林」

我把目前能查到的 agentic commerce 相关协议拉到一起，光能叫上名字的就有 10 个——这不是夸张，是这张表自己说话：

十个协议里，五个直接围绕支付。你要是今年在做一个购物相关的 Agent 产品，光「我该接哪个」这个问题就能拖死你。

这就是 2026 年最真实的行业状态：标准通胀。 当所有人都想要一个标准时，结果往往是十年里冒出十几个「标准」，谁也没被真正采用。

有意思的是，PAP 的名字里没有 Commerce。它叫 Personal Agent Protocol，而不是 Personal Commerce Protocol——这个命名本身就是一次表态：我不碰钱，我只管「人」。在一堆抢着定义「钱怎么走」的协议里，它选择去定义「人是谁」。至于这是深思熟虑的错位竞争，还是因为它知道支付那摊事自己插不进去，只有 v0.1 规范能回答。

最该注意的细节：Stripe 和 Shopify 在两头下注

如果 PAP 只是「第九个协议」，那它顶多是个注脚。真正让我多看两眼的是署名名单里两个名字：Stripe 和 Shopify。

这两家早在 2026 年 6 月就加入了 Visa 的 TAP——Visa 当时把 TAP 接进 ChatGPT，宣称能覆盖约 1.75 亿商家，微软、Stripe、Shopify、Worldpay 都在名单上。现在他们又出现在 PAP 的伙伴列表里。

同一家公司，同时在两个互相竞争的标准里署名。

这不是骑墙，这是这一轮协议战最清晰的信号：大厂不再赌哪一个标准赢，而是同时签下所有标准，把接哪家的选择权推给商家，让市场自己收敛。对 Stripe、Shopify 这种「谁做 Agent 都得经过我」的基础设施来说，多签一个协议的边际成本几乎为零，但少签一个就可能错过未来入口。

对创业公司，这几乎是坏消息。你想靠「提出一个更优雅的协议」建立护城河，对手可以直接用「我所有协议都支持」把差异化抹平。协议本身不值钱，能同时连上最多商家和最多 Agent 的那一层才值钱——而那层通常是分发，不是设计。

授权不等于意图：PAP 和 Visa TAP 的根本分野

把 PAP 和 Visa 的 TAP 摆在一起，藏着一个技术上的硬问题。

TAP 的做法是加签名。Agent 每次请求带上一段基于 **RFC 9421（HTTP Message Signatures）**的密码学签名，签名绑定「商家域名 + 具体操作 + 时间戳」，带防重放保护，还对齐了 Web Bot Auth。商家收到请求，先验签：这是不是一个被认可的 Agent、它替哪个已认证用户办事、它这次操作是否被授权。TAP 传递三层信息——Agent 意图、消费者识别、可选的支付信息。

PAP 的做法是给授权。OAuth 授权的是「这个 Agent 有权读你的订单、有权改你的地址」。

差别在哪？OAuth 管的是权限，管不了意图。 一个合法拿到「可写」授权的 Agent，如果被商家页面上的一段恶意文字诱导，同样可以用这个合法授权去做坏事。OAuth 能回收、能限权，但它天生不负责判断「这一秒的这次操作，到底是不是用户的真实意思」。

TAP 是在交易那一刻做验证，PAP 是在会话那一刻做授权。两者确实互补，这也是为什么 Stripe 能在两边同时站住。但「授权之后被滥用」这一段——注入攻击穿过合法授权——目前谁都没给出答案。想深挖这条攻击面，可以回看本站此前对 MCP 供应链安全的梳理。

这也是我这两年反复讲的一件事：Agent 的瓶颈从来不是模型能力，是信任边界。你可以把模型换得更强，但「它到底是替谁在动这笔钱」这个问题，模型答不了。

谁最想要 PAP？可能不是 Agent，是商家

媒体叙事里，PAP 是「给个人 Agent 开的一扇门」。我倒是觉得，最先把它接进生产的，可能是商家。

现在商家对 Agent 的反制基本只有一招：封。管你是正经购物助手还是刷接口的黄牛，一律按机器人拒掉。亚马逊此前就把 Meta 的 Muse 购物 Agent 挡在门外——从商家的角度，一个身份不明、登录就下单的东西，和一个骗子没有区别。

PAP 给商家的真正价值，是把「一刀切封 IP」升级成「分级拒绝层」：你可以查订单，但不能改地址；你可以发起退货，但不能动支付方式。被 Agent 爬爆的零售巨头，第一次能对一个 Agent 说「到这儿为止」。这比「给用户方便」的商业动机强得多——用户的方便是商家的成本，商家的可控才是商家的收益。

顺带一个政治观察。Sierra 的联合创始人 Bret Taylor 同时是 OpenAI 的董事长，而这次跟他一起署名的 Meta，恰恰是 OpenAI 消费级 Agent 的直接对手。一个「中立协议」对所有不想把命脉交给某一家 Agent 的玩家都有吸引力——它既是技术方案，也是一次站位。附录里那家 Hark，甚至在硬件上市前一年就先放出了「帮你买菜、订车、付账单」的 Agent，行业的时间表已经快过它自己的产品了。

还有一个没人愿意碰的合规问题

欧洲那边卡着一道更硬的关。

强客户认证（SCA）是欧盟支付规则里为「人」写的：一笔交易要由本人确认，绑定到明确的收款方和明确的金额。可「由软件替某人批准的一笔支付」，在规则里没有豁免。这意味着哪怕 PAP 的技术做得再漂亮，只要一笔钱是 Agent 替用户拍板的，在欧盟的合规口径下，它仍然缺一层法律认可的用户在场证明。

Sierra 把支付列为「未来扩展」而不是首发规范，未必全是技术上的谨慎，也可能是在绕开这块最烫的石头。再回头看署名名单：唯一的欧洲总部是 Stripe（旧金山 + 都柏林双总部），没有任何一家欧洲零售商、银行或支付公司加入。这个空白，比协议本身更说明问题——一个主打「替全球消费者和全球商家牵线」的标准，第一版里欧洲是缺席的。

泼一盆冷水：伙伴名单不等于生产接入

最后说点煞风景的。

PAP 现在没有规范。v0.1 承诺在 10 月内发布，设计工作坊和参考实现还都在计划里。伙伴「参与开发」和「真的在线上支持」是两回事——沃尔玛或 Shopify 会不会在门户里真开这个口，一个字都没说。

参照物就在眼前：Visa 的 TAP 2025 年 10 月发布，到 2026 年 6 月，状态还是 Beta，GitHub 仓库里没有打过任何 release tag，除了初期署名伙伴外的商家采用情况也没有一手记录。一条协议从「发布」走到「能用」，业内普遍要 12 到 18 个月。

所以我的判断是：PAP 的 v0.1 就算 10 月如期发布，真正跑起来的窗口要到 2027 年。2026 年剩下的这几个月，你会在各种公告里看到它的名字，但在生产环境的日志里，基本见不到。

写在最后

我对 PAP 的态度是「谨慎看好，但别急着接」。

它有这个领域最缺的东西：一个愿意把自己放在中立位置、还带得动 Meta、沃尔玛、Stripe 的发起方。它也有这个领域最常见的东西：一份还没落地的规范和一堆可能在明年就变了的伙伴。更重要的是，它精准地绕开了已经打烂的支付层，去抢「身份与授权」这块空地——这个判断本身，我认同。

真正要盯的就三件事：第一，v0.1 规范里 discovery 怎么做——Agent 靠什么发现商家支持哪些能力，这一条决定了控制权归谁；第二，有没有一家大商家真的在生产环境里接——哪怕只是一家，也比九家署名更有分量；第三，支付扩展怎么落——它决定了 PAP 是停在「登录层」，还是往有油水的地方长。

标准这东西的规律很残酷：发得最早的，很少是最后活下来的。跑得起来的，才是标准。PAP 现在站在起跑线上，而它真正的对手，不是 Visa，不是 OpenAI，是所有人对「又一个协议」的耐心。

相关阅读

• 《「在聊天框里点确认」撑不住了：Agent 的审批和权限，正在长成独立的一层》 —— 同一个问题的另一面：Agent 权限为什么必须单独成层
• 《UHP 深度拆解：继 MCP 之后，Agent Harness 也要有自己的协议了！》 —— 另一条「想当标准」的协议，可以对照它的野心与代价
• 《MCP 供应链安全：npm 的惨痛教训正在 Agent 生态重演》 —— 授权之后的滥用从哪里来，这篇给了更完整的攻击面