两个AI代理在互联网上相遇，第一件事不是握手，而是互相查身份证。这听起来像科幻片的安检桥段，但过去两周，有人真的把这套系统跑通了。
Google的AgentID和ArkForge的信任层完成整合，解决了多代理协作里最基础也最被忽视的问题：我怎么知道对方不是冒充的？
多数框架假装这个问题不存在
现在的AI代理开发，身份验证基本靠" assume good faith "——要么假设网络可信，要么甩给用户一串API密钥。但当代理开始通过注册中心、枢纽站、目录服务动态发现彼此时，这套假设瞬间崩塌。
Agent A调用Agent B发布的服务，A需要确认三件事：B的端点是否真实、B的能力是否属实、B的创建者是否可信。大部分框架只回答了第一个问题，后两个直接跳过。
Agent Card是一种JSON文档，描述代理的名称、类型、版本、能力列表、服务端点、创建者信息。它很有用，但致命缺陷是缺乏密码学验证——攻击者可以伪造一份Agent Card，声称自己是任何人。
AgentID的解决方案是给Agent Card加上数字签名。代理向A2A Hub注册时，生成密钥对，用私钥签署Agent Card，将公钥公开托管。下游用户验证时，只需核对"这份Agent Card是否由持有对应私钥的实体创建"。
但这里卡住了：你怎么知道那把公钥真的属于声称的创建者？
ArkForge填上了最后一块拼图
ArkForge的DID（去中心化标识符）框架解决了密钥归属问题。它在https://trust.arkforge.tech/.well-known/did.json发布符合W3C标准的DID文档，包含：
代理的公钥（用于验证签名）、ArkForge作为信任锚的公钥、服务发现端点、可验证凭证的发行端点。
当ArkForge为某个代理背书"此代理合法"时，下游验证者可以：用DID文档中的公钥验证ArkForge的签名、追溯代理的完整信任链、无需依赖任何中心化注册表。
这是用密码学建立的信任，不是约定俗成的惯例。
具体实现分两步。代理端创建带签名的注册请求：构造包含名称、能力、端点的代理对象，用私钥对JSON序列化后的内容签名，通过HTTP头携带身份标识、签名和DID证明，发送到注册端点。
信任层收到请求后，解析Agent ID获取公钥，验证签名有效性。失败返回403，成功则签发可验证凭证，存入不可篡改日志。
生产环境暴露的粗糙边缘
整合过程中，作者发现几个实际问题。密钥轮换没有标准方案——代理私钥泄露怎么办？DID文档更新机制尚未统一。跨域验证时，DNS劫持风险如何规避？
这些不是技术难题，是生态碎片化。每个信任层都想做自己的标准，互操作性反而成了事后补丁。
AgentID+ArkForge的组合至少证明了一件事：代理身份验证可以不走"先污染后治理"的老路。密码学基础设施就位，剩下的问题是——
当每个代理都能自证身份，我们还需要平台中介吗？
热门跟贴