Sierra Personal Agent Protocol 新增 35 家合作伙伴，但企业仍掌握控制权

Sierra 发布了 Personal Agent Protocol 草案，并新增 35 家设计合作伙伴，使 Poppy 从一项提议发展为一项严肃的标准化工作。Sierra Personal Agent Protocol 目前已获得 OpenAI、Bank of America、Mastercard、PayPal、Visa、Cloudflare 等大型公司的意见投入。

这一公告之所以重要，是因为个人代理通常通过为人类设计的界面进入企业系统。它们会浏览页面、填写表单，有时还会使用拥有广泛账户访问权限的凭据。Poppy 提出了一条折中路径：企业识别代理，用户批准权限，一次会话可跨越网站、API 和企业代理。

这条折中路径也带来了核心冲突。个人代理需要广泛且一致的访问权限才能发挥作用，而企业则希望控制身份、权限、渠道和客户关系。Sierra 招募了一个覆盖面异常广泛的群体来协商这条边界，但尚未证明这些公司会部署最终形成的协议。

Sierra Personal Agent Protocol 新增 35 家设计合作伙伴

Poppy 已从最初的公告迈向公开技术草案，但参与目前仍意味着提供设计意见，而非在生产环境中采用。

Sierra 于 2026 年 10 月 9 日发布了 Poppy 草案。该公司还公布了 35 家新增设计合作伙伴，覆盖金融、零售、旅游、保险、媒体、身份认证、通信和 AI 等领域。

新增成员包括 Adyen、Atomic、Bank of America、BBVA、Chime、Cigna、Cloudflare、Comcast、DIRECTV、ElevenLabs、FOX、Gap Inc.、GEICO 和 Hertz，也包括 Insurify、Klaviyo、Liberty Mutual、Mastercard、Nordstrom、Notion、Okta、OneSignal、OpenAI、PayPal、Plaid 和 SiriusXM。

Synchrony、Target、United Airlines、Venmo、Visa、Wells Fargo、Zapier、Zendesk 和 1Password 则完成了这一新增名单。这些组织加入了先前公告中已参与的公司，包括 Meta、Genesys、Instinct、NiCE、Rocket、Shopify、Stripe 和 Walmart。

原始参与群体与新增 35 家企业之间的区别很重要。Sierra 并未宣布共有 35 家参与者，而是在 10 月 6 日与 Meta 及多家企业技术合作伙伴介绍该项目后，又宣布新增 35 家公司。

据 Sierra 表示，新加入的公司将根据自身业务需求提供反馈。这份名单汇集了通常处于交易不同位置的组织。

银行和支付网络负责身份、欺诈、授权和结算。零售商控制库存、结账、退货和客户账户。身份提供商管理身份验证。AI 公司则构建将请求访问权限的个人代理。

它们的利益存在重叠，但并不完全一致。代理开发者会在一次集成覆盖多家公司时受益。银行则会在每项操作都可追溯、受限制且可撤销时受益。零售商希望获得代理流量，同时不失去对服务政策或客户关系的控制。

因此，合作伙伴名单不只是一组熟悉的标志。它让 Sierra 能接触到那些必须就发现、委托访问和现实世界操作之间边界达成共识的各方。

不过，设计合作伙伴并不自动等同于实施者。Sierra 尚未公布 Poppy 的生产使用数据、已完成集成或交易量。这项公告表明的是对设计过程的参与，而非每一家被点名企业都已提供运营支持。

Sierra 表示，它将在未来一个月开展设计研讨会并发布参考实现。这些交付成果将比合作伙伴数量提供更有力的检验。在开发者能够评估实施成本之前，他们需要可运行的代码、测试环境和稳定的一致性规则。

因此，当前发布改变的是该协议的可信度，而非成熟度。Poppy 现在拥有公开规范和一大批感兴趣的公司，但它仍处于 Draft 0.1 阶段，许多重大技术和治理决策尚未确定。

Poppy 将权限作为产品核心

Poppy 的主要贡献并非另一种代理消息格式，而是面向在企业控制系统中行动的代理提供共享会话和权限模型。

Draft 0.1 规范 将个人代理定义为代表单个用户行动的软件，并将企业定义为允许该代理与其服务交互的组织。

