Meta为Personal Agent推出一个新协议PAP
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由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是否仍然能够满足需求?

智能体互联网的临界点
无论如何,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 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


