Personal Agent Protocol：Meta 与 Sierra 想让每个 AI Agent 共用一套「登录」

2026 年 10 月 6 日，Sierra 与 Meta 发布 Personal Agent Protocol（PAP）——一套开放标准，规定个人 AI Agent 如何向企业系统认证、并代表用户行动。它构建在 OAuth 之上（也就是你早已在用的「使用……登录」），并定义了三档访问权限。以 Shopify、Stripe、Walmart、Genesys、Rocket、Instinct 为早期伙伴，PAP 试图用「一扇前门」取代当下碎片化、彼此设防的高墙。

PAP 意在标准化 Agent 向企业的认证方式

为什么 Agent 商务需要一次「握手」

Agent 擅长研究，却不擅长购买，原因不在模型。问题在于，企业没有可靠的办法弄清敲门的「是谁」——或者「是什么」。当 Meta 的 Muse 这样的个人 Agent 试图结账时，零售商无法把合法的受托购物者与自动化爬虫区分开来，于是要么拒绝所有人，要么信任所有人。正是这种摩擦，让 Agent 商务的研究远远跑在支出的前面。PAP 试图修的是「前门」，而不是去争论「走廊」。

# Personal Agent Protocol, from the October 6, 2026 announcement.
# It is built on OAuth: agents identify themselves, declare intent,
# and act on a user's behalf within granted access.

PAP = {
    'announced': '2026-10-06',
    'authors': ['Sierra', 'Meta'],
    'based_on': 'OAuth',
    'partners': ['Shopify', 'Stripe', 'Walmart', 'Genesys', 'Rocket', 'Instinct'],
    'spec_v0_1': 'later in October 2026',
}

PAP 如何运作

这套协议标准化了 Agent 与企业相遇的那一刻：Agent 如何自证身份、声明意图，并代表用户执行任务——全部构建在 OAuth 之上，也就是你早已在用的「使用……登录」按钮背后的机制。它定义三档权限。访客：无需登录即可读取营业时间、库存、退货政策等公开信息。只读：经用户同意后可查看订单历史或账户余额。写入：Agent 可以实际采取行动——下单、预约、提交表单。

# Three access levels define what an agent may do at a business.

class AccessLevel(Enum):
    GUEST = 'guest'              # public info only, no sign-in
    READ_ONLY = 'read_only'      # with user consent, read account data
    WRITE = 'write'              # agent can take action

# Guest: opening hours, stock levels, return policies.
# Read-only: order history, account balances.
# Write: place an order, make a booking, submit a form.

早期伙伴包括 Shopify、Stripe、Walmart 与 Genesys

谁进、谁出

早期伙伴名单——Shopify、Stripe、Walmart、Genesys、Rocket、Instinct——很重要，因为一套协议的价值，取决于它的采用度。值得注意的是缺席者：Amazon、OpenAI、Anthropic。这个缺口正是全部故事所在：共享标准只有在最大平台都认同「一扇共同的前门胜过一堵私人设防的墙」时才成立。在那之前，会有相当一段重叠期：一些 Agent 与一些企业讲 PAP，另一些则继续守着自己的墙——而集成的成本，会落到所有需要「搭桥」的人头上。

# PAP maps onto OAuth scopes, so existing identity systems plug in.

PAP_SCOPE = {
    AccessLevel.GUEST:     ['catalog:read', 'store:read'],
    AccessLevel.READ_ONLY: ['orders:read', 'account:read'],
    AccessLevel.WRITE:     ['orders:write', 'account:write'],
}

def scopes_for(level):
    return PAP_SCOPE[level]

三层协议栈

把 PAP 理解为 AI Agent 基础设施的「第三根支柱」最为贴切。第一层是工具互操作，MCP 已成为「Agent 如何调用工具」的事实答案。第二层是 Agent 与 Agent 之间的通信。PAP 补上的是那层注定最难的：身份与授权治理——即「一个 Agent 是谁、它被允许做什么」的规则。身份一旦被标准化，就成了一张强有力的交换机；同样并非巧合的是，它也是「锁定」最容易藏身之处——正因如此，开发者应当在规范落地时仔细读它。

# Consent is explicit and scoped: the user grants, the agent obeys.

def grant(user, agent, level):
    token = oauth.issue(
        subject=agent.id,
        actor=user.id,
        scopes=scopes_for(level),
        intent=agent.declared_intent,
    )
    return token   # revocable, auditable, time-bound

写入级权限，正是权限与责任相撞之处

风险：权限与责任

写入级权限，正是「承诺」与「危险」相遇之处。一个能代表你行动的 Agent，也能「代表你行动错」；而最棘手的问题不是技术性的，而是法律性的：当自主 Agent 买错东西或泄露错数据，谁负责？PAP 的分级同意模型是个起点——用户授予某一档权限，且该授权可限定范围、可撤销。但「可以行动」与「应该行动」是两个不同的问题。做对这件事的团队，会给写入级权限配上明确的预算与审批阈值，而不只是一个权限开关。

# Write access should come with a budget, not just a permission.

def act(agent, action, token):
    assert token.allows(action.scope), 'scope not granted'
    assert action.amount <= token.budget, 'over budget'
    return execute(action, on_behalf_of=token.actor)

# 'Can act' and 'may act' are different questions. Ask both.

开发者该做什么

三件事。一：盯住本月稍晚发布的 0.1 版规范，把它的访问档位映射到你已经在签发的 OAuth scope 上。二：现在就把「同意」与「预算」设计成一等概念，让你的系统能表达「这个 Agent、这个意图、这个上限」，而不是一个粗糙的是或否。三：从第一天起，就用用户 ID 给 Agent 行动打点——如果一个 Agent 要代表某人行动，当有人问「到底发生了什么」时，你会需要那条 trace。PAP 押注的是「Agent 会有一扇共享的前门」。无论它是否胜出，这都是行业正在走的方向。