代理身份问题
我们正在进入一个 AI 代理代表人类行事的时代 — 预订航班、协商合同、管理基础设施，甚至编写代码。这些代理与其他代理、API 和人类系统交互。
每一次这样的交互都提出了一个根本问题：这个代理是谁，我为什么应该信任它？
今天，大多数代理通过 API 密钥进行认证 — 在代理的运营者和它访问的服务之间共享的静态密钥。这在简单场景下有效，但随着代理变得更加自主，就会崩溃：
- 当代理做出错误决策时，谁负责？
- 一个代理如何验证另一个代理的声明？
- 如何撤销代理的访问权限而不撤销其运营者的访问权限？
- 如何审计代理做了什么，以及代表谁做的？
为什么不直接用 API 密钥？
API 密钥解决了认证问题 — 证明你有一个有效的凭证。但它们不能解决身份问题 — 证明你是谁以及你被授权做什么。
| API 密钥 | 基于 DID 的身份 | |
|---|---|---|
| 凭证 | 静态、长期有效的密钥 | 可轮换的加密密钥对 |
| 身份 | 没有内在身份信息 | 丰富、可验证的身份声明 |
| 访问 | 二元：有效或无效 | 细粒度的能力和权限 |
| 权限 | 中心化颁发和撤销 | 自主权，无中心化权威 |
| 委托 | 没有委托模型 | 原生的委托和撤销 |
DID 是答案
去中心化标识符（DID）由 W3C 设计为通用身份层。虽然最初是为人类构想的，但其架构完美适配 AI 代理：
自主权
代理创建自己的 DID — 无需注册机构。代理控制自己的密钥，可以向任何人证明自己的身份。
可验证凭证
代理的能力可以表达为可验证凭证："该代理被 X 公司授权进行不超过 1,000 美元的采购。" 任何人都可以验证此声明，而无需联系 X 公司。
委托链
人类 → 代理 → 子代理的委托是 DID 模型的原生功能。每个操作都可以通过权限链追溯。
实际架构
以下是基于 DID 的代理身份在实践中的样子：
人类 (DID: did:abt:alice) │ ├── 颁发凭证："代理 X 可以代表我预订航班" │ ▼ 代理 X (DID: did:abt:agent-x) │ ├── 向航班 API 出示凭证 ├── 航班 API 验证：凭证 → Alice 的 DID → 受信任的颁发者 │ ▼ 航班已预订。审计追踪：代理 X → 由 Alice 授权 → 航班 #123
关键洞察：每次交互都可审计，每项能力都有范围限定，每个委托都可撤销 — 无需任何中心化权威管理密钥或权限。
我们在构建什么
在 ArcBlock，我们正在将 DID 在基础层面集成到 AIGNE 框架中：
- 每个 AIGNE 代理在创建时都获得一个 DID。无需主动选择加入。
- 代理到代理的通信使用基于 DID 的双向认证。
- 可验证凭证定义每个代理可以做什么 — 以及谁授权了它。
- 审计日志将每个操作链接到一个 DID，创建完整的问责链。
这不是理论上的 — 它将在 AIGNE 1.0 中发布。如果你正在构建与现实世界交互的 AI 代理，身份不是可选的。它是基础。
推荐阅读
- AIGNE 框架介绍：构建 AI 原生软件 — 将 DID 身份内置于每个代理的开源框架。
- AFS：重新思考 AI 时代的系统抽象 — 智能体文件系统如何将身份集成到每个文件操作中。
- 从 Blocklet 到 Chamber：我们的架构如何为 AI 演进 — 约束架构从人类工程师到 AI 代理的演进。