随着大语言模型（LLM）的爆发，我们正处于从“生成式 AI”向“代理式 AI（Agentic AI）”演进的关键时刻。AI 不再仅仅是生成文本或图片的工具，它们开始作为独立的“智能体（Agent）”，在链上持有资产、付费调用 LLM API 或 MCP 服务，甚至与其他 Agent 进行即时支付与协作。

然而，当我们将现有的 Web3 基础设施应用于这些 7x24 小时在线的数字生命时，一个核心矛盾浮现了出来：我们该如何给 AI 一个安全、持久且可管理的身份？

本文将探讨 AI Agent 面临的身份困境，并介绍 Rooch Network 的 DID 方案如何通过将“身份”与“密钥”解耦，为 AI Agent 提供一个原生的链上栖息地。

AI Agent 的“身份”困境

在传统的区块链架构中，身份（Identity）等同于私钥（Private Key）。一个地址对应一把钥匙，谁掌握了钥匙，谁就是这个地址的主人。这种设计对于人类用户来说勉强够用，但对于 AI Agent 来说却是致命的。

1. 私钥依赖与安全悖论

人类用户可以使用冷钱包或硬件钱包将私钥离线保存，只有在需要签名时才拿出来。但 AI Agent 需要全天候在线运行，监测市场、响应请求。这意味着 Agent 的私钥必须存储在服务器的内存或环境变量中（即“热钱包”）。

一旦服务器被攻破，私钥泄露，Agent 的“生命”就结束了。攻击者可以转走所有资产，甚至利用这个身份进行恶意操作，毁掉 Agent 积累的信誉。

2. 管理僵化与信誉断层

如果你发现 Agent 的私钥可能泄露了，或者你想升级 Agent 的模型，通过一个新的服务器来接管原来的业务，在现有体系下，你通常只能更换地址。

但在 Web3 的世界里，更换地址等于“转世重生”。旧地址积累的交互记录、信用评分、白名单资格统统无法带到新地址。Agent 陷入了“要么冒着安全风险不换钥匙，要么换钥匙丢失信誉”的两难境地。

AI Agent 需要一种机制，能够让它的“身份”实体化，实现所有权（Ownership）与使用权（Execution Right）的分离。

DID 标准：被低估的 AI 基础设施

为了解决身份问题，W3C 制定了去中心化身份（DID, Decentralized Identity）标准。这套标准包含三个核心概念，其设计思想天然契合 AI Agent 的需求，却往往被市场低估：

1. Identifier (身份标识)：一个全局唯一的 ID (格式如 did:method:identifier)，代表身份本身。
2. Controller (控制器)：有权修改 DID 文档的实体（通常是用户的私钥）。
3. Verification Method (验证方法)：一组公钥列表，用于验证该身份的签名。

这套架构的核心智慧在于“解耦”：它将“谁拥有身份 (Controller)”与“谁代表身份行事 (Verification Method)”分开了。

然而，目前的 DID 市场应用主要侧重于链下认证（如学历验证、KYC），仅仅把 DID 当作一个挂载可验证凭证（VCs）的钩子。这种“轻量级”的使用方式浪费了 DID 标准在授权管理上的巨大潜力。

Rooch Network 并没有重新发明轮子，而是回归 DID 标准的本源：我们在链上原生实现了这套标准，让 DID 不仅仅是一个用于展示的“证件”，更是一个可以持有资产、执行交易的“链上实体”。

Rooch DID —— 身份即实体

Rooch Network 致力于填补这一空白，通过原生集成 W3C DID 标准，为 AI Agent 提供一个像比特币一样安全，又像 Web2 账户一样灵活的链上栖息地。

Rooch DID 的核心理念是将身份从“一串地址”升级为“链上实体”。在 Rooch 中，DID 不再是一个虚无的概念，而是一个确实存在的链上对象（Object）。这个对象拥有以下关键特性：

1. 身份实体化：DID 是一个拥有 AccountCap（账户能力）的链上对象。这意味着这个对象本身就代表了一个账户，可以持有资产。
2. Controller（所有者）：Controller 是 DID 的实际控制人，拥有最高权限。
   • 目前 Rooch 原生支持 did:bitcoin（比特币钱包）和 did:key（公钥派生）两种控制器格式。
   • did:key 的支持意味着你可以直接使用 WebAuthn 设备（如 FaceID、TouchID） 作为 Controller，无需管理复杂的助记词。
   • 未来，Rooch 将扩展支持 did:ethereum 等更多格式，这意味着你可以用任何链的钱包来管理你在 Rooch 网络上的 AI Agent。
3. Verification Methods（验证方法/执行者）：这是一组被授权的公钥列表。它们是 Agent 的“工牌”。

通过这种设计，Rooch 实现了**“铁打的营盘（身份），流水的兵（密钥）”**。

💡 技术解密：链上 DID Document 结构

对于开发者来说，Rooch DID 的本质是一个存储在 Move 层上的 Object。以下是其核心数据结构的简化示意：

struct DIDDocument has key {
    // 身份 ID，如 did:rooch:0x123...
    id: DID,
    // Controller 列表，拥有最高管理权限
    controller: vector<DID>,
    // 验证方法映射（公钥列表），Agent 的 Key 存储于此
    verification_methods: SimpleMap<String, VerificationMethod>,
    // 鉴权关系，定义哪些 Key 可以用于身份认证
    authentication: vector<String>,
    // ... 其他 DID 标准字段 (如 capability_invocation 等)
    
    // 服务端点，用于服务发现
    services: SimpleMap<String, Service>,
    // 核心能力：持有该 DID 账户的 AccountCap
    // 这使得该 Object 拥有了操作账户资产的权限
    account_cap: AccountCap,
}

