搜索
基于TEE构建Eliza：安全的AI代理解决方案
基于 TEE + Eliza 的技术视角，今天咱们聊聊隐私计算那些事儿。作为 Artela 的创始人，以下是我对技术构建的思考，特别是我在 AI 代理使用中遇到的两大困境：
1）CTO 的烦恼：不想把 Twitter 密码交给 AI 代理
想让 AI 代理管理我们公司官方 Twitter？那我得把用户名、密码和 Cookies 都交出去。这样可就得完全信任 AI 背后的服务器管理员了。一旦这些人搞事情或者遭到攻击，凭据泄露可能给我们的社区带来不可估量的经济损失。
就算通过 OAuth 授权，我可以随时撤销访问权限，但在现有设计下，还是面临着彻底失去账户控制的风险，甚至连我都可能察觉不到密码被改了。
2）交易员的顾虑：不敢把钱交给交易 AI 代理
正如我绝不会把资金交给 Telegram 上的中心化交易机器人，我也绝对无法把私钥交给中心化的 AI 代理。在这一点上，这些代理和中心化的交易平台没有任何区别。
总结：未来的加密 AI 代理不可避免地要管理钱包、处理用户资产和敏感信息，与链上系统更深度交互。
因此，如何让 AI 代理在没有人工干预的情况下自主运行，并确保其决策完全来源于 AI 流程，成了一个关键挑战。
目前 TEE + Eliza 的解决方案足够吗？
从工程的角度看，要实现它的潜力还需补充更多细节。
当前进展： Phala network 和 @NousResearch ( https://x.com/NousResearch ) 已经在这方面打下了基础：
- 他们将 Eliza 容器化，封装在可运行于 TEE 的 Docker 环境中。
- 通过从 TEE 根密钥派生一个 AI 代理专用的私钥，省去了手动配置钱包私钥的麻烦。 作为 AI 代理的开发者，我觉得我们需要进一步提升以下功能，以实现更高的信任度：
✨ 增强 TEE Eliza 的可验证性
Eliza 在 TEE 中到底做了哪些事？又漏掉了什么？我们需要有明确的方法来验证这一切。
Eliza 应该记录所有接收到的信息、回复及执行的操作，并确保这些日志既可读又可验证，确认是由 Eliza 自己生成的。
因此，TEE Eliza 的基础功能之一就是可验证日志。📝
Eliza 应利用 TEE 内派生的密钥对日志进行签名，提供查询接口，方便用户验证其真实性。
🔒 解决 TEE Eliza 的活跃性问题
Eliza 在 TEE 中持有私钥和敏感数据，但它依赖于支持 TEE 的物理机器。如果管理员关闭了机器，这个 AI 代理的「生命」可能就此终结，管理的资产和数据也可能随之消失。
要解决这个问题，我们需要：
- 将 AI 代理在 TEE 中的重要「生命」数据（例如角色定义、短期和长期记忆、密钥存储）进行加密。
- 将这些数据上传到区块链或去中心化网络。
一旦托管 AI 代理的 TEE 关闭，另一台 TEE 机器应能下载加密数据，解密并恢复 AI 代理的「生命」，让它继续运作。
⚙️ 额外功能：构建 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 节点可以下载这些加密的「生命」数据，轻松恢复代理并继续它的旅程，真是太酷了！
为什么我会发起 focEliza 及其背后的技术愿景呢？
那我为什么选择基于 Eliza 来构建呢？这里有几点：
-
Eliza 有潜力成为加密与 AI 代理领域的 EVM，未来可期🌟。
-
它背后有一个活跃的领导团队和开发者社区，合作气氛非常不错（ @ai16zdao 和 @shawmakesmagic 💬）。
-
focEliza 不是分叉版本，而是会合并回 Eliza 的主版本。
-
高质量的开源工程是实现去中心化的关键。无权限的构建与恢复，正是让 AI 代理实现「永生」的核心。
我们不打算在这里定义它将如何改变世界——先让它发生吧！让 AI 代理在链上活起来！🚀
