原文作者：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 代理活在链上！

「原文链接」