文章背景：基于 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 代理活在链上！