JOTO
Contact us
← AI 智库
大语言模型

Meta为Personal Agent推出一个新协议PAP

2026 年 10 月 7 日

Meta联合Sierra等企业发布Personal Agent Protocol(PAP),旨在解决Personal Agent代表用户与企业服务交互时的身份认证、用户授权与可信关系建立问题。PAP聚焦于Personal Agent→User→Business链路,区别于以任务为中心的A2A模型,强调协议化连接而非浏览器模拟操作,并与ANP、MCP在交互模型上呈现交集。

PAP的发布背景与核心目标

前不久Meta爆火的MUSE就被亚马逊封禁,禁止个人使用MUSE在亚马逊购物。今天Meta就推出了一个新协议。Personal Agent真正要进入互联网,仅仅依靠Browser Use还远远不够,协议才是打破互联网孤岛、实现Agent之间真正互联互通的关键。

PAP协议概念图
PAP协议概念图

PAP由Meta和Sierra联合发起

PAP,Personal Agent Protocol,尚未正式发布。参与PAP的还有Genesys、Instinct、Rocket、Shopify、Stripe、Walmart等企业,他们代表了两类agent:personal agent和企业agent。PAP的目标就是未来打通这两类agent。

PAP解决的核心问题:可信身份与授权关系

PAP要解决的核心问题是Personal Agent如何代表用户和企业进行交互。未来Muse这样的Personal Agent会帮助用户订机票、购物、修改订单、联系客服。企业首先需要知道:这是哪个Agent?它代表哪个用户?用户到底授权它做什么?

所以PAP解决的并不只是Agent怎么调用API,而是Agent身份、用户身份、用户授权和企业服务之间如何建立可信关系。为什么Meta不用A2A?权限问题A2A肯定可以解决,难解决的是A2A以任务为核心的交互,其实不适合这个场景。

Browser Use的根本局限与协议化必要性

今天的Personal Agent大量依靠浏览器模拟人的行为:打开网页、点击按钮、填写表单、完成购买。这种方式最大的好处是什么网站都能用,但问题也非常明显:网站不知道来的到底是人还是Agent,也不知道Agent代表谁,更不知道用户到底给了它什么权限。

Amazon封禁Muse,正好把这个问题暴露出来。只靠模拟人的操作进入网站,很容易和网站的安全、风控、商业规则发生冲突。所以我一直认为,Browser Use是智能体互联网早期的过渡方案,长期一定会走向协议化连接。协议才是智能体连接的最高效方式。

协议化后的安全模型:身份与授权分离

从目前已经公开的信息,以及参与PAP工作组的PACT方案来看,一个很重要的原则是:Agent身份和用户授权分开。Agent先证明“我是谁”;用户仍然在企业自己的系统中登录,然后明确授权这个Agent可以读取什么、修改什么。

比如:
Muse是谁 → 证明Agent身份
Muse代表哪个用户 → 企业确认用户账户
Muse可以干什么 → 用户授权orders、orders等权限
这比把浏览器和账号直接交给Agent安全得多。ANP也是这种模型。

PAP与ANP的交集与差异

PAP和ANP已经开始出现明显交集。ANP从一开始就在解决开放智能体互联网中的几个基础问题:Agent Identity → Agent Discovery → Authentication → Authorization → Communication。其中ANP使用W3C DID作为Agent的长期身份,并正在设计DID + VC + OAuth的授权机制。

PAP更聚焦于:Personal Agent → User → Business;而ANP希望解决的是更广泛的:Agent ↔ Agent ↔ Service ↔ Organization。两者不是完全相同的协议,但在Agent身份、OAuth授权、企业服务发现和Agent-to-Business交互上已经产生了明显交集。

交互模型对比:PAP、ANP、MCP趋同,A2A不同

从交互模型看,ANP、MCP和PAP更加像,A2A则与这三个协议不同。主要原因,是A2A的任务交互模型,这种模型不适合智能体在互联网上的协作。

最明显的一个点,是MCP、ANP、PAP即允许对方是一个agent,也允许对方不是一个agent,就是一个传统的软件系统。在可组合性上,ANP和PAP比较像,都可以将MCP作为协议的接口。

身份模型尚无定论,DID仍具互操作优势

在身份模型上,还没有看到具体的方案。有两个可能方案:Meta自己的私有身份+OAuth;OAuth最新的草案CIMD(OAuth Client ID Metadata Document,能够让客户端避免在企业agent注册账号)。应该不是使用DID。不过我们仍然认为DID的互操作性还是这几个方案中最强的,并且did也可以和OAuth配合使用。

纵向打通与横向打通的张力

Personal Agent和企业agent打通是纵向打通。Personal Agent和Personal Agent会横向打通吗,即不同公司的Personal Agent之间打通?我们认为会的,不过Meta不一定有动力做这个事情。Meta的动力是让更多的人留在MUSE,MUSE代表用户访问企业agent。

这里会有一个经典的问题,怎么证明MUSE代表了我的利益而非Meta的?明天接受美国一个13岁播主的访谈,这也是他关心的核心问题。当agent需要横向打通的时候,PAP是否仍然能够满足需求?

PAP与ANP、MCP、A2A模型对比示意图
PAP与ANP、MCP、A2A模型对比示意图

智能体互联网的临界点

无论如何,Personal agent都代表了智能体的一个新的阶段,并且催生了对智能体协议和开放智能体网络的强大需求。我在用这些personal agent产品的时候,已经无法忍受需要我频繁介入的情况了。智能体互联网也许真的不远了。

JOTO 企业落地观察

  • Personal Agent与企业服务的协议化对接,意味着企业需重构API网关层,嵌入Agent身份校验与细粒度OAuth授权策略,而非仅面向人类用户的会话管理。
  • PAP所强调的“Agent身份-用户身份-授权范围”三元分离模型,对企业RAG知识工程提出新要求:需将用户权限上下文动态注入检索与生成链路,避免越权访问敏感知识片段。
  • 当企业Agent需同时响应多厂商Personal Agent请求时,FDE驻场共创团队将面临跨协议适配压力——PAP、ANP、MCP并存环境下,统一身份联邦与策略中心成为基础设施刚需。
  • 浏览器自动化交互被协议替代后,企业AI安全治理重点将从“防爬虫”转向“防冒充Agent”,需部署基于DID或OAuth Client ID的实时凭证验证能力,而非依赖IP或行为指纹。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们
Contact Us

Start your enterprise AI rollout

Tell us your industry, team, and current pain points. We'll get back to you within one business day to help you decide what to tackle first, what data to prepare, and which platform fits.

WeChat
Scan to add us for a 1:1 chat
JOTO WeChat consultation QR code

Tell us what you need

Once we receive your details, we'll be in touch within one business day.