企业官网建设流程全解析

个人智能体协议 Poppy 草案：Agent 怎么证明自己在替谁办事

原文：Sierra Blog - 《Sharing a draft of Personal Agent Protocol》（https://sierra.ai/blog/poppy）

让智能体替你去退货、改签、下单，今天多半靠它"假装成你"：登录你的账号，在为人设计的页面上点来点去。企业这边没有标准手段告诉这个智能体"你能做什么、不能做什么"，客户的授权也说不清边界。Sierra 在 2026 年 10 月 9 日公开了 Personal Agent Protocol（简称 Poppy）的草案，想给这件事定一套规矩。

一、核心原则：客户决定给什么权限，企业决定能做什么

Poppy 的出发点写得很直白——客户有权决定给自己的个人智能体开多少访问权限，企业则设定这些智能体能做什么。企业可以沿用现有的网站和 API，也可以用自己的智能体接进来，以对客户最合适的方式配合个人智能体工作。

二、五个积木

1. 发现（Discovery）：企业在自家网站的标准地址放一个文件/.well-known/poppy.json，说明智能体该怎么和企业交互、客户如何登录、智能体能做什么。
2. 会话（Sessions）：个人智能体代表客户开启一个会话，可以先以访客身份开始——查库存、问退货政策这类事通常够用。智能体会表明自己是智能体，企业始终知道对面有代理正在替某位客户办事。
3. 登录（Sign-in）：需要用到账户时，客户在企业页面上通过 OAuth 登录；在企业允许的前提下，智能体也可以拿一个会话令牌代表客户登录，而这个令牌只授予客户批准过的那部分权限。
4. 跨渠道同一会话：同一个令牌在企业的 API、网站，以及与企业自有智能体的对话中都有效。登录前问的问题和登录后改的订单属于同一次访问，客户不必从头再来，企业看到的是完整旅程而不是断片。
5. 把事办完：企业自己决定开放哪些渠道——自己的网站（智能体浏览常规页面，企业在每个页面上应用客户权限）、自己的 API（智能体走 OpenAPI、MCP 这类标准接口）、或者企业自己的智能体（适合保修申请、换货这类需要对话的任务，回复可以流式写出，企业也可以把请求挂住、等有结果再回）。

三、搭在现有标准上

Poppy 用的是 OAuth、JWT、HTTPS、OpenAPI 和 MCP。这些都是开放且被广泛使用的技术，团队用现有的库和工具就能实现；核心设计也允许扩展，方便行业在上面加自己的分层。对企业还有个实际好处：接一次 Poppy 就够了，不必为每个个人智能体单独对接一遍。

它和 Universal Commerce Protocol（UCP）这类协议是互补关系——UCP 聚焦购物链路，从找商品、结账到管订单；Poppy 管的是更一般的问题：个人智能体怎么表明身份、怎么拿到客户授权、怎么跨任意类型的任务与企业协作。

四、三个具体场景

• 退一件夹克（走网站渠道）：智能体找到零售商、表明身份，客户登录一次，然后使用零售商常规的退货页面。零售商知道这是一个替已登录客户办事的智能体，允许它发起退货，但不允许它改动存档的支付信息。
• 航班取消要改签（走 API 渠道）：智能体用客户授权的访问权限，通过 MCP 连上航空公司的预订工具，找到下一班可用航班，跟客户确认座位之后再下单。
• 房贷预批（走企业自有智能体渠道）：在 Sierra Summit 现场，Rocket 产品副总裁 Alex McGillis 做了实时演示。他让 Meta 的个人智能体 Muse 去办房贷预批——Muse 到 Rocket 网站上通过 Poppy 找到 Rocket 的智能体，并请 Alex 授权连接；Alex 登录后共享了房贷所需的信用与收入信息；两个智能体谈好购房价格、首付和利率，很快预批函就绪。

五、设计伙伴

首发时是 Meta，加上 Genesys、Instinct、NiCE、Rocket、Shopify、Stripe 和 Walmart。10 月 9 日又新增了 35 家设计伙伴：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。这些公司会参与草案的设计过程，从各自的业务视角给出反馈。

六、给智能体开发者的四件事

1. 预留发现文件。哪怕协议还是草案，"站点标准路径放一份能力清单"的做法与 robots.txt、各类 well-known 约定一脉相承，现在准备成本很低。
2. 把能力拆成接口。协议把执行渠道分成网站、API、企业自有智能体三类，其中 API 这一路建在 OpenAPI 和 MCP 上。对企业来说，把业务能力包成 MCP 工具，等于同时服务人和智能体。
3. 令牌最小权限要落到具体字段。原文举的例子很具体：允许发起退货，但不允许修改支付信息。授权粒度直接决定智能体一旦出错能造成多大损失。
4. 会话要能跨渠道续上。官方目标里，登录前的一问和登录后的一改属于同一次访问——这要求你的身份与上下文不是按页面切碎的。

七、接下来一个月

草稿只是起点。官方说接下来一个月会举办设计工作坊，并发布一份参考实现帮开发者上手。目标写得很简单：客户选谁代表自己，企业清楚自己在和谁打交道，双方都在自己划定的边界内安全行事。

Poppy 目前还只是草案，参考实现尚未发布，字段名与流程细节请以 personalagentprotocol.org 上的草案和官方文档为准；本文未验证最新版本。