正在加载，请稍候
个人助手代表用户进企业微信改单、查账，凭据谁签发、撤销能撤到多细、动作能不能审计——三条接入路径的差异，以及交付前的六项验收清单。
客户的个人助手进企业微信客服号改了个收货地址，动作执行完才发现订单已经发货。问题不在助手做错了，而在它手里的凭据是三周前签发的长效令牌——撤销要走一次发版窗口，止损只能靠停机。
2026 年 10 月 6 日，Sierra 与 Meta 联合 Genesys、Instinct、Rocket、Shopify、Stripe、Walmart 发布了 Personal Agent Protocol 的公开说明：一个定义个人助手如何与企业交互的开放标准，任何一方都可以实现，认证被放在了第一位。
下面只谈接入与认证层：三条路径的凭据差异，以及做企业微信开发时会撞上的边界。沙箱隔离与提示注入防护是另一层的事，不在这里展开。
官方对现状的描述很直白：今天多数个人助手用网站和 App 的方式干活，加载页面、点击表单；搞不定就打电话或开网页客服。慢，而且常常做不完。直连本可以在几秒内把同一件事安全地完成。
难点是三方的诉求并不一致。原文列得很清楚：消费者要速度、可靠和信任；品牌要可见性与控制权，也就是「知道什么时候有助手在代表客户，并自己决定它能做什么」；做助手的公司要一条直接且一致的对接通道。
协议的原则只有一句：消费者决定给自己的助手什么访问权，企业设定它被允许做什么。落地形态是建立在 OAuth 上的会话——助手从企业官网起步，可以先当访客查库存、问退货政策；需要动账户时，用户在企业页面上登录，或者用已经与助手绑过的凭据。读写权限由用户自己挑，会话跨渠道延续：登录前问的问题和登录后改的订单算同一次访问。
对企业侧来说，这意味着以后进来的请求要能回答「谁授权、谁执行」，而不只是「这个来源有没有权限」。
官方给了三个路由，由企业自己决定开放哪些能力：走企业官网、走企业 API（原文点名 MCP 与 OpenAPI 这类标准），或者走企业自己的智能体。三者的差别不在能不能连上，而在凭据活多久、撤销能撤多细、动作能不能被审计。
| 接入路径 | 凭据形态 | 建议有效期 | 撤销粒度 | 审计留痕 |
|---|---|---|---|---|
| 企业官网（网页会话） | 站点会话 + 授权码换取的短时访问令牌 | 访问令牌 5–15 分钟；刷新令牌绑定单条连接 | 按「用户 × 应用」整条撤销 | 页面级访问日志，动作语义弱，需自己补埋点 |
| 企业 API（MCP / OpenAPI） | 带 scope 的委托授权令牌 | 5–15 分钟，按动作逐次换取 | 按「用户 × 连接器」逐条撤销 | 调用级日志，可记录工具名、参数摘要与返回码 |
| 企业自有智能体 | 会话凭据，实际动作由企业侧执行 | 会话级，任务结束即失效 | 按会话撤销 | 对话记录加后端事件，最完整，但正确性与成本由企业自担 |
表里的取值是我们按企业系统落地经验给的默认值，不是规范原文——v0.1 规范预计在本月内发布，届时以规范为准。给一句判断：凭据生命周期越短、scope 越窄，越权后的爆炸半径就越小；代价是每次动作多一次换取令牌的往返。
企业微信里的请求会同时带三种身份：外部用户、内部账号（员工或客户档案）、以及企业自己的机器人或应用身份。这三层要分开维护映射表，否则「谁授权的」在日志里根本查不出来。自建应用、第三方应用与服务商代开发之间的边界怎么划，这几条工程决策的取舍可以先过一遍再动手。
建议的映射是：外部身份 ID 映射到内部账号 ID，再映射到单次会话的授权记录。动作执行时只用内部账号的权限，不叠加企业应用自身的超级权限——应用只负责转发与签名，不替用户做决定。
IM 消息通道可以自由问答，但不能当交易确认通道：消息会被转发、截图、被自动化程序读取。凡是写操作——改地址、退款、下单、改绑手机号——都要回到会话外确认。
可行的做法有两个：给本人推一张带一次性操作码的卡片，或者跳到企业自己的账户中心做二次授权。无论哪种，确认都要绑定到具体动作和有效期，而不是「这次会话里点过同意」。
地址、手机号、支付信息、工单正文这几类默认不出域。能在企业侧算完的，就不要把原文回灌进助手的上下文；支付可以借鉴协议路线图里的 payments extension 思路——把购买完成，而不把卡号交出去。字段该留在哪一侧，可以对照我们此前整理的数据边界与区域路由，清单结构直接搬过来即可。
审计上把两条线分开：IM 侧只留对话，动作级日志留在业务系统，两者用同一个 correlation id 串起来，否则复盘时对不上。
最常见的失败模式是这样：为了让 IM 里的机器人先跑通，把企业系统的长期 API key 或长效刷新令牌直接塞进助手的凭据库。上线快，代价全在后面。
第一，撤销一次要轮换全部凭据，等于一次停机发布。第二，一个助手被越权，所有租户一起受影响。第三，事故复盘时无法回答「这个动作是哪个用户授的权」，因为所有调用都顶着同一个 key。
改法不复杂，但必须在设计阶段定下来：每个用户、每条连接签发独立短时凭据，撤销精确到连接；同时保留 kill switch，支持按用户、按连接、按 scope 三档关停，并且在演练里真的拉过一次匝。
不必。协议的内核是会话型委托授权加三条路由，用现有的网页授权与 API 授权先做起来，把撤销与审计抽象成独立一层，规范发布后对齐字段即可，改动主要在校验与元数据。
不建议。消息可被转发与自动化读取，写操作应回到会话外的二次确认，并绑定到具体动作与有效期。
访问令牌 5–15 分钟，刷新令牌绑定到「用户 × 连接」并支持逐条撤销。不要用月级长效凭据透传，那是把撤销成本推给未来的自己。
审计最完整，但动作语义比 API 弱，且正确性与成本落到企业自己头上。它适合需要对话的任务，比如保修申请，不适合当唯一路径。
能，前提是审计用统一的 correlation id，否则同一个任务在三条路径上留下的痕迹对不上，复盘等于没有日志。
如果你正在把个人助手接进企业微信或自建 IM，可以先看已交付的企业 IM 集成案例，再带着现有的身份映射与授权流程联系我们做一次接入评审。