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