Poppy – Sierra 联合 Meta 等推出的开放协议草案

1. Poppy是什么

Poppy（Personal Agent Protocol）是由 Sierra 联合 Meta 及多家企业共同推出的开放协议草案，旨在解决个人 AI Agent 访问企业服务时的身份识别与授权问题。该协议通过标准化的发现机制、分级权限控制和基于 OAuth 的授权流程，在"Agent 冒充用户"与"企业全面封禁代理"两个极端之间建立了中间方案。目前已有 Stripe、Shopify、Walmart、Visa、OpenAI 等 35 余家企业参与共建。

技术定位与领域： 属于 AI Agent 基础设施层的身份与授权协议，位于 OAuth 2.0、JWT、DPoP、OpenAPI、MCP 等既有标准之上，专门解决个人 AI Agent 代表用户与企业服务交互时的可信身份声明、最小权限授予和跨渠道会话复用问题。该协议填补了当前 AI Agent 生态中"企业无法识别代理身份"与"用户不愿交出密码"之间的空白地带。

研发背景： 由 Sierra 与 Meta 联合发起，并汇聚 Stripe、Shopify、Walmart、Visa、OpenAI 等 35 余家企业的行业共识。其研发动机源于 AI Agent 大规模落地时面临的现实困境——企业无法判断访问者是真实用户还是代理程序，用户也不愿将账户凭证交给第三方代理。该协议试图通过行业协作建立统一规范，而非由单一厂商主导封闭标准。

核心价值： 解决了三个关键问题：其一，企业可明确识别访问者的 Agent 身份，知晓"谁在替谁办事、能做什么"；其二，用户无需交出密码，仅授予最小化、可撤销的权限令牌；其三，一次登录即可跨网站、API 与企业自有 Agent 复用会话，避免重复授权。该协议以 Apache 2.0 许可开源，企业可用现有 OAuth 基础设施快速接入。

技术特点： 构建于成熟标准之上而非另起炉灶，通过 /.well-known/poppy.json 发现文件实现标准化的 Agent 接入声明，权限分五档可调，支持 direct、device、mediated 三种登录模式，所有操作全程可审计、可撤销，并支持行业自定义扩展。

2. 主要功能

• 标准发现机制： 企业通过在网站根目录发布 /.well-known/poppy.json 文件，声明 Agent 接入方式、登录入口和可用能力。该机制借鉴了 RFC 8615 的 Well-Known URI 规范，使 Agent 无需事先了解企业系统架构即可自动发现接入路径，降低了集成门槛。

• 分级授权体系： 权限从完全禁止到完全接管共分五级，由企业决定开放档位、用户决定授权范围。这一设计打破了传统"全有或全无"的授权模式，例如银行场景中用户可仅授予 poppy:read 权限让 Agent 查询余额，而转账等写操作需单独授予 poppy:write，实现了细粒度的权限管控。

• OAuth 安全登录： 用户在企业的官方页面亲自完成登录，代理仅获得用户批准的最小范围会话令牌。协议基于 RFC 8414 OAuth 2.0 授权服务器元数据规范，支持 direct（直接重定向）、device（设备码）、mediated（代理中介）三种登录模式，兼顾 Web、移动端和纯 API 场景。

• 单会话跨渠道复用： 同一个令牌可在企业网站、API 和企业自有代理之间复用，交互过程连续不中断。这一特性避免了用户在不同渠道重复授权的繁琐流程，同时通过 DPoP（Demonstrating Proof of Possession）绑定令牌与客户端密钥，降低令牌被盗用风险。

• 多通道执行能力： 支持 Agent 直接操作网页、调用 OpenAPI/MCP 接口，或与企业自建的 AI Agent 协作完成任务。协议将发现、身份、API、对话定义为四大构建块，行业可在此基础上扩展支付、推送通知、交互组件等能力，具备良好的可扩展性。

• 全程可审计可撤销： 企业能看到 Agent 的完整操作路径，用户可随时在账户设置中查看已连接代理并一键断开。所有请求均绑定已验证的 client_id、用户 ID 和 scope，形成完整的操作审计链路，满足企业合规与安全要求。

• 基于现有标准构建： 协议构建于 OAuth 2.0、JWT、DPoP、OpenAPI、MCP 之上，企业现有授权服务器基本可直接改造接入，无需从零搭建。协议遵循"控件而非策略"原则，只提供选项而非强制规则，企业可自主决定匿名/登录要求、放行哪些代理、开放哪些渠道。

• 隐私保护设计： 用户登录前企业只能看到一个不含个人信息的稳定 ID，同一用户在不同企业的 ID 互不相同。这一设计使企业可识别回头客但无法跨站追踪用户，在提供个性化服务的同时保护用户隐私。

3. 如何使用

Poppy 协议涉及三类参与方，各自的使用方式不同：

1. 终端用户侧： 用户无需安装任何额外组件，直接向 AI Agent 下达任务。当任务需要访问企业账户时，用户被引导至企业官方页面亲自完成登录，勾选批准 Agent 的权限范围后即可继续。用户可随时在账户设置中查看已连接的代理并一键断开授权，整个流程对用户透明且可控。

2. 个人代理开发者侧： 开发者需先在客户端发布元数据文档（包含 client_id、公钥、回调地址）作为 Agent 的身份凭证。随后读取企业的 poppy.json 发现文件，了解其登录方式和可用接口。发起会话时，开发者需向企业 token 端点发送签名断言及 DPoP 证明，启动匿名会话获得 Session Token。当需要访问受保护资源时，按企业支持的方式发起 direct、device 或 mediated 三种登录之一，用户批准后获得长期 Account Token 并加密保存。此后可使用 Session Token 调用企业 API（携带 DPoP）、浏览网页（浏览器断言换 Cookie）或与企业自有代理对话，并处理 429 限流、幂等重试、sign_in_required 等错误场景。

3. 企业接入侧： 企业需在 /.well-known/poppy.json 发布发现文件，声明登录方式、权限范围和提供的接口；按 RFC 8414 配置 OAuth 服务器并声明 poppy_domains；对每个请求校验代理签名、DPoP 证明和 scope 权限。企业还需在网页、API、企业代理和人工客服所有渠道执行同一套权限检查，并提供合规的授权页面（展示代理身份和权限说明）和账户设置中的断开入口。

关键配置说明： 企业接入时需注意 poppy_domains 声明必须与 OAuth 服务器配置一致，确保授权服务器元数据可被 Agent 正确发现。权限档位的设定需结合业务风险评估，建议从只读权限起步逐步开放写操作。代理开发者需确保 client_id 与公钥的对应关系稳定，避免会话续期时出现身份校验失败。

注意事项： 协议目前仍为草案阶段，部分细节可能随版本演进调整。企业接入时应关注协议更新动态，建议在非生产环境先行验证；代理开发者需处理 sign_in_required 等错误状态，在令牌过期时引导用户重新授权而非静默重试。

4. 优缺点分析

5. 同类工具对比

选型建议： 若企业需要解决"AI Agent 代表用户访问企业服务"的身份与授权问题，且已有 OAuth 基础设施，Poppy 是当前最贴合需求的方案——它在现有标准之上补充了 Agent 身份识别和分级授权能力，且已有头部企业背书。若企业主要关注"如何让 LLM 调用外部工具"，不涉及用户身份代理场景，MCP 是更轻量的选择。

对于依赖 ChatGPT 生态的开发者，ChatGPT Actions 提供了最低的接入门槛，但受平台约束较强，无法面向企业自有 Agent 开放。综合来看，Poppy 与 MCP 并非互斥关系，二者可在同一系统中协同工作——Poppy 负责身份与授权，MCP 负责工具调用，共同构成完整的 Agent 企业服务接入方案。

6. 编辑总结

Poppy 的出现回应了 AI Agent 规模化落地过程中一个被长期忽视的关键问题：当代理代表用户与企业服务交互时，如何建立可信的身份声明与授权机制。从技术创新性来看，该协议的价值不在于发明了全新的技术范式，而在于将 OAuth 2.0、JWT、DPoP、OpenAPI、MCP 等成熟标准有机整合，并补充了 Agent 身份识别和分级授权这两个关键缺失环节。这种"基于现有标准做增量设计"的思路，既降低了企业的采用门槛，也避免了重复造轮子的资源浪费。

从实用价值角度，Poppy 的"控件而非策略"原则体现了务实的工程哲学——协议只提供选项，企业决定开放档位，用户决定授权范围，这种灵活性使其能够适配电商、金融、航空等不同行业的差异化需求。单会话跨渠道复用和全程可审计可撤销的设计，则在用户体验与企业合规之间找到了平衡点。

该协议最适合三类人群：一是正在构建个人 AI Agent 产品的开发者，Poppy 提供了标准化的企业服务接入路径；二是希望向 Agent 开放服务但又担忧安全风险的企业技术决策者，分级授权与审计机制提供了可控的开放方案；三是关注 AI Agent 基础设施演进的行业观察者，Poppy 有望成为 Agent 与企业服务交互的事实标准之一。

需要指出的是，协议目前仍处于草案阶段，其最终形态取决于参与企业的实际部署反馈和社区贡献。Poppy 能否真正成为行业标准，关键看两点：一是更多企业是否愿意在真实业务场景中部署验证，二是协议治理机制能否保持开放中立、避免单一大厂主导。从当前 35 余家企业的参与阵容来看，Poppy 已具备良好的起步基础，其发展轨迹值得持续关注。

7. 应用场景

• 电商退换货： 用户对 Agent 说"退掉夹克"，Agent 以访客身份查询退货政策，经用户登录授权后自动完成退货或换货流程。该场景充分利用了 Poppy 的分级授权和单会话复用特性，用户无需反复登录即可完成从查询到执行的全流程操作。

• 航班改签： 航班取消后，Agent 通过航空公司的 MCP 接口查询备选航班，在用户批准后自动完成改签。此场景体现了 Poppy 多通道执行能力——Agent 既可调用 API 查询航班信息，也可在用户授权后执行改签写操作，全程可审计可撤销。

• 房贷预审批： 用户授权后，Meta 的 Muse Agent 与 Rocket 的 Agent 协作完成价格、首付、利率确认，几分钟内出具预批信。该场景展示了 Poppy 的 mediated 登录模式和企业间 Agent 协作能力，用户只需一次授权即可让多个 Agent 协同完成复杂金融流程。

• 银行账务服务： 用户只授予 poppy:read 权限时 Agent 可查余额账单，转账等写操作需单独授予 poppy:write。此场景体现了 Poppy 细粒度权限控制的价值，用户可根据任务需求灵活调整授权范围，兼顾便利与安全。

• 保修与客服升级： Agent 与企业客服 Agent 对话处理保修，复杂情况自动转人工或开启用户与企业专员的直接对话。该场景充分利用了 Poppy 的企业自有 Agent 协作能力，实现智能客服与人工客服的无缝衔接，提升售后服务效率。

8. 常见问题FAQ

Q：Poppy 与现有 OAuth 2.0 授权机制有何区别？
A：OAuth 2.0 识别的是应用程序而非 Agent，且通常采用"全有或全无"的授权模式。Poppy 在 OAuth 之上增加了 Agent 身份识别层，通过 client_id、用户 ID 和 scope 的绑定，让企业明确知道"谁在替谁办事、能做什么"。同时引入五档分级权限和单会话跨渠道复用机制，弥补了 OAuth 在 AI Agent 场景下的不足。

Q：使用 Poppy 协议，用户需要交出密码或 API 密钥吗？
A：不需要。用户始终在企业官方页面亲自完成登录，代理仅获得用户批准的最小范围令牌。令牌通过 DPoP 绑定客户端密钥，且用户可随时在账户设置中一键断开授权。整个过程中用户的密码和长期凭证不会暴露给代理。

Q：Poppy 与 MCP 是什么关系，会互相替代吗？
A：二者解决的是不同层面的问题。Poppy 负责身份识别与授权，MCP 负责标准化 LLM 与外部工具的连接方式。二者可以协同工作——Poppy 确认"谁有权限做什么"，MCP 解决"如何调用工具"。在实际部署中，企业可同时采用两种协议构建完整的 Agent 服务接入方案。

Q：企业接入 Poppy 需要重构现有系统吗？
A：不需要。Poppy 构建于 OAuth 2.0、JWT、DPoP、OpenAPI、MCP 等现有标准之上，企业现有授权服务器基本可直接改造接入。协议遵循"渐进式采用"原则，企业可只从网页、API 或自建代理之一开始，逐步扩展，无需一次性重构全部系统。

Q：Poppy 如何处理跨站追踪和用户隐私问题？
A：协议设计上明确禁止跨站追踪。用户登录前企业只能看到一个不含个人信息的稳定 ID，且同一用户在不同企业的 ID 互不相同——企业可识别回头客，但无法将同一用户在不同平台的行为关联起来。所有授权操作均可审计、可撤销。

Q：Poppy 目前是正式标准吗，可以用于生产环境吗？
A：Poppy 目前是开放协议草案，尚未成为正式标准。尽管已有 35 余家企业参与共建，但协议细节可能随版本迭代调整。建议企业在非生产环境先行验证，并关注协议更新动态，待稳定版本发布后再大规模部署。

9. 项目地址

• 项目官网： https://personalagentprotocol.org/