一个开放标准，定义了智能代理如何代表你的客户购物！🤝

由 @btaylor 领导的 @SierraPlatform 发布了 Personal Agent Protocol（个人代理协议）的首份草案，代号 Poppy，并宣布新增 35 家合作伙伴参与其设计，其中包括 OpenAI、Visa、Mastercard 和 PayPal。

• 客户决定授予其代理的权限，企业则规定代理被允许执行的操作。
• 企业在其网站上发布一份文件，向代理说明如何与之交互。
• 代理始终表明自身身份，使企业清楚自己正在与代理打交道，以及该代理代表谁。

在线商店经营者或处理预订的诊所需要做好准备：客户将派自己的代理前来，而不是亲自浏览网站。

Sierra 于周二与 Meta、Shopify、Stripe 和 Walmart 一同宣布了该协议，目前草案已开放，接受来自企业和开发者的反馈。

深入解读 Meta 的 PAP（Personal Agent Protocol）

来源：https://x.com/changgaowei/article/2108923831616209041 作者：常高伟，ANP 开源社区发起人

协议是代理之间最高效的交互方式，即传递上下文和相互调用。

这是我从去年开始讲协议以来一直强调的观点。随着个人代理的兴起，协议变得更加重要。

几天前我写了一篇 PAP 的介绍（Meta 推出 PAP，面向个人代理的新协议 https://x.com/changgaowei/article/2107834303753212059）。今天 PAP 规范正式发布。我花了一上午通读了全文，以下是我的解读。我将用通俗的语言，阐述 PAP 的核心设计，以及它与 MCP、A2A 和 ANP 的区别。

让我们从一个场景开始。

假设我下周要去纽约出差。我打开 Meta 的个人代理 Muse，对它说：

“帮我在纽约曼哈顿订一家酒店，住两晚，总预算不超过 600 美元，如果可以的话要含早餐，且支持免费取消。”

在没有 PAP 的情况下，Muse 会怎么做？

它可能不得不像人一样操作酒店网站，搜索房间、查看价格、填写表单，或者通过企业提供的某个界面来完成任务。但企业并没有统一的方式来识别这个代理，也无法确认用户授权了它哪些操作。

更糟糕的是，如果这家酒店上架在 Amazon 等平台上，该平台可能已经封禁了 Muse。

PAP 要解决的不只是如何连接企业，更是如何让代理在用户授权和企业规则的范围内完成任务。

假设这家酒店已支持 PAP。整个流程可以这样进行：

第 0 步：酒店支持 PAP 并发布其服务入口。

酒店采用 PAP，并在其官方网站的标准地址 /.well-known/poppy.json 下，发布一份面向代理的“服务手册“，描述其服务接口、客服代理以及登录和授权方式。

此外，如果 Google 这样的搜索引擎支持识别这些文件，就可以对发现的 PAP 服务进行索引。

第 1 步：Muse 通过搜索引擎找到这家酒店。

Muse 首先通过搜索引擎找到位于正确位置的酒店，然后读取每家酒店的服务手册，了解如何查询房间可用性、获取价格以及联系酒店的客服代理。

接下来，Muse 向酒店证明其客户端身份并建立会话。酒店知道来访的是一个个人代理，可以让它先查询公开信息，而不需要我立即登录。

第 2 步：我授权 Muse 并决定它能做什么。

查询会员价格、查看历史订单或创建预订都涉及我的账户和我的权限。

Muse 引导我到酒店自己的登录和授权页面。我在酒店页面上登录，而不把用户名密码交给 Muse，并选择允许它做什么。例如，我可以先允许它仅查看会员信息和订单，等它需要创建或修改预订时再授予相应权限。

然后酒店向 Muse 签发一个访问令牌。Muse 获得的是范围受限的访问权限，而非对我账户的完全控制，并且该授权可以被撤销。

第 3 步：Muse 在授权范围内与酒店交互。

Muse 可以调用酒店的 API 或 MCP 查询房间，也可以与酒店的客服代理协商提前入住等特殊需求。必要时，它仍然可以操作网页。

第 4 步：我确认具体方案，Muse 完成预订。

当 Muse 找到合适的房间后，它会向我确认：

“这家酒店两晚含税总价 560 美元，含早餐，可在入住前一天免费取消。您要确认预订吗？”

在我授出预订所需的权限并确认后，Muse 提交订单，通过酒店现有的流程完成支付或担保，最后将结果告诉我。

PAP 解决什么问题

