本文要点
- 协议从10月6日介绍文章推进到10月9日Draft 0.1草案。
- 设计伙伴新增35家，场景扩展到支付、航空、零售、保险和SaaS。
- 个人Agent入口从网页模拟转向企业可识别、可授权的会话机制。
阅读辅助
先看数字、证据和来源，再读正文。
10月9日新增事实是Poppy草案发布和35家设计伙伴。
2026-10-06 · Sierra发布Introducing Personal Agent Protocol，提出0.1版规格和参考实现计划。
Sierra 10月9日把Personal Agent Protocol的草案公开为Poppy，并把个人Agent进入企业系统时最麻烦的几件事拆成协议问题：企业如何发现Agent，用户如何授权，Agent如何在网页、API和企业自有Agent之间保持同一次会话。
已核实的当天事实包括三项。Sierra博客页面标注发布时间为2026-10-09T19:56:06Z，正文称正在发布Poppy草案，并宣布新增35家设计伙伴。Personal Agent Protocol规格页同时显示Draft 0.1和Updated Oct 9, 2026。Sierra还写明，未来一个月会举办设计工作坊，并发布reference implementation帮助开发者上手。
需要保留的边界也很重要。10月6日的《Introducing Personal Agent Protocol》是背景，不是本期当天新增；它用于说明Sierra为什么要做PAP，以及早期计划如何演进到10月9日草案。35家设计伙伴来自Sierra官方自述，本文不把它扩写成35家已经生产接入。参考实现仍是计划项，不应写成已经发布。
对开发者和企业团队来说，Poppy真正触及的是Agent接入方式。过去个人Agent要帮用户退货、改签、查账单或申请贷款，往往只能模拟浏览器、复用用户凭据，或者等待每家公司定制一个接口。Poppy试图给双方一个更明确的握手过程：Agent代表谁，能看到什么，能改什么，企业如何记录这次访问，用户如何撤销授权。
草案具体新增了什么
Sierra在10月9日的博客里把Poppy拆成五个基础块。第一是Discovery，企业在自己网站的标准地址发布/.well-known/poppy.json，告诉个人Agent如何交互、如何登录、能做什么。第二是Sessions，个人Agent可以先以访客身份代表用户开启会话，用来检查库存、查询退货政策等不需要账号的任务，同时向企业表明自己是Agent。
第三是Sign-in。任务需要访问用户账号时，用户在企业页面通过OAuth登录；如果企业允许，Agent可以拿到只覆盖用户授权范围的session token。第四是one session across every channel，同一个token可用于企业API、网站和企业自有Agent，避免用户在提问、登录、改订单之间被切成多个孤立流程。第五是Getting the job done，企业可以选择让Agent走网页、OpenAPI或MCP接口，也可以让Agent和企业自己的对话式Agent协作。
这五块共同回答一个企业最关心的问题：怎样让Agent可识别、可限权、可审计，而不是把它当成一个伪装成人类的浏览器会话。博客举的例子也围绕真实商业流程：退夹克、查航班、处理保修、申请按揭预批。它们都不是单轮问答，而是需要身份、上下文、权限和状态持续性的多步任务。
| 构件 | Sierra原文含义 | 对企业系统的要求 | 仍未确认 |
|---|---|---|---|
| Discovery | 在标准地址发布poppy.json | 公开Agent可用入口、登录方式和能力边界 | 字段会否在0.1后调整 |
| Sessions | Agent代表用户开启会话 | 区分访客任务和登录后任务 | 会话风控和限流口径 |
| Sign-in | 用户通过OAuth授权 | 只发放用户批准范围内的token | 不同企业的授权体验 |
| 跨渠道会话 | 同一token覆盖网页、API和企业Agent | 把一次旅程串成连续记录 | 多渠道状态冲突处理 |
| 完成任务 | 网页、OpenAPI、MCP或自有Agent任选 | 复用既有渠道并逐步扩展 | 参考实现覆盖哪些路径 |
标准栈不是装饰
Poppy最重要的写法，是尽量不发明一整套新身份系统。Sierra博客和协议概览都写明，它建立在OAuth、JSON Web Tokens、安全传输、OpenAPI和MCP之上。规格页进一步把这些标准落到具体机制：企业必须通过加密网页地址发布poppy.json；个人Agent的client_id必须是可访问的网址，企业可取回Agent元数据、签名密钥和回调地址；Session Token和Account Token沿用OAuth语义，并通过JWT bearer grant、DPoP等机制限制使用边界。
API部分也没有把所有工具协议混成一个抽象口号。规格页写明，企业可以在poppy.json里列出API，类型包括OpenAPI 3.0或3.1描述，以及使用Streamable HTTP transport、MCP 2025-06-18或更新版本的远程MCP server。个人Agent应跳过自己不认识的API类型，以便后续版本增加类型；列出的MCP server必须接受Session Token作为access token，并执行scope限制。
这说明Poppy的位置更像一个会话和授权协议，而不是替代OpenAPI、MCP或企业Agent框架。OpenAPI说明“接口长什么样”，MCP说明“工具和上下文怎样暴露给模型”，OAuth说明“用户怎样授权”。Poppy试图把这些标准串到同一次企业访问里，让个人Agent不必为每家公司猜入口、猜权限、猜任务是否还在同一上下文。
与10月6日背景的关系
10月6日文章已经提出Personal Agent Protocol的基本愿景：个人Agent先在网站发现企业能力，然后代表用户开始会话；任务需要账号时，用户通过公司页面登录，或者使用已经授予个人Agent的凭据；用户决定Agent是只读还是可写。那篇文章还提到，公司可以让Agent访问网站、API或企业自己的Agent，并计划发布0.1版规格、设计工作坊和参考实现。
10月9日的增量是把这个愿景推进到公开草案和伙伴协作。博客标题是“Sharing a draft of Personal Agent Protocol”，页面元数据也写明“Today we’re publishing a draft of Personal Agent Protocol, known as Poppy, and announcing additional design partners.” 因此，本期不把10月6日当作当天新闻主体，而是把它视为Poppy草案的前置说明。
这种日期区分很关键。如果只看概念，Poppy像是又一个Agent基础设施倡议；如果看10月9日新增事实，它的新闻点在于Sierra已经把0.1草案放到协议站，并用35家设计伙伴把讨论对象从单家公司扩展到多行业企业。对于协议类项目，伙伴是否参与设计往往比单篇宣言更能说明方向，因为真正难的是企业是否愿意为Agent开放受限入口。
对企业和Agent厂商的影响
企业侧最直接的变化，是从“识别并阻挡自动化访问”转向“识别并管理授权Agent访问”。Poppy概览页写到，随着Agent承担更多在线任务，all or nothing的成本会上升：公司花更多精力检测Agent，Agent花更多精力规避检测。协议的目标，是让双方以更多选择和控制一起工作。
这对风控团队提出了更细的要求。企业不能只看请求是不是来自浏览器，也不能简单把所有Agent访问都封掉。它需要知道Agent是谁、代表哪个用户、当前token有什么scope、能否读写账号信息、是否需要把请求转给真人或企业自有Agent。尤其在支付、航空、保险和贷款这类场景里，身份和授权边界比模型回答本身更重要。
Agent厂商也会受到约束。Poppy如果被采用，个人Agent不再只是“帮用户打开网页并点击按钮”的自动化脚本，而要成为能公开身份、管理用户授权、处理session token、遵守企业scope和撤销机制的客户端。对做消费Agent的团队来说，这会增加工程成本；但换来的收益是更稳定的企业入口，以及更少与反爬和登录风控对抗的灰色空间。
更宽的竞争含义在于，Agent入口正在从模型厂商的产品体验扩展到企业协议层。浏览器控制、RPA和网页代理解决的是“怎么操作现有界面”；Poppy讨论的是“企业怎样给Agent一个被承认的入口”。如果后者跑通，Agent产品之间的竞争会部分转向谁能管理更多授权关系、接入更多企业能力、处理更复杂的跨渠道状态。
早报判断是，Poppy把Agent商业化最容易被低估的问题摆到了桌面：个人Agent如果要真正替用户办事，就不能长期依赖伪装成人的浏览器会话。企业需要知道对面是谁，用户需要知道授权给了谁，Agent厂商需要稳定入口，监管和审计也需要可追踪记录。
这件事对模型能力没有直接提升，却会影响Agent能进入哪些高价值流程。退货、改签、保险理赔、贷款预批、企业SaaS变更都不是靠一次聪明回答完成的任务。它们需要登录、权限、状态、回执、异常处理和责任归属。Poppy把这些问题包装成Discovery、Sessions、Sign-in和跨渠道会话，本质上是在给Agent时代补“企业访问控制层”。
限制同样明显。Poppy现在仍是Draft 0.1，参考实现还没发布，35家设计伙伴也不等于35家生产系统接入。协议能否成立，取决于企业是否认为开放受控入口比继续拦截自动化访问更划算，也取决于个人Agent厂商是否愿意承担OAuth、JWT、DPoP、scope和撤销机制带来的产品复杂度。
如果未来一个月的参考实现足够具体，Poppy会成为Agent基础设施里值得跟踪的协议样本。如果它只停留在愿景和伙伴名单，这条新闻的意义就会收窄为一次行业协作信号。当前最稳妥的读法是：Sierra把个人Agent与企业系统的矛盾从产品演示推进到了协议草案，但真正的采用率还要等代码、伙伴接口和开发者实现来证明。
还要等哪些证据
第一类证据是参考实现。Sierra博客使用的表述是“Over the next month we will host design workshops and publish a reference implementation”，这不是已经发布。后续需要看示例是否同时覆盖网站、OpenAPI、MCP和企业自有Agent，是否给出token刷新、撤销、scope、DPoP、错误处理和用户授权UI的完整路径。
第二类证据是伙伴开放范围。新增35家设计伙伴是当天最明确的数字，但企业参与设计和开放生产能力之间差距很大。真正要跟踪的是：支付伙伴是否允许个人Agent完成授权支付或只做查询，航空伙伴是否允许改签和退款，零售伙伴是否开放退货状态变更，SaaS伙伴是否允许Agent代表用户修改工作流。
第三类证据是与其他协议的边界。Sierra在10月9日博客里提到，Universal Commerce Protocol聚焦购物，包括找商品、结账和管理订单；Personal Agent Protocol则覆盖个人Agent如何识别自己、获取客户许可，并跨任务与公司协作。这个区分如果能保持清晰，Poppy可以作为身份和会话层，UCP等垂直协议处理具体行业动作。如果边界模糊，开发者会面对重复授权、重复发现和重复schema。
第四类证据是安全审计。Poppy概览页强调secure and private，说明个人Agent会始终标识自己，但用户登录前，公司只看到不含个人信息的ID；该ID在同一公司稳定，在不同公司不同。这个设计方向是合理的，但实际系统还要回答更细的问题：企业如何验证Agent元数据没有被替换，用户如何查看和撤销授权，MCP server如何强制scope，企业如何记录Agent与真人客服的交接。
接下来看什么
最短期的观察点是未来一个月的设计工作坊和参考实现。只要参考实现发布，就能判断Poppy是偏向网页会话、API授权，还是把MCP和企业Agent作为同等一等公民。其次看35家伙伴是否有任何一家公开开发者文档或沙盒接口。第三看个人Agent厂商是否把poppy.json发现、OAuth授权和MCP Session Token放进产品路线。
如果这些后续证据出现，Poppy会从“协议草案”变成Agent入口标准化的一次实测。若没有，它仍然是一个有价值的行业信号：Agent厂商和企业系统之间需要一种比浏览器模拟更可控的连接方式，而这条连接必须同时回答身份、权限、会话和责任边界。