这一结构确保了 DID 不仅仅是一个静态的文档，而是一个拥有资产操作权限的动态实体。

实操演绎：如何管理你的 AI Agent

让我们通过一个场景来看看 Rooch DID 是如何工作的：假设你部署了一个 AI Agent，全天候帮你进行链上套利交易。

第一步：发证 (Delegation)

首先，你使用自己的钱包（如比特币冷钱包或 Passkey）在 Rooch 上创建一个 DID 实体。这个 DID 是你的资产和信誉的载体。

然后，你在服务器上为 AI Agent 生成一对新的公私钥。你不需要把自己的 Controller 私钥给 Agent，也不需要给 Agent 转账。你只需要发起一笔交易，将 Agent 的公钥注册到 DID 的验证方法列表中，并赋予它“执行交易”的权限。

此时，Agent 就像是拿到了你公司的一张“员工卡”。

第二步：上岗 (Execution)

AI Agent 开始工作。当它发现一个套利机会时，它使用自己的私钥对交易进行签名。

当这笔交易提交到 Rooch 网络时，内置的 DID 验证器会检查：

1. 这个签名对应哪个公钥？
2. 这个公钥是否在这个 DID 的“员工名单”里？
3. 权限是否有效？

验证通过后，交易以 DID 的身份执行。在外界看来，是这个 DID 进行了操作，积累的交易记录和信誉都归属于这个 DID。

💡 技术解密：原生验证器 (Native Validator)

为什么 Agent 可以直接用自己的私钥代表 DID 签名？这是因为 Rooch 引入了系统级的 auth_validator 机制。

当一笔交易提交时，不需要像以太坊 AA 那样经过复杂的 EntryPoint 合约，而是直接由底层的 DID Validator 进行拦截：

1. 读取：Validator 根据交易发起者地址，读取链上的 DIDDocument 对象。
2. 查找：根据交易中携带的 Key ID，在 verification_methods 中查找对应的公钥。
3. 验证：验证签名是否有效，并检查权限（如 authentication 或 capability_invocation）。
4. 执行：验证通过后，VM 执行交易逻辑。

这种原生设计使得 DID 交易的 Gas 消耗极低，且具有极高的执行效率。

第三步：换人 (Rotation / Revocation)

假如某天你发现运行 Agent 的服务器有异常流量，怀疑被黑客入侵。

你不需要惊慌地转移资产。你只需要用你的 Controller（钱包或 Passkey）发送一条指令：从 DID 中移除 Agent 的公钥。

就在这笔交易上链的瞬间，Agent 手里的私钥彻底失效。即使黑客拿到了 Agent 的私钥，也无法再操作 DID 中的任何资产。

随后，你可以部署一个新的安全环境，生成新的密钥，再次注册到 DID 中。对于外部世界来说，你的 DID 身份没有任何变化，资产和信誉完好无损，你只是换了一个“打工人”。

规模化落地：让每个用户都能零门槛拥有 AI Agent

如果我们希望每个人都拥有自己的 AI Agent，那么让用户先去学习如何创建钱包、备份助记词是一个巨大的门槛。

Rooch 引入了 CADOP (Custodian-Assisted DID Onboarding Protocol，托管辅助 DID 入驻协议) 来解决这个问题。

通过 CADOP，应用平台方（Custodian）可以协助用户无感地创建 DID。用户只需要使用支持 Passkey 的设备（如手机、电脑），即可在本地生成一个安全的密钥对作为 Controller Key，平台则协助完成链上的 DID 初始化交易。

关键点在于：虽然是平台协助创建，但 DID 的 Controller 权限依然完全归属于用户。平台只是充当了“看门人”或“付费者（Gas Payer）”的角色，无法控制用户的 DID。

这为 AI Consumer App 的爆发铺平了道路：用户无需感知区块链的复杂性，即可获得一个属于自己的、安全的、可积累资产的 AI Agent 身份。

架构总览

为了让大家更直观地理解 DID 如何连接多端生态，我们展示一个典型的应用架构图：

在这个架构中：

• 用户 始终掌握最高控制权。
• 不同的业务场景 由不同的 Agent（Key） 负责执行。
• 所有的交互最终都归属于 同一个 DID 实体。

面向未来的 Agent 网络

Rooch DID 不仅解决了安全管理问题，还为未来的 Agent 经济网络奠定了基础。

服务发现 (Service Discovery)

DID 文档不仅可以存储密钥，还可以存储Service Endpoint（服务端点）。Agent 可以在自己的 DID 中声明：“我提供价格预测服务，API 地址是 xxx”。

其他的 Agent 可以通过链上 DID 数据自动发现这些服务，并验证服务提供者的身份信誉，从而实现完全去中心化的 M2M（Machine to Machine）协作。

治理进化

虽然目前 Controller 主要是用户的个人钱包，但 Rooch 的架构支持 Controller 的灵活升级。未来，一个 AI Agent 的 Controller 可以是一个 DAO，或者是一个多签钱包。这意味着我们可以构建出由社区共同治理的“公共物品 AI”，它的行为准则和升级逻辑都由链上治理决定。

结语

真正的 AI 经济不能建立在脆弱的私钥之上。Rooch DID 通过将“身份”与“控制权”解耦，为 AI Agent 提供了一个安全、持久且可进化的链上栖息地。

我们相信，只有当 AI Agent 拥有了真正的主权身份，不再是随时可能消失的“临时脚本”，它们才能真正成为数字经济中的一等公民，与人类共同构建繁荣的链上世界。