当AI_Agent出门需要身份证

摘要

当AI Agent从一个聊天窗口"走"进另一个系统，它如何证明"我是谁""我代表谁行动""我可以做什么"？在2025至2026年的AI浪潮中，以Anthropic Claude、OpenAI Operator为代表的自主Agent已经开始联网执行真实任务，但Agent之间的信任缺口被急剧放大。没有中心平台背书时，机器与机器互不相认。去中心化身份DID原本是为人类设计的W3C标准，如今正被注入AI生态——从自托管密钥到链上可验证声誉，从ERC-8004标准到Visa/Mastercard的Agent支付认证。本文将拆解DID的密码学架构、四种AI Agent身份落地模式、以太坊基金会dAI团队的最新推进，以及赛道上的工程挑战，为开发者与观察者提供完整的技术图谱。

一、场景：你的订票Agent认识我的理财Agent吗？

设想这样一个场景：你用OpenAI Operator（2025年1月发布的网页操作式自主Agent）输入一句指令——"帮我订下周末去杭州的高铁票，如果二等座没了就改一等座，同时让家里的理财Agent检查一下预算是否足够"。

Operator开始行动。它打开铁路12306页面模拟操作，然后需要与你的"家庭理财Agent"通信，查询本月可支配旅行预算。问题来了——理财Agent如何确认：眼前这个突然发请求的程序，是不是真的是你授权的订票助手，而不是某个伪造的请求？

这个场景里存在三个身份验证层次：

• 第一层：订票Agent需要证明"我代表用户X在行动"
• 第二层：理财Agent需要确认"请求来自一个经过认证的程序实体"
• 第三层：两个Agent之间需要建立一次性的会话信任，且不能依赖任何单一平台的背书

人类世界中，这通常由OAuth 2.0、OpenID Connect或CA机构签发的数字证书解决——平台A向平台B出示一张由Google/Facebook/银行签名的授权令牌，平台B选择信任Google，于是代理行为成立。但在AI Agent的开放生态中，没有B计划里那个"平台B天然信任Google"的假设。Agent来自不同厂商、运行在不同基础设施、甚至部署在用户本地，谁的背书才算数？

这就是自主AI Agent的身份基础设施危机。全球AI Agent数量在2025-2026年迎来爆发式增长，但Agent与Agent之间交换的不是API Key，而是意图、权限和声誉——这些都需要一种去中心化、密码学可验证的身份协议来支撑。

去中心化身份（DID）恰好提供了这样的工具箱。它最初在2019-2022年由W3C标准化，核心理念是"每个实体自己控制自己的身份标识"，不依赖中心化注册表。现在，这个人类互联网的身份自救方案，正被移植到AI Agent世界。

二、DID的密码学内核：不依赖任何平台的"自我证明"

要理解DID为何适用于AI Agent，需要先拆解其底层机制。

2.1 W3C DID标准的诞生背景

DID（Decentralized Identifiers）标准由W3C于2019年开始制定，2022年7月发布为正式推荐标准（W3C DID Core 1.0）。它旨在解决一个根本矛盾：互联网上的身份几乎完全由平台控制——你的微信ID属于腾讯，你的Google邮箱身份属于Alphabet，你的银行账户身份依赖开户行。一旦平台撤销账户，数字身份随之消失。

W3C提出的方案中，DID是一段由实体自行生成的URI格式标识符，形式如 did:ethr:0x123... 或 did:pkh:0xabc... 。关键特性在于：

• 去中心化解析：DID不依赖DNS、ICANN或任何中心化注册表，其解析路径可指向区块链、分布式存储（如IPFS）或本地P2P网络
• 自控制私钥：DID的控制者持有私钥，对应DID文档（DID Document）中记录的公钥，密码学上自证身份
• 可验证凭证（VC）绑定：VC是W3C另一项标准（可验证凭证数据模型，2019年发布），由可信第三方（如政府、大学、银行）签名并关联到某个DID，实现"声明的可验证传递"