参与企业会在 /.well-known/poppy.json 发布发现文档。该文档会标识组织，并列出其身份验证选项、API、网站访问、企业代理和支持的扩展。

这种模式与其他众所周知的 Web 发现机制类似。Poppy 不要求代理开发者寻找各自独立的集成说明，而是为代理提供一个可预测的统一起始地址。

发现只是第一层。个人代理会为特定用户开启会话，并向企业表明自身身份。这一设计让企业能够区分自动化活动与用户直接使用网站的行为。

会话可以在没有账户访问权限的情况下开始。例如，代理可作为访客查询产品是否有货，或询问退货政策。当任务需要个人账户信息或修改账户时，用户再登录。

Poppy 定义了直接登录、设备登录和中介登录。直接登录将身份验证保留在企业自身页面上。设备登录允许用户通过访问链接并输入代码，在另一台设备上批准访问。

中介登录允许代理在企业允许该方法时，将凭据发送至企业定义的端点。该选项提供了兼容性，但也带来了草案中最敏感的安全问题之一。

获得授权后，代理将取得限定范围的访问权限。宽泛的 poppy:read 范围涵盖查看账户信息，而 poppy:write 涵盖换货或预订更新等变更。企业还可为更窄范围的活动定义额外权限。

这些权限在两个不理想的极端之间建立了一道权限阶梯。企业不必阻止所有代理，用户也不必向代理交出账户提供的全部能力。

会话会跟随用户跨越受支持的界面。代理可在网页、OpenAPI 端点、MCP 服务器以及与企业代理的对话之间切换。登录前的提问和之后的账户变更可以保持为同一次访问的一部分。

这种连续性对双方都很重要。用户不必反复解释同一目标，企业则能获得更连贯的记录，了解会话如何跨渠道推进。

Poppy 还定义了将人类引入代理对话的方式。消息会注明由 AI 还是人类创建。个人代理可以请求人工客服代表，用户则可在无需阅读代理先前交流的情况下直接进入对话。

以航班取消为例。个人代理可以发现航空公司支持的界面，开启会话，并在无账户访问权限的情况下搜索替代方案。之后，用户可以登录、批准预订访问权限，并确认替代航班。

零售商可以采用不同的政策。它可能允许代理发起退货，同时阻止其修改已保存的付款信息。每项权限解锁哪些操作，由企业而非个人代理决定。

这一机制解释了该协议为何对企业具有吸引力。Poppy 并不要求企业将政策让渡给外部代理，而是提供一种标准方式，让企业公开这些政策，并在多种技术渠道中执行它们。

企业而非个人代理掌握主动权

该协议承诺给予用户选择权，但其架构赋予参与企业大量控制权，使其决定哪些代理可以进入以及能够完成哪些操作。

Sierra 将 Poppy 描述为代理访问与企业监督之间的折中方案。用户选择个人代理并批准其账户权限，企业则决定支持哪些界面、登录方式、权限范围和操作。

从高层面看，这种划分似乎较为平衡，但其实际结果将取决于企业如何配置实现。

企业可以只发布网站、只发布选定的 API，或提供任务范围有限的企业代理。它可以支持读取访问而不支持写入访问，可以要求敏感操作使用直接登录，也可以拒绝不被其识别的代理。

因此，该协议标准化的更多是协商过程，而非普遍访问。发布 Poppy 文件并不要求企业开放每一项客户操作，而是告诉代理有哪些入口以及适用何种条件。

这一模式直接回应了当前 Web 上代价高昂的冲突。企业常常试图检测自动化行为，因为使用人类界面的代理可能看起来像滥用行为。代理开发者则会调整浏览器，使其在这些控制措施下仍能正常运行。

双方都无法从这种对抗中获得可靠信息。企业可能不知道运营该代理的是哪项服务，或它代表哪位用户。代理也可能不知道一次失败的操作是源于政策、身份验证，还是界面变更。

Poppy 用明确的身份和政策取代了部分模糊性。企业可以识别个人代理的客户端身份，将其关联到某一用户，并签发仅限于已批准权限范围的令牌。

