status
Published
type
Post
category
WEB3
date
Nov 11, 2025
slug
——DID + AI 驱动的 A2A 智能体交互新范式
summary
可验证人工智能——去中心化身份(DID)如何赋能智能体人工智能
tags
password
icon
在 Agent-to-Agent 的 AI 交互体系中,
DID 负责标识主体身份并绑定公钥,
用户通过 DID 所控制的密钥,对数据访问与能力委托进行签名授权;
未经 DID 层明确授权的数据调用,既无法满足合规审计要求,也无法支撑真正个性化的智能行为。
因此,没有数据合规性和 DID 级别授权的个人人工智能助理,只能停留在“通用模型”层面,是能力受限的“残缺体”,难以在公域场景中承担关键职能。
📝 主旨内容
一、问题背景:为什么需要 DID + AI + A2A?
A2A Background:
为了让“谁在行动、凭什么行动、边界何在、如何审计”可被机器验证,业界自然引入DID(身份根)+ 可验证授权/能力凭证(权限根)+ 审计/存证(可追溯)合规、可信的 Agent-to-Agent 网络
在「Agent to Agent(A2A)」的世界里,不再只是“人 ➜ App”,而是:
- 你的个人 AI 助理
和
- 各种服务方的 AI 助理(银行、券商、教育平台、政府服务等)
在后台不断自动对话、协商、拉数据、下指令。
但如果没有一套统一的身份 + 授权 + 审计机制,这种 A2A 很快会踩到三个雷:
- 不知道谁在行动:是用户本人、哪个 Agent,还是平台乱调接口?
- 搞不清凭什么有权限:数据到底有没有授权、授权到什么范围?
- 出了问题难以追责:事后说不清是谁在什么前提下做了什么决策。
因此,在 A2A 场景下,一个比较自然的设计是:
用DID 作为身份根 用密钥和可验证凭证(VC)作为权限根 用数据授权策略作为能力根 把它们全部绑定到 AI Agent 的生命周期里。
二、总体架构:DID + AI + A2A 参考模型
这张图反映了几个关键点:
- 身份解耦:用户、个人 Agent、服务方、服务 Agent 各有 DID。
- 权限委托:用户通过主密钥向个人 Agent 签发“能力凭证”(VC/Token)。
- A2A 交互:两个 Agent 之间的调用都必须带上可验证授权。
- 合规可追溯:授权、访问行为都能被记录并(可选地)上链存证。
三、核心模块说明
1. 身份与 DID 层(Identity & DID)
目标:解决“谁在行动?”
- 用户 DID:did:user123
- 个人 Agent DID:did:user123#agent1
- 服务方 DID:did:service456
- 服务 Agent DID:did:service456#risk-advisor
每个 DID 对应一个 DID Document,里面挂:
- 公钥(verificationMethod)
- 通信端点(service endpoints)
- (可选)支持的协议声明(如 DIDComm、A2A 协议版本等)
关键点:
DID 本身不一定“存密钥”,但它是公钥 / 权限 / 服务端点的入口,相当于“这是谁 + 他能怎么被找到”的根信息。
2. 密钥与能力委托(Keys & Delegation)
目标:解决“凭什么有权?”
- 用户主密钥(主冷钱包 / 密钥管理器)只做两件事:
- 签发授权凭证(VC / Capability Token)
- 必要时做一次性高风险操作(比如大额转账)
- 个人 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)
目标:解决“数据从哪里来?能怎么用?”
数据大体分三类:
- 用户私域数据
- 本地设备、私有云、个人知识库等
- 服务方业务数据
- 交易、账单、学习记录、行为日志等
- 公域数据
- 区块链数据、公开网站、开放数据集等
A2A 的关键是:
Agent 不是“到处乱抓”,而是带着“有边界的授权”去访问特定数据源。
每次访问都应有:
- 调用者 DID
- 所携带的 VC/Token
- 授权的 scope
- 时间戳与追踪 ID(trace_id)
5. A2A 通信协议层(Agent-to-Agent Protocol)
目标:规范两边 Agent 的“握手流程”
可以用一个时序图来描述个人 Agent 和服务方 Agent 的典型交互:
在这个过程中,每一步都有:
- 明确的身份:由 DID 表示
- 明确的授权:由 VC/Token 表示
- 明确的边界:由 Policy + scope 约束
- 可审计:请求和返回都可以被记录
6. 合规与审计层(Compliance & Audit)
目标:解决“事后能不能说清楚?”
监管/用户在乎的三件事:
- 是谁下的指令?
- 由 DID + 签名链条证明
- 在什么授权前提下?
- 由 VC/Token 内容 + 签发记录说明
- 到底看了什么 / 做了什么?
- 由访问日志 + 审计链路回答
实现方式可以是:
- 日志系统记录:
- caller_did / agent_did
- scope
- resource_id
- timestamp
- decision(allow / deny)
- 关键日志条目的哈希上链:
- 不泄露明文内容
- 但可以证明日志未被篡改(完整性证明)
四、为什么说“没有数据授权的个人 AI 助理是瘸子”?
在 Agent-to-Agent 的 AI 交互体系中,若缺乏基于 DID 的身份标识与可验证的数据授权机制,个人 AI 助理既无法合法、透明地访问与用户相关的关键数据,也无法在合规审计框架下承担高价值的自动化决策任务。 这类“失明”的 Agent 只能停留在通用问答层面,无法真正进化为具有行动能力的「数字分身」,从能力与合规两个维度看,都是一种“功能残缺”的形态。
五、「Agent-to-Agent 的 AI 交互体系」从背景、演进到架构的逻
🧭 一、智能交互演进脉络图
从「人 ↔ App」到「Agent ↔ Agent」
解读:
- Web2:以中心化 App 为核心,人只与平台交互。
- Web2.5:以 LLM 为接口,但仍靠中心化 API。
- Web3 / A2A:AI 有身份(DID)、有密钥(授权),能在跨平台、跨域间直接通信。
⚙️ 二、A2A 系统五层架构图
解读:
- 身份层:定义“谁”在行动
- 授权层:定义“凭什么”
- 交互层:定义“如何通信”
- 数据层:定义“能访问什么”
- 合规层:定义“如何说清楚”
🔐 三、Agent-to-Agent 通信流程图(典型交互)
关键特征:
- 所有操作均携带 DID 和签名凭证
- 授权范围可验证、可撤销、可追溯
- 访问日志上链防篡改
🧩 四、典型行业应用矩阵
行业领域 | A2A 交互示例 | 对 DID 的价值 | 对 合规/授权 的需求 |
金融 | 用户理财 Agent ↔ 银行风控 Agent | 身份认证 + 授权交易 | 高(KYC、AML) |
教育 | 学习助理 Agent ↔ 教育平台 Agent | 课程进度可追踪 | 中(数据隐私) |
医疗 | 患者健康 Agent ↔ 医院诊断 Agent | 授权病历访问 | 极高(HIPAA/GDPR) |
政务 | 企业 Agent ↔ 政府报税 Agent | 实体身份验证 | 高(合规记录) |
IoT | 家庭 AI Hub ↔ 设备控制 Agent | 设备身份确权 | 中(安全控制) |
🧠 五、Agent 生态发展阶段图
Agent-to-Agent 的 AI 交互体系,是智能自动化从“人机协作”走向“机机协作”的必然结果。 它需要以 DID 为身份根、以授权凭证为权限根、以区块链审计为信任根,才能在合规、可信的前提下,让智能体真正成为“能独立行事的数字公民”。
六、扩展方向:DID + AI + zk + DAO
- 结合 ZK(零知识证明)
- 在不暴露具体数据的情况下,向服务方 Agent 证明:
- “这个用户的资产超过 X”
- “这个用户完成了某个任务 / 课程”
- 进一步减少数据面暴露。
- 结合 DAO 治理与隐私投票
- 用 DID 标识成员身份
- 用 zk-SNARK 实现私密投票
- 用 Agent 帮用户“看懂提案并给出投票建议”,
- 但最后投票由用户 DID + zk 证明完成。
- 跨平台 / 多域 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
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.
juejin.cn
Loading...

.png?table=block&id=8cbd9ef4-8c1c-4581-80f1-a15297380674&t=8cbd9ef4-8c1c-4581-80f1-a15297380674&width=1080&cache=v2)