2.2 DID文档与可验证凭证的协作

每个DID背后都有一份DID文档，通常是JSON-LD格式的数据对象，包含：

• 公钥列表（用于签名验签的密码学材料）
• 服务端点（如通信地址、数据查询端点）
• 身份认证方法（如椭圆曲线密钥对、多重签名策略）
• 授权委托关系（如这个DID可以代表另一个DID行使某些权利）

以下Mermaid图展示了DID与VC之间的标准交互流程——一个VC持有者向验证方出示经过密码学签名的凭证，验证方通过DID解析器获取公钥并完成验签，全程不经过任何中心化身份提供商。

flowchart TD
    subgraph Holder["&#128037; DID持有者<br/>(可以是AI Agent)"]
        DID["DID: did:ethr:0x123..."]
        SK["私钥(本地安全存储)"]
        VC["可验证凭证(由大学/政府/机构签名)"]
    end
    subgraph Issuer["&#127970; 凭证签发方"]
        IssuerKey["签发方私钥"] --> SignedVC["签名后的VC"]
    end
    subgraph Verifier["&#128274; 验证方<br/>(另一个AI Agent或协议)"]
        Resolver["DID解析器<br/>(查询链上/分布式DID文档)"]
        PubKey["获取公钥<br/>(从DID文档提取)"]
        Verify["密码学验签<br/>(验证VC签名有效性)"]
    end
    DID --> Resolver
    IssuerKey -."签发时" .-> SignedVC
    SK --> DID
    Holder -->|"出示VC"| Verify
    Resolver -->|"返回DID文档+公钥"| PubKey
    PubKey --> Verify
    SignedVC -."VC内含签发方DID".-> Resolver
    style Holder fill:#1a1a2e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style Issuer fill:#202038,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style Verifier fill:#16213e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style VC fill:#e94560,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style SignedVC fill:#e94560,stroke:#4a9eff,stroke-width:2px,color:#ffffff

图1：DID+可验证凭证的标准验签流程

这张图的典型流转如下：某大学向毕业生（或毕业生代表的AI Agent）签发一张"本科毕业"VC，使用大学自己的DID签名。当Agent求职或申请服务时，向某平台出示这张VC。平台并不直接信任"这个Agent"，但通过DID解析器查询链上的大学DID文档，获取大学公钥，再用该公钥验证VC数字签名的有效性。一旦验签通过，平台就间接信任了这张凭证的内容。整个过程中，没有中心化OAuth网关，没有CA证书链，只有密码学验证。

2.3 核心优势：跨域、密码学原生、可组合

DID方案对AI Agent身份场景有三项天然优势：

其中"可组合性"对AI Agent尤其重要。一个Agent可以持有多个VC——"这是我的制造商认证""这是用户X的授权委托""这是过去100笔成功交易的声誉证明"——验证方可以根据业务逻辑组合检验这些凭证的交集。这种"凭证组合"在链上智能合约中可以被程序化验证，这是传统OAuth令牌难以实现的。

三、Agent身份危机：为什么传统方案不够用了

DID标准早已存在，但直到2025年AI Agent爆发后才真正获得紧迫的应用场景。理解这种紧迫性，需要看清传统身份协议在Agent世界里的"水土不服"。

3.1 传统方案的四种 Agent 支付/认证模式

2026年的主流Agent身份验证领域，实际形成了四条并行路线（来源：多个行业报告于2026年初整理的分类，包括Mastercard、Visa、Google/Apple的公开技术文档）：

这四条路线并非互相取代，而是针对不同场景的分层。银行和电商会优先采用Mastercard/Visa方案，因为清算网络已是基础设施。但在开发者生态、开源社区、链上协议场景中，DID方案正快速获得关注。

3.2 传统方案的三大瓶颈

瓶颈一：平台锁定。如果一个Agent的身份完全由Mastercard系统或Google账户定义，它就无法与一个运行在中国银行体系或以太坊Layer 2上的Agent直接建立信任。Agent的身份变成了平台的附属品，而非独立实体。

瓶颈二：缺乏机器可验证的声誉。人类用户的身份验证聚焦于"你是谁"（认证）和"你有没有权利做这件事"（授权）。但Agent场景增加了第三维——"你过去做得怎么样"（声誉）。一个订票Agent的可靠性，可能取决于它过去100次出票的准时记录、用户评分、退款处理记录。传统系统缺乏将这类声誉数据以密码学可验证方式跨系统传递的标准格式。DID+VC天然支持"可验证声誉凭证"的签发与组合。

瓶颈三：审计与合规悖论。金融机构的KYC（了解你的客户）要求越来越严格。当Agent代理人类执行操作时，"谁对决策负责"成为法律和合规难题。传统方案中，Agent只是用户的代理人，法律主体仍然是人类。但DID方案提供了更精细的权限委托链：用户DID可以签发一个限定范围的VC给Agent-DID，明确"这个Agent只能支付不超过¥5000的差旅费用"——这条规则可以编码在VC里，也可以编码在链上智能合约中自动执行。这种"可编程委托"是传统OAuth范围（scope）机制的延伸，粒度更细且可审计。

flowchart LR
    subgraph Centralized["传统中心化Agent身份"]
        A1["Agent A<br/>(Google生态)"] -->|"OAuth令牌"| GW1["Google网关"]
        B1["Agent B<br/>(银行生态)"] -->|"API密钥"| GW2["银行网关"]
        GW1 -->|"互不信任"| GW2
        style GW1 fill:#ff4444,stroke:#ff8888,stroke-width:2px,color:#ffffff
        style GW2 fill:#ff4444,stroke:#ff8888,stroke-width:2px,color:#ffffff
    end
    subgraph Decentralized["DID方案下的Agent身份"]
        A2["Agent A<br/>(DID: did:abc)"] -->|"VC+签名"| V1["验证方<br/>(链上合约或Agent C)"]
        B2["Agent B<br/>(DID: did:xyz)"] -->|"VC+签名"| V1
        User["用户DID<br/>签发授权VC"] --> A2
        User --> B2
        style V1 fill:#44ff44,stroke:#88ff88,stroke-width:2px,color:#111111
    end
    style Centralized fill:#1a1a2e,stroke:#ff4444,stroke-width:2px,color:#ffffff
    style Decentralized fill:#0a2e28,stroke:#44ff88,stroke-width:2px,color:#ffffff

图2：中心化方案 vs DID方案的跨域信任架构对比

图2左侧展示了传统困境：Google生态的Agent A和银行生态的Agent B无法直接对话，只能各自通过各自的网关。网关之间没有信任协议，就像两个说不同语言的网关各自为政。右侧展示了DID方案：Agent A 和 Agent B 各持一个DID，用户通过VC向两者分别授予权限。当它们向共同验证方（可以是另一个Agent或链上智能合约）出示VC组合时，验证方通过区块链上的DID文档和密码学验签直接验证，无需任何平台网关居中翻译。Agent的"护照"是自己持有的，而非平台借出的。

四、DID在AI Agent中的四种落地模式

DID标准提供了原理，但在AI Agent生态中的具体落地出现了四种不同的工程模式。理解这四种模式，可以看当前这个交叉领域的技术全景。

4.1 模式一：Agent自托管身份（Self-Custody Agent DID）

这是DID最纯粹的应用方式。每个AI Agent在初始化时生成自己的密钥对（如基于secp256k1曲线的以太坊兼容密钥），在以太坊或其他兼容链上注册DID文档，或者使用无需链上注册的DID方法（如 did:key 方法将公钥直接编码在DID字符串中）。

Agent私钥存储在本地安全飞地——可以是硬件安全模块（HSM）、可信执行环境（TEE）、或经过MPC分片的密钥份额。用户需要与Agent交互时，通过钱包签名一笔交易或一条消息，向Agent的DID授予特定权限VC。

这种模式的特点是：

