📝 主旨内容

一、问题背景：为什么需要 DID + AI + A2A？

为了让“谁在行动、凭什么行动、边界何在、如何审计”可被机器验证，业界自然引入

DID（身份根）+ 可验证授权/能力凭证（权限根）+ 审计/存证（可追溯）

合规、可信的 Agent-to-Agent 网络

• 你的个人 AI 助理
和

• 各种服务方的 AI 助理（银行、券商、教育平台、政府服务等）

1. 不知道谁在行动：是用户本人、哪个 Agent，还是平台乱调接口？

2. 搞不清凭什么有权限：数据到底有没有授权、授权到什么范围？

3. 出了问题难以追责：事后说不清是谁在什么前提下做了什么决策。

用DID 作为身份根 用密钥和可验证凭证（VC）作为权限根 用数据授权策略作为能力根 把它们全部绑定到 AI Agent 的生命周期里。

二、总体架构：DID + AI + A2A 参考模型

1. 身份解耦：用户、个人 Agent、服务方、服务 Agent 各有 DID。

2. 权限委托：用户通过主密钥向个人 Agent 签发“能力凭证”（VC/Token）。

3. A2A 交互：两个 Agent 之间的调用都必须带上可验证授权。

4. 合规可追溯：授权、访问行为都能被记录并（可选地）上链存证。

三、核心模块说明

1. 身份与 DID 层（Identity & DID）

• 用户 DID：did:user123

• 个人 Agent DID：did:user123#agent1

• 服务方 DID：did:service456

• 服务 Agent DID：did:service456#risk-advisor

• 公钥（verificationMethod）

• 通信端点（service endpoints）

• （可选）支持的协议声明（如 DIDComm、A2A 协议版本等）

2. 密钥与能力委托（Keys & Delegation）

• 用户主密钥（主冷钱包 / 密钥管理器）只做两件事：
1. 签发授权凭证（VC / Capability Token）
2. 必要时做一次性高风险操作（比如大额转账）

• 个人 Agent 通过这些凭证获得“受限能力”，比如：
• 在某个时间窗口内：
• 只读：资产余额、交易记录、课程学习数据……
• 只读 + 推理：可对这些数据做分析，但无权直接下单 /转账
• 权限随时间、用途、数据范围受控。

• 最小权限原则（Least Privilege）

• 可撤销（Revocation）：用户可以撤销某个 VC / Token

• 可过期（Expiration）：设置 TTL，超时自动失效

3. 授权与策略引擎（Authorization & Policy Engine）

• 策略引擎负责对每一次 A2A 请求做决策：
• 验证凭证是否有效（是否由正确 DID 签发、是否在有效期内）
• 匹配授权范围（数据范围、操作类型、目的用途）
• 对于高风险行为（如“代用户下单”）可追加二次确认机制

• 仅允许访问：
• account_balance, historical_returns 字段
• 不允许访问 KYC, 身份证号, 联系人 等敏感字段

• 仅允许目的为：
• portfolio_recommendation
• 不允许 direct_marketing、二次转售

4. 数据与隐私层（Data & Privacy Layer）

1. 用户私域数据
• 本地设备、私有云、个人知识库等

2. 服务方业务数据
• 交易、账单、学习记录、行为日志等

3. 公域数据
• 区块链数据、公开网站、开放数据集等

• 调用者 DID

• 所携带的 VC/Token

• 授权的 scope

• 时间戳与追踪 ID（trace_id）

5. A2A 通信协议层（Agent-to-Agent Protocol）

• 明确的身份：由 DID 表示

• 明确的授权：由 VC/Token 表示

• 明确的边界：由 Policy + scope 约束

• 可审计：请求和返回都可以被记录

6. 合规与审计层（Compliance & Audit）

1. 是谁下的指令？
• 由 DID + 签名链条证明

2. 在什么授权前提下？
• 由 VC/Token 内容 + 签发记录说明

3. 到底看了什么 / 做了什么？
• 由访问日志 + 审计链路回答

• 日志系统记录：
• caller_did / agent_did
• scope
• resource_id
• timestamp
• decision（allow / deny）

• 关键日志条目的哈希上链：
• 不泄露明文内容
• 但可以证明日志未被篡改（完整性证明）

四、为什么说“没有数据授权的个人 AI 助理是瘸子”？

在 Agent-to-Agent 的 AI 交互体系中，若缺乏基于 DID 的身份标识与可验证的数据授权机制，个人 AI 助理既无法合法、透明地访问与用户相关的关键数据，也无法在合规审计框架下承担高价值的自动化决策任务。 这类“失明”的 Agent 只能停留在通用问答层面，无法真正进化为具有行动能力的「数字分身」，从能力与合规两个维度看，都是一种“功能残缺”的形态。

五、「Agent-to-Agent 的 AI 交互体系」从背景、演进到架构的逻

• Web2：以中心化 App 为核心，人只与平台交互。

• Web2.5：以 LLM 为接口，但仍靠中心化 API。

• Web3 / A2A：AI 有身份（DID）、有密钥（授权），能在跨平台、跨域间直接通信。

• 身份层：定义“谁”在行动

• 授权层：定义“凭什么”

• 交互层：定义“如何通信”

• 数据层：定义“能访问什么”

• 合规层：定义“如何说清楚”

• 所有操作均携带 DID 和签名凭证

• 授权范围可验证、可撤销、可追溯

• 访问日志上链防篡改

Agent-to-Agent 的 AI 交互体系，是智能自动化从“人机协作”走向“机机协作”的必然结果。 它需要以 DID 为身份根、以授权凭证为权限根、以区块链审计为信任根，才能在合规、可信的前提下，让智能体真正成为“能独立行事的数字公民”。

六、扩展方向：DID + AI + zk + DAO

1. 结合 ZK（零知识证明）
• 在不暴露具体数据的情况下，向服务方 Agent 证明：
• “这个用户的资产超过 X”
• “这个用户完成了某个任务 / 课程”
• 进一步减少数据面暴露。

2. 结合 DAO 治理与隐私投票
• 用 DID 标识成员身份
• 用 zk-SNARK 实现私密投票
• 用 Agent 帮用户“看懂提案并给出投票建议”，
• 但最后投票由用户 DID + zk 证明完成。

3. 跨平台 / 多域 Agent 协同
• 同一个用户 DID 对接不同平台的 Agent
• 通过统一的授权控制中心，让多个 Agent 协同工作，而不是“各玩各的黑盒”。

当每个智能体都带身份、带信用、带钱包， 世界就进入「Agent 经济体时代」。

📎 参考文章

• Indicio, Five reasons why AI needs decentralized identity

• ArcBlock, The AI Agent Needs a Wallet—Why Decentralized Identity

• Deloitte, AI agent architecture and design

LinkedInEditorsVerifiable AI - How Decentralized Identity (DID) Empowers Agentic AI

Verifiable AI - How Decentralized Identity (DID) Empowers Agentic AI

Welcome to the world of Agentic AI, where intelligent agents make decisions, complete transactions, and operate independently across digital spaces. Global AI leaders are defining agent to agent communication protocols for bringing interoperability and common framework for agentic AI ecosystem.

LinkedInEditors

juejin.cn

juejin.cn