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

「原文鏈接」

：