• 最高自主度：Agent不依赖任何外部身份平台，完全自托管
• 密码学原生：所有交互都是签名+验签，天然适用于区块链智能合约验证
• 密钥管理门槛高：如果私钥丢失，Agent身份即永久丢失（类似人类丢失助记词）

4.2 模式二：MPC/CA托管的混合Agent身份

为了解决纯自托管的密钥丢失风险，第二种模式引入多方计算（MPC）或证书机构的混合托管。Agent的私钥被拆分为多个份额，分别由用户设备、云服务商、MPC节点网络持有。任何单方无法重构完整私钥，需要达到阈值才能联合签名。

在这种模式下，Agent对外仍呈现为一个统一的DID，但内部签名由MPC链路完成。用户可以通过社会恢复（social recovery）机制——指定3个信任联系人，其中2人同意即可恢复密钥——来解决单点丢失风险。

4.3 模式三：基于ERC-8004的链上Agent身份与声誉

2025年8月，以太坊社区提出并发布了ERC-8004标准草案（信息来源：TradingView/Technology.org等多家技术媒体于2025-2026年初报道）。该标准专门面向AI Agent场景，定义了去中心化应用中的Agent身份注册与发现协议。其核心机制包括：

• Agent注册表：一个链上合约维护DID到Agent元数据的映射，包括Agent类型、版本、制造商签名、合规声明等
• 可验证声誉系统：基于交互历史的链上评分，每次服务完成由用户或Counter-Agent提交密码学签名的评价，聚合为链上声誉分数
• 服务发现协议：其他Agent或用户可以通过查询注册表，按声誉排序查找适合其需求的AI服务

2025年9月，以太坊基金会正式成立dAI Team（去中心化AI团队），由AI lead Davide Crapis主导方向。Crapis在多个场合明确表示："以太坊正处于成为AI-to-AI交互结算层的独特位置。"据公开技术报道，自2025年8月ERC-8004规范发布以来，已有1200-2000名开发者加入相关开发群组参与建设。

ERC-8004的价值不仅在于一张Agent ID，而在于构建了一个"可互动的Agent目录"——类似于App Store，但Agent的评分、评论、权限都在链上可验证，不可被单一平台操纵。

4.4 模式四：跨链/跨域可迁移Agent身份

第四种模式解决更复杂的问题：一个Agent可能同时在以太坊、Solana、企业联盟链甚至传统Web服务端运行，但它的身份需要保持一致。这要求DID解析能跨多个区块链和域名系统完成。

did:ethr 和 did:pkh 是两个最受欢迎的方法。did:ethr 将DID解析为以太坊地址；did:pkh 则更加通用，兼容任何使用公私钥对的区块链账户体系。2025年开始，基于DID的跨链身份桥接方案开始出现——通过向多个目标链同步DID文档哈希，确保Agent在任何链上的身份引用都指向同一个密码学实体。

flowchart TB
    subgraph User["用户层"]
        U["用户DID"] -->|"签发授权VC"| AgentDID["Agent DID"]
    end
    subgraph Model1["自托管模式"]
        TEE["TEE/HSM<br/>本地私钥存储"]
        AgentDID --> TEE
    end
    subgraph Model2["MPC托管模式"]
        MPC["MPC网络<br/>(阈值签名)"]
        AgentDID --> MPC
    end
    subgraph Model3["ERC-8004链上模式"]
        ERC["链上注册表<br/>(声誉+发现)"]
        AgentDID --> ERC
    end
    subgraph Model4["跨链迁移模式"]
        CC["跨链DID桥<br/>(多链文档哈希同步)"]
        AgentDID --> CC
    end
    subgraph VerifyLayer["验证层"]
        SC["智能合约/其他Agent<br/>(密码学验签)"]
        TEE -->|"签名消息"| SC
        MPC -->|"联合签名"| SC
        ERC -->|"链可查声誉"| SC
        CC -->|"一致性验证"| SC
    end
    style User fill:#1a0a1a,stroke:#ff66a3,stroke-width:2px,color:#ffffff
    style Model1 fill:#0a1a2e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style Model2 fill:#0a1a2e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style Model3 fill:#0a1a2e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style Model4 fill:#0a1a2e,stroke:#4a9eff,stroke-width:2px,color:#ffffff
    style VerifyLayer fill:#0a2e0a,stroke:#44ff44,stroke-width:2px,color:#ffffff

