Poppy协议解读：API该何时支持客户Agent？

个人Agent正在以人类的身份访问企业网站——登录、点击、填表，企业既无法分辨它是人还是机器，也无法为其提供更优路径。Sierra与Meta联合推出的Personal Agent Protocol（简称Poppy）试图填补这一空白。但截至draft 0.1阶段，大多数API平台的最佳策略是一个可丢弃的小型实验，而非生产部署。

Poppy解决什么问题

据Sierra的描述，大多数个人Agent目前使用企业网站和应用的方式与人无异：加载页面、点击表单。当这种方式无法完成任务时，它们可能拨打客服电话或打开网页聊天。Poppy的概览文档将这种状态称为"全有或全无"——Agent要么"以用户身份通过验证，用密码登录并点击为人设计的页面"，要么被企业屏蔽，而"企业无法区分Agent与人，也无法为其提供更好的通道"。

两个来源都未发布量化数据。在流量匹配的情况下，你无法分辨Agent与客户，客户也无法限制Agent进入后的行为。在涉及资金流转、健康记录或预订变更的平台上，这不仅是API团队的问题，更是欺诈与隐私负责人的问题。

Poppy的核心机制

Poppy draft 0.1定义了一套完整的会话生命周期，从发现到登出共六个环节：

发现（Discover）：企业必须在https://{domain}/.well-known/poppy.json发布其poppy.json文档，列出登录选项和通道。

Agent身份识别：Agent的client_id必须是一个返回元数据文档的HTTPS URL，企业可维护允许/阻止列表。

登出状态启动：Agent向企业的token_endpoint发送签名断言，命名自身（iss）和用户（sub）。会话以登出状态开始——企业可以随时间识别同一用户，但不知道用户是谁。User ID"不得包含或衍生自个人信息，如电子邮件地址、电话号码或姓名，即使使用密钥哈希也不行"。

登录与授权范围：登录方式包括Direct（OAuth 2.0授权码流+PKCE）、Device（设备授权授予）或Mediated（非OAuth流程）。基础范围为poppy:read和poppy:write。

密钥绑定会话令牌：账户令牌生成绑定到Agent持有密钥的会话令牌，"复制的令牌离开密钥后无效"，且"应持续数小时而非数天"。

行动、移交与撤销：Agent可通过API、MCP服务器、网站或企业Agent执行操作；可向人工移交；账户令牌撤销后，所有相关会话退回登出状态，购物车或未完成对话得以保留。

DPoP（Demonstrating Proof-of-Possession）：文中提到会话令牌「复制的令牌离开密钥后无效」，这正是密钥绑定令牌要解决的问题。DPoP 是 IETF OAuth 工作组定义的机制，客户端生成一对非对称密钥，用其私钥对每个 HTTP 请求签名，并在 Authorization 头中附带公钥的 JWK 和签名。资源服务器验证签名后，即使令牌被窃取，攻击者没有私钥也无法使用。这与传统的 Bearer 令牌形成鲜明对比——后者一旦泄露即可被任意重放。Poppy 的「密钥绑定会话令牌」若采用 DPoP，意味着即使企业侧的令牌存储被攻破，攻击者也无法冒充 Agent 行动。对 API 团队而言，落地 DPoP 需要资源服务器具备 JWK 解析和签名验证能力，且需处理时钟偏移与重放窗口，这与现有的 Bearer 令牌验证链路是两套不同的工程投入。

Poppy vs MCP vs A2A：层次关系

三者并非替代关系，而是不同层次的协议。

据MCP规范（2026-07-28）和A2A 1.0.0，Poppy负责决定"哪个Agent在请求、客户允许了什么"；MCP服务器是Poppy可路由Agent的通道之一；A2A则处理独立Agent系统间的通信。

据MCP授权规范，它确实提供了工具的范围化OAuth授权——受保护服务器"作为OAuth 2.1资源服务器"，发布RFC 9728元数据。MCP客户端和授权服务器"应支持OAuth客户端ID元数据文档"，即用HTTPS URL作为client_id。这些与Poppy的Agent身份机制重叠。

但MCP授权规范不定义登出会话、不含个人数据的每企业User ID、人工移交或跨通道共享会话。Poppy将六项需求统一在一个文档化接口之后。

A2A与Poppy的关系尚无定论。Poppy规范与Sierra的文章均未提及A2A。独立追踪器poppy.md称两者"大体互补，但有一个重叠值得关注：'企业Agent'路径"。

OAuth 授权码流 + PKCE 与设备授权授予：文中将 Direct 登录定义为「OAuth 2.0 授权码流 + PKCE」，设备流则对应 RFC 8628。PKCE（Proof Key for Code Exchange，RFC 7636）解决的是公共客户端的授权码拦截问题：客户端在授权请求时发送 code_challenge（原像的哈希），换令牌时提交 code_verifier，授权服务器校验两者匹配后才发放令牌。对无稳定重定向 URI 的原生应用和 Agent 而言，这是必需的防护。设备授权授予则面向浏览器能力受限的输入场景，客户端先取得 device_code 和 user_code，引导用户在另一设备上完成授权，再轮询令牌端点。Poppy 同时列出两者，说明其目标 Agent 既包括有浏览器的富客户端，也包括无头或嵌入式环境。企业侧要实现这两条流，需要在授权服务器中增加 PKCE 校验和设备流的轮询语义，不能仅靠现有授权码流直接复用。

