Meta等推出PAP，给AI代理立规矩

Sierra、Meta与Shopify、Stripe、沃尔玛等公司近日宣布推出个人智能体协议 PAP，目标是让企业能够识别代表用户办事的 AI Agent，并限制它能访问什么、执行什么操作。 这项协议回应的不是模型能力问题，而是 Agent 开始替用户访问网站、账户和商业服务之后，企业与用户之间缺少一套共同的身份和授权规则。

根据 Sierra 及合作方的公告，PAP（Personal Agent Protocol，个人智能体协议）基于 OAuth 等成熟标准设计。它提出的基本分工是：消费者决定向个人智能体授予哪些访问权限，企业则设定智能体在自家服务中可以执行哪些操作。参与合作的公司还包括 Genesys、Instinct 和 Rocket。

PAP 是一套用于规范个人 AI 智能体与企业服务交互的协议框架，而不是一个新的通用智能体或模型。 它试图让“谁在访问”“代表谁访问”“获准做什么”成为企业可以验证和管理的信息，而不再让自动化程序只靠模拟真人点击网页来完成任务。

Agent开始办事，企业先遇到身份问题

个人智能体与企业服务之间的摩擦，核心在于企业很难区分获准办事的 Agent、普通自动化脚本和未授权访问。 目前不少 Agent 通过读取网页、点击按钮、填写表单等方式完成购物、客服查询、预约或订单处理。对企业而言，这种交互看起来可能与真人操作相似，却不一定能说明操作背后是谁、是否经过用户同意，以及程序究竟会不会继续提交订单或修改账户。

这对企业不是抽象的治理难题。一个智能体可能先查询商品库存，之后又尝试使用用户账户下单；它也可能在处理退货时读取订单信息，甚至提交退款申请。若服务端无法识别调用者身份和授权范围，企业要么把自动化流量一概挡在门外，要么在看不清风险的情况下放开访问。前者会让合法的 Agent 体验受限，后者则可能扩大账号滥用、误操作和数据暴露的风险。

OAuth 是 PAP 所借用的授权基础，它让用户能够把特定访问权限授予第三方，而不必把账户密码直接交给第三方。 PAP 的方向是在这一类既有授权机制之上，进一步处理 Agent 身份和企业侧操作控制：用户授权某个智能体，不等于企业必须允许它执行所有任务；企业开放某类能力，也不意味着 Agent 自动获得用户账户的全部权限。

这层区分很关键。传统的网页自动化常把“能登录”近似当成“能做事”，而更细粒度的授权体系需要把查询、修改、下单、取消、退款等动作分开看。PAP的价值，最终不在于让 Agent 更像人，而在于让它的身份和权限对用户、企业都更可见。

用户给权限，企业定边界

PAP提出的治理逻辑可以概括为两道闸门：用户决定 Agent 能代表自己访问什么，企业决定访问者在自家系统里能做什么。 两道闸门叠加，才能避免把用户授权误读为企业对所有自动化行为的全面许可，也避免企业仅凭自身规则替用户决定是否允许某个代理人访问账户。

以查询订单为例，用户可以授权 Agent 读取与订单有关的信息，但这项授权不必同时覆盖修改收货地址或申请退款。企业则可以决定是否对已识别的 Agent 开放订单查询入口，以及哪些操作必须再次确认。对于用户来说，授权越具体，越容易知道 Agent 到底能动哪些数据；对于企业来说，规则越明确，越容易把访问策略和业务风险对应起来。

不过，现阶段公开材料呈现的是协议目标和设计原则，并不足以证明上述权限颗粒度已经在可用版本中完整实现。iThome 报道提到，Sierra计划在10月稍晚公布 PAP v0.1 规格，并计划举办设计工作坊、发布参考实现。换句话说，截至10月10日，PAP仍应被视为正在推进的早期标准，而不是已经被广泛部署、拥有稳定兼容性的成熟协议。

这个时间点值得留意。v0.1 的规范如果能清楚定义身份声明、授权流程、撤销机制、错误处理和审计信息，企业才有可能据此评估接入成本；如果关键语义仍留给各家自行解释，协议即便名字统一，实际集成仍可能碎片化。对开发者来说，真正需要追问的不是“是否支持 PAP”这句宣传语，而是哪些操作、哪些服务入口和哪些权限类型已经得到明确约定。

与企业自有Agent、网页自动化的区别

PAP试图规范的是个人智能体代表消费者访问企业服务的交互，不是替代企业内部的客服机器人或业务 Agent。 两类智能体的利益关系不同：企业自有 Agent 通常由企业控制，个人 Agent 则以用户利益为出发点，可能跨多个品牌和服务执行任务。协议要解决的正是这两方在身份、授权和操作边界上的协商问题。

它也与单纯的网页自动化不同。网页自动化把任务拆成页面操作，Agent 看见页面后再点击、输入；这种方式能快速适配现有网站，却容易受到页面变化、弹窗、验证码和状态不一致影响，也未必能向企业表达清楚“我是某个用户授权的代理人”。协议化交互的方向，则是让服务方获得更明确的访问上下文，并依据预先定义的规则处理请求。

| 方式 | 企业能看到什么 | 权限控制特点 | 主要局限 | |---|---|---|---| | 网页模拟操作 | 页面请求和操作行为，身份信息可能不充分 | 常依赖登录状态、页面流程和网站自身限制 | 难以判断代理人身份，网页变化可能导致流程失效 | | 企业自有智能体 | 企业控制的应用身份和业务上下文 | 企业可在自身系统内设计权限 | 不天然解决用户跨品牌使用个人 Agent 的授权问题 | | PAP所倡导的协议化交互 | 目标是让企业识别 Agent、用户授权及可执行范围 | 用户与企业分别设定授权和操作边界 | 规范仍在早期阶段，互操作和落地情况待验证 |

这张表比较的是交互方式和治理思路，不代表 PAP 已经实现所有列出的身份能力。 目前协议的实际行为仍要以正式规范和参考实现为准。对于企业，网页模拟有现实的兼容性优势；对于用户，协议化访问则有望把授权从“把登录态交给工具”推进到“只授予完成任务所需的能力”。两者短期内很可能并存，而不是一夜之间由 PAP 全面取代网页操作。

这次合作的意义与边界

PAP最值得关注的地方，是它把个人 Agent 与企业服务之间的信任问题摆到了产业协作层面。 合作名单横跨社交与技术平台、零售、电商、支付和客户服务等领域，说明参与者并不只关心某个聊天机器人能否回答问题，而是开始讨论 Agent 如何进入真实业务流程。购物、支付、客服和订单管理都涉及账户权限与交易责任，单靠模型“理解用户意图”无法替代身份验证和访问控制。

但合作名单不能直接等同于市场采纳。宣布共同推出协议，不代表每家合作方的线上服务都已完成接入，也不代表不同 Agent、不同企业之间已经可以互通。标准能否成为事实上的共同语言，通常取决于几个更具体的问题：企业接入要改多少系统；用户能否看懂并撤销授权；Agent 是否能携带清晰、可验证的身份；权限能否细化到具体动作；发生误操作时由谁负责。

PAP的成败指标不应只是合作公司数量，而应是授权是否可理解、操作是否可审计、跨服务接入是否可复用。 如果用户只能在冗长的授权页面里勾选一揽子权限，所谓“用户决定”就可能变成形式；如果企业无法确认一次操作对应哪个用户、哪个 Agent 和哪项授权，企业控制权也只是纸面承诺。相反，若授权界面能清楚显示 Agent 将读取什么、能提交什么、何时需要用户再次确认，PAP才可能改变实际产品体验。

这里还有一个不容易绕开的矛盾：用户希望 Agent 能跨平台连续办事，企业则希望保留对服务入口、数据和交易流程的控制。协议可以统一身份与授权的表达方式，却无法自动解决商业利益冲突。企业仍可能限制某些自动化访问，个人 Agent 也未必愿意接受每个服务方各自制定的一套复杂流程。PAP的任务是降低协商成本，不是消灭协商本身。

开发者和深度用户该看什么

对开发者而言，短期最实际的动作是关注 PAP v0.1 的规范和参考实现，而不是据公告推断马上需要重写现有 Agent。 在规范发布前，公开信息不足以回答具体字段、流程时序、权限粒度、撤销方式和兼容要求等工程问题。产品团队可以先盘点自己的 Agent 会代表用户访问哪些服务、会触及哪些敏感数据，以及哪些操作需要二次确认，为后续评估标准留出空间。

企业侧则应把“识别 Agent”与“信任 Agent”分开。知道请求来自某个智能体，并不自动说明这个智能体安全，也不代表用户授权有效；身份验证只是第一步，仍需要结合授权范围、风险等级、用户确认和日志审计来决定是否执行。对涉及付款、退款、账户资料修改等高影响操作，默认要求明确确认，通常比把所有任务交给通用权限更稳妥。

深度用户也不必把“基于 OAuth”理解成自动安全。OAuth提供授权框架，但安全效果取决于具体实现：授权是否过宽，令牌能否及时撤销，敏感操作是否有额外确认，企业是否能记录和解释 Agent 的行为。标准名称解决不了糟糕的授权设计，更无法替用户判断一个 Agent 是否值得信任。

截至2026年10月10日，PAP仍是一项值得跟进、但尚待规格和部署验证的行业倡议。 它抓住了个人 Agent 商业化不可回避的一环：当软件开始代表人采取行动，访问权限就不能只藏在登录状态和网页按钮背后。接下来最关键的观察点，是 Sierra 计划公布的 v0.1 规范能否把原则转化为可互操作的技术约定，以及合作企业是否会把它真正接入面向消费者的服务。

如果这两步推进顺利，PAP可能让企业从“封不封自动化流量”的二选一，转向“识别身份、限定权限、记录行为”的分层管理；如果标准迟迟停留在倡议层，个人 Agent 仍会继续依赖各家网站各自的登录和自动化兼容策略。对整个行业来说，这不是一个已经解决的问题，而是一次把问题摆到桌面上的尝试。

参考来源

• IT之家：Meta与多家伙伴合作推出PAP协议——介绍协议目标、参与方及基于 OAuth 等成熟标准的设计原则。
• iThome：Sierra、Meta推Personal Agent Protocol——补充协议规划、早期版本时间安排，以及 Agent 身份、企业控制和应用场景的报道。