图3：四种DID+AI Agent身份落地模式全景图

图3展示了四种模式如何共享同一个"用户授权VC"入口，但在内部采用不同的密钥管理策略（本地自托管、MPC阈值签名、链上注册表或跨链桥）。它们的共同点是：向验证层输出密码学可验证的签名和凭证，验证方（可以是另一个Agent或链上智能合约）无需知道Agent内部用哪种模式管理密钥，只需要验签通过即信任其身份。

五、从"谁签的名"到"谁做的事"：可验证声誉的链上实现

DID解决了"这是谁"的问题，VC解决了"它有什么权限"的问题。但AI Agent经济还需要回答第三个问题："它做得怎么样？"

5.1 声誉的三重维度

一个Agent的声誉远比人类简单。在技术语境下，Agent声誉通常被拆解为三个可验证维度：

在ERC-8004草案的框架描述中，这些维度通过链上注册表实现。每次Agent完成一项服务，请求方或智能合约记录本次交互结果并附加数字签名。这些数据形成时间序列，任何验证方在决定是否委托任务给该Agent时，都可以查询其历史表现并以密码学方式验证记录未被篡改。

这不同于传统的App Store评分体系。传统评分的可信假设是"平台没有操纵分数"，而链上声誉的可信假设是"密码学签名不可伪造"，以及"链上数据写入即留痕"。后者不依赖任何单一平台的诚实性。

5.2 声誉的可组合验证

链上声誉的精妙之处在于可组合性。一个验证方可以设定复合条件："我只接受满足以下三个条件的订票Agent：①持有铁路系统合作VC；②过去30天执行成功率＞95%；③由至少3个不同用户DID签发的正向评价。

这类逻辑可以被编码为链上查询条件或零知识证明。Agent向合约证明"我满足你的筛选条件"，但不需要暴露自己的全量历史记录。这在保护Agent商业秘密（如客户名单）的同时，建立了信任。

六、工程实践中的技术挑战

DID+AI Agent的愿景清晰，但落地过程中仍有若干严峻的工程挑战。

6.1 密钥管理：Agent比人类更容易"丢钥匙"

AI Agent是软件程序，运行在服务器、云容器或用户终端上。与传统人类用户的"助记词+硬件钱包"不同，Agent的私钥需要被程序化调用，这意味着私钥文件或密钥派生路径天然面临更高泄露风险。

当前有几个方向在探索解决：

• TEE内签名：如Intel TDX、AMD SEV-SNP、ARM TrustZone等，确保私钥从生成到签名全程不出安全飞地
• MPC阈值签名：私钥分片存在多个安全区，需要多方联签
• 可升级DID：W3C标准支持DID文档更新，允许Agent在密钥泄露后推转密钥对并发布新公钥到链上，同时保留DID本体不变。但这引入了新的问题——所有旧VC需要重新签发或链上声明作废

6.2 链上存储成本

DID文档和声誉数据最终需要存储在某处。以太坊主网存储价格昂贵，将完整DID文档存储在链上不现实。当前主流做法是：链上只存放DID文档的哈希指针或IPFS CID，文档本身存在IPFS/Arweave等分布式存储网络。但这引入了额外依赖——如果这些存储网络不可用（如IPFS节点下线），DID解析就会失败。

Layer 2和侧链提供了更低成本的选择。将Agent身份协议部署在Optimism、Arbitrum等Rollup上，存储成本降低1-2个数量级。ERC-8004的开发社群目前主要围绕以太坊L2生态构建。

6.3 隐私悖论：可验证与匿名的平衡