这种安排应能让合法代理更容易与匿名自动化区分开来。它并不能消除欺诈、账户被盗、提示注入或恶意代理开发者，但会为应用安全控制提供更结构化的证据。

用户获得了更清晰的选择，但这些选择仍受企业政策限制。个人无法向代理授予企业从未开放的能力。同样，一家参与企业也无法迫使另一家接受其偏好的代理。

这正是 Sierra Personal Agent Protocol 背后的核心取舍。一致的发现和授权机制可以扩大合法代理的访问范围，而同样的设计也将每家企业限制该访问的权利正式化。

这种平衡可能会鼓励受监管组织采用。Bank of America、BBVA、Wells Fargo、Cigna 以及多家保险公司都面临着使无限制自动化不切实际的义务。它们需要可审计性，以及在读取数据与修改账户之间作出明确区分。

支付公司也有类似动机。Mastercard、Visa、PayPal、Venmo、Adyen、Plaid 和 Synchrony 需要知道哪一方发起了一项操作；当 AI 界面位于客户与交易之间时，它们也需要仍然有效的控制措施。

对于个人代理构建者而言，如果这项折中方案能够减少定制集成，它依然具有吸引力。即便每家公司开放的业务操作不同，一种发现格式和一种授权模型也可能很有价值。

更大的风险在于标准内部的碎片化。企业可以定义自定义权限范围和扩展，而每个 API 都保留自身的模式。两家组织都可能支持 Poppy，却仍需要截然不同的实施工作。

Poppy 可以标准化代理如何抵达、表明身份并请求访问权限，但无法自动标准化每一份抵押贷款申请、保险理赔、航班变更或零售退货。

这一限制并不意味着该项目无关紧要。它只是厘清了真正困难的工作从何处开始。该协议可以建立一个统一入口，但行业和各家公司仍需定义内部会发生什么。

现有 Agent 标准是输入，而非竞争对手

Poppy 最可信的定位是利用现有标准的编排层，而不是替代 MCP、A2A、OpenAPI 或商业协议。

如今的 Agent 标准覆盖了多种不同的边界。若将它们视为一场只能有一个赢家的竞争，就会掩盖各自所解决的问题。

Anthropic 推出了 Model Context Protocol，作为 AI 应用与外部工具或数据之间的标准连接方式。MCP server 可以暴露 AI client 可发现并调用的能力。

Google 最初开发 A2A protocol，用于独立 Agent 之间的通信与协作。A2A 聚焦于跨越供应商边界的 Agent 之间交换任务、消息、工件和状态信息。

Poppy 面向的是更广泛的用户与公司关系。它涵盖公司发现、个人 Agent 身份、用户会话、授权、网页浏览、API、公司与 Agent 的对话，以及人工交接。

这种区别体现在 Poppy 的架构中。一家公司可以将 MCP server 列为可用 API 之一，也可以列出 OpenAPI 描述、提供其常规网站，或暴露一个公司 Agent。

因此，MCP 只是 Poppy 会话中的一条路径。Poppy 提供了工具接口本身无法完整定义的周边能力：身份、用户授权以及跨渠道连续性。

A2A 也有类似关系。公司 Agent 和个人 Agent 需要一种通信方式，但二者的对话只是此次访问的一部分。个人 Agent 也可能浏览网页，或调用传统 API。

商业标准则构成另一层。Shopify 和 Google 的 Universal Commerce Protocol 聚焦商品发现、结账和订单管理等商业活动。

Sierra 明确将 UCP 描述为互补方案。Poppy 可以确定 Agent 代表谁、用户授权了什么；随后，商业协议则可定义购买或管理订单所涉及的领域专属操作。

这种分层方式很务实，因为公司现有的技术栈各不相同。零售商可能同时提供 UCP 商业工作流、MCP 客服 server 和常规网页。Poppy 的目标是将这些入口连接至同一个可识别的会话。

这种做法也避免将每一个业务流程都强行纳入自然语言 Agent 对话。对于许多操作而言，结构化 API 仍然更高效、更可预测。网页访问则可以覆盖缺少现代 API 的旧系统。

Sierra 表示，该协议建立在 OAuth、HTTPS、JSON Web Tokens、OpenAPI 和 MCP 之上。这些选择降低了熟悉现有 Web 安全与 API 工具的团队的理解门槛。

