https://www.yesmiracle.net/tags/personal-agent-protocol/ AI博士万戈的技术博客，聚焦 Agentic AI、AI Infra 与 Agent Security，分享 AI 基础设施与工程落地实践。 Hugo -- gohugo.io zh-cn admin@yesmiracle.net (万戈) admin@yesmiracle.net (万戈) Sun, 11 Oct 2026 00:00:00 +0000 https://www.yesmiracle.net/post/20261011-personal-agent-protocol-agentic-commerce-standard/ Sun, 11 Oct 2026 00:00:00 +0000 admin@yesmiracle.net (万戈) https://www.yesmiracle.net/post/20261011-personal-agent-protocol-agentic-commerce-standard/ <img src="https://www.yesmiracle.net/post/20261011-personal-agent-protocol-agentic-commerce-standard/cover.svg" alt="Featured image of post Meta、沃尔玛、Stripe 联手给「AI 替你办事」写登录标准：比支付更值钱的，是「它证明它就是你」那一层！" /><p>如果你这几个月在小红书或 X 上刷到有人让 AI 帮忙比价、下单、改机票、退个货，那大概是今年最热闹的一条产品线：个人 Agent（personal agent）。它们不发自拍，但已经在替你点按钮、填表单、刷购物车。</p> <p>问题出在它们抵达商家网站的那一刻。沃尔玛的服务器看到的是一个来路不明的「用户」——分不清是真人在浏览，是一个正经的购物助手，还是一个被 prompt injection 劫持、正把钱往外转的机器人。于是商家只能一刀切封掉，用户的 Agent 就成了「坏掉的产品」。</p> <p>10 月 6 日，Sierra 和 Meta 宣布了一条新标准 Personal Agent Protocol（下文简称 PAP），想给这件事一个统一答案。一起署名的还有 Genesys、Instinct、Rocket、Shopify、Stripe 和沃尔玛。</p> <p>我看完的第一反应不是「AI 圈又多了一个协议」，而是：这批人挑的切入点很刁。支付那一层早就挤爆了，他们偏偏绕开它，去抢上面那层至今空着的东西——「你是谁，你被允许干什么」。</p> <h2 id="pap-想管的是登录不是结账">PAP 想管的是「登录」，不是「结账」</h2> <p>先把坐标摆正，不然后面全乱。</p> <p>现在的 Agent 协议大致分三层。最底下是连接层，MCP（Model Context Protocol）负责让 Agent 调用工具和数据，这一层的归属基本定了，Anthropic 把它捐给了 Linux 基金会。中间是交易层，负责「把这一单买完」，OpenAI 和 Stripe 的 ACP、Google 的 UCP、Coinbase 的 x402 都在这里厮杀。</p> <p>PAP 说自己不属于上面任何一层，它要做的是<strong>关系层</strong>：哪个 Agent 在访问、它替谁办事、它被授权做了什么。用 Sierra 自己的话，是「在网站上和公司建立一段会话，用户决定给 Agent 只读还是可写权限」。</p> <p>这个定位很聪明，也很危险。聪明在于没人占；危险在于，它必须和上下两层都能对接，否则就是个孤岛。</p> <h2 id="一次会话怎么走从游客到读写">一次会话怎么走：从「游客」到「读/写」</h2> <p>PAP 目前只公布了高层设计，没有线上格式（wire format）。但四个设计点已经说得很清楚，每一条都值得盯着看。</p> <p><strong>第一，底座是 OAuth。</strong> 用户授权 Agent 的方式，和你今天让某个 App 访问你的另一个账号是一回事：授权可读、可写，随时能撤销。这是它相对「把密码交给 Agent」那种野生做法的关键区别——凭证不再被 Agent 攥在手里。</p> <p><strong>第二，会话从游客身份开始。</strong> Agent 先以访客身份进来，可能只够查个库存、问个退货政策。真需要动你的账号了，你才在商家页面上登录，或者用你已经配给 Agent 的凭证。Sierra 强调「客户始终在掌控之中」，决定给不给写权限。</p> <p><strong>第三，会话跨渠道连续。</strong> 登录前问的那句话，和登录后改的那张订单，属于同一次访问。这听着琐碎，但它正是今天「Agent 登录后就失忆、每次都被当新访客」的痛点。</p> <p><strong>第四，商家决定走哪条路。</strong> 同一个会话，可以走商家自己的网页、走 MCP/OpenAPI 这类接口、或者走商家自己养的客服 Agent。三条路任选，商家说了算。</p> <p>未来还画了三个饼：更细的权限（能按具体动作设限）、推送通知（航班延误、订单发货时主动告诉 Agent）、以及支付扩展（让 Agent 完成购买但<strong>不接触信用卡号</strong>）。最后这条是大头，也是最难的一条，目前仅止于「未来扩展」。</p> <h2 id="把流程跑一遍一次改机票">把流程跑一遍：一次改机票</h2> <p>光看条款没感觉，拿一个具体场景走一遍。假设你让 Agent 把周四的航班改到周五。</p> <p>今天这件事怎么做？Agent 用你存的账号密码登录航空公司网站，像人一样点流程，或者干脆打客服电话。航空公司那边看到的，是一团和爬虫没区别的流量，它既不知道对面代表谁，也不知道这个动作有没有被你授权。</p> <p>换成 PAP 的流程，会长这样：你先给 Agent 一个「可读行程 + 可改行程」的限定授权；航空公司校验这份授权，把一个「改签」的动作通过 API 或它自己的客服 Agent 暴露出来；Agent 完成改签，航空公司那边留下一笔记录，写着「由某个具名个人 Agent 替某位客户执行」。如果产生了差价要付款，规划中的支付扩展会接手，而 Agent 全程不碰你的卡号。</p> <p>关键在于，每一步航空公司都能选择「允许、限制或拒绝」。这正是「一刀切封机器人」给不了的东西——它把一次黑箱式的爬取，拆成了一串可被商家逐项批准的具名动作。</p> <h2 id="一张表看清-2026-年的协议丛林">一张表看清 2026 年的「协议丛林」</h2> <p>我把目前能查到的 agentic commerce 相关协议拉到一起，光能叫上名字的就有 <strong>10</strong> 个——这不是夸张，是这张表自己说话：</p> <table> <thead> <tr> <th>协议</th> <th>主导方</th> <th>定位</th> <th>交易/支付</th> <th>成熟度</th> </tr> </thead> <tbody> <tr> <td><strong>MCP</strong></td> <td>Anthropic（已捐 Linux 基金会）</td> <td>连接层：Agent 调工具/数据</td> <td>否</td> <td>稳定</td> </tr> <tr> <td><strong>A2A</strong></td> <td>Google（Linux 基金会）</td> <td>Agent 之间通信</td> <td>否</td> <td>基础版</td> </tr> <tr> <td><strong>ACP</strong></td> <td>OpenAI + Stripe</td> <td>结账：ChatGPT Instant Checkout 底层</td> <td>是</td> <td>Beta</td> </tr> <tr> <td><strong>UCP</strong></td> <td>Google + Shopify（Etsy/Wayfair/Target/沃尔玛）</td> <td>全流程购物标准</td> <td>是</td> <td>Beta</td> </tr> <tr> <td><strong>AP2</strong></td> <td>Google（捐给 FIDO 联盟，60+ 伙伴）</td> <td>Agent 支付框架，扩展 A2A/MCP</td> <td>是</td> <td>基础版</td> </tr> <tr> <td><strong>x402</strong></td> <td>Coinbase（x402 基金会）</td> <td>HTTP 原生稳定币支付（402 状态码）</td> <td>是</td> <td>稳定</td> </tr> <tr> <td><strong>TAP</strong></td> <td>Visa + Cloudflare</td> <td>结账时验证 Agent 身份（RFC 9421 签名）</td> <td>部分</td> <td>Beta</td> </tr> <tr> <td><strong>Agent Pay</strong></td> <td>Mastercard</td> <td>发卡侧 Agentic Token 支付</td> <td>是</td> <td>已宣布</td> </tr> <tr> <td><strong>MPP</strong></td> <td>Tempo + Stripe</td> <td>HTTP 上的程序化支付（稳定币+法币）</td> <td>是</td> <td>Beta</td> </tr> <tr> <td><strong>PAP</strong></td> <td>Sierra + Meta（本次）</td> <td>关系层：身份与授权会话</td> <td>否（规划中）</td> <td>仅公告</td> </tr> </tbody> </table> <p>十个协议里，五个直接围绕支付。你要是今年在做一个购物相关的 Agent 产品，光「我该接哪个」这个问题就能拖死你。</p> <p><strong>这就是 2026 年最真实的行业状态：标准通胀。</strong> 当所有人都想要一个标准时，结果往往是十年里冒出十几个「标准」，谁也没被真正采用。</p> <p>有意思的是，PAP 的名字里没有 Commerce。它叫 Personal Agent Protocol，而不是 Personal Commerce Protocol——这个命名本身就是一次表态：我不碰钱，我只管「人」。在一堆抢着定义「钱怎么走」的协议里，它选择去定义「人是谁」。至于这是深思熟虑的错位竞争，还是因为它知道支付那摊事自己插不进去，只有 v0.1 规范能回答。</p> <h2 id="最该注意的细节stripe-和-shopify-在两头下注">最该注意的细节：Stripe 和 Shopify 在两头下注</h2> <p>如果 PAP 只是「第九个协议」，那它顶多是个注脚。真正让我多看两眼的是署名名单里两个名字：<strong>Stripe 和 Shopify</strong>。</p> <p>这两家早在 2026 年 6 月就加入了 Visa 的 TAP——Visa 当时把 TAP 接进 ChatGPT，宣称能覆盖约 <strong>1.75 亿</strong>商家，微软、Stripe、Shopify、Worldpay 都在名单上。现在他们又出现在 PAP 的伙伴列表里。</p> <p><strong>同一家公司，同时在两个互相竞争的标准里署名。</strong></p> <p>这不是骑墙，这是这一轮协议战最清晰的信号：大厂不再赌哪一个标准赢，而是同时签下所有标准，把接哪家的选择权推给商家，让市场自己收敛。对 Stripe、Shopify 这种「谁做 Agent 都得经过我」的基础设施来说，多签一个协议的边际成本几乎为零，但少签一个就可能错过未来入口。</p> <p>对创业公司，这几乎是坏消息。你想靠「提出一个更优雅的协议」建立护城河，对手可以直接用「我所有协议都支持」把差异化抹平。协议本身不值钱，<strong>能同时连上最多商家和最多 Agent 的那一层</strong>才值钱——而那层通常是分发，不是设计。</p> <h2 id="授权不等于意图pap-和-visa-tap-的根本分野">授权不等于意图：PAP 和 Visa TAP 的根本分野</h2> <p>把 PAP 和 Visa 的 TAP 摆在一起，藏着一个技术上的硬问题。</p> <p>TAP 的做法是加签名。Agent 每次请求带上一段基于 **RFC 9421（HTTP Message Signatures）**的密码学签名，签名绑定「商家域名 + 具体操作 + 时间戳」，带防重放保护，还对齐了 Web Bot Auth。商家收到请求，先验签：这是不是一个被认可的 Agent、它替哪个已认证用户办事、它这次操作是否被授权。TAP 传递三层信息——Agent 意图、消费者识别、可选的支付信息。</p> <p>PAP 的做法是给授权。OAuth 授权的是「这个 Agent 有权读你的订单、有权改你的地址」。</p> <p>差别在哪？<strong>OAuth 管的是权限，管不了意图。</strong> 一个合法拿到「可写」授权的 Agent，如果被商家页面上的一段恶意文字诱导，同样可以用这个合法授权去做坏事。OAuth 能回收、能限权，但它天生不负责判断「这一秒的这次操作，到底是不是用户的真实意思」。</p> <p>TAP 是在<strong>交易那一刻</strong>做验证，PAP 是在<strong>会话那一刻</strong>做授权。两者确实互补，这也是为什么 Stripe 能在两边同时站住。但「授权之后被滥用」这一段——<strong>注入攻击穿过合法授权</strong>——目前谁都没给出答案。想深挖这条攻击面，可以回看本站此前对 MCP 供应链安全的梳理。</p> <blockquote> <p>这也是我这两年反复讲的一件事：Agent 的瓶颈从来不是模型能力，是信任边界。你可以把模型换得更强，但「它到底是替谁在动这笔钱」这个问题，模型答不了。</p></blockquote> <h2 id="谁最想要-pap可能不是-agent是商家">谁最想要 PAP？可能不是 Agent，是商家</h2> <p>媒体叙事里，PAP 是「给个人 Agent 开的一扇门」。我倒是觉得，最先把它接进生产的，可能是<strong>商家</strong>。</p> <p>现在商家对 Agent 的反制基本只有一招：封。管你是正经购物助手还是刷接口的黄牛，一律按机器人拒掉。亚马逊此前就把 Meta 的 Muse 购物 Agent 挡在门外——从商家的角度，一个身份不明、登录就下单的东西，和一个骗子没有区别。</p> <p>PAP 给商家的真正价值，是<strong>把「一刀切封 IP」升级成「分级拒绝层」</strong>：你可以查订单，但不能改地址；你可以发起退货，但不能动支付方式。被 Agent 爬爆的零售巨头，第一次能对一个 Agent 说「到这儿为止」。这比「给用户方便」的商业动机强得多——用户的方便是商家的成本，商家的可控才是商家的收益。</p> <p>顺带一个政治观察。Sierra 的联合创始人 Bret Taylor 同时是 OpenAI 的董事长，而这次跟他一起署名的 Meta，恰恰是 OpenAI 消费级 Agent 的直接对手。一个「中立协议」对所有不想把命脉交给某一家 Agent 的玩家都有吸引力——它既是技术方案，也是一次站位。附录里那家 Hark，甚至在硬件上市前一年就先放出了「帮你买菜、订车、付账单」的 Agent，行业的时间表已经快过它自己的产品了。</p> <h2 id="还有一个没人愿意碰的合规问题">还有一个没人愿意碰的合规问题</h2> <p>欧洲那边卡着一道更硬的关。</p> <p>强客户认证（SCA）是欧盟支付规则里为「人」写的：一笔交易要由本人确认，绑定到明确的收款方和明确的金额。可「由软件替某人批准的一笔支付」，在规则里<strong>没有豁免</strong>。这意味着哪怕 PAP 的技术做得再漂亮，只要一笔钱是 Agent 替用户拍板的，在欧盟的合规口径下，它仍然缺一层法律认可的用户在场证明。</p> <p>Sierra 把支付列为「未来扩展」而不是首发规范，未必全是技术上的谨慎，也可能是在绕开这块最烫的石头。再回头看署名名单：唯一的欧洲总部是 Stripe（旧金山 + 都柏林双总部），没有任何一家欧洲零售商、银行或支付公司加入。这个空白，比协议本身更说明问题——一个主打「替全球消费者和全球商家牵线」的标准，第一版里欧洲是缺席的。</p> <h2 id="泼一盆冷水伙伴名单不等于生产接入">泼一盆冷水：伙伴名单不等于生产接入</h2> <p>最后说点煞风景的。</p> <p>PAP 现在<strong>没有规范</strong>。v0.1 承诺在 10 月内发布，设计工作坊和参考实现还都在计划里。伙伴「参与开发」和「真的在线上支持」是两回事——沃尔玛或 Shopify 会不会在门户里真开这个口，一个字都没说。</p> <p>参照物就在眼前：Visa 的 TAP 2025 年 10 月发布，到 2026 年 6 月，状态还是 Beta，GitHub 仓库里没有打过任何 release tag，除了初期署名伙伴外的商家采用情况也没有一手记录。<strong>一条协议从「发布」走到「能用」，业内普遍要 12 到 18 个月。</strong></p> <p>所以我的判断是：PAP 的 v0.1 就算 10 月如期发布，真正跑起来的窗口要到 2027 年。2026 年剩下的这几个月，你会在各种公告里看到它的名字，但在生产环境的日志里，基本见不到。</p> <h2 id="写在最后">写在最后</h2> <p>我对 PAP 的态度是「谨慎看好，但别急着接」。</p> <p>它有这个领域最缺的东西：一个愿意把自己放在中立位置、还带得动 Meta、沃尔玛、Stripe 的发起方。它也有这个领域最常见的东西：一份还没落地的规范和一堆可能在明年就变了的伙伴。更重要的是，它精准地绕开了已经打烂的支付层，去抢「身份与授权」这块空地——这个判断本身，我认同。</p> <p>真正要盯的就三件事：<strong>第一，v0.1 规范里 discovery 怎么做</strong>——Agent 靠什么发现商家支持哪些能力，这一条决定了控制权归谁；<strong>第二，有没有一家大商家真的在生产环境里接</strong>——哪怕只是一家，也比九家署名更有分量；<strong>第三，支付扩展怎么落</strong>——它决定了 PAP 是停在「登录层」，还是往有油水的地方长。</p> <p>标准这东西的规律很残酷：发得最早的，很少是最后活下来的。跑得起来的，才是标准。PAP 现在站在起跑线上，而它真正的对手，不是 Visa，不是 OpenAI，是所有人对「又一个协议」的耐心。</p> <h2 id="相关阅读">相关阅读</h2> <ul> <li><a class="link" href="https://www.yesmiracle.net/post/20261008-agent-approval-permission-layer/" >《「在聊天框里点确认」撑不住了：Agent 的审批和权限，正在长成独立的一层》</a> —— 同一个问题的另一面：Agent 权限为什么必须单独成层</li> <li><a class="link" href="https://www.yesmiracle.net/post/20261006-uhp-unified-harness-protocol-deep-dive/" >《UHP 深度拆解：继 MCP 之后，Agent Harness 也要有自己的协议了！》</a> —— 另一条「想当标准」的协议，可以对照它的野心与代价</li> <li><a class="link" href="https://www.yesmiracle.net/post/20261001-agent-mcp-supply-chain-security/" >《MCP 供应链安全：npm 的惨痛教训正在 Agent 生态重演》</a> —— 授权之后的滥用从哪里来，这篇给了更完整的攻击面</li> </ul>