DID承诺了自主控制，但区块链的透明性意味着DID的所有交互记录都是公开可查的。一个企业部署的Agent如果被关联到特定DID，其所有商业合作方的链上通信都可能被追踪分析。

零知识证明（ZKP）提供了可能的解决方案。Agent可以证明"我持有某VC"而不透露具体哪个DID持有它；可以证明"我的声誉分数＞阈值"而不透露每一次交互的详情。这被称为"选择性披露"（selective disclosure），是W3C VC 2.0标准正在推进的方向（注：截至本文写作时，VC 2.0仍在W3C标准化流程中，尚未最终定稿，开发者需要关注后续更新）。

七、未来生态：四条路线的融合正在发生

7.1 传统支付网络与DID并非互斥

虽然本文侧重去中心化方案，但工程现实是：Mastercard/Visa的Agent支付标准与DID方案并非互斥。一个Agent完全可以同时持有两套身份证明：一套是Mastercard Agent Pay令牌（用于电商支付场景），另一套是自己生成的DID+用户授权VC（用于链上协议交互）。两套系统各自服务于不同信任域，未来甚至可能出现"VC桥"——将Mastercard签发的可验证凭证映射到链上DID，实现传统金融机构主动向去中心化协议的信任输出。

7.2 AI Agent身份的"寒武纪时刻"

2025-2026年被许多人称为AI Agent的寒武纪大爆发。抛开营销叙事，一个确定的事实是：Agent之间的经济交互正在从零增长到有限但真实的规模。无论是帮你订票的Agent，还是自动化执行链上策略的Agent，还是代表企业对接供应链的Agent——它们都需要身份证明。

从DID标准被纳入W3C正式标准，到以太坊基金会2025年成立dAI Team，再到Mastercard、Visa、Google在2026年同时推出Agent身份解决方案——三条轨道正在交汇。DID方案的长期优势在于其开放性和可组合性，但短期内，传统体系的Agent支付标准会凭借既有商户网络占据主流。真正的变革可能发生在两类系统的接口处：当传统金融机构开始以VC形式签发身份凭证，当链上注册表能够以零知识证明方式验证链下声誉，当Agent可以用同一个DID同时登录电商网站和调用智能合约——一条不依赖任何单一平台信任边界的身份基础设施才算成型。

这个目标并不遥远。ERC-8004的推进、W3C DID 2.0的预研、以及Visa/万事达对可验证凭证技术的关注，都在2025-2026年同时发生。如果这篇文字能让你理解一件事，那就是：AI Agent的"人格"不是塞进云端数据库里的一张注册表，而是一套运行在密码学和共识协议之上的自证逻辑。这比任何平台账号都更接近"身份"这个概念的本意。

参考来源与延伸阅读

• W3C. Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, 2022年7月. https://www.w3.org/TR/did-core/
• W3C. Verifiable Credentials Data Model 1.0, W3C Recommendation, 2019年11月. https://www.w3.org/TR/vc-data-model/
• 多个行业技术媒体2025-2026年报道："Agent Identity Verification" (Eco, 2026年1月); "Why Verifiable Credentials Will Power Real-world AI in 2026" (Indicio, 2026年1月); TradingView/Technology.org对ERC-8004的技术报道
• 以太坊基金会dAI Team公开技术更新及社区讨论, 2025年8月-2026年1月
• Visa/Mastercard公开技术文档：Trusted Agent Protocol与Agent Pay技术白皮书, 2025年末
• W3C DID Working Group与Verifiable Credentials 2.0工作草案（正在推进中）
• 学术论文："AI Agents with Decentralized Identifiers and Verifiable Credentials"（arXiv, 2025年11月）

本文完成于2026年6月25日。 文中关于ERC-8004、Visa/Mastercard Agent支付标准、W3C VC 2.0进度的论述基于公开技术报道和行业调研，技术实现细节请参照官方规范文档。文中涉及的MPC/TEE技术方案仅作技术方向分析，不构成具体实施建议。