采用成熟组件并不等于保证互操作性。周边 profile 必须足够精确，才能让两个独立实现以一致方式运行。围绕 token audience、scope 执行、重试和失败状态的歧义，仍可能造成不兼容的系统。

因此，该协议的参考实现将十分重要。开发者需要的不只是文字要求，还需要可测试的示例，涵盖 Agent 注册、发现验证、token 交换、浏览器会话和对话交接。

一致性验证也是如此。如果每家公司对可选功能的理解不同，个人 Agent 仍将需要面向不同组织的专属逻辑。一项有用的标准必须明确哪些行为是实现基础兼容性所必需的。

Poppy 广泛的合作伙伴群体有助于解决这些细节，但由于参与方代表着相互竞争的平台、监管环境和客户关系，也可能拖慢达成共识的速度。

最佳结果不是由一个协议取代所有其他协议，而是形成一个各层职责清晰的技术栈。若 Poppy 能让身份、权限和会话连续性在整个技术栈中变得可预测，它便是成功的。

该草案仍留有棘手的安全问题

Poppy 提供了一套安全结构，但 Draft 0.1 并未消除软件能够通过客户账户采取行动所带来的风险。

该规范警告，Draft 0.1 的任何部分都可能在稳定版本发布前发生改变。这个警告很重要，因为这一层的授权错误可能影响购买、预订、金融申请和个人数据。

Poppy 使用短生命周期 session token，并将请求绑定至 Agent 身份。它还描述了持有证明保护机制，即请求方证明其持有与 token 关联的密钥。

这些控制措施可以减少 token 重放，并帮助公司追溯自动化活动。其有效性仍取决于正确的实现、安全的密钥存储，以及每个暴露接口上的一致验证。

跨渠道会话提高了便利性，但也扩大了执行边界。公司必须在其 API、浏览器端点和 Agent 对话中应用相同的账户状态和权限边界。

若某个 scope 在 API 上得到执行，却被网页忽略，就会形成绕过途径。若公司 Agent 执行了超出会话权限的操作，也会造成另一种绕过。

中介式登录尤其值得仔细审视。在这种模式下，个人 Agent 会在将凭据传给公司之前处理这些凭据。规范要求 Agent 保护机密字段，并避免显示或记录它们。

这项要求很有价值，但无法证明每个 Agent 都会安全地处理凭据。对于敏感账户，公司可能认为中介式登录带来的暴露风险不可接受。

直接登录提供了更清晰的边界，因为用户在公司自己的页面完成身份验证。当个人 Agent 在另一台设备上运行时，设备登录也可以提供类似的隔离。

权限设计带来了另一个问题。宽泛的 read 和 write scope 很简单，但现实服务中的操作后果差异极大。

修改新闻订阅偏好和修改邮寄地址都是写入操作。退还一件夹克和转账也同样是写入操作。对于高影响操作，公司将需要更细粒度的自定义 scope 或逐级加强审批。

自定义 scope 提升了控制力，但会威胁互操作性。Agent 必须先理解每个 scope 的含义，才能向用户解释。类似的操作在不同公司也可能有不同名称。

用户理解同样重要。人们经常不查看细节就批准访问提示。加入 Agent 后，风险更高，因为一次授权可能支持反复进行的自主操作。

值得信赖的界面必须说明：哪个 Agent 正在请求访问、它将使用哪个账户、它能读取什么，以及它可以更改什么。撤销权限也应当简单易行。

该草案支持撤销，并描述了可用于启动后续会话的长期账户 token。这种便利性在用户账户与个人 Agent 之间建立了持续关系。

公司和 Agent 提供商需要对这些关系保留清晰记录。用户应能查看活跃连接、已授予的 scope、近期操作和到期日期。

Prompt injection 仍不在协议的直接控制范围内。Agent 可能从网页、消息或外部文档中接收恶意指令。有效的身份验证并不能保证 Agent 最终的决策符合用户意图。

当 Agent 整合多个来源的信息时，这一担忧尤其相关。良好的个人知识管理可以改善上下文，但更多上下文也要求围绕信息披露和行动建立更强的边界。