成熟度与采用现状

规范状态：据Poppy规范页面，状态为Draft 0.1，更新于2026年10月9日，采用Apache License 2.0。警告称"任何部分在稳定版本前都可能变更，包括不向后兼容的变更"。规范、概览和主页均未出现编辑者、治理机构或标准组织。

实现情况：2026年10月9日，Sierra写道"在未来一个月内，我们将举办设计工作坊并发布参考实现"。截至10月12日，独立追踪器poppy.md表示官方参考实现"尚未公开"。仅列出社区和合作伙伴演示，如Cloudflare Workers演示、仅在X视频中展示的Meta Muse演示，以及独立Datalayer SDK。

生产采用：未发现公开证据。2026年10月9日，orka项目在检查约40个网站后报告"没有任何公司发布PAP文件"。Sierra的10月9日文章列出了35个设计合作伙伴，包括OpenAI、Visa、Mastercard、PayPal、Okta和Bank of America。但设计合作伙伴身份不等于实现。fillthemat项目的go/no-go审查指出，OpenAI被列为设计合作伙伴"并不确立ChatGPT支持或商户流量"。

设计合作伙伴（Design Partner）的真实含义：文中反复出现的 35 个「设计合作伙伴」容易被误读为采用信号。在标准与产品早期阶段，设计合作伙伴通常仅表示某组织参与了需求评审、工作坊或提供了反馈意见，既不承诺实现，也不代表其产品会发送或接收该协议的流量。这与「实现者」「部署方」是三个不同层级的角色。判断一个协议是否真正被采用，可靠信号是：公开的参考实现、其他组织发布的独立实现、生产流量中的协议指纹、以及第三方兼容性测试。就 Poppy 而言，这三类信号在 draft 0.1 阶段均缺失，因此设计合作伙伴名单不能作为立项依据。API 团队在评估时应把该名单视为「有人在关注」，而非「有人在用」。

反对现在加入的理由

最强烈的反对意见是：OAuth API加MCP服务器已经足够，新草案协议为时过早。证据支持这一观点的大部分。

据fillthemat项目发现，Datalayer在10月10-11日发布了11个非stage的npm版本，包括破坏性变更。没有采用量可服务，PACT是并行设计。在2026年10月9日至12日发现的四个公开GitHub issue中，三个未进入生产：orka写道"我们不应该构建任何东西"，OpenAgents将其issue关闭为"不在V1发布路径上"，fillthemat的审查称"暂不进行生产部署或重大投资"。

在Hacker News一个只有两条评论的帖子中，一位评论者问道："作为指挥个人Agent的人类，为什么它需要一个协议？"

在范围化授权方面，反对意见是正确的。但在其他方面则不够充分——MCP授权规范不定义登出会话、每公司User ID、人工移交或跨通道共享会话，无论客户的Agent使用什么协议，这些空白都存在。

决策框架：采用、实验还是等待

立即采用（需同时满足）：规范稳定；官方参考实现公开；客户使用的个人Agent向类似你的服务发送Poppy流量；审计记录、欺诈审查和人工队列已为poppy:write操作和移交做好准备。

有限实验（满足以下条件）：已运行PKCE或设备流OAuth、MCP服务器或公开OpenAPI；在网站或支持流量中看到客户Agent；能将工作限制在可丢弃范围内；范围保持在poppy.json、登出读取访问、不新增写入路径。

等待（出现任一情况）：尚无OAuth范围化公开API；客户Agent未出现在流量中；写入操作涉及资金或变更账户且无Agent操作审计轨迹。

等待期间仍可进行协议中立的工作：每Agent归因、短令牌生命周期、撤销和人工升级路径。

风险与开放问题

协议变动：draft 0.1允许破坏性变更，记录你实现的protocol_version并为返工做预算。

身份与授权：Mediated登录使用"用户为此企业提供的凭据"，Agent仍持有客户凭据。决定是否提供此选项。

同意：poppy:write涵盖"进行更改，如换货或更新预订"，自定义范围承载同意设计。

隐私：确保分析和欺诈工具不会在登录前将登出User ID与身份关联。

可审计性：规范未定义审计日志，需自行记录Agent、User、范围、会话和操作。

滥用与欺诈：注册、允许/阻止列表、client_id撤销和每client_id速率限制是可选控制，需决定欺诈审查适用于Agent写入的范围。

评估清单

对你的API逐项标记是/否：

1. OAuth服务器支持授权码流+PKCE和设备授权授予
2. MCP服务器（如有）作为OAuth 2.1资源服务器运行并带RFC 9728元数据
3. API可验证DPoP绑定令牌，或已评估工作量
4. 令牌端点可为Agent签发登出会话，User ID不含个人数据
5. 可通过HTTPS client_id识别Agent并维护允许/阻止列表
6. 一次撤销可登出所有相关会话，同时购物车和对话继续
7. 任何Agent移交后都有配员的人工队列
8. 日志记录每个请求的Agent、User、范围和操作
9. 当前流量中可见客户Agent
10. 有具名人员负责实验并跟踪规范

第1或2项为是，加上第9和10项，指向实验。第1和2项均为否，指向等待。全部为是，加上稳定规范和Agent交易对手，指向采用。