了解一个协议解决什么问题，是理解它最简单直接的方式。

MCP 解决模型如何连接工具和资源。A2A 解决两个代理如何在任务的基础上进行默认交互。ANP 解决如何让互联网上任意两个代理互联互通。

PAP 解决个人代理如何与代表企业的代理协作。它在个人代理和企业之间建立标准化的交互机制，使代理能够在企业认可和用户授权的范围内完成任务。

PAP 最鲜明的特色是，除了其身份和授权机制之外，它将授权延伸到了企业交互的整个流程。

PAP 的代理身份方案

继续酒店预订的例子。当 Meta 的 Muse 首次访问这家酒店时，酒店面临一个问题：我怎么知道这个请求真的来自某个特定的个人代理客户端，而不是某个冒充它的其他程序？

PAP 没有设计一套全新的身份系统。它采用了 CIMD（Client ID Metadata Document，客户端 ID 元数据文档），这是一个正在 OAuth 生态中标准化的方案。这份草案也已被 MCP 采用。

CIMD 解决的问题是：OAuth 客户端每次连接外部服务都要提前注册账户。这大大降低了代理的自动化程度，增加了需要人工介入的频率。

CIMD 的思路很简单：每个个人代理客户端都可以使用一个 HTTPS URL 作为标识符，并在该地址发布身份元数据文档。

例如，一个个人代理可以使用：

https://agent.example/agent.json

这个文档可以包含代理的名称、图标、公钥位置、OAuth 回调地址和支持的认证方法。

收到这个 client_id 后，酒店可以获取该地址的元数据，并据此找到公钥。个人代理用自己的私钥对其认证信息进行签名。酒店验证签名后，即可确认请求方持有与该客户端身份关联的私钥。

整个过程不需要事先交换密码。如果企业支持 CIMD 的动态客户端发现，就可以跳过传统 OAuth 逐一注册客户端的步骤。当然，企业仍然可以保留白名单或要求预注册来决定哪些代理可以连接。

这种方式与 ANP 使用的 W3C did:wba 方法非常相似：两者都通过 Web + HTTPS 分发公钥，然后用签名验证身份。区别在于 CIMD 使用 URL 作为标识符，而 ANP 使用 W3C 定义的 DID 作为标识符。

以上就是 PAP 的身份设计。那么 PAP 如何进行身份验证？

它使用了这套技术组合：OAuth 2.0 + CIMD + JWT + DPoP。

OAuth 2.0 是使用 Google 账号登录背后的协议，我们都在日常使用。CIMD 前面已介绍。JWT 是一种标准数据格式，用于承载身份、权限等声明（claims）。

我想重点谈谈 DPoP（Demonstrating Proof of Possession，持有证明），这是一项相当有趣的技术。

一个典型的令牌一旦泄露，就可能被攻击者利用。

DPoP 的核心思路是：即使黑客窃取了代理的令牌，没有代理的私钥，他们也无法直接使用该令牌访问企业的 API。

DPoP 将一对公私钥绑定到令牌上（不同于 CIMD 的密钥对，且动态更新）。当出示令牌时，客户端还必须证明它持有该令牌对应的私钥。

因此，仅仅泄露令牌本身不会造成直接的安全问题。

PAP 身份的其他特性

PAP 使用 HTTPS URL 作为个人代理的客户端标识符。同时，它为每个用户在每家企业生成一个独立的假名 ID，使企业无法通过用户标识符直接关联用户在不同企业间的行为。这两个 ID 各有用途。

PAP 身份与 ANP 代理身份的对比

PAP 和 MCP 都使用 CIMD 进行代理身份验证，解决了客户端连接服务时需预注册账户的问题。

将 CIMD 与 ANP 使用的 W3C did:wba 相比较，两者在底层技术上是相似的。它们都基于通过 Web + HTTPS 分发公钥，这在安全性、可扩展性和灵活性方面目前是最好的选择。

区别在于：

• CIMD 与 OAuth 更为契合，是 OAuth 生态的一部分，因此业界接受度更高。W3C DID 是一个相对新的生态。

• DID 的优势在于提供了一个统一的主体身份模型，可用于个人代理、企业代理等各类服务主体，并通过统一的认证协议实现跨平台互操作。

• 相比之下，PAP 目前主要规范了个人代理与企业之间的交互，尚未定义任意两个个人代理之间的对等认证和通信。

