最近几天圈子里都在聊 PPA 吗错了是 PAP——Person Agent Protocol。某头部科技公司最新公开的这一套协议名字比那三个字母有意思的地方在于它想规范的并不是模型怎么干活而是一个代表你的智能体跟另一个智能体打交道时到底按什么规矩来说话、报身份、传递意图、使用你的数据。用大白话讲PAP 是关于人-代理-代理之间社交礼仪和事务流程的技术标准。它能解决的问题很具体现在每个人的手机里可能同时住着日程助手、购物助手、出行助手、订餐助手可这些助手都来自不同平台彼此既不敢完全信对方也听不懂对方说的用户偏好是什么意思。PAP 就是给这套混乱的协作场景补上的一张通用棋盘——定义 Person Card人卡、意图票Intention Ticket、上下文租约Context Window Lease、信任评分等一整套机制。这篇文章适合两类人看一类是做 AI 应用、正在把智能体接到真实业务里的开发者另一类是整天在琢磨智能体到底怎么落地的产品经理。我会从协议为什么会出现开始把核心设计拆开再带大家走一遍完整的交互流程最后聊一聊实际落地时大概率会踩到哪些坑。文章不会把 PAP 讲成学术论文而是尽量按工程可复现的方式说清楚。1. 先想明白一个前置问题为什么现在需要一套人的代理协议1.1 智能体数量爆发之后的协作乱象前几天我在群里看到有人吐槽他让出行助手订一张机票出行助手转手去问购物助手用户喜欢哪个航空公司购物助手又去问日程助手用户下周三方便几点出发三个代理各自为政拉了三个会话窗口最后谁也没得到完整答案还差点把一张里程票重复订了两遍。这不是段子是目前智能体应用的真实缩影。问题出在每一个代理都站在自己的垂直领域里做事却缺少一套通用的、描述用户这个人的元语言。它们各自知道用户某一部分信息却没法在跨代理协作时安全地交换这部分信息。各家都有自己的私有上下文A 家助手知道用户偏爱靠窗座B 家助手知道用户对价格敏感这两条知识放在一起本来能产生有效的出行方案但它们之间没有标准协议只能靠自然语言对话互相问一对话就开始产生歧义。PAP 的出现本质上是在回答一个很朴素的工程问题两个分别由不同机构训练的智能体凭什么信任对方凭什么理解对方凭什么敢把自己主人的数据交给对方1.2 PAP 要解决的三个核心矛盾我把 PAP 试图化解的矛盾归结成三组。第一组是表达矛盾。用户说帮我安排一个不太贵的周末行程这是个模糊意图。模糊意图直接丢给代理去猜猜错的概率很高。PAP 要求把模糊意图转成结构化的意图票预算上限是多少、时间窗口是什么、可接受的交通方式有哪些、可替代项是什么。结构化之后代理与代理之间的沟通就从猜谜变成对表。第二组是信任矛盾。代理代表用户办事对方怎么知道这个代理真的获得了用户授权代理拿出一个用户的口头确认截图那根本不具备可验证性。PAP 的做法是给每个代理发一张可验证的身份卡背后有签名机制用户对某个任务的授权也以加密凭证形式存在随时可查验、可吊销。第三组是边界矛盾。代理合作过程中一定会涉及个人数据交换但哪些字段能传、哪些字段绝不能传、传出去的数据什么时候必须删掉这些边界在过去完全靠各家自觉。PAP 用上下文租约和最小字段集把边界变成协议约束而不是道德约束。打个类比过去两个系统做对接是直接互相暴露数据库接口等于把家里门钥匙交出去PAP 要求的则是一套外交礼仪——双方先递名片、说明自己能干什么、划定权限范围再在限定的会客厅里谈具体业务谈完立刻各自离开。1.3 PAP 跟现有各种 Agent 工具调用协议有什么不同很多人一听到Agent 协议就以为又是某种工具调用规范。这里要厘清一个关键区别现有大多数智能体领域协议解决的是代理如何调用外部工具/API重点在工具描述、参数校验、返回值格式。PAP 的起点更高一层它解决的是代理如何代表一个自然人与其他代理进行身份验证、意图协商、授权委托和数据交换。换句话说前者是命令通道后者是身份与外交框架。PAP 完全可以承载对工具调用的协商但它不是简单地在工具之上加一层壳而是把谁在做、代表谁做、做到什么程度、做完之后数据怎么办这四个问题全部纳入规范。2. 拆解 PAP 的核心设计2.1 Person Card一张属于数字人格的身份证PAP 协议里最基础的数据结构是 Person Card人卡。它相当于代理持有的数字身份证对外声明我代表的是一个什么样的自然人、我有哪些公开偏好、我的数据权限声明是什么。一张典型 Person Card 由四块构成Profile 块公开身份信息包括 Person ID一个人在不同平台间的统一标识、显示名、语言偏好、时区。Permissions 块当前持有的授权列表每一条包含授权范围、生效时间、过期时间、吊销状态。State 块代理当前可对外暴露的状态快照比如会议中差旅中勿扰不包含敏感隐私。Contact 块代理的受理范围描述比如可处理票务类事务可处理日程类事务同时标明服务等级。下面给一个简化的 Person Card JSON 示例方便理解它的数据结构{ protocol: PAP, version: 0.9, person_card: { person_id: did:example:u-8f1a2b, profile: { display_name: alice, locale: zh-CN, timezone: Asia/Shanghai }, state: { availability: busy, busy_until: 2025-06-20T18:00:0008:00 }, permissions: [ { scope: purchase.flight.ticket, granted_at: 2025-06-20T09:00:0008:00, expires_at: 2025-06-20T23:59:5908:00, revoked: false } ], contact: { accepts: [travel.booking, expense.report], service_level: instant } } }注意 Person ID 用的是可验证标识体系而不是普通 UUID原因很简单Person Card 要被其他代理查验真伪必须能够签验证链。普通 ID 只是名字可验证标识才是名字证明。在设计 Person Card 时最大的隐性原则是永远不要把私密字段放进默认展示位。它对外展示的所有信息都应当是可以被陌生人看到也不构成风险的。真正的敏感数据只能在后面说到的意图票上下文租约流程里按最小必要原则临时释放。2.2 意图票把我想要变成机器可协商的提案如果说 Person Card 是身份层意图票Intention Ticket就是业务语义层的核心。PAP 不要求代理之间用自然语言互相猜需求而是要求发起方生成一张结构化的意图票里面写清楚目标、约束、优先级和弹性空间。一张意图票包含目标描述机器可读的任务类型例如hotel.booking、flight.reschedule。硬约束必须满足的条件例如入住日期6月25日离会议地点距离2公里。软约束优先级排序的偏好例如价格800元权重高有无障碍通道权重中含早餐权重低。弹性与替代方案当无解时允许的降级路径例如如果 2 公里内无房可接受 5 公里内接驳车。有效时限这张票在多少秒内有效过期作废。为什么要设计成票而不是一上来就互相发请求因为票是有生命周期、有协商历史、可流转的实体。代理 A 把票发给代理 B 后B 可以基于票上的约束返回候选方案如果没有完全符合的方案B 可以返回部分满足的建议由 A 侧的决策模块判断是否接受降级。整张票的每次改动都会记录版本号防止两个代理同时修改导致状态混乱。这里有一个细节很值得学意图票里的软约束不要写死成单一阈值而是写成带权重的评分项。比如价格不是简单地必须低于 800而是价格越低越好800 为可接受上限。这样对方代理在返回结果时可以附带一个匹配度评分A 侧就能按照用户的历史偏好做综合排序而不是拿一个布尔值做行不行判断。2.3 上下文租约让临时数据长着倒计时的生命代理协作必然要交换上下文比如订酒店总得告诉对方出差地点和时间范围。PAP 对上下文交换做了极其严格的限制——核心机制叫上下文租约Context Window Lease。我把它理解为临时借阅证。代理 B 想要读取代理 A 持有一段用户上下文必须先申请租约租约里写明要读哪些字段、用途是什么、最长持有多久。默认租约时长只有 30 秒到期自动失效如果任务处理需要更多时间必须发起续租每一次续租都会同步推送给用户侧的可信节点。这个机制背后有一个很容易被忽视的工程理由让数据自然腐烂比让数据到期销毁更加可靠。如果设计成永久存储事后删除一旦删除逻辑出 bug数据就永久留在对方服务器里如果设计成默认短租、频繁续租即使某一次续租逻辑被绕过数据也会因为过期而失去效用。就好比借书证每 30 秒要重新刷一次那就算有人偷了借书证也看不了几分钟损失是可控的。协议层还规定上下文快照的体积上限默认是 64KB超过这个上限的交换必须走异步分片通道防止握手阶段就被一个超大上下文卡死。敏感字段在租约申请里必须显式列出未列出的字段不允许被读取这从协议层堵住了顺手牵羊的可能性。2.4 为什么采用分层协议栈而不是只用一个 JSON 结构PAP 把整体设计分成了五层链路层负责传输、连接建立、心跳检测。支持多种底层通道比如 WebSocket、加密消息队列。身份层处理 Person Card 的验证、签名链校验、信任评分更新。语义层处理意图票的定义、协商、评分、降级。策略层处理权限检查、授权发放、数据最小化策略。审计层记录每次交换的操作摘要、时间戳、签名供事后追责。分层的好处是在实际落地时可以把某一段换掉而不影响其他段。比如你对语义协商有特殊需求可以替换语义层的实现身份层和策略层还能照常工作。这和当年 TCP/IP 协议栈的出发点一模一样——不让每一层都绑定死在同一套实现里。很多人在设计 Agent 间协议时喜欢一个大 JSON 包打天下初期很爽一旦要加权限控制、要调整协商策略就得把整个数据结构推翻重来。PAP 的分层设计本质上是在为协议的长生命周期做铺垫。3. 安全与隐私设计PAP 真正难啃的地方3.1 最低权限与逐次授权机制智能体时代的权限控制比传统 App 时代更难。传统 App 是在安装时向用户列一个静态权限清单用户点同意基本就永久授权了。但 PAP 的授权模型是意图绑定授权所有权限都挂在一张意图票下面意图票过期权限随之失效。我用一个例子说明区别。传统模型里用户给助手授权可以读取日历助手就能一直读日历直到用户手动收回PAP 模型里用户给日程助手下达安排下周三的会议这个意图票日程助手只能在处理这一单任务期间读取相关时间段的日历数据这单任务完成后读取权限立刻失效。下次用户再下达另一个任务需要重新生成新的授权。系统里存在三种授权粒度PAP 明确选择第三种授权类型特点风险全量长期授权一次授权长期有效泄漏后影响面失控会话级授权一次会话内有效会话内无边界代理可越权意图绑定授权按单个意图、单次任务、最小字段授权控制粒度最精细可审计性强实际操作时意图绑定授权会产生一个明显的 UX 代价用户可能在一个忙碌上午收到七八条授权确认弹窗。PAP 的折中方案是可信任代理快速通道对于信任评分高且历史交易记录良好的代理允许它发起一次批量意图授权一次确认内含 3~5 个子任务但每个子任务仍然单独计算权限边界并留痕。3.2 身份证明怎么防止代理冒充人类用户代理最大的安全漏洞是冒充。如果任何一个程序都能声称自己是Alice 的代理那整个信任体系就崩塌了。PAP 的做法是双重绑定第一重用户公钥签名。Alice 创建自己的代理时用私人密钥为代理的 Person Card 签名。其他代理验证时只需要验签就能确认这张 Person Card 确实由 Alice 本人背书。第二重代理私钥证明。代理持有与 Person Card 公钥对应的私钥在每次消息交互里使用短期会话密钥签名。这样即使别人复制了 Person Card 的 JSON也无法伪装成代理发消息因为对方没有私钥。信任评分是另一道补充防线。PAP 定义了一个轻量评分机制每次代理间交互完成后双方可以提交评价评价受密码学保护不可篡改。履约率高、按时释放上下文、从未触发吊销事件的代理信任评分逐步增长反之评分下降后其他代理可以选择拒绝高风险协作或者要求额外的保证金。这个机制和电商信用分很像只是在小规模代理网络里它可以依靠自动算法快速更新而不是靠人工打星。3.3 吊销、遗忘与数据最小化的实操细节数据要能发出去更要能撤回。PAP 规定代理间的授权和上下文租约都必须支持吊销令牌。用户侧只要一键吊销相关令牌会同步到一个分布式状态同步网目标代理下一次交互校验时就能立刻得知。理想情况下全网同步时间不超过 30 分钟在实践中多数实现能压到 1 分钟内。还有一个很容易被忽略的点是数据字段最小化。PAP 协议建议发送方在组织消息体时主动裁剪字段只发执行当前任务必需的字段。比如订酒店时接收方代理完全不需要知道用户的身份证号只需要一个脱敏的乘客 ID 和出生日期订餐时接收方不需要知道用户的家庭住址只需要送达范围的网格坐标。这个裁剪动作不是靠底层传输脱敏完成的而是在协议语义层由发送方的策略引擎强制执行防止内部员工绕过协议直接拉取原始字段。我在实际推演中发现很多开发团队一开始对最小字段集非常抵触觉得反正用户授权过了多传一个字段怎么了。可一旦你的代理接入生态面对的是几十个风格各异的第三方代理任何一个代理的数据集一旦被拖库所有曾经传过完整字段的代理用户全部遭殃。协议把最小化变成强约束之后等于帮整个生态降低了数据集中泄漏的爆炸半径。4. 实操推演完整走一遍 PAP 交互流程4.1 场景设定与会话角色假设这样一个微场景某公司在某城市办线下技术交流会员工的日程代理 P1 要帮主人预订一家离会场近、预算 1200 元以内、允许携带宠物的酒店。P1 发现主人所在协作平台上有一个第三方酒店预订代理 P2于是触发 PAP 协议交互。这里涉及三类角色用户主人合法自然人持有数字身份公钥。主代理 P1代表用户发起意图守护用户隐私。外部代理 P2酒店预订服务方可提供房态与价格但必须通过验证才能接收用户偏好。4.2 握手与能力发现P1 向 P2 发送握手请求。P2 返回自己的 Person Card 和能力列表。P1 先做三件事验证 P2 的 Person Card 签名是否有效、是否在吊销列表里。查看 P2 的能力列表里是否包含hotel.booking。检查 P2 的信任评分是否高于阈值。完成这些之后P1 才会继续后续流程。这一步做得好后面省掉的扯皮非常多。我见过不少团队为了省一次往返把握手和意图提交合并到一个请求里结果遇到坏代理时用户的敏感偏好已经提前泄露出去了。正确顺序一定是先验证、再交互。4.3 生成意图票并完成多轮协商P1 根据用户指令生成意图票关键字段大致如下{ intent_id: intent-a9c021, type: hotel.booking, hard_constraints: { check_in: 2025-06-24, check_out: 2025-06-26, max_distance_from_venue_m: 2000, pets_allowed: true }, soft_constraints: { price_per_night: { target: 800, max: 1200, weight: 0.5 }, breakfast_included: { target: true, weight: 0.2 }, quiet_floor: { target: true, weight: 0.1 } }, fallback: { allow_upgrade: true, max_upgrade_budget: 1300 }, expires_at: 2025-06-20T18:00:0008:00 }P2 收到意图票后并不立刻返回最终结果而是返回候选房源清单以及每个候选的评分明细。P1 侧的经济决策模块会按用户历史偏好做二次排序——比如用户历史订单显示他更看重含早餐而不是安静楼层那么权重的微调就应该体现出来。协商过程可能不止一轮。如果预算 800 元以内的房源距离都超过 2 公里P2 会返回一个部分满足建议推荐距离 2.5 公里、价格 750 元但含早餐的酒店。P1 检测到该建议落在意图票的 fallback 逻辑范围内可以自行决策接受不必再去打扰用户。在这个环节里PAP 的优势体现得特别明显因为所有约束都结构化协商的每一轮变动都能准确记录。如果 A 侧代理临时改了一个软约束权重下次协商可以直接在当前票版本上打补丁而不是重新生成一整张票。4.4 授权执行、支付与上下文回收协商完成后P1 向 P2 发放一个一次性授权令牌。令牌绑定三样东西特定房源 ID特定金额上限不超过 1200 元/晚特定过期时间比如 10 分钟后P2 使用该令牌完成预订动作。这里需要注意真正的支付动作不应发生在 P1 和 P2 之间而是由 P1 向用户的金融侧服务发起支付确认P2 只需要拿到支付成功的回执。这样设计可以避免外部代理直接接触用户的支付密码和银行卡信息。预订完成后双方执行会话回收流程P1 向 P2 发送session_close请求。P2 停止读取任何与本次意图票相关的上下文数据。所有上下文租约到期或主动释放。双方在审计层写入一条摘要记录包括意图票 ID、授权令牌 ID、操作结果、时间戳。整条流程从握手到回收如果按标准实现走往返次数大概在 12~20 次之间。对于需要低延迟的场景协议还允许乐观执行在信任评分较高的代理之间P2 可以先返回候选方案P1 同时异步核对 P2 的身份把握手延迟和业务延迟重叠起来。但乐观执行的代价是遇到伪造代理时会造成一次无效数据交换所以默认是关闭的需要显式开启。5. 落地中常见的坑与排查建议5.1 沙箱里一切正常上生产就握手失败很多开发团队在测试环境模拟 PAP 交互时全部通过一接入真实网络就出现大量握手失败。我排查过几次原因集中在这几个地方证书链不完整测试环境用的自签名证书生产环境换成正式证书后中间证书没有正确传递导致对端验签失败。时间戳偏差PAP 消息里都带时间戳超过 300 秒偏差就会被拒绝。一些业务服务器时钟同步不到位就会出现间歇性握手失败。消息体超过 MTU前面提到默认上下文快照上限 64KB但有些实现没有做分片就硬塞在复杂网络环境下容易丢失。排查建议很简单先在代理节点上配置详细协议日志把握手阶段每一步的校验结果打出来。绝大多数问题在日志里一眼就能看到不需要猜。5.2 用户口头同意被当成永久授权在设计授权流程时最容易犯的一个错误是用户跟主代理说过一次允许主代理就把这个允许当成长期通行证。PAP 要求所有授权都必须绑定意图票每张意图票必须有明确的过期时间。我在模拟项目里遇到过这种情况主代理 A 同事先帮用户订过酒店后来酒店权益变更外部代理 B 自动发起续订请求A 直接拿上次的授权来用。从产品视角看A 确实在执行用户的常订这家酒店意愿但协议层面这严重违规。正确做法是主代理 A 检测到用户历史意图里有常订这家的偏好于是重新生成一张新的意图票并让用户快速确认确认后再发起新的授权而不是复用旧授权。用户确实会觉得多一步操作有点烦但这一步是防止代理自作主张的最后防线。5.3 多代理同时操作导致状态覆盖多个代理同时代表用户处理不同事务时可能发生状态冲突。最典型的是两个代理同时改日历一个代理往下午 2 点插了一个会议另一个代理把原来的会议改成 3 点最后后提交的覆盖了先提交的用户两边信息都对不上。PAP 的解决思路是给每个可写状态加版本号写入时必须携带期望版本号对不上就冲突失败。实践中还要在冲突失败后触发合并协商流程由主代理汇总冲突项向用户展示不同代理的申请让用户决定优先级。真正困难的不是实现乐观锁而是设计冲突提示的交互——既要足够显眼让用户知情又不能频繁打断用户把所有决策都推给用户。5.4 想一步到位反而把自己卡死还有一类问题属于建设层面的团队一开始就想把 PAP 五层完整实现结果反复盘旋在身份层和策略层的细节里业务迟迟没跑起来。以我个人的经验落地速度更快的路径是三层起步先把链路层和身份层的必要验证做扎实语义层用一张简化的意图票跑通一个最小场景策略层采用最笨但最有效的每次任务弹确认方案跑通后再迭代。不要追求一开始就做到前置自动授权复杂评分体系那会把你拖死在权限设计的泥潭里。协议设计者的初心是分层解耦落到工程上天然就适合渐进式实施。6. 影响范围与下一步推演6.1 对普通用户从一个 App 一个账号到一个 Person 一个代理网络过去十年用户的数字化身份被切成碎片——购物平台账号、出行平台账号、社交平台账号各管一摊。PAP 这类协议一旦普及用户会逐渐意识到真正值钱的不是各家平台里的积分和会员等级而是一份统一的 Person Card 和几页可追溯的授权记录。你跳槽换平台时代理身份可以迁移历史偏好和执行记录可以打包带走。这会在用户侧产生一个心理上的拐点账号不再属于 App而是属于自己。当然这也带来了新问题用户需要开始管理授权疲劳。如果一个早晨弹出 20 次授权确认再安全的机制也会被用户当作弹窗广告一样划掉。所以短期内产品层面一定会出现代理信任分级和批量授权模板用经过充分验证的默认设置去降低用户的交互负担。6.2 对开发者与平台方应用入口从 UI 转向可被代理读懂的服务以前做一款酒店预订应用核心是把界面做好看。以后接入 PAP 生态的应用核心工程变成了服务描述你的服务该以什么样的数据结构暴露给代理能力边界怎么定义价格和库存怎么在协议层同步不可否认这会倒逼平台重构产品架构。我判断未来会出现一个新的岗位职能——代理交互设计师专门负责设计意图票的 schema、协商逻辑的评分函数、错误处理与降级路径。因为协议层的服务质量会直接影响代理是否愿意把你的服务推荐给主人。如果你的服务在意图协商过程中动辄返回无解也不会给出部分满足的候选建议用户主代理的排序算法很快就把你降权了。6.3 对中介商业模式流量会被重新分配一次传统互联网的商业模式建立在用户在页面上停留、点击、下单。PAP 生态里大量消费决策由代理在后台替用户完成用户看不到列表页也感受不到 App 的品牌氛围。这听起来对广告和推荐引擎是坏事但从另一个角度看价格、服务质量、履约能力的权重会被放大。过去靠品牌溢价的平台未来可能需要靠结构化数据质量和响应速度来赢单。中介之间还会出现新的博弈主代理握有用户的历史偏好和预算信息它会更愿意把任务分给数据配合度高、权限消耗少的服务代理。这会让一些平台被迫修改强制注册才能预订的产品流程否则代理根本无法代表用户完成任务。长期来看谁能设计出既保护用户隐私、又方便代理高效完成任务的接口谁就能在新一轮生态里占据身位。最后说点个人体会如果你问我 PAP 最有价值的地方是什么我的回答可能和很多人不一样不是身份验证多安全不是意图协商多智能而是它把智能体之间应该如何相处从一个纯逻辑问题变成了一个可以被实测、被审计、被迭代的工程规范。代码里的签名链和租约机制比任何一句我们尊重用户隐私都可靠。我在自己的模拟项目里第一次把两个异构代理通过 PAP 协议跑通时最深刻的感受是工作量比想象中大得多。协议文档只规定了消息结构和状态机实际要填的坑全是工程细节信任评分怎么初始化、吊销令牌怎么在高并发下保证一致性、意图票协商失败时怎么优雅降级。光是把这些边缘情况处理完就占了我大约七成的时间。给准备上车的团队一个建议不要先在线上铺大场景先找一个像订酒店这样边界清晰、授权链短的任务写好意图票 schema跑通一两个真实代理再慢慢扩容。协议不会替你解决所有问题但它给你提供了一个把问题一件件解决掉的框架。