当前位置：首页 > news >正文

AGI第三级，智能体需要一个新的身份认证技术

news 2024/10/23 17:06:49

前言

根据OpenAI的AGI（人工通用智能）路线图，第三级（Level 3）被定义为“智能体（Agents）”。在这个阶段，AI系统能够独立运作，执行复杂任务，并在没有持续的人类监督下适应变化的情况。这些智能体能够代表用户执行任务，进行决策，并在长时间内自主操作。

智能体之间需要相互协作共同完成人复杂的任务，未来智能体会形成一个相互协作的网络。

在上一篇文章《智能体互联网时代即将来临，我们需要新的连接技术》，智能体网络面临的一个挑战就是身份认证，今天我们来深入的探讨下这个问题，我们来一起看看智能体需要一个什么样的连接方式，需要怎么样的身份认证技术，当前行业有哪些身份认证技术，以及我们给出的方案。

人是数字世界的连接器

当前互联网和软件世界中，人是一个非常重要的角色，它即是数字世界的最终用户，又在数字世界中承担了连接器的角色。这里你可以想下，无论是在生活中，还是在工作中，你是不是一直不停的在不同的系统或软件之间来回切换？

智能体的出现，将有可能把人从数字世界中解放出来，智能体可以在没有人类监督的情况下独立运作，代表用户执行任务，进行决策。同时，数字世界连接器的角色，也将会由智能体承担。

智能体网络需要什么样的连接方式

我一直认为，AI是先进的生产力，但是当前互联网的生产关系无法完全发挥AI先进的生产力。根源还是在于当前互联网的连接方式：依托互联网巨头形成的“数据孤岛”导致信息无法自由流动（我之前有篇文章，讨论AI时代信息消费最高效的方式）。

智能体需要最开放的连接方式，就像人可以使用数字世界的任何软件，在没有人参与的情况下，智能体应该能够和任意的智能体、任意的软件进行自由协作。开放性，是发挥AI生产力的关键。

新的连接方式需要什么样的智能体身份认证技术

我认为智能体身份认证技术有几个特点：

跨平台：无论智能体使用什么技术构建，运行在那个平台，它都可以和世界上任何一个智能体进行身份认证。
低成本：身份生成、认证成本低，尽量减少或没有三方机构的参与，基于技术保证安全而非三方机构或组织。
标准化：作为未来的一个重要基础设施，它应该是一个行业标准规范，以形成最大的行业共识。

当前身份认证技术分析

主流身份认证技术

当前主流的身份认证技术，比如推特账号、苹果账号、微信账户、谷歌账户等，他们一般是中心化、平台内部的身份认证，即一个用户的身份只在一个平台或系统内部有效，无法进行跨平台的认证。比如，苹果的账户，在微信中是无法识别的。

虽然当前也有很多使用微信账户、谷歌账户登录其他平台的方法，但他们底层使用的是Oauth技术，本质上用户授权其他平台访问用户在微信、谷歌上的数据，而非身份的跨平台认证。

还有一种使用云端资源时比较常见的身份认证做法：比如我要使用云服务，我先在云服务平台申请一个api key，然后将api key放入到http请求中，发送给云服务进行身份认证。这种方案确实可以跨平台身份认证，但是过程相对繁琐，需要先去对方平台注册，然后获取api key。

email邮箱：互联网最开放的账号体系

email邮箱现有互联网体系中最开放的账号体系，用户只要有一个账户，就可以和世界上所有的邮箱进行收发邮件。这种模式是智能体通信最理想模式。

但可惜的是，邮箱协议是专门为邮箱业务设计，随着技术和需求的发展，邮箱协议也拓展出了很多标准，整体有些臃肿，并且对端到端加密支持的也不是很好。

我们可以参考邮箱账户的开放性设计，但是要针对智能体通信做深度优化。

比特币：基于区块链的最开放的账号体系

比特币等基于区块链数字货币账号应该是当前最开放的账号体系了，它完全的去中心化、完全的由用户来控制，它的安全性基于加密算法，而非机构或组织。

比特币的身份ID，也就是比特的地址有一个非常精妙的设计：比特币地址基于非对称加密公钥生成，而非对称加密公钥根据非对称加密秘钥生成。这样它们三者就是唯一的一对一关系。

这在身份验证的时候非常的有帮助：

比特地址作为身份ID，可以通过可靠渠道（微信、面对面等）传递；
只要知道了对方的比特币地址，就可以验证比特币地址对应的公钥是否正确，验证公钥的成本低。（在标准的TLS流程中，这一步需要证书颁发机构（Certificate Authority）颁发的CA证书验证。）
只要确认了对方的公钥，就可以根据数字签名验证对方是否持有正确的密钥。

至此，一个典型的身份验证过程就完成了。非常的简洁、高效。

但是这套身份ID系统也有两个硬伤：

如果私钥遗漏、丢失、泄露，身份ID将无法使用。不过这里可以通过多重签名、社交恢复等技术进行ID更新。
区块链技术受限于其扩展性，当前阶段无法承担大规模的商业应用。

W3C DID

