原文作者:CP,Artela 创始人

文章背景:基于 TEE + Eliza 的技术视角

基于我在隐私计算(TEE、PPML、区块链)领域的经验,这篇文章探讨了技术上的构建思路。

先跳过宏大叙事,直接聚焦两个我在 AI 代理使用中面临的真实困境:

1)作为 CTO,我无法将公司官方 Twitter 账号及密码交给第三方 AI 代理服务

目前,如果我想让一个 AI 代理管理我们的 Twitter 账号,我必须提供用户名、密码和 Cookies。

这意味着公司必须信任 AI 代理背后的服务器管理员。一旦这些管理员恶意操作或遭到攻击,凭据泄露可能对我们的社区造成巨大经济损失。

即使通过 OAuth 授权,我可以撤销访问权限,但在目前的设计中,我们仍面临完全失去对账户控制的风险,甚至可能无法察觉密码被更改。

2)作为一名交易员,我无法将大量资金托付给交易型 AI 代理

正如我绝不会使用 Telegram 上的中心化交易机器人,我也无法将我的私钥交给这些中心化的 AI 代理。

在这一点上,中心化部署的 AI 代理没有任何本质区别。

总结:下一阶段的加密 AI 代理不可避免地需要管理钱包、处理用户资产和敏感信息,并与链上系统更深度地交互。

因此,如何让 AI 代理在摆脱人工控制的情况下自主运行,并证明其决策完全来自 AI 流程,成为了关键挑战。

目前 TEE + Eliza 的解决方案足够了吗?

从工程角度来看,要实现其潜力还需要补充更多细节。

当前进展: Phala network 和 @NousResearch 已经打下了坚实的基础工作:

· 他们将 Eliza 容器化,封装在可运行于 TEE 的 Docker 环境中。

· 通过从 TEE 根密钥派生一个 AI 代理专用的私钥,去掉了手动配置钱包私钥的需求。

作为 AI 代理的开发者,我认为需要进一步增强以下功能,以实现信任最小化:

a) TEE Eliza 的可验证性需要增强

Eliza 在 TEE 中究竟做了什么?又没做什么?需要一种具体方式来验证。

Eliza 需要记录所有接收到的消息、响应和执行的操作,并且这些日志必须是可读且可验证的,确保其由 Eliza 生成。

因此,TEE Eliza 的第一个基础功能是可验证日志。

Eliza 应使用 TEE 内派生的密钥对日志进行签名,提供查询接口,并允许用户验证其真实性。

b) TEE Eliza 需要解决活跃性问题

运行在 TEE 中的 Eliza 持有私钥和敏感数据。但它依赖于支持 TEE 的物理机器运行。如果管理员关闭了机器,AI 代理的「生命」可能会永久终止,其管理的资产和数据也可能永远丢失。

为了解决这个问题,我们需要:

· 将 AI 代理在 TEE 中的关键「生命」数据(如角色定义、短长期记忆、密钥存储)加密。

· 将这些数据上传到区块链或 DA 网络。

当托管 AI 代理的 TEE 关闭时,另一台 TEE 机器应能下载加密数据,解密并恢复 AI 代理的「生命」,使其继续运行。

c) 额外功能:构建 TEE 工程与构建区块链一样具有挑战性

· 用户对 AI 代理的控制:

· AI 代理必须允许用户定义类似智能合约的策略,以信任最小化的方式管理资产。

· 区块链交互组件:

· 在 TEE 内运行的可信区块链客户端、数据同步器等组件,以实现与区块链系统的无缝交互。

focEliza 的当前进展:正在开发的两个基础 TEE 插件

1. plugin-tee-verifiable-log

Eliza 在 TEE 中运行时,会使用派生的密钥对其操作进行签名。这确保了所有操作都由 Eliza 执行。第三方可以通过 Eliza 的公钥远程验证这些操作。

2. plugin-tee-onchain-da

Eliza 将指定 AI 代理的「生命」数据(如角色文件、记忆、密钥存储)以接近实时的方式写入区块链或 DA 层。当运行代理的 TEE 节点关闭时,另一台 TEE 节点可以下载加密的「生命」数据,恢复代理并继续运行。

ps: 查看 focEliza 的代码

为什么我发起了 focEliza 及其背后的技术愿景?

下一个问题是,为什么选择基于 Eliza 构建?我的思考:

1. Eliza 有潜力成为加密 x AI 代理领域的 EVM。

2. 它拥有活跃的领导团队和开发者社区,合作氛围良好(@ai16zdao 和 @shawmakesmagic)。

3. focEliza 不是分叉版本;它将合并回 Eliza 主版本。

4. 高质量的开源工程是实现去中心化的关键。无权限的构建和恢复是使 AI 代理实现「永生」的核心。

我们不在这里定义它将给世界带来怎样的改变——先让它发生吧!让 AI 代理活在链上!

「原文链接」