最近圈子里聊得最多的除了各类大模型本身的能力迭代就是“AI到底能不能替人把事办了”。之前大家更多在聊模型会不会写代码、会不会做总结但某头部社交平台开源的这份PAPPerson Agent Protocol协议方向不太一样——它盯上的是“个人智能体”和“各类在线服务”之间那层一直没人标准化过的通信方式。我花了两天时间把协议文档啃完又搭了个最小样例跑了一轮今天想把这份协议的来龙去脉、核心设计、安全模型和落地时真正会遇到的问题按我的理解完整讲一遍。这套东西值得谁看如果你在做AI Agent相关的开发、在研究个人数据接口开放、或者正在纠结“怎么让智能体帮我订餐/预约/投诉而不只是聊几句”那PAP很可能就是未来一两年里你绕不开的底座。这篇不是复述官方文档而是结合我自己的实验过程把协议背后的设计逻辑和实操中容易踩的坑一起讲清楚。1. 现在的AI Agent为什么“只会聊天、办不了事”先从一个很朴素的观察说起。大众对“个人助理”的想象是你告诉它去订一家餐厅它自己完成选店、下单、支付然后把结果汇报给你。但实际拿主流智能体试下来绝大多数情况它只能给你列一个餐厅清单或者生成一段话让你自己复制到App里操作。为什么差这么远1.1 智能体知道自己该干什么但它够不到你的服务模型本身不缺“规划能力”。给定明确的任务描述它能拆出子步骤选定餐厅—确认时间—下单—支付—获取凭证。问题出在最后一步它没有任何途径去调用你在外卖平台、银行、政务系统里的账户权限。传统开放平台不是没有对外开放接口而是这些接口是给人用的、也是给开发者用的不是给智能体用的。你在某平台申请一个开发者账号拿到API Key只能调用你自己名下的资源。而个人智能体要替你办事需要的是“以你的身份”去访问那些本来属于你的数据和服务。这中间缺一个“用户授权的、可编程的、可回退的”标准通道。1.2 会话上下文无法跨服务持久化还有一个被很多人忽略的问题就算智能体接上了某个服务的API它怎么记住你和这个服务之间的关系你的常用地址、默认支付方式、偏好窗口期这些数据散落在各个服务的数据库里。传统做法是每个服务自己维护一套用户画像但Agent想要的是在授权前提下、安全地读取并复用这些信息。PAP要解决的恰恰就是这三个缺口身份怎么授权、服务能力怎么暴露、操作状态怎么同步。我举个例子你就能体会。现在你让智能体去查一个月前在医院做的检查报告它可能需要你手动登录医院公众号再翻半天。但如果医院的服务端实现了PAP你的个人智能体只要拿到一次性授权凭证就能按协议标准去查询、下载、转述报告。整个链路里你的账号密码不交给AgentAgent拿到的是一把“时限很短的专用钥匙”。这是PAP和“把所有密码都喂给Agent”最本质的区别。2. PAP核心设计拆解智能体、服务商和数据系统之间怎么对话PAP并不是一个大而全的应用层框架它更像一套“角色分工 消息格式 操作流程”的组合约定。拆开看主要围绕三个参与方和一组核心机制展开。2.1 三个参与方各自只操自己该操的心协议里最核心的参与方有三个用户、个人智能体Person Agent、服务提供方Service Provider。用户是数据的主人也是授权的发起者。个人智能体是替用户跑腿的执行者它不拥有数据但可以在授权范围内读写数据、发起操作。服务提供方则是那些手握用户数据或业务能力的系统比如外卖平台、挂号平台、银行App等。这三者之间最关键的协调点是“授权”。传统模式下用户把账号密码交给AgentPAP的做法是从设计上就杜绝这种“全量交出”的行为——用户只授权特定能力、特定范围、特定时长。2.2 能力声明与发现服务商主动告诉智能体“我能干什么”PAP里有一个很重要的设计叫能力声明。每个支持PAP的服务都要暴露一份机器可读的描述文件说明自己提供了哪些可调用的操作、每个操作需要什么参数、会返回什么结构、需要用户授权哪些权限。这个设计的好处是Agent不再靠硬编码去适配每一个服务。它只要读取能力声明就能自动知道这家医院支持“查询报告”“预约复诊”“取消预约”等操作而不支持“修改诊断结果”。这让智能体具备了一种“即插即用”的扩展能力。我一开始看到这里就想到了一个类比打印机驱动。以前装打印机要装一整套专用驱动后来操作系统通过标准驱动模型接上就能自动识别。PAP的服务能力发现机制本质上就是在给“个人服务生态”制定一套类似的即插即用标准。我按文档写了个最小的能力描述片段大概是这个感觉{ protocol: PAP/1.0, service: hospital.sandbox.example, capabilities: [ { action: report.query, input: {patientId: string, dateRange: object}, output: {reports: array}, permissions: [read:health_report:own] }, { action: appointment.cancel, input: {appointmentId: string}, output: {result: boolean}, permissions: [write:appointment:own] } ] }注意每个操作都显式声明了自己需要的权限项。Agent拿着这个能力清单去请求授权用户只需要勾选“允许查询报告”而不是把整个账号共享出去这是整个协议能够安全运转的基础。2.3 操作执行的端到端链路PAP的操作执行不是简单的“发个请求等结果”。我按规范跑通的最小闭环包含了下面这几个步骤第一步Agent先通过服务发现拿到能力清单。第二步Agent向用户发起授权请求说明要用到哪些权限用户同意后服务方签发一个短期授权凭证。第三步Agent携带这个凭证发起具体操作请求。第四步服务方校验凭证和权限范围校验通过后执行操作并回报执行结果。第五步Agent把结果整理成用户能看懂的语言进行汇报。从协议层面上看它的消息体是一个标准信封里面包含操作标识、参数、权限引用、幂等键、预期回调地址等字段。我实际抓了一次调用链路操作请求大概长这样{ messageId: msg_9f2b7d1c, auth: pap_v1.eyJhbGciOiJFUzI1NiJ9..., action: report.query, args: { patientId: demo_p001, dateRange: {start: 2025-01-01, end: 2025-01-31} }, idempotencyKey: op_7c83fd2a91 }注意我在示例里加了idempotencyKey幂等键。这是PAP里一个容易被低估的机制——它确保同一个操作不会被重复执行两次。你做支付类操作时如果网络超时后客户端自动重试没有幂等键就可能给用户扣两笔钱。有了幂等键服务端就能识别“这跟上一笔是同一个请求”直接返回上次结果而不是再执行一遍。2.4 状态与记忆为什么“操作可恢复”是关键PAP还定义了一套操作状态模型。每个操作在执行过程中会经历已提交、执行中、已完成、已失败、待用户确认等状态。Agent可以在任意时刻查询操作状态也可以基于状态做恢复。这套机制的实际意义有多大我实测中遇到过一种很典型的场景Agent发起预约操作后网络断了收不到回执。如果没有状态模型Agent就不知道预约到底成没成。有了状态模型Agent重连后可以按消息ID去轮询“这个操作目前是什么状态”发现是“已完成”就直接继续后续流程发现是“已提交未执行”就重新触发。我把这一个机制单独拎出来说是因为在真实智能体系统里网络闪断太常见了而绝大多数初版Agent实现根本没考虑过操作的一致性。PAP把状态模型写进协议层等于逼着开发者在第一行代码之前就面对这个经典问题。个人智能体要替用户办事就不能像聊天一样“忘了就忘了”它必须对用户的每一个委托负责任。3. 安全模型与授权机制相比OAuth、无头浏览器方案有什么本质区别安全模型是PAP最能打的部分也是我研究过程中信息密度最高的部分。要理解它最好先看一遍传统路径长什么样。3.1 三种老方案各自的死穴在PAP之前大家想让Agent替自己办事实际用过的无非是这么几条路开放API、无头浏览器模拟操作、浏览器插件辅助点击。开放API的问题是老问题API设计时默认使用者是开发者权限模型不是按“用户个人委托”设计的而且绝大多数生活服务类平台根本没有开放API。无头浏览器这条路最野直接模拟用户在网页上的点击、输入、甚至验证码识别。它的最大问题是极不稳定、风控风险极高、而且一旦出现误操作很难追溯。浏览器插件这条路比无头浏览器好一些但本质上还是“UI自动化”——它依赖页面DOM结构页面一改版就崩。3.2 PAP的授权能力凭证而不是账号密码PAP基于可验证凭证的思路设计了一套授权协议。用户不是把账号共享给Agent而是由服务方签发一个结构化的凭证里面写明被授权者是谁、能调用哪些能力、有效期到什么时候、是否可撤销。我用一个表把这几种方案的关键差异列出来对比维度传统开放API无头浏览器/RPA浏览器插件辅助PAP协议身份证明API Key或OAuth Token账号密码用户在页面上操作短期能力凭证授权粒度通常是全量或静态作用域无控制粒度页面级操作级字段级操作一致性看具体API设计极难保证较难保证协议内置幂等与状态模型页面改版影响无影响致命影响致命影响无影响服务商改造成本高需要额外开发零零中部署协议适配层可撤销性取决于Token策略弱弱强可即时撤销注意最后一行“可撤销性”。PAP里的凭证是支持即时吊销的用户可以在Agent授权管理界面里一键回收权限。这一点很重要你授权Agent去查一次报告用完之后它手里的钥匙就失效了。即便Agent被攻破攻击者能访问到的数据范围也极其有限。3.3 权限范围的细粒度从“我能访问所有”到“我只能做这一件”我在协议里看到权限声明可以精确到资源和操作这比普通OAuth的scope要细得多。某服务声明“读报告”需要的权限是read:health_report:own这个own意味着只能读自己的报告。如果有人试图用一个只包含“读报告”权限的凭证去调“预约”接口服务端会直接拒绝。做安全模型设计的人都知道真正的安全不是建一堵墙而是给每个实体最小够用的能力。这个原则在理论上是业界共识但落到实际系统里极少有平台真正做到因为细粒度授权会带来巨大的设计和管理复杂度。PAP的价值在于把这种复杂度吸收进协议规范里服务商照着实现即可不需要各自拍脑袋发明一套。我实验时最直观的感受是切换权限范围后行为差异非常清晰只授权read类权限的凭证去调write类接口返回403把某个服务的凭证拿去调另一个服务返回401。整个流程里Agent从头到尾没有见过密码也没法越权。3.4 安全边界里还没解决的问题凭证代管与恶意Agent坦白说PAP不是万能安全方案。协议本身假设的前提是服务方是可信的、Agent运行环境是可信的、用户能理解自己授权了什么。这三个假设在现实中都不一定成立。凭证代管是第一个隐患。Agent需要持有多个服务各自签发的凭证这些凭证如果集中存在Agent侧某个文件里那Agent一旦被攻破所有服务的受限凭证都会泄露。协议建议凭证加密存储但“建议”不等于“实现”落到产品里还是得开发者自己兜底。恶意Agent是第二个隐患。如果用户使用的某个Agent本身就是恶意的它可以诱导用户授权一堆相关权限然后在权限范围内做所有坏事。PAP对此的约束是每次授权都尽量短期化、局限化把“被滥用时的损失”压缩到最小。这算是设计上的一个清醒之处——它不假设所有人都是好人而是让好人和坏人的差距尽量缩小。4. 从协议文档到真实落地我跑通最小闭环的全过程看文档是一回事跑起来是另一回事。我照着协议规范在本地搭了一个最小环境目的是验证“从服务发现到操作执行到结果回执”这一整条链路能不能通。这节我完整讲讲实验步骤和遇到的三类坑。4.1 我搭的实验环境与准备工作我用一台闲置的Linux机器装了Python 3.10环境用Docker起了两个容器一个模拟服务提供方本地8001端口一个模拟个人智能体运行环境本地8002端口。服务提供方里实现了一个简化的能力描述接口和操作执行接口逻辑上只做了两件事查一个固定的测试报告取消一个模拟预约。协议栈官方有一个参考实现代码库我直接clone下来用了。整个架构里我没有引入真实数据库全部用内存数据代替以便聚焦协议本身。4.2 最小闭环的实现步骤第一步让服务提供方的能力描述接口上线。我启动容器后访问/pap/capabilities拿到了前面那段JSON格式的能力声明。第二步Agent侧读取这份声明自动生成了一个授权请求页面我这里用命令行模拟用户点击“同意”。第三步服务方签发了一张有效期10分钟的凭证。第四步Agent携带凭证调用report.query操作拿到报告对象。第五步我故意在10分钟后带着同一张过期凭证再次调用服务端返回过期错误。这一步是整个闭环里最有“仪式感”的时刻——它意味着“让Agent替你办事”这件事在技术上已经有一个干净、规范、可审计的通道了。4.3 跑通之后遇到的三类坑第一类坑是发现服务超时。Agent启动时会并发请求多个服务提供方拉取能力声明其中一个服务响应慢整个Agent启动流程就被拖住了。参考实现里没有设置超时上限我后来在客户端加了3秒超时这个坑就再没出现过。第二类坑是权限表达式解析失败。我在写自定义权限表达式时少加了一个字段限定符服务端返回了“权限解析异常”。排查之后发现是权限模型的Schema校验比我想象的严格它要求每个权限都必须显式声明资源归属不能留默认值。这个设计确实别扭但反过来想它也是在逼开发者把权限写清楚。第三类坑是回执乱序。我在测试并发取消多个预约时服务端返回的回执顺序和请求顺序不一致。Agent侧如果直接按顺序处理回执就会把“取消A预约的结果”错误匹配到“取消B预约”上。解决方案是基于消息ID做结果关联而不是顺序关联——这一点也是协议里明确建议过的。这几个问题都不难解决但它们提醒了我一个很实在的事协议文档写得再完善真正服务于业务时网络抖动、并发乱序、边界条件这些老问题一个都不会少。协议解决的是“标准缺失”的问题无法替你解决“工程质量”的问题。4.4 如果企业想接PAP我的落地建议按照我现在做技术选型的习惯如果一个平台要接入PAP我会建议分三步走。第一步评估现有系统的权限模型。PAP要求“操作级权限”和“字段级权限”如果现有系统的权限模型还是“登录后全都能看”那接入成本会很高。第二步做一个协议适配层。不需要把整个核心系统改成PAP格式只需要在网关层做翻译把PAP请求翻译成内部服务调用再把内部结果翻译成PAP标准回执。第三步灰度发布。先接一个低频、低风险的服务比如查询类跑通稳定后再接写操作类比如预约、取消最后再接支付类。“适配层”是我特别想强调的一个点。很多团队担心接新协议要动核心系统其实完全不必。PAP协议本身是外部的“统一语言”你只要在边界处找一个“翻译官”核心系统的内部逻辑可以保持原样。这个思路能大大降低接入门槛和试点风险。5. 关于PAP生态的未来我倾向于保持谨慎的乐观协议本身设计得比较优雅但一个协议能不能成最终看的不是设计得好不好而是有没有足够多的“供需双方”愿意接它。这一节我想聊几个更宏观的判断。5.1 从“模型能力竞赛”到“服务生态竞赛”过去两年业界焦点都在模型本身谁的模型参数多、推理强谁就有话语权。但PAP这类协议把焦点拉到了“执行层”——模型再强如果没有服务愿意让你调用那也只能停留在“会说话”的阶段。所以我看好PAP的第一步是它会先在一些特定垂直领域落地比如医疗预约、政务办事、银行客服这些“流程固定、操作标准化、合规敏感”的场景。这些领域受互联网平台“封闭生态”影响较小反而更容易用标准协议打通。5.2 开放协议与封闭生态的博弈没有结束也要泼一盆冷水。PAP能不能做大取决于有多少大型平台愿意把自己内部的服务能力暴露出来。大型平台天然倾向于建立封闭生态因为封闭生态可以形成数据壁垒和用户锁定。如果头部平台选择不支持PAP那PAP就只能在小范围内自嗨。当然协议还处于规范早期真正的巨头态度还看不清楚。但我个人的判断是最终形态大概率是“标准协议与封闭生态共存”——大平台自建Agent入口小平台接入PAP寻找增量入口。5.3 如果想深入研究我的建议我在研究PAP时做的第一件事是把官方规范通读一遍然后立刻跑一个最小Demo不做过多设计、不加复杂权限先把链路跑通。跑通之后再回过来研究细粒度授权、幂等、状态恢复这些机制——这时你会真正理解这些设计是为了解决什么问题。第二件事是关注协议的版本演进。PAP目前还存在一些未定义的边界情况比如说跨服务的复合操作如何做事务回滚多凭证的联合授权如何管理这些大概率会在后续版本里补上。如果你打算在生产环境引入建议盯紧版本变更记录。第三件事是把安全和合规交给专门的同事去审。协议标准和技术实现是对开发者的要求但用户授权流程的话术、凭证存储的合规性、敏感数据的最小化收集这些是另一套专业领域的问题技术再安全也替代不了制度层面的把关。我在自己的实验里最深的一点体会是PAP没有试图去造一个全新的技术栈而是把分布式系统里一系列成熟的老办法——幂等、状态机、可验证凭证、细粒度权限——用一份协议串成了适合“个人智能体办事”的标准链路。这种“不制造新概念、只重新集成”的做法反而是它最难得的地方。个人智能体的时代大概率会来而PAP这张基础设施图纸值得每个做Agent方向的人提前读一读。