• 这是身份模型上的差异：DID 是统一模型，企业和个人都是 DID，每个 DID 都可以互操作；而在 PAP 的模型中，个人和企业是不同的角色。

PAP 的代理授权方案

以上内容涵盖了 PAP 如何解决代理认证。但酒店知道来访者是 Meta 的 Muse，并不意味着 Muse 有权查看我的订单，更不用说直接为我预订酒店了。

这引出了 PAP 设计中另一个非常重要的部分：代理授权。

PAP 没有重新发明授权协议。它基于 OAuth 2.0 构建，并将用户授权融入个人代理与企业交互的整个业务流程中。我认为有三个独特的设计要点。

第一，授权与代理身份分离，支持按需授权。

Muse 可以在未登录的情况下先查询酒店的公开信息。当它需要访问我的会员信息或创建订单时，它引导我到酒店自己的页面进行登录和授权，这样我从不需要将用户名密码交给 Muse。

PAP 定义了两种默认权限类型：poppy:read 和 poppy:write，企业可以定义更细粒度的权限。Muse 可以先获得读取权限，在需要修改订单时再请求额外的授权。用户也可以撤销授权。

第二，跨渠道的统一会话和权限管理。

这是 PAP 授权设计中相当独特的地方。

Muse 可能先通过 API 查询订单，然后通过 MCP 调用酒店的工具，接着与客服代理对话，最后通过网页完成预订。

PAP 将这些交互绑定到同一个业务会话中，并保持跨渠道的权限控制一致。

例如，如果我只允许 Muse 查看订单，那么即使它切换到与酒店的客服代理交互，也无法绕过权限限制来修改订单。

在安全性方面，PAP 还使用 DPoP 机制将访问令牌绑定到个人代理持有的私钥上，降低了令牌被盗的风险。不过并非所有渠道都使用 DPoP。例如 MCP 使用的是限制到目标资源的 Bearer Token。

第三，授权访问账户不等于授权执行具体操作。

这是另一个值得注意的设计。

即使我授予了 Muse 修改订单的权限，也不意味着它可以不经确认直接预订 560 美元的酒店。

PAP 提供了一个可选的 Operations 扩展，为每个具体的企业操作创建唯一 ID，记录操作的条款和版本，并管理确认和执行状态，避免重复下单等问题。

不过，目前 Operations 中的确认声明主要由个人代理提供，因此仅凭该声明，企业无法独立证明用户确实同意了。

总之，PAP 将 OAuth 授权、跨渠道权限控制和具体企业操作的确认整合在一起，使个人代理能够在用户授权和企业认可的规则下完成任务。

与 MCP 主要解决访问工具和资源的授权不同，PAP 将授权管理扩展到了个人代理与企业交互的整个业务流程。

OAuth 在授权方面相当完善且应用广泛。MCP 的授权也建立在 OAuth 之上。ANP 已有草案将 OAuth 与 DID 融合来实现代理授权方案，ANP 还使用 VC（Verifiable Credentials，可验证凭证）来表达代理属性。

PAP 的代理发现方案

PAP 使用了一种类似网站发现的机制。企业只需在其自有域名下的标准地址 /.well-known/poppy.json 发布一份服务描述文件，告诉个人代理它提供哪些服务、支持哪些 API 和 MCP 接口、其业务代理的通信地址以及登录和授权方式。

个人代理一旦找到企业的网站，就可以自动读取这个文件，发现并调用企业提供的服务。PAP 解决的是已知企业的服务发现，没有定义在全网范围内搜索代理的机制，但搜索引擎未来可以索引这些标准文件，使个人代理更容易在互联网上发现企业服务。

代理发现目前是业界共识最广泛的方式。ANP、A2A、PAP 以及许多其他协议基本都采用域名 + well-known 的方式，未来搜索引擎将可以非常方便地搜索代理信息。

PAP 的交互机制

PAP 没有设计全新的代理交互协议。它尽可能复用现有的技术标准。它支持四种交互方式：OpenAPI、MCP、网页操作，以及个人代理与企业代理的直接对话。企业可以选择支持其中哪些方式，个人代理则根据企业发布的服务描述选择合适的接口。

第一是通过 API 和 MCP 调用企业服务。例如，Muse 可以直接调用酒店的 API 查询房间价格，或通过 MCP 调用预订工具。这比在浏览器中模拟点击更高效。对于尚未开放此类接口的服务，PAP 仍然允许个人代理通过浏览器操作网站，并将网页操作绑定到同一个业务会话。

第二是直接…