W3C DID（Decentralized Identifiers，去中心化标识符）规范是由万维网联盟（W3C）发布的标准，旨在为去中心化身份管理提供一个全球统一的标准。DID 使得个人、组织和设备可以拥有一个独立于中心化机构的唯一标识符，确保用户对其身份的完全控制。

核心理念：

去中心化：DID 是一种不依赖于中心化的注册机构（如政府、公司等）的标识符，可以通过各种分布式账本或网络生成。
互操作性：互操作性确保不同去中心化网络、平台和实现方式之间能够无缝协作。
自我主权：DID 持有者拥有完全的控制权，不依赖第三方来管理或验证其身份。
可验证性：DID 允许关联可验证的凭证（Verifiable Credentials），这些凭证可以由其他机构或个人签发，证明某个身份的真实性。
可解析性：每个 DID 都关联着一套称为“DID文档”的元数据，记录了与该 DID 相关的公钥、服务端点等信息。这些文档可以通过不同的方式解析出来，从而进行身份验证或其他交互。

W3C DID更多的是一个标准的框架，在具体使用的时候，还需要根据自己的场景，定义具体的方法。

比如，有一个DID的web方法草案，就是定义了通过http来进行DID文档的创建、更新、查询、删除等操作。不过这个方法对于两个用户如何进行端到端加密通信并没有明确定义，架构灵活性也差。后面会有详细的分析对比。

从上面的特性可以看出，DID确实是一个非常适合智能体的一套身份方案。但它最大的缺点是，W3C DID v1.0 于 2022 年 7 月 19 日发布为推荐标准，相对来说比较年轻，暂时没有什么大规模商用的案例。再说的直白一点，是去中心化的身份技术没有直接的需求。不过，智能体的出现，正在改变这一点。

备注：W3C DID规范 https://www.w3.org/TR/did-core/

Agent Network Protocol：我们的方案

通过上面的分析，可以看到，现有的身份认证技术，对于智能体连接方式的需求来说，都或多或少有无法满足的地方。

因此，我们提出了我们的技术方案：Agent Network Protocol，一个基于W3C DID规范的跨平台身份认证和端到端加密通信技术方案。它融合了W3C DID规范、比特币相关技术、TLS技术，即定义了跨平台身份认证的详细流程，又定义了两个DID用户端到端加密通信过程。

Agent Network Protocol的核心由两部分组成：

W3C DID ALL（alliance）方法：一个基于联盟思路的DID方法。
基于DID的端到端加密通信技术：基于websocket，使用DID的公钥和私钥完成端到端加密通信协商。

W3C DID ALL（alliance）方法

现有已经定义的DID方法大部分基于区块链设计，受限于区块链技术阶段，在扩展性、商业化落地上存在非常大的问题。

我们提出了一个新的DID方法all（Alliance，联盟），类似区块链中的联盟链，即所有支持此方法标准的服务提供商，都可以对外提供DID的相关服务。DID的使用者可以根据所有服务提供商的价格、服务水平、口碑等，选择一个或多个提供服务。所有支持此方法的服务提供商可以将自己的服务域名写入到区块链一个特定内存上，以保证所有all方法的使用者能够得到完整的服务提供商列表。

在all方法中，用户可以选择优秀的供应商来托管DID文档、进行加密通信协商，同时，也可以选择自建DID基础设施，这是我们方案灵活性的有点。

all方法的操作全部使用https等标准的web协议，以让all方法能够利用已有的web基础设施。

除此之外，all方法在设计上最有创造力的点，是参考比特币地址的生成过程，使用非对称加密公钥来生成DID。

这带来的好处显而易见：只要知道对方的DID，就可以判断DID文档的完整性，进而验证对方身份，而不用关心文档托管在什么地方，托管机构是否具有安全资质。安全完全依赖密码学，而非三方机构的授权与认证。

备注：all方法设计规范： DID all方法设计规范

基于DID的端到端加密通信

基于DID，Agent Network Protocol实现了真正的端到端加密。我们参考久经行业检验的TLS1.3秘钥协商过程，使用DID的非对称加密密钥，实现了一个具备TLS1.3同等安全级别的应用层端到端加密通信方案。Agent Network Protocol在底层使用websocket协议，可以最大程度的复用现有互联网的基础设施，在应用层使用DID的非对称加密密钥代替CA证书，极大的降低了安全认证的成本，同时仍然具有同等的安全等级。

DID web方法 vs DID all方法

DIDweb方法和我们的all方法有很大的相似之处，也有不同之处，这里做个详细的对比。

相同点：

都致力于实现DID的目标：去中心化身份
都希望能够复用现有互联网基础设施，基于HTTP协议实现

不同点：

DID web方法最大的优势是，DID完全和域名绑定，即便是相关私钥泄露，也影响不大。而DID all方法，DID是和私钥绑定的，在带来便利性的同时，如果私钥泄露，这个ID将无法使用，需要设计更新流程来更新DID。
DID all方法最大的优势是架构灵活性，用户可以没有域名，自己生成DID，然后使用公开的DID文档托管服务即可，同时也可以使用自己搭建的服务。而DID web方法，则和域名绑定，创建DID文档必须要有域名，成本较高，且托管不方便。

我们当前支持的是DID all方法，后面会进一步支持DID web方法，并且all方法用户也可以和web方法用户互相认证、通信。