🗒️ 🤖 从「人 ↔ App」到「Agent ↔ Agent」

可验证人工智能——去中心化身份(DID)如何赋能智能体人工智能

🤖 从「人 ↔ App」到「Agent ↔ Agent」
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 很快会踩到三个雷:
  1. 不知道谁在行动:是用户本人、哪个 Agent,还是平台乱调接口?
  1. 搞不清凭什么有权限:数据到底有没有授权、授权到什么范围?
  1. 出了问题难以追责:事后说不清是谁在什么前提下做了什么决策。
因此,在 A2A 场景下,一个比较自然的设计是:
DID 作为身份根 密钥和可验证凭证(VC)作为权限根 数据授权策略作为能力根 把它们全部绑定到 AI Agent 的生命周期里。
 

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

这张图反映了几个关键点:
  1. 身份解耦:用户、个人 Agent、服务方、服务 Agent 各有 DID。
  1. 权限委托:用户通过主密钥向个人 Agent 签发“能力凭证”(VC/Token)。
  1. A2A 交互:两个 Agent 之间的调用都必须带上可验证授权。
  1. 合规可追溯:授权、访问行为都能被记录并(可选地)上链存证。

三、核心模块说明

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)

目标:解决“凭什么有权?”
  • 用户主密钥(主冷钱包 / 密钥管理器)只做两件事:
      1. 签发授权凭证(VC / Capability Token)
      1. 必要时做一次性高风险操作(比如大额转账)
  • 个人 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. 用户私域数据
      • 本地设备、私有云、个人知识库等
  1. 服务方业务数据
      • 交易、账单、学习记录、行为日志等
  1. 公域数据
      • 区块链数据、公开网站、开放数据集等
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)

目标:解决“事后能不能说清楚?”
监管/用户在乎的三件事:
  1. 是谁下的指令?
      • 由 DID + 签名链条证明
  1. 在什么授权前提下?
      • 由 VC/Token 内容 + 签发记录说明
  1. 到底看了什么 / 做了什么?
      • 由访问日志 + 审计链路回答
实现方式可以是:
  • 日志系统记录:
    • 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

  1. 结合 ZK(零知识证明)
      • 在不暴露具体数据的情况下,向服务方 Agent 证明:
        • “这个用户的资产超过 X”
        • “这个用户完成了某个任务 / 课程”
      • 进一步减少数据面暴露。
  1. 结合 DAO 治理与隐私投票
      • 用 DID 标识成员身份
      • 用 zk-SNARK 实现私密投票
      • 用 Agent 帮用户“看懂提案并给出投票建议”,
      • 但最后投票由用户 DID + zk 证明完成。
  1. 跨平台 / 多域 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
LinkedInEditorsLinkedInEditorsVerifiable AI - How Decentralized Identity (DID) Empowers Agentic AI
juejin.cn
 
💡
 
上一篇
macos 终端
下一篇
Web3 用户增长三大关键:PMF、MVP 与 GTM 策略详解
Loading...