Personal Agent Protocol 是一份草案标准,规定个人 AI 助手如何进入企业的网站、API 和客服 agent,以及进入之后企业允许它做什么。它由 Sierra 和 Meta 联合发布,合作方包括 Stripe、Shopify 和 Walmart(Sierra 公告),几天后,代号 Poppy 的首份草案也公开了(Sierra 谈草案)。它还不是一个你现在就能打开使用的产品。
如果你经营一家企业,实用的结论是:什么都不会坏,也没有任何强制要求。但 AI 助手已经在替客户访问网站了,而这份草案是第一次认真尝试让你对访问方式拥有话语权。现在花一小时了解它的大致样子,成本很低;如果置之不理,接下来几年你可能要被迫临时拼凑一堆应对机器人的规则。
本文会讲这份草案定义了什么、它与 MCP、A2A 以及各类商务协议有何不同、谁加入了、谁没加入,最后给出几件现在就值得做的事。
目前公开了什么,没公开什么
目前有三样东西。一是 Sierra 的公告,列出了合作方和设计目标。二是一份草案规范,标注为 Draft 0.1,采用 Apache 2.0 许可(规范)。三是关于设计工作坊和参考实现的承诺,但在本文查阅的资料中,这两样都还没有出现(Sierra)。
还没公开的有:任何一家在生产环境中实际运行它的公司、治理机构,以及支付问题的明确答案。消息刚出来时,有报道指出尚未发现任何治理机构或许可证(FourWeekMBA)。许可证的问题已经由草案本身回答了,而治理问题,在我们查阅的页面里仍然没有答案。
所以,把它当作一份有重量级支持者的提案就好。Meta 用电子邮件打了个比方来说明其野心:"电子邮件之所以普及,是因为大家就寻址、消息传输和投递达成了一致。没有人拥有它,任何人都可以在它之上构建"(VKTR)。但电子邮件也花了很多年,期间不少企业各搞各的邮件规则。这里也会是类似的拼凑局面:早期采用者定下惯例,其他人照着抄。
问题所在:要么全部拦住,要么交出密码
项目官网把现状说得很直白:企业要么彻底屏蔽 agent,要么让 agent 用用户的完整凭据登录,用户能做什么它就能做什么(personalagentprotocol.org)。两种做法都不好。屏蔽会惹恼派出 agent 的客户,完全放开则等于埋下一次安全审查的雷。
屏蔽是真实存在的。一篇对公告的汇总文章列出了屏蔽 agent 的网站,包括 Amazon、Delta、United、Zillow 和 eBay,还提到 Cloudflare 的一项反机器人策略误伤了一些 agent(AI Weekly)。Stripe 的 Kevin Miller 把客户的立场说得很清楚:派出 agent 的人"期望获得与自己亲自操作时相同的服务"(Unite.AI)。
草案给出的答案是一个"阶梯"。官网用酒店举例:屏蔽 agent;允许任何 agent 搜索房间;登录后允许查看预订;只有在本人每次批准后才允许订房;或者给予完全访问权限。你可以针对每个操作选择停在哪一级。
关键在中间几级。大多数企业会希望 agent 可以自由浏览和读取,但只有在真人点头之后才能修改内容。
一次会话是怎么运转的
企业在 /.well-known/poppy.json 发布一个文件,说明 agent 可以如何与自己交互。agent 读取这个文件,开启一次会话(如果没人登录就以访客身份),需要更多权限时,再引导用户完成基于 OAuth 的登录(Sierra)。草案列出三种登录类型:direct(直接),用户在企业自己的页面上登录;device(设备),用户在另一台设备上输入验证码;mediated(代理),由 agent 自己提交凭据(规范)。
有两个细节是安全人员需要关注的。会话 token 有效期很短,并通过 DPoP 绑定到密钥;草案还规定,agent 不得在 URL 中发送 token,企业也不得接受放在 URL 里的 token。草案也承认了薄弱环节:"接受来自 Personal Agent 的凭据,会让企业承担更多责任"(规范)。
另一个值得了解的思路是,一个 token 通用所有场景。Sierra 表示,同一个 token 可用于企业的 API、网站,以及与企业 agent 的对话(Sierra)。登录前提的问题和登录后修改的订单,会被算作同一次访问(The Next Web)。
三条接入路径,由你选
你不必全部实现。企业自己选择 agent 的接入方式:通过网站,通过用 OpenAPI 描述的 API 或 MCP server,或者通过企业自己的 agent 进行对话。API 做得好的零售商可以跳过浏览这条路径;只有网站的小店则可以从这里起步。
对话这条路径有一条客户会喜欢的规则:每条消息都要标明是真人还是 AI 写的,草案还涵盖了转接真人的流程。如果你已经在运行客服 agent,比如来自客服榜单的产品,最先影响到你的就是这条路径。
它与 MCP、A2A、ACP 和 AP2 的关系
它不会取代其中任何一个,也不该被看作与它们竞争。它们各管不同的事,草案本身还借助了 MCP。
| 协议 | 发起方 | 作用 |
|---|---|---|
| MCP | 开源标准 | 将 AI 应用连接到工具和数据(MCP 文档) |
| A2A | Google 发起,现属 Linux Foundation | 让不同厂商的 agent 互相通信(A2A) |
| ACP | Stripe 和 OpenAI | agent 结账与支付凭据共享(ACP) |
| AP2 | 用签名授权凭证证明用户授权了一次购买(AP2) | |
| Personal Agent Protocol | Sierra 和 Meta(草案) | 个人 agent 与企业之间的发现、会话、登录和权限 |
上面这种分层是我们自己的理解,不是官方示意图。简单来说:MCP 是 agent 调用工具的方式,A2A 是 agent 之间对话的方式,ACP 和 AP2 管支付,而这份草案管的是"进门并被认出来"。支付被列为未来扩展,所以眼下结账仍要靠 ACP 或 AP2 之类的协议。最容易引发争论的重叠点是 MCP,因为草案和一个普通的 MCP server 都可以暴露企业的操作。
在访问这一层也有竞争对手。Visa 运营着一个 Trusted Agent Protocol,今年早些时候发布,The Next Web 报道称 Stripe 和 Shopify 已经加入(The Next Web)。Visa 现在也在 Personal Agent Protocol 的设计合作伙伴名单上,所以这两个项目可能是重叠而非正面竞争。行业最终会只有一个标准还是两个,目前还没有定论。
谁加入了,谁缺席
公告中除 Sierra 和 Meta 外,还点名了 Genesys、Instinct、Rocket、Shopify、Stripe 和 Walmart(Sierra)。草案文章还把 NiCE 列入第一批,并新增 35 家设计合作伙伴,包括 Adyen、Bank of America、BBVA、Cloudflare、Mastercard、OpenAI、PayPal、Target、United Airlines、Visa 和 Wells Fargo。Sierra 表示它们将参与设计过程,这和已经交付支持不是一回事(Sierra)。这也改写了之前的说法:公告当天,有报道指出 OpenAI 缺席,而 Sierra 联合创始人 Bret Taylor 正是 OpenAI 董事会主席(AI Weekly)。
Amazon、Anthropic 和 Google 既不在发布时列出的合作方中,也不在草案文章里。名单上没有不代表它们不参与,所以引用前请再查一下 Sierra 的页面。Claude、ChatGPT 和 Perplexity 都是天然的个人 agent,如果没有主流助手支持,这个标准就只是企业这一侧的一份检查清单。公告当天,The Next Web 指出没有任何欧洲零售商、银行或支付公司被点名(The Next Web)。现在更长的名单里已经有了 BBVA 和 Adyen。
对开发者和营销人员意味着什么
开发者拿到的是更明确的交易。如果你的产品已经有 OAuth 和 OpenAPI 描述,那么走 API 这条路你已经完成了大半,草案里的 token 规则(短有效期、绑定密钥、绝不放进 URL)读起来也就是普通的好习惯。新增的工作是发现文件,以及决定 scope。
营销人员面对的是一个衡量问题。今天,替客户研究你定价页的 agent 看起来像机器人,或者根本看不到。如果会话能标识出 agent 以及背后的客户,这部分流量就变成了你可以统计、并区别于爬虫对待的东西。这是不是好事,取决于你希望 agent 怎么谈论你,这既是内容问题,也是技术问题。
企业现在可以做什么
下面这些都不需要这份协议。不管草案最终胜出还是销声匿迹,它们都有用。
- 查看日志和机器人防护工具,弄清已经有哪些 agent 流量到达你这里。如果你在用 Cloudflare,检查它的机器人规则会如何处理替客户办事的 agent。
- 逐个操作写清楚 agent 可以读什么、可以改什么。可以参照上面的阶梯:浏览、查看账户、经批准后操作。
- 确认客户可以通过标准 OAuth 流程登录。agent 会依赖它。
- 把最常用的操作(订单状态、退货、预订)放到有文档的 API 或 MCP server 后面。一份描述清晰的 OpenAPI 文件本来就值得拥有。
- 如果你在 Shopify 上开店,关注平台会推出什么,而不是自己从头做。
- 指定一个人负责跟进这份草案。规范的 Open topics 页面有更新时去读一读。
下面的评分器把这份清单变成一个快速自查工具。这是我们自己的清单,不属于协议的一部分。
谁暂时不用操心:没有登录系统、没有 API、也没有客服 agent 的企业,你没有什么可暴露的。如果你做的是客户服务,最接近的参照就是你已经在运行的 AI agent(Sierra AI Agents 就是一个;AI 客服聊天机器人榜单列出了其他选择)。相关阅读:我们的 AI agent 平台选购指南和 AI agent 总榜。
尚未解决的问题
身份。 草案允许企业要求 agent 注册,按 client ID 维护允许名单和屏蔽名单,并撤销滥用协议的 client ID(规范)。谁来为一个 agent 担保,小商家又如何核实,都留给各家企业自己决定。公告发布时,有报道称对于 agent 如何证明身份没有给出细节(FourWeekMBA)。规范也没有描述一个共享的可信 agent 注册表。
授权。 direct 登录会展示所请求的 scope,并让用户批准其中一部分、全部或一个都不批准。这很好。但还没定下来的是 agent 多久请求一次,以及用户会不会无脑点同意。
责任。 如果 agent 订错了航班,总得有人买单,而规范没说是谁。它压根没提责任问题。支付也没提,那被留到以后再说。
垃圾请求与滥用。 企业可以按 client ID 对会话创建进行限流。面对不断更换身份的 agent,这招管不管用,还没有经过检验。
常见问题
Personal Agent Protocol 已经上线了吗?
还没有作为正式发布的标准上线。Draft 0.1 规范已经公开,Sierra 承诺会举办工作坊并提供参考实现。在我们查阅的资料中,没有点名任何生产环境部署。
它会取代 MCP 吗?
不会。它把 MCP 当作企业暴露操作的方式之一。MCP 把 AI 应用连接到工具,而这份草案管的是 agent 是谁,以及它在某家企业可以做什么。
我需要发布 poppy.json 文件吗?
暂时不用。草案说企业发布它是为了便于发现,但在规范稳定、agent 开始读取它之前,没人必须这么做。真正有用的是提前把背后的决定想清楚。
我还能屏蔽 AI agent 吗?
可以。屏蔽就是阶梯的第一级。草案的卖点是,在屏蔽和完全放开之间,你有了更多选项。
它处理支付吗?
草案里不处理。Sierra 把"不暴露银行卡信息的支付"列为未来扩展。眼下要做结账,请看 ACP 或 AP2。
谁来掌控它?
草案采用 Apache 2.0 许可,由 Sierra 与 Meta 发布。已发布的页面里没有出现任何治理机构,所以长期由谁来掌舵,仍是个未决问题。