代理身份問題
我們正在進入一個 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 代理的演進。