作者：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 架構如下: