作者：0xhhh 來源：X，@hhh69251498
Eliza 原理介紹這個系列會分成三部分來寫:
Provider 和 Action 的運行原理
Evaluator 的運行原理
Eliza Memory 的設(shè)計思想
當(dāng)前是第一篇文章主要介紹：Provider 和 Action 的運行原理
最上層抽象成了 Provider 和 Evaluator 以及 Action ，分別對應(yīng)人類獲取信息的能力 ( 眼睛獲取視覺信息，耳朵獲取聽覺信息等等 )，以及人類根據(jù)信息的執(zhí)行能力 ( 比如通過市場信息判斷 BTC 未來還有 )，還有 Evaluator 只類似人類的思考能力，通過思考從海量的信息中提取知識從而形成個人的認(rèn)知。
最下層是不同的 AI Model:目前 Eliza 框架支持了市面上大多數(shù)的 AI Model，比如 openai, claude, gemini, gork, xai 等等，這個類似人類的大腦是所有做出決策的關(guān)鍵處理模塊。
memory 則是讓通過 Eliza 框架啟動的 Ai Agent 擁有跳出 Content Limitation 限制的能力，因為 AI 既可以在 Provider 階段把從環(huán)境中獲取的信息和 Action 執(zhí)行后結(jié)果的信息壓縮之后存儲進入 Memory 之中；并且也可以通過 Evaluator 提取跟人類對話或者其他任意交互過程中一些關(guān)鍵信息 ( 這個會在下一個 Thread 里詳細(xì)介紹 )
對于 Provider 我們需要思考三個問題：
Why need Provider(Eliza 框架為什么要設(shè)計 Provider 這個組件 )?
AI 如何理解 Provider 提供的信息？
How to invoke Provider(Eliza 框架內(nèi) AI 如何通過 Provider 獲取信息 )?
Why need Provider?
Provider 主要用來解決在一些信息我們通過 prompt 讓 AI 獲取不準(zhǔn)確也不夠全面的問題，因為我們現(xiàn)在使用的模型都是通用大模型，所以對特定領(lǐng)域的信息獲取有時候會存在不夠全面的問題。
比如下面的代碼就是 Eliza 中 TokenProvider 的實現(xiàn)，它最終會通過我們提供的 Api 去拿到一個 Token 在鏈上多個緯度的關(guān)鍵信息，比如這個代幣前十個 Holder 是誰每個人占據(jù)了多少份額的代幣，這個代幣 24h 的價格變化等等信息并且最終會用文本的方式返回給 AI Model，這樣一來 AI Model 就可以根據(jù)這些信息來作做出一些是否購買 meme token 的關(guān)鍵決策了。
但是如果我們直接通過 Prompt 告訴 AI 幫我獲取對應(yīng)的這些信息，你會發(fā)現(xiàn) AI 會提供給我們對應(yīng)的代碼 ( 并且有些時候 AI 提供的代碼不一定能跑出來還需要把對應(yīng)代碼運行產(chǎn)生的錯誤提交給 AI 最終才能讓代碼順暢運行 )，但是我們還是需要將其部署到區(qū)塊鏈環(huán)境（同時我們也需要提供可靠的 API-KEY).
比如下面的例子:
所以為了保證獲取數(shù)據(jù)的順暢性，在 Eliza 的框架里會這部分獲取數(shù)據(jù)的代碼封裝到 Provider 的定義下，這樣以來我們就能很方便的獲取任意賬戶內(nèi)在 solona 上的資產(chǎn)信息了，因此這是 Why need Provider 的核心原因.
AI 如何理解 Provider 提供的信息？
Eliza 框架通過 Provider 拿到的信息最終會用文本 ( 自然語言 ) 的形式來返回給 AI Model，因為 AI Model 對請求信息的格式要求就是自然語言。
How to invoke Provider(Eliza 框架內(nèi) AI 如何通過 Provider 獲取信息 )?
目前 Eliza 框架內(nèi)對于 Provider，雖然有提供對應(yīng)的接口抽象，但是目前 Provider 的調(diào)用方式并不是模塊化的，還是有特定的 Action 根據(jù)自己的信息需求直接調(diào)用對應(yīng)的 Provider 進行獲取，關(guān)系圖如下:
假設(shè)我們有一個 BuyToken Action 當(dāng)他在判斷自己是否應(yīng)該根據(jù)人類的推薦購買一個 Token 時，他就會在執(zhí)行這個 Action 過程中請求 TokenProvider 和 WalletProvider 提供信息，TokenProvider 會提供信息輔助 AI Agent 判斷這個 Token 值不值得買，Wallet Provider 會提供私鑰信息用于交易簽名，同時也提供該錢包可用資產(chǎn)的信息。
可以在以下 Github 鏈接很方便的找到 Action 的定義，但是你如果沒有深入看代碼你很難理解：
Why need Action？（Eliza 框架為什么需要 Action）
How to Invoke Action？(Eliza 框架如何讓 AI 調(diào)用 Action)
Eliza 框架 Action 具體執(zhí)行了什么？
怎么讓 AGI 理解他剛剛調(diào)用的 Action 做了什么 ？
Why Need Action? (Eliza 框架為什么需要抽象出 Action?)
假如我跟 AI 說: 我的私鑰
0xajahdjksadhsadnjksajkdlad12612
這里面有 10 個 sol，你能不能幫我買 100 個 Ai16z 的代幣。
Claude 的回復(fù)如下：
很明顯通過這樣給予私鑰的操作并不安全，同時 AGI 也很難執(zhí)行這種鏈上操作。
這里我們可以進一步問 AGI: 你能不能給我們實現(xiàn)相應(yīng)的執(zhí)行代碼：當(dāng)我們錢包中有 Sol 的時候，我希望可以把錢包里的所有 sol 都買成我指定的 meme 代幣。
Claude 當(dāng)然有這個能力，但是還是需要我們多次引導(dǎo)，才最終可以得到讓我們滿意的代碼。
因此我們可以把 AI 給予的代碼封裝成 Eliza 的一個 Action,并且給一些 Prompt 的 Example，來幫助 AI 理解什么時候我該調(diào)用這個 Action。
（而且在真實的使用場景里我們想做的操作比這個要復(fù)雜很多，比如一筆 Swap 交易我們希望有滑點限制，那么這些條件限制交給 AI 大模型去完成的時候我們其實很難保證執(zhí)行過程后每一個要素都可以滿足我們的要求）。
How to Invoke Action？(Eliza 框架如何讓 AI 調(diào)用 Action)
下面就是 Eliza 框架中，一個在用來讓 AI Model 在 Pumpfun 中創(chuàng)建一個 meme 代幣并且買入一定價值的該 meme 代幣的 Prompt Example,當(dāng)我們在對應(yīng)的 Action 中給出這些 Example 之后，AI Agent 就知道,之后跟人類的交互過程中出現(xiàn)類似的內(nèi)容的時候就會因為我們提供的這類 Promt Exapmle 知道要調(diào)用執(zhí)行哪個 Action。
但是 Eliza 框架是同時支持多個 Action 的，因為也提供了以下的 HandlerMessageTemplate 來讓 AI Model 會選擇合適的 Action 進行調(diào)用。
事實上，這個 Template 對所有的數(shù)據(jù)進行了重排，把數(shù)據(jù)更有邏輯的提供給了 AI Model，從而讓 AI Model 可以做出更準(zhǔn)確的調(diào)用這些預(yù)定義好的 Action.（這也是我們直接使用 AI Model 客戶端比較難做到的）
Eliza 框架 Action 具體執(zhí)行了什么？
https://github.com/elizaOS/eliza/blob/main/packages/plugin-solana/src/actions/pumpfun.ts#L279
具體還是以 Pumpfun Action 的這個例子來解釋，它的流程如下：
從 WalletProvider 和 TokenProvider 獲取信息
生成創(chuàng)建 MemeToken 以及購買 MemeToken 的交易
對交易進行簽名并發(fā)送到鏈上
調(diào)用 callback 函數(shù)對 Action 執(zhí)行后的結(jié)果進行處理。
其實核心就是兩部分，一部分就是從 Provider 獲取信息，然后生成要執(zhí)行動作的操作函數(shù)。
怎么讓 AGI 理解它調(diào)用的 Action 做了什么 ？
這個問題如果沒有解決,那么我們就無法讓 AI 理解并執(zhí)行有關(guān)聯(lián)性的任務(wù)。
答案如下：我們執(zhí)行 Action 之后會用文本來總結(jié)這個動作產(chǎn)生了什么結(jié)果，并且把這個結(jié)果加入到 AI 的 memory 之中。
細(xì)節(jié)如下：Action 的 Handle 函數(shù)第四個參數(shù)是一個 callback 函數(shù)，我們會把 callback 函數(shù)定義成把執(zhí)行結(jié)果加入到 AI Model 的 Memory 模塊中。
callback 函數(shù)的定義如下:
完整的 Eliza 的 Action 和 Provider 架構(gòu)如下:
喜來順財經(jīng)