对于购买、预订和账户变更，人工确认可以降低风险。然而，若每一个小步骤都要求确认，就会削弱个人 Agent 所承诺的效率。

因此，该协议需要的不只是安全的 token 交换。实现方案还需要基于风险的审批、交易记录、恢复流程，以及 Agent 犯下代价高昂的错误时明确的责任划分。

来自银行、支付、身份、保险和云安全领域的设计合作伙伴，可以帮助对这些问题进行压力测试。但仅凭其名称并不能解答这些问题。

独立安全审查将是另一个重要信号。公开的威胁模型、互操作性测试和记录在案的失败案例，比关于信任或控制的表述能提供更多证据。

评判 Poppy 的标准应是：其控制措施能否在对抗性条件下保持一致。成功演示固然有用，而一次可恢复的失败往往更具参考价值。

三个信号将决定 Poppy 的未来

可运行的代码、真实公司的部署，以及独立安全测试，将决定 Poppy 是成为基础设施还是停留在雄心勃勃的草案阶段。

第一个信号是 Sierra 承诺推出的参考实现。该公司表示，计划在未来一个月的设计研讨会结束后发布。

一项有价值的发布应同时涵盖交互双方。开发者需要示例个人 Agent、参与公司的服务、发现文档、身份验证流程，以及 scope 执行测试。

该实现也应演示失败情形。过期 token、已撤销的访问、不足的 scope、重复消息、人工交接和中断的流，都是生产系统中的常见状况。

清晰的代码和一致性测试将增强 Sierra 的论点：公司可以使用熟悉的工具实现该协议。延期发布或范围狭窄、预先编排的演示，则会削弱这一主张。

第二个信号是具名合作伙伴的采用情况。合作伙伴自行控制的域名上公开的 poppy.json 文件，比又一次设计公告更有分量。

早期部署不必支持所有操作。零售商可以从商品问答和退货状态开始；航空公司则可以先提供航班时刻信息，再允许修改预订。

关键在于，独立的个人 Agent 能否在没有私有集成的情况下发现并使用这些能力。如果访问仍需要定制合同和未公开的行为规范，那么该标准就尚未实现可移植性。

OpenAI 和 Meta 在个人 Agent 一侧尤其重要。它们的参与为广泛分发创造了可能性，但任何一方的参与都不保证消费级产品会支持 Poppy。

银行、支付公司、零售商和旅行服务商在公司一侧很重要。它们的部署选择将揭示哪些身份验证和权限模型能够经受监管与反欺诈审查。

第三个信号是安全模型能否在受控演示之外有效运作的证据。应关注公开威胁模型、第三方审计、互操作性活动，以及测试后记录在案的修复措施。

能够执行账户操作的协议必然会受到严格审视。这是健康的。研究人员应能够测试发现验证、token 绑定、自定义 scope、浏览器会话、凭据处理和 Agent 冒充防御。

这三个信号相互强化。参考代码使测试成为可能，真实部署暴露运行问题，独立审查则在缺陷扩散至大量服务之前发现弱点。

合作伙伴名单为 Sierra Personal Agent Protocol 提供了强有力的起点。它横跨了受个人 Agent 从回答问题迈向完成交易影响最大的行业。

不过，标准能否成功取决于持续、反复的落地实施，而非发布时的声势。企业必须开放真正有用的能力。Agent 构建者必须一致地支持该协议。用户则必须理解并信任自己授予的权限。

对开发者而言，当务之急是审阅草案，并将其会话模型与现有认证架构进行比较。最有价值的反馈应聚焦于具体的不兼容之处、缺失的失败状态，或不明确的安全要求。

企业采购方应询问供应商：参与是指提供设计反馈、开展试点，还是承诺部署。这些表述对应着截然不同的支持程度。

个人 Agent 用户应关注控制权究竟体现在哪里：他们能否查看活跃连接、限制操作、审查历史记录，并在无需穿梭于多个产品的情况下撤销访问权限？

Poppy 正试图以明确的协作，取代 Agent 拦截与 Agent 伪装之间不稳定的博弈。这是一个值得追求的目标。接下来的一个月应能显示，Sierra 及其合作伙伴能否将这一目标转化为其他人可以安全实施的代码。