ARTICLE · 1157331
当你的 AI 助理能替你办房贷:PAP 协议如何重塑 Agent 时代
当你的 AI 助理能替你办房贷：PAP 协议如何重塑 Agent 时代
2026 年 10 月，Meta 与 Sierra 联合发起的**个人 Agent 协议（Personal Agent Protocol, PAP）**公布首版 0.1 草案，代号"Poppy"。OpenAI、Visa、Mastercard、PayPal 等 35 家企业新加入制定。
这不是又一个聊天机器人框架。PAP 要解决一个更根本的问题：当 AI Agent 替用户办事时，企业如何确认它的身份、获得了哪些授权，以及能执行什么操作？
一、问题：Agent 时代的"身份危机"
现状：模拟人类的笨办法
今天的大多数 Agent 仍在用一种尴尬的方式工作——模拟真人操作网站：
登录你的账号 点击按钮、填写表单 截图识别页面内容 重复操作直到任务完成
对企业来说，这带来两个难题：
分不清是人还是 Agent：网站无法区分访问者是用户本人还是某个 Agent 在自动化操作 无法精细授权：企业只能给整个账号开权限，无法单独限制"这个 Agent 只能查余额，不能转账"
后果：安全与效率的双重损失
安全风险：
Agent 需要用户的完整登录凭证（用户名+密码+2FA） 一旦 Agent 被攻击或误操作，用户账户完全暴露 企业无法审计"哪些操作是 Agent 做的"
效率瓶颈：
企业必须为每家 Agent 单独开发适配 Agent 靠模拟点击，速度慢、易出错（网站改版就挂） 无法实现 Agent 与 Agent 之间的直接协作
二、PAP 的解法：给 Agent 发"身份证"
核心思路：从"模拟人"到"表明身份"
PAP 的核心创新是让 Agent 主动表明身份，而不是假装自己是人。
技术架构（简化版）：
用户 → 个人 Agent（如 Meta Muse） ↓ PAP 协议层（身份验证 + 授权） ↓企业网站 / 企业 Agent（如 Rocket 房贷 Agent）三个关键机制
1. 企业接入文件（Enterprise Access File）
企业在网站公布统一格式的接入文件（类似 robots.txt），列明：
登录方式：支持 OAuth、API Key，还是其他认证 可用接口：哪些操作开放给 Agent（查余额、下单、退货……） 企业 Agent 入口：如果企业也有 Agent，它的接入地址
示例（简化）：
{"version":"0.1","auth_methods":["oauth2","api_key"],"capabilities":[{"action":"check_balance","requires":["read"]},{"action":"initiate_return","requires":["write"]},{"action":"modify_payment","allowed":false}],"agent_endpoint":"https://example.com/agent"}2. Agent 身份声明
Agent 访问企业时，必须携带：
Agent 身份标识：由哪家厂商签发（如 Meta、OpenAI） 用户授权证明：用户授予该 Agent 的具体权限范围 会话上下文：当前任务的元数据（如"用户正在申请房贷预审批"）
3. 细粒度授权
企业可以精确控制 Agent 能做什么：
关键区别：授权是操作级的，不是账号级的。用户可以授权 Agent"查余额"，同时禁止"转账"。企业也可以直接拒绝特定厂商的 Agent 接入。
三、实战演示：Agent 协作办房贷
Sierra 此前现场演示过一个场景：Meta Muse 通过 PAP 找到房贷公司 Rocket 的 Agent，用户授权后，双方 Agent 协作完成了房贷预审批。
对比两种流程
传统流程：
登录 Rocket 房贷网站 手动填写个人信息（收入、信用、房产） 上传文档（工资单、税表） 等待审批（数天到数周）
PAP 流程：
用户告诉 Meta Muse："帮我看看房贷预审批能批多少" Meta Muse 读取 Rocket 的接入文件，发现其 Agent 端点，发起 Agent-to-Agent 连接 Rocket Agent 提出授权要求："需要读取你的收入证明和信用报告"（只读、7 天有效） 用户确认授权 Meta Muse 提供授权范围内数据，Rocket Agent 运行预审批模型 返回结果："预批额度 50 万美元，利率 6.5%"——全程无需手动填表
关键优势
速度：从几天缩短到几分钟 安全：用户不把密码交给 Agent，授权细粒度、可撤销 可审计：每一步都有记录，企业清楚"是哪个 Agent 在替哪个用户操作" 跨渠道会话：同一任务可在网页、API、Agent 渠道间延续
四、技术细节：PAP 怎么实现
协议栈
PAP 基于现有 Web 标准构建：
身份验证流程（简化）
1. Meta Muse → Rocket： "我是 Meta 签发的 Agent，用户 Alice 授权我办理房贷预审批" [附带 OAuth token + 用户授权凭证]2. Rocket → Meta Muse： "验证通过。需要：年收入（近 2 年）、信用评分、目标房价"3. Meta Muse → Rocket： [仅提供授权范围内的数据]4. Rocket → Meta Muse： "预批：额度 50 万美元，利率 6.5%，有效期 30 天"安全机制
默认拒绝：接入文件未声明的能力，Agent 一律不可用 最小权限：Agent 只能访问用户明确授权的操作 随时撤销：用户可一键收回授权 审计日志：所有 Agent 操作留痕
五、生态影响：谁受益，谁承压？
受益方
用户：不再重复填表；Agent 可跨网站协作完成复杂任务；授权精细、风险更低。
企业：一次公布接入文件，即可对接所有支持 PAP 的 Agent，不必为 OpenAI、Meta 各做一套适配；权限可控、操作可审计。
Agent 厂商：统一标准降低接入门槛，可以专注 Agent 能力本身；支持 PAP 的企业越多，Agent 越有用（网络效应）。
承压方
传统 RPA：靠模拟点击的机器人流程自动化，在身份可验证、接口直接调用的 PAP 模式面前竞争力大打折扣。
封闭平台：拒绝接入 PAP 的企业，可能把"代办业务"的流量让给支持 PAP 的竞品——当用户的 Agent 能直接在别家办完事，你的网站就失去了入口。
隐私监管：Agent 代表用户流动于多个企业之间，数据链路变长，"谁在什么时候拿走了什么数据"的审计复杂度上升。
六、未解问题与未来演进
当前局限（0.1 草案）
1. 支付未纳入。虽然 Visa、Mastercard、PayPal 参与制定，付款、主动通知等功能尚未定义。支付涉及资金流转与各国合规，预计要到 0.2/0.3 版本。
2. 主动通知未定义。目前只支持"用户发起 → Agent 执行"的被动模式。
3. 草案可修改。Poppy 仍是 0.1 草案，条款随时可能调整——35 家企业的博弈才刚开始。
演进方向
去中心化身份：当前身份签发依赖大厂中心化背书，未来可能引入 DID，让用户自己掌控身份。
授权规则可编程：结合智能合约思路——用户预先写下规则（如"利率低于 6% 时自动再融资"），Agent 在链上授权约束内自动执行。
跨平台信任网络：当 PAP 与 Agent 支付协议（如 x402 等）拼接，"Agent 身份 + 授权 + 结算"三层齐备，真正的 Agent 经济才算闭环。
七、对中国企业的启示
机会
窗口期仍在：PAP 只是 0.1 草案，中国厂商参与制定、影响规则的门槛还不高 本土化落地：在 PAP 基础上适配微信/支付宝登录、国内征信与合规要求（如数据出境限制），在电商、金融场景先行
挑战
生态壁垒：PAP 由 Meta、Sierra、OpenAI 主导，缺席者可能被排除在全球 Agent 生态之外 技术门槛：涉及 OAuth 2.1、数字身份、结构化能力声明，需要专业团队 合规约束：Agent 代表用户访问数据，受《个人信息保护法》等约束，需要法务深度参与
结语
PAP 不是完美的协议，但它指向一个清晰的方向：Agent 时代需要新的"社会契约"。
过去的互联网，人操作网站；未来的互联网，Agent 替人办事。PAP 试图定义这个新世界的规则：表明身份、获取授权、遵守边界、留下审计。
当你的 AI 助理能替你办房贷、退货、签合同，你凭什么相信它不会越权？PAP 的答案是：用协议约束，用密码学保障，用审计监督。
这或许是人类与 AI 协作商业化的第一步。
本文基于 PAP 0.1 草案 Poppy 公开信息撰写，部分技术示例为简化说明，不构成任何接入建议。