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

原文連結