技術解讀Eliza 工作原理：Provider 和Action

作者：0xhhh 來源：X，@hhh69251498

Eliza 原理介紹這個系列會分成三個部分來寫:

1. Provider 和Action 的運作原理

2. Evaluator 的運作原理

3. Eliza Memory 的設計思想

目前是第一篇文章主要介紹：Provider 和Action 的運作原理

1. Eliza 的架構如下，主要分為3 個部分

• 最上層抽象成了Provider 和Evaluator 以及Action ，分別對應人類獲取信息的能力( 眼睛獲取視覺信息，耳朵獲取聽覺信息等等)，以及人類根據信息的執行能力( 比如通過市場信息判斷BTC 未來還有) ，還有Evaluator 只類似人類的思考能力，透過思考從海量的信息中提取知識從而形成個人的認知。

• 最下層是不同的AI Model:目前Eliza 框架支援了市面上大多數的AI Model，例如openai, claude, gemini, gork, xai 等等，這個類似人類的大腦是所有做出決策的關鍵處理模組。

• memory 則是讓透過Eliza 框架啟動的Ai Agent 擁有跳出Content Limitation 限制的能力，因為AI 既可以在Provider 階段把從環境中獲取的信息和Action 執行後結果的信息壓縮之後存儲進入Memory 之中；並且也可以透過Evaluator 擷取跟人類對話或其他任意互動過程中一些關鍵資訊( 這會在下一個Thread 裡詳細介紹 )

2. 在接下來的部分我們將詳細介紹「Provider」 和「Action」的運作原理

「Provider」

對於Provider 我們需要思考三個問題：

1. Why need Provider(Eliza 框架為什麼要設計Provider 這個元件)?

2. AI 如何理解Provider 提供的資訊？

3. How to invoke Provider(Eliza 框架內AI 如何透過Provider 取得資訊)?

Why need Provider?

Provider 主要用來解決在一些資訊我們透過prompt 讓AI 取得不準確也不夠全面的問題，因為我們現在使用的模型都是通用大模型，所以對特定領域的資訊取得有時會存在不夠全面的問題。

例如下面的程式碼就是Eliza 中TokenProvider 的實現，它最終會透過我們提供的Api 去拿到一個Token 在鏈上多個緯度的關鍵信息，比如這個代幣前十個Holder 是誰每個人佔據了多少份額的代幣，這個代幣24h 的價格變化等等信息並且最終會用文本的方式返回給AI Model，這樣一來AI Model 就可以根據這些信息來作做出一些是否購買meme token 的關鍵決策了。

但是如果我們直接透過Prompt 告訴AI 幫我獲取對應的這些信息，你會發現AI 會提供給我們對應的代碼( 並且有些時候AI 提供的代碼不一定能跑出來還需要把對應代碼運行產生的錯誤提交給AI 最終才能讓程式碼順暢運行)，但是我們還是需要將其部署到區塊鏈環境（同時我們也需要提供可靠的API-KEY).

比如下面的例子:

所以為了確保獲取資料的順暢性，在Eliza 的框架裡會這部分獲取資料的程式碼封裝到Provider 的定義下，這樣以來我們就能很方便的獲取任意帳戶內在solona 上的資產資訊了，因此這是Why need Provider 的核心原因.

AI 如何理解Provider 提供的資訊？

Eliza 框架透過Provider 拿到的資訊最終會用文字( 自然語言) 的形式來傳回給AI Model，因為AI Model 對請求資訊的格式要求就是自然語言。

How to invoke Provider(Eliza 框架內AI 如何透過Provider 取得資訊)?

目前Eliza 框架內對於Provider，雖然有提供對應的介面抽象，但是目前Provider 的呼叫方式並不是模組化的，還是有特定的Action 根據自己的資訊需求直接呼叫對應的Provider 進行獲取，關係圖如下:

假設我們有一個BuyToken Action 當他在判斷自己是否應該根據人類的推薦購買一個Token 時，他就會在執行這個Action 過程中請求TokenProvider 和WalletProvider 提供信息，TokenProvider 會提供信息輔助AI Agent 判斷這個Token 值不值得買，Wallet Provider 會提供私鑰資訊用於交易簽名，同時也提供該錢包可用資產的資訊。

「Action」

可以在以下Github 連結很方便的找到Action 的定義，但如果沒有深入看程式碼你很難理解：

1. Why need Action？ （Eliza 框架為什麼需要Action）

2. How to Invoke Action？ (Eliza 框架如何讓AI 呼叫Action)

3. Eliza 框架Action 具體執行了什麼？

4. 怎麼讓AGI 理解他剛剛呼叫的Action 做了什麼？

Why Need Action? (Eliza 框架為何需要抽像出Action?)

假如我跟AI 說: 我的私鑰

0xajahdjksadhsadnjksajkdlad12612

這裡面有10 個sol，你能不能幫我買100 個Ai16z 的代幣。

Claude 的回覆如下：

很明顯地透過這樣給予私鑰的操作並不安全，同時AGI 也很難執行這種鏈上操作。

這裡我們可以進一步問AGI: 你能不能給我們實現相應的執行代碼：當我們錢包中有Sol 的時候，我希望可以把錢包裡的所有sol 都買成我指定的meme 代幣。

Claude 當然有這個能力，但還是需要我們多次引導，才最終可以得到讓我們滿意的程式碼。

因此我們可以把AI 給予的程式碼封裝成Eliza 的一個Action,並且給一些Prompt 的Example，來幫助AI 理解什麼時候我該呼叫這個Action。

（而且在真實的使用場景裡我們想做的操作比這個要複雜很多，比如一筆Swap 交易我們希望有滑點限制，那麼這些條件限制交給AI 大模型去完成的時候我們其實很難保證執行過程後每一個要素都可以滿足我們的要求）。

How to Invoke Action？ (Eliza 框架如何讓AI 呼叫Action)

下面就是Eliza 框架中，一個在用來讓AI Model 在Pumpfun 中創建一個meme 代幣並且買入一定價值的該meme 代幣的Prompt Example,當我們在對應的Action 中給出這些Example 之後，AI Agent就知道,之後跟人類的互動過程中出現類似的內容的時候就會因為我們提供的這類Promt Exapmle 知道要呼叫執行哪個Action。

但Eliza 框架是同時支援多個Action 的，因為也提供了以下的HandlerMessageTemplate 讓AI Model 選擇適當的Action 來呼叫。

事實上，這個Template 對所有的數據進行了重排，把數據更有邏輯的提供給了AI Model，從而讓AI Model 可以做出更準確的調用這些預定義好的Action.（這也是我們直接使用AI Model 客戶端比較難做到的）

Eliza 框架Action 具體執行了什麼？

https://github.com/elizaOS/eliza/blob/main/packages/plugin-solana/src/actions/pumpfun.ts#L279

具體還是以Pumpfun Action 的這個例子來解釋，它的流程如下：

1. 從WalletProvider 和TokenProvider 獲取信息

2. 產生創建MemeToken 以及購買MemeToken 的交易

3. 將交易進行簽名並發送到鏈上

4. 呼叫callback 函數對Action 執行後的結果進行處理。

其實核心就是兩個部分，一部分就是從Provider 獲取訊息，然後產生要執行動作的操作函數。

怎麼讓AGI 理解它所呼叫的Action 做了什麼？

這個問題如果沒有解決,那麼我們就無法讓AI 理解並執行有關聯性的任務。

答案如下：我們執行Action 之後會用文字來總結這個動作產生了什麼結果，並且把這個結果加入到AI 的memory 之中。

細節如下：Action 的Handle 函數第四個參數是一個callback 函數，我們會把callback 函數定義成把執行結果加入AI Model 的Memory 模組。

callback 函數的定義如下:

完整的Eliza 的Action 和Provider 架構如下: