Agent 也需要身份，DID 可能是最合适的起点

Agent 最终要有自己的身份。这不是给每个进程分一个 UUID，也不是把 API Key 换个名字。一个真正能代表人或组织做事的 Agent，至少要能回答几件事：谁控制它的长期身份，谁授权它做这次操作，眼前这个运行实例是不是获准的那个，以及出了问题能不能马上收回权限。

今天很多 Agent 还只是某个产品里的一个功能。它读一组环境变量，连几个工具，停掉进程就没有了。平台当然可以给它账号、token 和日志，这在单一系统里足够方便。但一旦它要跨组织工作，换模型、换云、换设备，或者替人执行有后果的操作，平台账号就不再等于身份。它只能证明“这个平台把它叫作什么”，很难证明它是谁、代表谁、权限从哪里来。

我的判断是：Agent 的根身份不应永久属于任何一个平台，Agent 的实际权力也不应由它自己声明。 前者需要一个可携带、能由控制者证明的身份锚点；后者需要明确的委托、范围、期限、撤销和审计。DID 很可能是目前最适合承担前一层的开放标准，但它绝不是后面所有问题的答案。

身份不是账号，也不是一把万能钥匙

人类互联网是先把服务跑起来，后来才慢慢补登录、权限和身份恢复。早期单机电脑开机就用，谁会在意多个用户、跨机器协作和权限隔离？等到网络和服务连成一片，账号被盗、账户被关、数据被锁在单一服务商手里，才发现这些不是边缘问题。

DID can anchor identity; authorization and runtime proof still need design.

Agent 的节奏会快得多。一个被盗用的人类账号，可能发几封钓鱼邮件；一个能调用代码部署、采购、设备或数据工具的 Agent，可能在很短时间内并行做很多错误操作。NIST 在 2026 年启动 AI Agent Standards Initiative，并把 Agent 的身份、授权与安全列为研究重点。这说明问题已经不是“Agent 要不要登录”，而是怎样让人、组织、Agent 和资源之间的授权关系能够被看见、限制和追溯。^[1]

但这里最容易犯一个错误：把“身份自主”理解成“Agent 可以自己给自己授权”。不是。一个 Agent 可以控制自己的标识符，却不能因此证明自己有权支付、发布生产代码，或代表一家公司签署什么。控制密钥只证明控制密钥，和业务授权是两回事。

DID 提供锚点，不提供万能证明

W3C 的 DID Core 在 2022 年成为 Recommendation。它定义的是一种可解析的标识符和对应的 DID Document。该文档可以包含验证方法和服务端点，DID 的主体可以是人、组织、设备、数据模型，也可以是软件。标准的重点是让控制者能够用密码学方式证明对标识符的控制，而不必先向某个中心化身份提供商申请许可。^[2]

这正好适合 Agent 的长期连续性。一个 Agent 迁移到另一台机器、换了模型提供商，甚至重建了运行实例，仍可以沿用一个长期身份，或者在必要时把身份分成根身份和任务身份。它不必把“我是谁”完全绑在某一家平台的账号系统上。

不过 DID 不会自动给它信誉、职位或权限。DID Core 本身也把认证之后如何处理、需要什么保证等级留给具体方法和应用决定。^[2] 这里需要 Verifiable Credentials。VC 让一个签发者对某个主体作出可验证声明，例如“这个 Agent 由某个组织登记”“它可处理这一类工单”。验证者仍然要决定是否信任签发者，凭证也需要有效期、状态和撤销策略。^[3]

所以比较可靠的结构不是“给 Agent 一个 DID，问题就解决了”，而是把几层分开：DID 负责长期标识和控制证明，凭证表达第三方声明，委托限定谁可以做什么。少了后两层，DID 只是一个很好的名字和一组密钥。

现有技术不会消失，它们要各做各的事

把 DID 当作 Agent 的长期身份锚点，并不等于 OAuth、MCP 或 SPIFFE 都该被替换。它们回答的本来就是不同的问题。

MCP 的 HTTP 授权基于 OAuth。它处理的是“这个客户端能否代表资源所有者访问这个 MCP server”，并要求服务端验证 token 是否确实为自己这个资源签发。^[4] 这是具体操作的访问控制，不是一个 Agent 跨系统、跨生命周期的完整身份模型。

SPIFFE/SPIRE 处理的又更靠近运行时：当前发出请求的，到底是不是那一个经过证明的 workload。它能依据节点和进程属性给 workload 签发短期凭证，并持续轮换。^[5] 这对 Agent 很重要，因为长期身份并不能证明眼前这个容器或进程没有被替换、复制或劫持。但 SPIFFE 的 trust domain 仍由运营者管理，它不取代一个可跨组织携带的长期身份。

更合理的方向是分层协作：DID 给出可携带的长期锚点，VC 和委托表达来源与范围，SPIFFE 证明当前运行实例，OAuth/MCP 执行对具体资源的最小权限访问。DIF 的 Trusted AI Agents Working Group 正在把 identity、authority 和 governance 放在一起讨论，而不是只给 Agent 发一个编号。^[6]

这套组合也有代价。DID 方法之间的互操作、密钥轮换和恢复、凭证状态、签发者信任、复制后的 Agent 是否还是同一个主体，都没有一个标准替我们做完。人类用户觉得复杂的地方，Agent 也许能把它自动化，但自动化并不会替我们做治理决定。尤其不能让语言模型直接掌握没有边界的长期密钥和权限。

趁历史包袱还轻，把边界先画出来

ArcBlock 在 2018 年研究 DID，2019 年把它纳入核心技术栈。这并不能证明我们已经提前知道 Agent 会走到今天，更不是本文结论成立的证据。它只解释了为什么我会特别在意这件事：身份一旦被某个产品的账号体系吞掉，等到跨平台协作成为常态，再把它搬出来会非常痛苦。我们 2022 年写下过这段选择的来由。

现在的机会在于，Agent 生态还没有形成不可迁移的身份历史包袱。我们可以先把长期身份和单一模型厂商、云平台或应用商店分开，也可以先规定实际权限必须有委托、范围和收回机制。以后产品形态会变，今天的协议也会变，但这两条边界不该变。

一个平台账号能让 Agent 登录，一把 API Key 能让它调用工具，一张运行时凭证能说明当前进程来自哪里。它们都很有用，却没有哪一个单独回答“这个 Agent 在平台之外是谁，又凭什么代表谁”。DID 不是完整答案，但它给了这套问题一个可以开始验证的锚点。