APASS：分别识别 Agent、运行实例与责任主体

商家收到两个使用同一 Agent 品牌的请求：一个来自已批准部署，另一个可能是沿用相同名称的修改实例。Logo 或 user-agent 字符串不足以解释区别。APASS 为这类 Agent 商业交互提出了分层身份模型。

核对范围： 2026 年 11 月 1 日查阅官方公开架构，没有访问私有控制台、签发凭证或进行对抗验证。产品安全描述归属于发布方，不作为本站实测结果。

三种身份回答不同问题

APASS 页面区分静态 Agent 身份、运行时身份和责任主体，并介绍持续核验以及颁发方、Agent、验证方之间的凭证流程。它比一个反复使用的“已验证 Agent”标记包含更多层次。

对商家而言，需要分别知道：代表哪套软件、当前是哪一个运行实例、由哪个组织承担责任。一次部署更新，可能只改变其中一个答案。记录应保留这些区别，不能拿过去对组织的认可，代替对所有新实例的判断。

根据 APASS 公开模型绘制的概念解释。“商家执行策略”表示接入责任，不代表某个已部署 API 的实测能力。

凭证是决策依据，不是决定本身

假设某个 Agent 只允许查看库存，不能下单。有效身份凭证可以说明谁在请求，商家仍需判断操作是否超出范围。签名声明也不会自动在另一套支付系统里执行金额限制。

我们建议分别记录身份核验、业务授权和支付检查。若凭证包含授权声明，接收方需要把它映射到即将执行的具体操作。“商业 Agent”这样的宽泛标签，不足以证明可以修改账户资料或发起付款。

持续核验要明确失败时怎么办

APASS 的定位包含持续核身和风险处理。真正需要运营方设计的是：过去通过的实例发生变化、凭证到期、或者验证依赖临时不可用时，系统如何响应。

应在上线前定好规则。只读商品查询与付款指令，对证据新鲜度的要求可能不同。高影响操作不能因为验证器超时就悄悄放行；临时核验失败，也不应抹掉已经完成的订单，或把正常用户直接标成欺诈。

决策边界	评估时需要取得的证据
Agent 注册	身份绑定了什么，谁有权更新
运行实例变化	哪些变化使证据失效或需要重发
凭证出示	如何处理接收方、有效期与重放风险
撤销	接收应用多久得知，在哪一层执行
审计记录	能否还原决定，同时避免过量收集个人信息

这些是采购和工程问题，不意味着公开概览已经逐项给出答案。生产依赖某项控制前，应取得对应技术文档与实际接入条件。

留下有用证据，不必收集所有数据

商家审计记录应能说明证据版本、相关声明、策略决定和最终操作。把完整身份材料或敏感运行数据复制进普通应用日志，可能带来不必要暴露。需要明确客服解释拒绝所需的信息，以及哪些内容只能留在更受限系统。

多方参与时尤其如此：颁发方声明、验证方结果、商家业务决定，应分别能够追溯。一个“可信”布尔值会掩盖谁作出了哪项判断。

APASS 不是 ACT，也不是支付通道

ACT是更广的开放 Agent 商业框架，APASS 是其中的身份与信任基础设施方案；支付宝 Agent Pay则关注用户授权的支付体验。它们解决系统的不同层次，应该分开收录。

评估 Agent 交互如何携带可追责身份与运行证据时，可以研究 APASS。通过资料页进入官方入口，但在把身份核验理解成花钱权限之前，必须补上具体操作的执行控制。